|
[
Permalink
| « Hide
]
Martin Dougiamas added a comment - 05/Dec/07 10:42 AM
Yu, can you take a look at this next? The whole preset code is dodgy, so any cleaning up and testing you can do in here would be great (and also help the GHOP students too)
Can you also post the resolution on http://code.google.com/p/google-highly-open-participation-moodle/issues/detail?id=54
 please? Hi Yu,
Thanks for your patch. The database preset import works perfectly for me now Does this need testing in Moodle 1.8 too before resolving the issue? I am sorry, but this issue needs to be reopend.
In the latest Moodle 1.8.4 the templates are not imported. I tried the same preset zip in 1.8.4 and in 1.9. In 1.9 all is ok, 1.8.4 does not import the templates, only the fields. This might have been fixed since the report. I can sucessfully import a preset, like the one given on http://moodle.org/mod/forum/discuss.php?d=84050#p371801
by Martin.
If this one works but another one doesn't, can you send it to me? Confirmed that importing (as well as exporting) a preview.zip still does NOT work in the latest Moodle 1.8.4+, which uses moodle/mod/data/preset.php v1.20.2.4 from Dec 6, 2007.
The content of all templates will be ignored, in both importing and exporting! Only the fields will be taken care of. you can try for example with the "official" preset for Moodle Buzz, posted by Martin at http://moodle.org/mod/forum/discuss.php?d=84050&parent=371801 Reopening following Robert's comment.
To make it more clear what works and what doesn't on 1.8.4+:
If you create a fresh new DB and then immediately import the Buzz preset.zip, all works fine so far. So testing it up to here is not enough. Because: after you edit content from the "Add template" sub page of the "Templates" tab, save it (by clicking on "Save template") and then try to use "Save as preset" and "Use a preset" from the "Presets" tab, the export/import will start to ignore the modified and saved templates. All the problems with preset.zip observed in Moodle 1.8.4+ are gone with 1.9+, so a solution would be to just go with the 1.9 Moodle. It's probably not worth to struggle around with the database module's preset functionality in Moodle 1.8 too much, since it works fine in 1.9.
I have now intensively tested the "preset.zip" import and export ability with Moodle 1.9+. Things that did not even work in 1.8.4+ work in 1.9, but unfortunately, there are still many bugs:
After creating the fields within the web interface, exporting the resulting "preset.zip" works fine. However, re-importing it does not work properly when the "preset.xml" file contains certain characters within the tags, such as a single-quote (' char). For example: Does NOT work: Does work: Next problem: <field> will be converted to Tip for first issue: Quotes read from XML and importing failing = Missing addslashes() somewhere.
Tip for 2nd one: IMO, separing choices with linefeed is 100% incorrect. So I'd propose to: a) Make code able to read linefeeds for backwards compatibility when importing menus Thanks for the tips, Eloy.Unfortunately, I need a quick fix for that to work now...
My workaround for the first bug was to rename all description text so that they no more contain any characters ' or ´ I still need a workaround for the second bug. I totally agree on your proposal - the current way of separating more options is anything but not XML I have now found and fixed the bug which prevented to import a "preset.xml" containing menu or multimenu field types. The problem was related to "moodle/ib/xmlize.php" which incorrectly documents that xmlize($data, $WHITE, $encoding) defaults to $WHITE=0 if not specified. In fact, it defaults to 1.
"moodle/mod/data/lib.php" uses just xmlize($data), so $WHITE should be set to zero, but in fact gets one, which strips the newlines. My fix explicitly calls xmlize() with setting $WHITE to 0, which keeps the newlines Wow, $WHITE=1 sets XML_OPTION_SKIP_WHITE parser option. And that option AFAIK only is used to ignore XML nodes which contents are, COMPLETELY whitespace chars (space, linefeeds, tabs).
But it should affect to the <param1> tag above at all. It isn't formed exclusively by whitespace chars. Has other contents. So the XML_OPTION_SKIP_WHITE won't make any difference. I've done this quick test with the contents above, using both possibilities... and in both cases, the menu elements are linefeed-separated. Differences are only in whitespace-only contents. <?php include_once('config.php'); $data='<field> traverse_xmlize(xmlize($data,0)); ?> Uhm... sure it's an explanation for this (different linefeed/return chars?), but not sure if the $WHITE value is the correct one... although you say it worked for you... uhm... we need proper XML ASAP (export/import) although fixing linefeeeds and maintaining them for backwards compatibility (import only). Ciao Yes this seems strange but nevertheless it works
 I spent hours in an in-deep code look -through to find out the step where the newlines got stripped. And this was $parsedxml = xmlize($presetxml) within "moodle/mod/data/lib.php". So I took a closer look at the xmlize() function which is defined in "moodle/ib/xmlize.php" and first found that is has two optional parameters - $WHITE and $encoding., but the documentation of the default $WHITE value is WRONG. So I just set the parameter to the value it should be according to the documentation, tried a preset.zip import once again and - bingo - worked for the first time with menu fields.
You could easily try it yourself within a latest 1.9+ Moodle installation: Create a new database activity within a course, then immediately go to the Presets tab and import "buzz-db-preset.zip" (provided by Martin at the link given above). After the import has been successfully, go to the Fields tab, click on the Field type icon next to the Field name "Format" and you will see only one option - "htmldocpdfimageaudio/video". Then to the same again after patching "moodle/mod/data/lib.php". The result will then be correct - having several options I think this little but effective patch does not harm, it just calls xmlize() with its defaults according to its documentation. It's a workaround that works now. So I don't see a reason to not commit the patch. I'm running into the same problem the Urs encountered where the database preset is not importing templates, but it is importing the fields. if I try to import the buzz preset referenced above (with debugging set to all) I get the following error:
Notice: Array to string conversion in C:\Program Files\Apache Group\Apache2\htdocs\Moodle\moodle19\lib\datalib.php on line 28 It seems that the notification field requires an integer value and will not accept a Null value (like the one being passed). This causes the import to fail (but it actually displays a message saying that the preset was applied successfully) I've attached a screenshot of the error. Environment: Screenshot of Import error
Please, can we use different bugs to track all these errors. Sumarizing... we have:
1) 2) 3) 4) And that's all... am I missing anything? Do you agree on 1-4 ? TIA and ciao Eloy, agreed in all 1-4. This bug can be closed and we should continue discussing the others at the appropriate places.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Bug
Closed
Critical
Templates not imported in database preset import
In which source file should I look for a quick bugfix? |
|
