The scope of this change is limited to modifying the MongoDB cache
plugin to use the new version of the driver that accepts PHP 7.x
versions. Following the instructions in the official MongoDB
documentation, https://docs.mongodb.com/php-library/current/, the
MongoDB PHP Library was included and used.
We add a new theme config so the theme can say it supports font-awesome.
If this is true, the pix_icon renderer will call a mapping function to map
from the moodle style t/edit to a font-awesome style fa-cog icon name. Then the renderer
will either render an image tag for old icons - or an accessible font-awesome <i> tag.
This mostly works - but there are some places where we don't use the pix icon renderer, and
we directly create image tags with pix_url image sources. These will need updating (Atto icons,
drag and drop move icons, editpdf icons).
The videojs javascript is over 1MB of javascript which we don't need to
load on every page, now that we only require it demand, the js can be
lazily loaded when its needed, which keeps the first.js smaller and more
likely to stay in browser cache.
The previously used minification libraries were:
a) Unmaintained
b) Had some silly licensing issues (MDL-36457)
The new library is smaller, maintained, active and GPL-compatible.
No changes from the upstream version have been made, it is recommended by
upstream to install these depdencies via composer - but the composer
installation is bundled with a load of test files, shell scripts etc (and
we don't use composer to manage 'production dependencies') so we have to
do it manually.
The SDK that this plugin was designed around is not compatible with recent
versions of Alfresco so the decisio has been made to move the repository to
the plugins database.
1) Parse thirdpartylibs.xml and generate an array of third party
file paths to use in grunt tasks
2) In the lint tasks, we filter third party files from being linted
3) We add a new task to generate ignore files - currently for eslint,
but will be potentially useful for other things in the future
4) Remove .eslintignore from source control
Why have the ability to generate a .eslintignore file? For tooling
integration - by having the eslintignore file people can use other
eslint tools without having to just use grunt (e.g. editor
integrations).
Because we don't have the entire YUI rollup, we can't apply some of the
rules safely, so we ignore some rules.
At this point I am not 100% certain this configuration is robust enough,
to deal with the lack fo rollup knowledge although its a good sign that
there are no errors on our entire yui codebase.
