During request lifecycle ensure that column, filter and condition
persistents are only loaded a single time to prevent additional
database reads.
Provide invalidation method, used by the report helpers, to ensure
that the persistents are re-loaded appropriately.
Co-authored-by: Marina Glancy <marina@moodle.com>
Apart from applying the points described in readme_moodle.txt, the following
changes have been done too:
- The parameter $folderName from the method libraryToString() have been removed
and a new method, libraryToFolderName() has been added to the H5PCore API.
References to libraryToString() with the $folderName set to true have been
replaced to the new method.
- missing-main-library has been added and replaces in some cases to
missing-required-library.
- The framework saveLibraryData method must be called before saveLibrary
(h5p.classes.php file has been patched to leave the original order because
libraryid is required to save the itemid).
- The getLibraryId() method from H5PCore has been rewritten to use MUC, in
order to avoid PHPUnit failures.
Cache locking fails if the cache store supports multiple identifiers
(in core, the only two which do are cachestore_static and
cachestore_mongodb, so this is unlikely to cause severe problems).
The Preview questions icon shouldn't be displayed unless the user can
edit the feedback or access to the reports; otherwise, it's causing
confusion (especially when the feedback is not opened).
Replace the old course/dragdrop.js file (which was not even minimised)
to AMD modules and integrate them to the new reactive course editor.
From now on, a file can be drop over any course section, no matter if it
is in the course content or in the course index. It will also start
using the new process monitor to show the uploading state to the user.
In 4.0- version each time the course page is loaded the file handlers
are calculate din the backend and injected directly into JS using a json
encapsulation. With this new webservice the handlers can be obtained
directly from the frontend when needed.
This commit adds all the necessary CSS and logic to handle file dropping
into a reactive compoment. From now on, a reactive application can
handle both element drag&drop and file drop easily.
Create a new UI compoment to queue, execute and display errors on batch
processing. The first use of this component is when the teacher drops a
file into the course page.
Half of the times the normalise module is used is to get a single
element. However, because jQuery elements can contain multiple elements
the getList is always an array. Due to this in many ocasions we repeat
the getList(VAR)[0] line instead of having a more readable getFirst
method which only implies a couple of lines in the original code.
Basically, we only need to change:
- PHP 8.0
- MySQL 8.0
- PostgreSQL 13
Also, remove any php-xmlrpc installation because they aren't
needed since Moodle 4.1.
Finally, ensure that we aren't using mysql bin logs ever, because
they are huge and can make the 1Gb tmpfs to become full. This is
specifically needed for MySQL 8.0, because it comes with bin logs
enabled by default.
We have forked the mysql-action to achieve that:
https://github.com/moodlehq/mysql-action
Worth blaming travis because, after PG 11 and 12 using port 5433,
now they are back (in PG 13) to port 5432. Surely there is some
logic behind the undocumented ping-pong but...
Note that, despite the commit message, this is not possible. Moodle
3.11.0 (and 3.10.0) were developed in parallel with Moodle 4.0, and
when they were released, the master branch had already diverged, so
the master branch does not contain the comment lines:
"// Automatically generated Moodle v3.11.0 release upgrade line"
And they are needed to know which parts of the upgrade are safe to delete.
So we only proceed to delete all those steps from lib/db/upgrade.php
which version is known to be < 2021051708 (v3.11.8), master ones will
be, always bigger than that. We don't touch plugin upgrade scripts
because they may have different versions, not 100% matching the
2021051708 rule, so there will be an excess of steps there.
Note this is not a big problem, just a few more steps will be skipped and
that's all. Whenever we bump the Moodle requirements again (to Moodle
4.0 or up), the lines will be back and we'll be able to safely remove
all the steps before them. See previous Moodle requirements issues as
example.
The upgrade steps deleted by this commit weren't using any stuff from
upgradelib, tasks..., so there isn't anything else to be removed but
the core steps themselves.
Also includes an upgrade step to prevent upgrading from any
version < 2021051708 (v3.11.8) as anti-cheating measure.
Now that the required PHP version has been raised to php80, set
it in the composer.json file and regenerate everything, following
the instructions @ https://docs.moodle.org/dev/Composer .
The only changes, as agreed in the issue are:
- Raise min PHP version to 8.0 (from 7.4).
- Make the php-sodium extension required (was optional).
- Small behat/behat bump to 3.12.0 (from 3.11.0)
