The PSR-4 specification does not preclude a single namespaces from
having multiple sources. This is the case for several PSR standards
including standard packagist packages distributed by PSR:
- PSR-7 - HTTP Message Interfaces: \Psr\Http\Message
- PSR-17 - HTTP Factories: \Psr\Http\Message
- PSR-15 - http-server-handler: \Psr\Http\Server
- PSR-15 - http-server-middleware: \Psr\Http\Server
* Make sure that we respect the fullnamedisplay and alternativefullnameformat
parameters to decide on the initials for a given user
* Add further tests
Co-authored-by: Tatsunori Uchino <tats.u@live.jp>
When bulk-updating course module visibility, set_coursemodule_visibily
was triggering a partial cache purge and rebuild for each course module.
This potentially led to 2 cache sets each requiring a lock to be
acquired and released per course module, plus any other cache updates
for other changes to the course in the same request.
This adds a new $rebuildcache paramter to the
set_coursemodule_visibilty, which is true by default to retain the
existing behaviour. If set false, it will skip doing the partial purge
and rebuild for that course module, and it is up to the calling code to
ensure the cache is updated as requried.
To assist with this, there is a new
course_modinfo::purge_course_module_cache_multiple() method, which
allows multiple course modules to be purged from the cache in a single
cache set.
* When reloading a section, we also forced the reloading of
course modules, resulting in doing the same work twice (once for
the section reload and once for the course module reload)
* Debounce the reloading process so prevent unwanted duplicate
reloads
If `moduleName` param is passed in config object for modalform, it will be
used to instantiate modal class, otherwise 'core/modal_save_cancel' is
used.
Co-authored-by: Marina Glancy <marina@moodle.com>
* The arrow characters in link_arrow_right() and link_arrow_left()
functions get announced by screen readers. This causes confusion
and is unnecessary.
This was causing the toast notification upon the clipboard action
result to immediately disappear as the modal was closed. The toast
module can happily handle this for us itself, so remove from the
template.
During the bootstrap of PHPUnit we ensure that the database has been
reset to its initial state.
We do this by checking the internally-stored DB write count between
runs. If the count is not yet set (null), or it has been increased, we
force a reset.
When running an isolated test the test runner resets the database, it
then sets up a new isolated test environment by writing a new PHPUnit
test case and passing it to a new PHP Process using standard in. As part
of this, the bootstrap is run for that process.
Because we are in a new process, the db write count is fresh and not yet
set. This has been leading to an additional db reset before the isolated
test.
To handle this we want to _not_ perform a reset during the
initialisation for isolated runs. We know that the DB is in a fresh
state before we start the run.
To support this we need to know whether the test is an isolated test
during the bootstrap, which means we cannot use the previous approach to
calculating this.
Instead we look at the PHP_SELF value. PHP sets this to "Standard input
code" when run from stdin, instead of running a file.
There should not be any other legitimate reason to run a PHPUnit
bootstrap via this stdin approach.
Unfortunately this approach is a little bit risky as it depends on the
presence of a specific string, however this string has been in place
since 2016, and there is no legitimate way of calculating this.
I did consider looking at whether the called script included `/vendor/`
and `/phpunit`, but this is also likely a risky approach if someone
calls PHPUnit in an unexpected way.
This approach is itself unit tested so any change to PHP's stdin string
before we deprecate this approach entirely in 12 months time will be
caught.
This hack was introduced to work around a bug in MySQL 5.6.14 and
MariaDB at the time.
https://bugs.mysql.com/bug.php?id=69882
It was addressed a few months later in 5.6.16, and 5.7.4.
MariaDB merged version 5.6.16 of MySQL's InnoDB engine in MariaDB
10.0.11 and got hte patch from there.
Moodle has required MySQL 8.0, and MariaDB 10.6.7 since Moodle 4.2 and
it is therefore safe to remove these hacks.
Huong Nguyen