MDL-76499 revealed a few problems with resource generators:
1. We were not covering with unit tests the upload of files from disk
(and here it's where the problem was).
2. There was a little of confusion between disk paths (only needed
to upload files) and file_area paths (the generator only creates
or uploads files to the root directory of the file area.
3. It was possible to request the upload of a file to the generator
without that file effectively existing.
This commit fixes those points and covers 99% of the generator code.
When rendering content items, check whether the plugin has monologo
icons. If so, add a 'nofilter' class so the plugin icon can be
rendered as is and without the CSS filter.
Add the `.nofilter` class for activity icons when the icon URL's
`filtericon` parameter is not set, so they get rendered as they are on
the timeline block.
Add the `.nofilter` class for activity icons when the icon URL's
`filtericon` parameter is not set, so they get rendered as they are on
the recently accessed items block.
Add the `.nofilter` class for activity icons when the icon URL's
`filtericon` parameter is not set, so they get rendered as they are on
the context header on the activity page.
Add the `.nofilter` class for activity icons when the icon URL's
`filtericon` parameter is not set, so they get rendered as they are on
the course homepage.
* Apply the filter CSS property only to activity icons
that don't have the ".nofilter" class. This will allow
activities with non-SVG icons to be rendered as they are.
* If a plugin defines a `filtericon` custom data or uses its monologo
version of the icon, a `filtericon` parameter is being added to the
icon's URL. This information can help plugins determine whether to
render the activity icon as is or with CSS filtering.
This is a workaround for an upstream bug which I have not been able to
reproduce outside of Moodle whereby the editor.contentWindow does not
math the editor.iframeElement.contentWindow when it should.
This issue only seems to affect Firefox, and it may even be a bug in
Firefox. It can only be reproduced when using a fresh browser which has
never had a TinyMCE window open.
The step i_enable_plugin cannot be used as bigbluebuttonbn_default_dpa_accepted
setting needs to be enable in order for the BigBlueButton plugin to be enabled.
