Whoops will only be used under the following conditions:
- Not an AJAX request
- Not a CLI usage
- debugdisplay is set
- composer dependencies are installed
- Whoops is available
- The configuration setting is enabled
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.
* 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
When we deprecate the use of a file, we often include tests which ensure
that the legacy behaviour is maintained. There are also legacy uses
in the community where people would like to use the deprecated API for a
period.
The issue that we face is that, if the deprecated file is included once,
then it will be included for all other, unrelated, tests. This means
that other tests may not detect cases where the deprecated file was
included.
We can solve these cases by running the test that performs the inclusion
in a deprecated process. This means that the inclusion is only performed
in that isolated process, and other unrelated tests do not include the
file.
However, we also then need to detect which files which are including the
file and which we do not know about.
This change introduces:
- an override to the TestCase::setInIsolation method to define a
constant when the test is running in isolation
- a new function that a file can call when it is included, to make sure
that the test process was isolated, where there is any test.
At the moment, quiz_statistics\task\recalculate gives no useful
information about what it is doing, which makes it hard to investigate
if the task fails. This commit makes it more usefully verbose.
Also, following this change, one instance of this task will not
run for more than one hour at a time.
As part of this commit, I have added a new helper mtrace_exception.
to consistently log exceptions in scheduled tasks. It is sad to
add a new function to moodlelib.php, but that seemed the logical place.
Looking at other tasks, this method is badly needed. Many are just
logging the ->getMessage() which is normaly insufficient for proper
debugging. However, swiching all existing tasks to use the new function
will need to wait for a future MDL.
Default value of the $flag argument changed in PHP 8.1 from ENT_COMPAT to ENT_QUOTES | ENT_SUBSTITUTE
To ensure consistent behavior across different PHP version the second parameter is now required for the functions:
htmlspecialchars(), htmlentities(), htmlspecialchars_decode(), html_entity_decode() and get_html_translation_table()
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.
Added parameter type hint to make_request_directory()
Removed invalid parameters from calls to make_request_directory()
Removing these parameters should have no effect on behaviour.
It's important to say that this bug apparently (till now) only happens
when an *incorrect* instalation of a site happens, reusing the dataroot
from another existing site.
When that happens, the localcache/bootstrap.php file from the old
site is reused, setting siteidentifier and SYSCONTEXTID when it's not
time for them to be defined yet.
Their existenece leads to reusing some other structures from the old
dataroot (that, again, should have been changed or wiped!), ultimately
leading to all sort of errors about non-existent tables (course,
context...).
With this change we ensure that:
1) Whenever any change to the database configuration (prefix, user,
type..) happens, it's detected and immediately the information
in the localcache/bootstrap.php is discarded and the file removed.
This should fix problems like MDL-73098 itself.
2) We only set SYSCONTEXTID if the file is not stale. Main reason
for doing that check within the localcache/bootstrap.php file
itself is that we cannot "undefine" it @ setup.php. This should
prevent errros like MDL-72888 to happen.
3) Finally, little detail, we only define SYSCONTEXTID if it has
not been defined earlier. In the past, it was recommended to
define it in config.php (exactly to save one DB read) and, sites
having them will face "already defined" warnings.
It was deprecated in php72 and now it's gone.
Have used this regexp to find all the uses in core:
ag set_error_handler | uniq
And then checked all them manually, that parameter was not
being used in the 3 methods where we are removing it.
Also, ensure that remove_dir() only processes directories,
because sometimes it was being called by shutdown managers
with files, leading to PHP warnings.
Co-authored-by: Eloy Lafuente (stronk7) <stronk7@moodle.org>
Co-authored-by: Jun Pataleta <jun@moodle.com>
Some errors can happen really early in Moodle bootstrap/warmup
(basically when executing setup.php stuff, before general libraries
are loaded and available).
That's called "early errors" and there are good parts within
setuplib.php that must be able to run without any dependency
other than vanilla php code.
It seems that, along the years, some dependencies have been
added (calls to debugging(), to s()....) and they worked mostly
ok because early errors are rare.
This commit just makes all those dependencies conditional so,
if an early error is detected... the exception handler will
return real information about he error happening and not
handler own errors (like it's happening now).
