Test required for two new plugins: tinymce_managefiles and repository_areafiles.

Test 1. Basic editor

Open any form with empty texteditor (HTML edtor using TinyMCE)

Add images, upload files to link to.

Check that you can pick those files again using repository "Embedded files"

Check that you can manage those files using "Manage files" button in TinyMCE

Try replacing, removing, renaming files, adding new there.

Make sure error is displayed when file is missing

Delete links to the embedded files

Open "Manage files" window, make sure it offers to delete the files as well

Make sure the form is saved with all files, files are displayed in view mode and text can be edited again

Test 2. Textareas with supported subdirs:
editors in all classes extending question_edit_form support subfolders. They are not used now but may contain files in subfolders after the upgrade from ancient versions of Moodle.

Create quesiton

Enter some text, embed files

Open "Manage files" and create subfolders, place files in them

Make sure you can link to those files using "Embedded files" repository

Make sure form can be saved, files are properly displayed, text can be edited again.

Test required for two new plugins: tinymce_managefiles and repository_areafiles.
Test 1. Basic editor
Open any form with empty texteditor (HTML edtor using TinyMCE)
Add images, upload files to link to.
Check that you can pick those files again using repository "Embedded files"
Check that you can manage those files using "Manage files" button in TinyMCE
Try replacing, removing, renaming files, adding new there.
Make sure error is displayed when file is missing
Delete links to the embedded files
Open "Manage files" window, make sure it offers to delete the files as well
Make sure the form is saved with all files, files are displayed in view mode and text can be edited again
Test 2. Textareas with supported subdirs:
editors in all classes extending question_edit_form support subfolders. They are not used now but may contain files in subfolders after the upgrade from ancient versions of Moodle.
Create quesiton
Enter some text, embed files
Open "Manage files" and create subfolders, place files in them
Make sure you can link to those files using "Embedded files" repository
Make sure form can be saved, files are properly displayed, text can be edited again.
Try placing extra files in subfolders or removing used files
Make sure all warnings/information appear in "Manage files" form.

Description

User are not able to:
1/ delete "uploaded" file
2/ user can not find out what files were already uploaded
3/ users can not link again already existing image

The reason is that there is no way to manage the files that are uploaded to the file area referenced from the text in tinymce editor. Attempts to work around this missing feature (overriding of files, link from forms, etc.) were only creating regressions.

Possible solution - add a new tab "Used files" to the file picker, this would solve all 3 issues above. I have proposed several different solutions before, but I think this is the best one.

Please note that this feature is not implemented because Martin decided that users do not need to delete, rename or manage any files used in file areas attached to text editors. I personally disagree because I myself need a way to manage files used in book chapters, resource pages, etc.

Petr Skoda
added a comment - 09/Oct/11 9:49 PM Please note that this feature is not implemented because Martin decided that users do not need to delete, rename or manage any files used in file areas attached to text editors. I personally disagree because I myself need a way to manage files used in book chapters, resource pages, etc.

Julian Ridden
added a comment - 12/Oct/11 7:04 AM +1 with Petr. I have also heard similar phrased requests from a couple of clients now. I am urging them all to come and vote on this issue to raise its priority.

I have an issue within one of my moodle sites where files that are uploaded via the picker, and cannot be deleted create a bloated backup... Do you have a workaround for files that do not remove with the cron after the resource is deleted?

Brent Lee
added a comment - 09/Nov/11 12:38 AM I have an issue within one of my moodle sites where files that are uploaded via the picker, and cannot be deleted create a bloated backup... Do you have a workaround for files that do not remove with the cron after the resource is deleted?

This functionality is very important for our migration to Moodle. I've just started using Moodle but from what I can see, there seems to be no way to reference relative paths within xml files. I have flash files that load in xml data files, which then use relative paths to reference the locations of images and sound files.

Unless I am mistaken, there is no way to do this without being able to see and references files I have uploaded

Simon Hudson
added a comment - 23/Nov/11 4:32 PM This functionality is very important for our migration to Moodle. I've just started using Moodle but from what I can see, there seems to be no way to reference relative paths within xml files. I have flash files that load in xml data files, which then use relative paths to reference the locations of images and sound files.
Unless I am mistaken, there is no way to do this without being able to see and references files I have uploaded

Paul Ganderton
added a comment - 02/Dec/11 9:28 AM Just adding my 2c from an NSW, Australian perspective. Lots on our social mdeia about the upgrade to 2.x.x and this issue is being raised. It's keeping people at 1.9.x at the moment.

I agree as well. We are in the process of preparing to move from 1.9 to 2.2, but a lot of our content is housed using the book tool and we have to have a way to manage and maintain those files. I hope this gets fixed soon.

Joe Pollard
added a comment - 13/Dec/11 8:54 PM I agree as well. We are in the process of preparing to move from 1.9 to 2.2, but a lot of our content is housed using the book tool and we have to have a way to manage and maintain those files. I hope this gets fixed soon.

As a user with admin rights, I can see the files that are not pruned despite repeated days & weeks cron jobs & being deleted from front end of course as "actively used" files. This will only lead to ballooning of courses. We need to be able to permanently delete files at the teacher user level without a huge song and dance routine at upper admin levels. Been dealing with this issue since August 2010.We need to have more manageable file control at the teacher user level that isn't cosmetic--but actually does what users are expecting on the back end. I don't think there are as many reports as should be here, because really, only a person with admin rights can see what's really going on in the back end right now. We're the canaries in the Moodle 2.x coal mine. Listen to us chirp!
Newer admins are likely unaware of this issue--but it will loom large as files accrue with out deletion in their instances.

Julia Hengstler
added a comment - 17/Jan/12 6:08 AM As a user with admin rights, I can see the files that are not pruned despite repeated days & weeks cron jobs & being deleted from front end of course as "actively used" files. This will only lead to ballooning of courses. We need to be able to permanently delete files at the teacher user level without a huge song and dance routine at upper admin levels. Been dealing with this issue since August 2010.We need to have more manageable file control at the teacher user level that isn't cosmetic--but actually does what users are expecting on the back end. I don't think there are as many reports as should be here, because really, only a person with admin rights can see what's really going on in the back end right now. We're the canaries in the Moodle 2.x coal mine. Listen to us chirp!
Newer admins are likely unaware of this issue--but it will loom large as files accrue with out deletion in their instances.

I also think this should be possible. For example, a teacher submited a huge video, by mistake, to a Book resource... now it coccupies a lot of space and the user has no way to delete this unneccessary file. Why?
The solution should implement a way to detect if the file is in use elsewhere...

Pedro Crispim
added a comment - 24/Feb/12 2:43 AM I also think this should be possible. For example, a teacher submited a huge video, by mistake, to a Book resource... now it coccupies a lot of space and the user has no way to delete this unneccessary file. Why?
The solution should implement a way to detect if the file is in use elsewhere...

As an instructor with a good working knowledge of HTML, CSS, and some JavaScript, I find the 2.* file setup unbearable. I don't know if it's Moodle or Moodlerooms at fault, but the MCE editor goes blank or offers only HTML, and I have to use time-consuming workarounds (that don't always work) just to get a a URL for a link if I want to change a file or update broken links (links now break spontaneously, going to brokenlink.php for no good reason as well as when a course is backed up and restored). I would like to be able to see the structure of my files. The new setup was supposed to be more efficient, ensuring that files were not duplicated on a course site--that is how it was before 2.*. The thinking behind the new setup is completely out of touch with user needs. It may be better on the back end, but on the user side it's a giant step backwards.

Mary Pringle
added a comment - 22/Apr/12 1:22 AM As an instructor with a good working knowledge of HTML, CSS, and some JavaScript, I find the 2.* file setup unbearable. I don't know if it's Moodle or Moodlerooms at fault, but the MCE editor goes blank or offers only HTML, and I have to use time-consuming workarounds (that don't always work) just to get a a URL for a link if I want to change a file or update broken links (links now break spontaneously, going to brokenlink.php for no good reason as well as when a course is backed up and restored). I would like to be able to see the structure of my files. The new setup was supposed to be more efficient, ensuring that files were not duplicated on a course site--that is how it was before 2.*. The thinking behind the new setup is completely out of touch with user needs. It may be better on the back end, but on the user side it's a giant step backwards.

This is crucial for less technical staff who may have uploaded large images without resizing. I know they could be trained to always resize and manage images before use but that's not a realistic prospect.

steve baxter
added a comment - 25/Apr/12 9:17 PM This is crucial for less technical staff who may have uploaded large images without resizing. I know they could be trained to always resize and manage images before use but that's not a realistic prospect.

Browsing some tracker's issues, it appears to me that MDL-33884 is a clear illustration why this is urgently needed and I think we will see more and more cases like this one : Moodle sites with so many files attached to an HTML field in a question that it can no more been exported !! Something must be done to solve this issue, either a proper file management or an automatic garbage collection of files that are no more used in HTML fields. Just my two cents ...

Jean-Michel Vedrine
added a comment - 13/Jul/12 11:22 PM Browsing some tracker's issues, it appears to me that MDL-33884 is a clear illustration why this is urgently needed and I think we will see more and more cases like this one : Moodle sites with so many files attached to an HTML field in a question that it can no more been exported !! Something must be done to solve this issue, either a proper file management or an automatic garbage collection of files that are no more used in HTML fields. Just my two cents ...

Jago Brown
added a comment - 16/Jul/12 6:31 PM My college has used the book as a Scheme of Work for some courses where each chapter is a week or topic so files integration would i'm sure be welcomed by teachers.

Yes this issue is going to bite me hard in about 3-6 months when the teaching staff here want to reorganise and delete resources with M2.x. I Delayed upgrading from 1.9.x for as long as I could as my way of expressing this filesystem is/was: "deal breaker". It is at best challenging. I moved our moodle to mymoodle/moodle and crudely stuck a few sub directories in mymoodle/ for placing a few bits of web stuff there that needs a real address rather than an abstracted addressing means. Frog must be licking their lips: not all Schools have the ability to pay a full time or get specialist support. Moodle conversion 1.9.x to 2.2 was definitely not part-timer stuff. Additional issues like this make even full time technical staff look incompetent: "you just cannot delete it" is not an answer to be given when you could before especially if it does not go automatically.
Anyone found a work around by changing permissions assigned to teacher role?

Richard Price
added a comment - 17/Sep/12 4:16 PM Yes this issue is going to bite me hard in about 3-6 months when the teaching staff here want to reorganise and delete resources with M2.x. I Delayed upgrading from 1.9.x for as long as I could as my way of expressing this filesystem is/was: "deal breaker". It is at best challenging. I moved our moodle to mymoodle/moodle and crudely stuck a few sub directories in mymoodle/ for placing a few bits of web stuff there that needs a real address rather than an abstracted addressing means. Frog must be licking their lips: not all Schools have the ability to pay a full time or get specialist support. Moodle conversion 1.9.x to 2.2 was definitely not part-timer stuff. Additional issues like this make even full time technical staff look incompetent: "you just cannot delete it" is not an answer to be given when you could before especially if it does not go automatically.
Anyone found a work around by changing permissions assigned to teacher role?

Agreed, what we have done to mitigate this risk is use the Moodle Repository. Our repository is broken up into organizational categories and then into flash, video, audio, and ext_pkg (SCORMs). A simple front-end page was made to upload and delete material from the repository as the other way required users SFTP access to the moodledata/repository folder. This should limit the large files that will cause the majority of the problems. In addition to this we limited the filesize a user can upload into the picker forcing them to use the repository for large files - videos, audio, SWFs, and external packages such as captivate or articulate.

Well this reduces the issue, it does not remove it. It'd be nice to see an offical status update on this from moodle.com.

Jason
added a comment - 20/Sep/12 11:49 PM Agreed, what we have done to mitigate this risk is use the Moodle Repository. Our repository is broken up into organizational categories and then into flash, video, audio, and ext_pkg (SCORMs). A simple front-end page was made to upload and delete material from the repository as the other way required users SFTP access to the moodledata/repository folder. This should limit the large files that will cause the majority of the problems. In addition to this we limited the filesize a user can upload into the picker forcing them to use the repository for large files - videos, audio, SWFs, and external packages such as captivate or articulate.
Well this reduces the issue, it does not remove it. It'd be nice to see an offical status update on this from moodle.com.

Hello,
It seems that this will unfortunately not be part of 2.5.
I added some affected versions so that is not forgotten when 2.6 development cycle will start.
This issue is now 2nd after MDL-13114 in the list of open popular tracker issues.

Jean-Michel Vedrine
added a comment - 08/Apr/13 9:26 AM Hello,
It seems that this will unfortunately not be part of 2.5.
I added some affected versions so that is not forgotten when 2.6 development cycle will start.
This issue is now 2nd after MDL-13114 in the list of open popular tracker issues.

Marina Glancy
added a comment - 13/Jun/13 6:56 AM I created plugins and put them in Moodle plugins database:
Moodle 2.4-2.5:
Repository "Embedded files" https://moodle.org/plugins/view.php?plugin=repository_areafiles
TinyMCE plugin "Manage embedded files" https://moodle.org/plugins/view.php?plugin=tinymce_managefiles
Moodle 2.0-2.3:
Repository "Embedded files plus": https://moodle.org/plugins/view.php?plugin=repository_areafilesplus
Now it's up to Frontend team to decide which of them can be included in standard Moodle 2.6

Marina Glancy
added a comment - 13/Jun/13 11:59 PM Jonathan, subfolders are not allowed in the filearea attached to the editor.
Sorry, did not quite understand what you mean by "expand compressed files" in scope of this issue.

Jonathan Champ
added a comment - 14/Jun/13 12:13 AM Ah! So subfolders are not a possibility? Or it just does not do that yet? I was hoping that since the File resource could do it, we could just pull that in.
If I upload a zip file on a File resource, I have the option of extracting the files from the zip files. Is this something that could be included?

Jonathan, using "Manage embedded files" you can upload zip file and extract it. If it contains subfolders unfortunately they won't be saved.

About the subfolders - that's an interesting question actually. There is no real reason to prohibit the subfolders in filearea attached to the editor. But since there was no possibility to manage embedded files so far, they were not needed. When somebody uploads a file it is saved in the filearea under root without questions.

All my plugins explicitly say that filearea does not allow subfolders. But this definitely should be taken from the filearea options (I will implement it in the next version).

The other thing is that no editor form element in moodle currently that would have 'subdirs'=true in their options (and the default is obviously false), so this would not work for any editor in moodle core or standard plugins (and I'm sure the most of 3rd party plugins too).
We probably could add setting "Allow subfolders by default in editor filearea" in 2.6.

Marina Glancy
added a comment - 14/Jun/13 1:40 AM Jonathan, using "Manage embedded files" you can upload zip file and extract it. If it contains subfolders unfortunately they won't be saved.
About the subfolders - that's an interesting question actually. There is no real reason to prohibit the subfolders in filearea attached to the editor. But since there was no possibility to manage embedded files so far, they were not needed. When somebody uploads a file it is saved in the filearea under root without questions.
All my plugins explicitly say that filearea does not allow subfolders. But this definitely should be taken from the filearea options (I will implement it in the next version).
The other thing is that no editor form element in moodle currently that would have 'subdirs'=true in their options (and the default is obviously false), so this would not work for any editor in moodle core or standard plugins (and I'm sure the most of 3rd party plugins too).
We probably could add setting "Allow subfolders by default in editor filearea" in 2.6.

Martin Dougiamas
added a comment - 14/Jun/13 6:34 AM It was deliberately hardcoded that way to reduce complexity in the HTML fileareas.
Is there really a use case for so much complexity in simple html texts?

A big thank you Marina,
This is a beautiful solution to this problem.
And the really wonderful thing is that even older Moodle versions can benefit from it, as you have done it with plugins !! They just need to install these plugins.
I don't think subfolders are really necessary for html areas (unless somebody is able to show a real use case ?).
Is it necessary to say that I think the repository and editor plugin must be part of Moodle 2.6 ?

Jean-Michel Vedrine
added a comment - 14/Jun/13 7:10 AM - edited A big thank you Marina,
This is a beautiful solution to this problem.
And the really wonderful thing is that even older Moodle versions can benefit from it, as you have done it with plugins !! They just need to install these plugins.
I don't think subfolders are really necessary for html areas (unless somebody is able to show a real use case ?).
Is it necessary to say that I think the repository and editor plugin must be part of Moodle 2.6 ?

Hi Marina,
Testing in master, works wonderfully, but give me the now famous "Did you remember to call setType()" warning for 'itemid', 'maxbytes', 'accepted_types', 'return_types', 'context', 'areamaxbytes' in \lib\editor\tinymce\plugins\managefiles\manage.php

Use case for "unzip" and "subdirs" in an HTML text area is the ability to upload a Camtasia-style video with all it's associated files in one go so that it can be displayed inline within a book or lesson content area. Particularly when dealing with backup and restore, having the files directly associated with the activity which "owns" them makes the process consistent and simple.

Jonathan Champ
added a comment - 14/Jun/13 5:45 PM Use case for "unzip" and "subdirs" in an HTML text area is the ability to upload a Camtasia-style video with all it's associated files in one go so that it can be displayed inline within a book or lesson content area. Particularly when dealing with backup and restore, having the files directly associated with the activity which "owns" them makes the process consistent and simple.

Hello Marina,
I have changed my mind about subdirs
Reason is that somebody reported MDL-40499 and I discovered that when I solved MDL-33424 in fact if the image embedded in a question was into a subfolder on the Moodle 1.9 website where the backup file was created, it is imported with a path different from '/'.
Everything is fine until you try to edit the question, but when you save the question in the editor, images are lost.
Solution to MDL-40499 will be to support subdirs when calling file_save_draft_area_files (they were already supported in the question_edit_form class)
so your idea "But this definitely should be taken from the filearea options (I will implement it in the next version)" seems now excellent to me
Using your actual version of the TinyMCE plugin "Manage embedded files" with one of those restored questions look strange as the images are here but are reported as missing (I will upload a screenshot).
Your plugins have been a great help when studying MDL-40499. Thanks.

Jean-Michel Vedrine
added a comment - 04/Jul/13 12:30 PM Hello Marina,
I have changed my mind about subdirs
Reason is that somebody reported MDL-40499 and I discovered that when I solved MDL-33424 in fact if the image embedded in a question was into a subfolder on the Moodle 1.9 website where the backup file was created, it is imported with a path different from '/'.
Everything is fine until you try to edit the question, but when you save the question in the editor, images are lost.
Solution to MDL-40499 will be to support subdirs when calling file_save_draft_area_files (they were already supported in the question_edit_form class)
so your idea "But this definitely should be taken from the filearea options (I will implement it in the next version)" seems now excellent to me
Using your actual version of the TinyMCE plugin "Manage embedded files" with one of those restored questions look strange as the images are here but are reported as missing (I will upload a screenshot).
Your plugins have been a great help when studying MDL-40499 . Thanks.

I'm glad this is getting fixed - and the repository at least will work for for my custom text editors too.

I found a couple of things when testing this and looking at the code.

1. If I add an image to a html area, then open the manage files plugin and delete the image - I get 2 warnings for the same image in the missing files section.
2. I think the icon will need updating once the tinymce icons are refreshed (and the repository should possibly use the moodle icon like the other moodle repositories).
3. The manage files popup does not work on small screens. It might make sense to use the tinymce functions for opening the window - but at least the width of the window should not be wider than the screen width. I would actually prefer this added in core so it can be called from "other" text editors easily (personal bias).

4. Some comments on the way the CSS is implemented:

+#tinymce_managefiles_manageform.hasmissingfiles .managefilesstatus

color: Color value is invalid

This is not very nice for themers. Bootstrap "red" is not red but #9d261d.

This is also not an error - just a warning.

IMO this should be just adding the class .text-warning in the HTML and have no color specified in the plugin CSS. "text-warning will then need to be added to the base theme css to handle this case. I know there are alot of cases like this in core already - we need to be cleaning this up - not adding more.

Also - it seems that the rest of the CSS for the tinymce plugin could be removed by adding and removing the existing .hidden class instead of defining a whole bunch of new CSS rules resulting in the same "display: block" / "display: hidden" logic.

Damyon Wiese
added a comment - 22/Jul/13 2:50 AM Hi Marina,
I'm glad this is getting fixed - and the repository at least will work for for my custom text editors too.
I found a couple of things when testing this and looking at the code.
1. If I add an image to a html area, then open the manage files plugin and delete the image - I get 2 warnings for the same image in the missing files section.
2. I think the icon will need updating once the tinymce icons are refreshed (and the repository should possibly use the moodle icon like the other moodle repositories).
3. The manage files popup does not work on small screens. It might make sense to use the tinymce functions for opening the window - but at least the width of the window should not be wider than the screen width. I would actually prefer this added in core so it can be called from "other" text editors easily (personal bias).
4. Some comments on the way the CSS is implemented:
+#tinymce_managefiles_manageform.hasmissingfiles .managefilesstatus
color: Color value is invalid
This is not very nice for themers. Bootstrap "red" is not red but #9d261d.
This is also not an error - just a warning.
IMO this should be just adding the class .text-warning in the HTML and have no color specified in the plugin CSS. "text-warning will then need to be added to the base theme css to handle this case. I know there are alot of cases like this in core already - we need to be cleaning this up - not adding more.
Also - it seems that the rest of the CSS for the tinymce plugin could be removed by adding and removing the existing .hidden class instead of defining a whole bunch of new CSS rules resulting in the same "display: block" / "display: hidden" logic.
5. White space errors in:
lib/editor/tinymce/plugins/managefiles/tinymce/editor_plugin.js
Cheers, Damyon

I spent half of the day today on this TinyMCE popup window. But I did not make it part of API, just implemented for this plugin. You are welcome to create an issue for frontend team to move it. Just to mention that there is no function in TinyMCE for maximizing the window (I had to cut out the code from function 'open'). Also if window is maximizable, then toggling the maximize button does not trigger CSS responsiveness. So this function is not yet ready for API. Seriously no more time to dig in it

#1 fixed, thanks for spotting it!
#2 sure, is there an issue for the new tinymce icons so I can comment on it?
#3 see above
#4 Now I add the CSS class .error, that is themeable.

There is no standard CSS class .hidden. It is present only in bootstrapbase and conflicts terribly with the rest of the moodle (when it is used instead of .dimmed for showing hidden sections/activities)

But I removed the 2.4-compatibility CSS that was present in initial plugin, so the file is easier to read now.

Marina Glancy
added a comment - 23/Jul/13 4:39 AM I spent half of the day today on this TinyMCE popup window. But I did not make it part of API, just implemented for this plugin. You are welcome to create an issue for frontend team to move it. Just to mention that there is no function in TinyMCE for maximizing the window (I had to cut out the code from function 'open'). Also if window is maximizable, then toggling the maximize button does not trigger CSS responsiveness. So this function is not yet ready for API. Seriously no more time to dig in it
#1 fixed, thanks for spotting it!
#2 sure, is there an issue for the new tinymce icons so I can comment on it?
#3 see above
#4 Now I add the CSS class .error, that is themeable.
There is no standard CSS class .hidden. It is present only in bootstrapbase and conflicts terribly with the rest of the moodle (when it is used instead of .dimmed for showing hidden sections/activities)
But I removed the 2.4-compatibility CSS that was present in initial plugin, so the file is easier to read now.

Thanks Damyon. Well different commits were there for a reason. Some of them (not all) I was planning to pick into the plugins in plugins DB. Now the history of the changes is lost. Besides this issue was a blocker for another one which became out-of-sync because of this squash and Eloy reopened it.

Marina Glancy
added a comment - 24/Jul/13 1:02 AM Thanks Damyon. Well different commits were there for a reason. Some of them (not all) I was planning to pick into the plugins in plugins DB. Now the history of the changes is lost. Besides this issue was a blocker for another one which became out-of-sync because of this squash and Eloy reopened it.

David Monllaó
added a comment - 24/Jul/13 3:02 PM Hi,
There are a few things that I doubt if they are normal, but I don't know if they are caused by this issue:
Insert Moodle media empty, for example mod_assign, giving feedback to a student submission
Insert Moodle media does not include images, for example when editing a user's description
After selecting a file from the embedded files manager (in a numeric question) I see the attached debugging message
I would fail it, waiting for feedback in case I'm missing or I misunderstood something.

Hello David,
Concerning he 3rd point of your list, I think the debugging message is unrelated to this issue, this is MDL-39507 that I reported some time ago and which is worked on. So I don't think you should fail this issue for that

Jean-Michel Vedrine
added a comment - 24/Jul/13 3:46 PM Hello David,
Concerning he 3rd point of your list, I think the debugging message is unrelated to this issue, this is MDL-39507 that I reported some time ago and which is worked on. So I don't think you should fail this issue for that

Well, in fact this is not exactly MDL-39507 because while studying MDL-39507 I greped all question component code to find all occurrences of the problem, but I forgot to look at the quiz module
So you have found a similar but new problem. I will ask Tim if we should extend MDL-39507 to also deal with quiz or create a new issue.
Bu my remark that this is unrelated to Marina's work and he present issue still stand

Jean-Michel Vedrine
added a comment - 24/Jul/13 3:58 PM Well, in fact this is not exactly MDL-39507 because while studying MDL-39507 I greped all question component code to find all occurrences of the problem, but I forgot to look at the quiz module
So you have found a similar but new problem. I will ask Tim if we should extend MDL-39507 to also deal with quiz or create a new issue.
Bu my remark that this is unrelated to Marina's work and he present issue still stand

So in filepicker you won't see images in any other repository as well - private files, dropbox, etc.
I have no idea why text for the button also mentions images. You are welcome to create an issue about it

Marina Glancy
added a comment - 25/Jul/13 1:25 AM David, the options for filepicker that is opened inside moodlemedia button say ( https://github.com/moodle/moodle/blob/master/lib/form/editor.php#L327):
$args->accepted_types = array('video', 'audio');
So in filepicker you won't see images in any other repository as well - private files, dropbox, etc.
I have no idea why text for the button also mentions images. You are welcome to create an issue about it
And as Jean-Michel said, this warning is another issue
PS sorry did not quite understand this: "Insert Moodle media empty, for example mod_assign, giving feedback to a student submission"

oh ok, I meant that in mod_assign, when writing feedback to a student submission, if I click on the "Insert Moodle media" icon of the feedback comments editor it seems broken as it is displaying en empty "General" section.

David Monllaó
added a comment - 25/Jul/13 7:37 AM oh ok, I meant that in mod_assign, when writing feedback to a student submission, if I click on the "Insert Moodle media" icon of the feedback comments editor it seems broken as it is displaying en empty "General" section.

I have begun documenting this on http://docs.moodle.org/26/en/Embedded_files_repository but I won't remove the docs_required label just yet as I'd appreciate someone checking it first - I am a bit confused as to what its correct behaviour should be: when I added an image to a topic summary and the went back, I found it from the button http://docs.moodle.org/26/en/File:26embeddefiles2.png but when I tried the same with a label I just got a blank screen when clicking the button, although the image was present when going to the Embedded files link in file picker. Is this a bug or am I misunderstanding its use?

Mary Cooch
added a comment - 13/Nov/13 11:08 AM I have begun documenting this on http://docs.moodle.org/26/en/Embedded_files_repository but I won't remove the docs_required label just yet as I'd appreciate someone checking it first - I am a bit confused as to what its correct behaviour should be: when I added an image to a topic summary and the went back, I found it from the button http://docs.moodle.org/26/en/File:26embeddefiles2.png but when I tried the same with a label I just got a blank screen when clicking the button, although the image was present when going to the Embedded files link in file picker. Is this a bug or am I misunderstanding its use?

Hi Mary, thanks a lot for doing this!
I think you confuse a little "embedded files repository" and "manage files tinymce plugin". They are two different and actually independent plugins - they can be installed/enabled separately and don't depend on each other's existence.

1. "Manage files" is a button in tinyMCE that allows to delete/overwrite files embedded in editor.

2. "Embedded files" is a repository that allows to re-use embedded files. To re-use embedded files user should click on "insert image" or "insert video" or "insert link" button in tinymce and then check "Embedded files" repository. (Alternative to copy-pasting the images/videos/links inside the textarea.)

I can see screenshots of both in your document and also the picture that is called "26embeddefiles2.png" is actually a screenshot of "manage files" popup.

Regarding your actual question - all embedded files should appear in both manager and repository (except in repository they are filtered by file type, for example pdf won't appear when you try to insert an image). I tried to replicate your example but always had files in both places. So it is (would be) a bug, could you try to replicate it and send step-by-step instructions? Also make sure you use integration branch because there was one bug with fileareas that was recently integrated. Although master will be rolled today.

Marina Glancy
added a comment - 14/Nov/13 12:17 AM Hi Mary, thanks a lot for doing this!
I think you confuse a little "embedded files repository" and "manage files tinymce plugin". They are two different and actually independent plugins - they can be installed/enabled separately and don't depend on each other's existence.
1. "Manage files" is a button in tinyMCE that allows to delete/overwrite files embedded in editor.
2. "Embedded files" is a repository that allows to re-use embedded files. To re-use embedded files user should click on "insert image" or "insert video" or "insert link" button in tinymce and then check "Embedded files" repository. (Alternative to copy-pasting the images/videos/links inside the textarea.)
I can see screenshots of both in your document and also the picture that is called "26embeddefiles2.png" is actually a screenshot of "manage files" popup.
Regarding your actual question - all embedded files should appear in both manager and repository (except in repository they are filtered by file type, for example pdf won't appear when you try to insert an image). I tried to replicate your example but always had files in both places. So it is (would be) a bug, could you try to replicate it and send step-by-step instructions? Also make sure you use integration branch because there was one bug with fileareas that was recently integrated. Although master will be rolled today.

Mary Cooch
added a comment - 15/Nov/13 9:45 AM I've edited the info now in both http://docs.moodle.org/26/en/Embedded_files_repository and also section 3.2.1.1 in http://docs.moodle.org/26/en/Text_editor so hopefully I have understood it better. I am still getting a blank screen when clicking the Manage files button so I made a tracker issue here MDL-42917