Unfortunately, we can't simply use session_id() to regenerate the
session id in unit tests. Starting from PHP 7.2, it would trigger
"session_id(): Cannot change session id when headers already sent",
refer to MDL-60978 and PHP bug #75628 for more details.
As a workaround, we use a static property allowing us to inject the
value that we then use as a session identifier. This is reasonably
enough to make sure that the identifier is used as a part of the key
prefix.
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.
The cache invalidation check was previously occuring every time either
the `set` or `get` function was called on the cache. However, the cache
invalidation check is based on the jsrev which is static for the
lifetime of the page.
This change moved the invalidation to happen during the setup of the AMD
module such that it only happens one time per storage type (Local +
Session).
We only use the jsrevPrefix to determine if the cache should be
invalidated, but the prefix that we were using is based on the new
jsrev.
For example, the jsrevPrefix will be:
hash(wwwroot + '/ + config.jsrev) + '/jsrev'
Where config.jsrev is the _current_ (new) jsrev.
As a result when searching for the jsrev used to store the data which is
currently in the storage cache, no key is returned, and we instead set
an 'initial' value and the cache is not cleared
This patch changes the jsrevPrefix to be:
hash(wwwroot) + '/jsrev'
Since the wwwroot does not change, the key remains static for the
current site. As a result, when the jsrev is bumped via a Moodle cache
purge, we are able to correctly fetch the old jsrev from the cache,
determine that the jsrev has changed, and purge the cache.
