During install/upgrade, caching is disabled. This change provides a
way to temporarily enable caching (using in-memory cache storage only)
within a specific function; caches are deleted afterwards.
Adding this to two locations improves install performance quite a lot.
Caching is not enabled during the parts of plugin installation that
can vary for individual plugins (install.php/upgrade.php) as these
might be relying on its absence, for example by making direct database
changes.
Adding new capabilities can be slow if they have permissions cloned
from an existing capability, and if there are many places in the
database where the existing capability was overridden.
This change optimises the clone-capability performance, approximately
halving the number of queries required.
Adding multiple capabilities was very slow because it clears and
rebuilds the capability cache after each one. This change makes it
clear the cache once after adding all capabilities, before adding
permissions to the archetype roles.
This will find all data generators that can be used in behat via the
'the following "something" exist:' step, and display them in a select
list on the step definitions page.
When a generator is selected, it will fetch the required fields for that
generator and display them on the page.
jQuery submit events do not trigger the native submit event, and
therefore the TinyMCE submit listener is not called. This means that the
tinymce.triggerSave() function is not called, and the editor content is
not saved.
To work around this, if there is a form for the Node that the editor is
attached to, the jQuery submit event is listened to and the save event
called.
Unfortunately it is not possible to use a global jQuery submit listener
added to the document to save all editors on the page.
In some cases, this is too late because the bubbling process means that
a child node consumer may attempt to consume the data before the
delegated handler is called for the document.
Use the full result from download_file_content within the component
installer to ensure that spurious debugging is not emitted during
operation. Handle validation of the returned data consistently.
Right now we have the information only in docs:
- https://docs.moodle.org/dev/Core_APIs
- https://moodledev.io/docs/apis
And, in fact, we are crawling those pages to get the information
from various tools (moodlecheck, CiBoT...). Obviously, that's far
from ideal, the source only has the current list of APIs, and
there isn't much information there but the names.
So we are moving the source of information to be in core, so it
can be modified between branches, and contains richer information:
- The component the API belongs to, usually a subsystem or core.
- If the API can be used as level 2 namespace.
- If the API can be used as level 2 namespace out from its component.
Note that all that information has NO USES right now in core (and maybe
never will), but tools/checkers will benefit enormously by having that
information at hand, so we can check for namespaces, categories and
other bits way better.
Also, once we have this, the APIs dev documents linked above, surely
can be improved by being automatically generated and include all the
meta-information available.
It also includes a very basic json schema validating the basis. It can
be tried online @ https://www.jsonschemavalidator.net , or any other
tool. PHP requires extra libraries to be able to perform the validation.
Covered with unit tests, both api-related functions and structure validation.
