-
Bug
-
Resolution: Fixed
-
Blocker
-
2.1, 2.3.8, 2.4.5, 2.5.1
-
MOODLE_21_STABLE, MOODLE_23_STABLE, MOODLE_24_STABLE, MOODLE_25_STABLE
-
MOODLE_26_STABLE
-
w37_
MDL-28094_m26_subdirs -
Synopsis
========
The HTML editor has an option called 'subdirs' where the developer declares whether embedded images can be put into subdirectories or not. This works well for the content created from scratch in 2.0 and higher.
However, when restoring a 1.9 course backup, the referenced images in HTML text fields are converted into embedded images, using the original path within legacy course_files. If such fields is then edited with 'subdirs' off, the files in subdirectories are thrown away.
How to reproduce
================
1. Define a course-level outcome in 1.9 and embed some image in its description, for example
/images/icon.gif
2. Backup the course and restore it in 2.1
3. The referenced <img> will be converted into embedded image pluginfile.php/1/grade/outcome/2/images/icon.gif where "1" is the syscontextid and "2" is the outcome id
4. Try to edit the description
Expected behaviour
==================
The image should be displayed and be editable (this works well for example in mod_page content field)
What actually happens
=====================
The image is not displayed. This is because the editor defined in grade/edit/outcome/edit.php does not declare support for subdirs.
This should be easy to reproduce for all HTML fields that do not support subdirs.
Alternative solutions
=====================
1. Hack the moodle1 converter so that it generates unique filenames for embedded images and puts them all into the root foolder of the given file area. This would lead to a pretty cryptic filenames like the path hashes - for example f00af045f3fe6e4955f2647c20295d2cd1e0c183.gif - because we need to move all files from the tree into one root directory, keeping the path unique
2. Drop the 'subdirs' support, forcing 'true' everywhere. This would not hurt as we do not have UI for directories in the embedded image picker
3. Change the meaning of the 'subdirs' option so that it influences just the UI (if the support for it will be implemented one day) and not the functionality. In other words, if 'subdirs' is off, the user would not have UI elements to create new subdirs. But if there are some subdirs already created, the user would be able to pick files from them normally.
My personal vote is for 2. as I do not see much point of forcing the one folder only.