This has been generated running the following Sniff,
part of the Moodle's CodeSniffer standard:
- PSR2.Methods.MethodDeclaration
It just ensures all the function declarations have
the correct order for:
- abstract and final.
- visibility (public, protected, private).
- static.
So, all the lines modified by this commit are function declarations
and the only changes are in the positions of those keywords.
This has been generated running the following Sniffs, all
them part of the Moodle's CodeSniffer standard:
- PSR12.Functions.ReturnTypeDeclaration
- PSR12.Functions.NullableTypeDeclaration
- moodle.Methods.MethodDeclarationSpacing
- Squiz.Whitespace.ScopeKeywordSpacing
All them are, exclusively, about correct spacing, so the changes
are, all them, only white space changes.
Only exceptions to the above are 3 changes what were setting the
return type in a new line, and, when that happens, the closing
parenthesis (bracket) has to go to the same line than the colon.
* Makes it possible to safely call acquire_lock so that it throws an
exception instead of returning false if it can't get a lock (which
most existing uses assumed it already does).
* Fix some omissions from the requirelockingbeforewrite option (it
now checks on delete).
* Modinfo uses a versioned cache, so it is not necessary to delete
items, only increase the version. (Provided we keep track of
cacherev carefully...)
* all constans usable in ABORT_AFTER_CONFIG should be always defined
* MDL_PERFDB and $PERF->logwrites not used after legacy log removal
* MDL_PERF_TEST should be documented in codebase
* deprecated warnings in shutdowb manager
If a statically accelerated cache returns an empty array then the value
was still fetched from the non-static cache store.
The check of the `$result` should be strictly checked against `false`,
which is the value used if no value was found.
In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
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).
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.
Create or update the breadcrumbs in the site administration
pages where it is required.
Highlight the corresponding site adminstration tab.
Highlight the primary nav to Site administration when user
is navigating to any of the site administration pages.
Also changed the boostnavbar so that the nodes in the secondary
navigation are not shown in the breadcrumbs when user is in site
administration page.
In certain cases where it doesn't already redirect to run the upgrade,
users could see an exception 'Unexpectedly found non-versioned cache
entry'. This change ensures the upgrade happens instead.
Adds new set_versioned and get_versioned APIs to cache, which means you can
request a specific version from cache and it will not return an outdated
version.
This is important when using multi-layer-caches where a local cache might have
an outdated version of the cache, but the shared cache has a current version.
With this feature, the content of the cache does not have to be rebuilt, as
it will automatically retrieve it from the shared cache if necessary.
I checked using a diff tool and the difference between 'get' in cache
and cache_session is only:
a) cache_session: call to check_tracked_user at the start
b) cache: Includes code to use static acceleration (but this would
not run anyway in cache_session because use_static_acceleration
returns false)
c) cache: $setaftervalidation logic is used so that it sets it slightly
later (I can't see how this would make any difference)
d) cache_session: uses functions eg get_store() instead of variables
$store; those functions aren't overridden.
This seems like a ridiculous duplication of very complicated code, so
I'm going to remove the duplication before I change it.
For cache types which mean this information can be obtained without a
significant performance cost (i.e. just by calling strlen and not
having to serialize something that wasn't serialized already),
this change calculates the size of data read from or written to cache
in each request and includes it in the perfdebug table at bottom of
output (when that is turned on).
This supports the following cache types:
* File store
* Redis (only if caching is enabled)
When we read the MUC configuration, a file which exists but is empty
will not error, but will cause all configuration to be empty.
We already perform an {{is_array()}} check on the {{$configuration}}
variable, but the default value for {{$configuration}} is an empty
array. In the case where the file exists, but is empty, no errors occur
when the file is loaded, and the initial {{$configuration}} value is
not overwritten, leading to the file being replaced with an empty copy.
\cache::make() may return a cache_disabled subclass but callers, specifically
user/lib.php:user_create_user(), invoke \cache::purge_current_user() which was
only implemented by the cache_session subclass. Added empty
\cache::purge_current_user() which subclasses can implement, i.e.
cache_session, or not, i.e. cache_disabled.
The current logic in the cache_session::check_tracked_user() is not
right. We must always set the current session id. A typical use case is
when the cache instance is instantiated for a not logged in user. We
can't let the sessionid property null in that case as it forms an
important part of the parsed key.
Similarly, even if we have the same user currently loaded, we must still
set the sessionid to make sure the data will be associated with the
current PHP session. Same user (including visitors or guest users) can
access the site from different browsers and each must end up with its
own key prefix.
