While, right now, sites using long (> 10 chars) $CFG->prefix
can continue working (because we still don't have any table
> 28 chars), as soon as some new table with long name is added,
it won't work with PostgreSQL anymore (if the 63 limit is raised).
Hence, this environmental check will verify on both install and
upgrade that the $CFG->prefix is always <= 10 chars.
Sites with longer prefixes will need to rename all their tables
(and maybe other objects, depending on the dbtype) to use a shorter
prefix.
This commit adds an additional environment check for the unsupported
PHP 8.1 version to Moodle 3.9.x, 3.11.x and 4.0.x.
It also updates the lang string for unsupported PHP version.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
For Moodle 4.1 and up, the php-xmlrpc is not needed anymore:
- All the MNet stuff has been moved to use php library (MDL-76055).
- The webservice/xmlrpc has been moved from core to contrib (MDL-76052).
So we just remove the check here. Starting with 4.1, it's not
needed for any core functionality.
Note that the string has been removed, and not deprecated, because it's
a non-generic string, not belonging to core/moodle main lang file, and
hardly reused ever. That fits with the allowed deletions, not requiring
any deprecation.
Of course, the lang removal only has been applied to master (4.1dev).
Older branches still keep it and will be used when checking < 4.1
upgradability.
This is a partial backport of MDL-73270 to ensure that the
check_xmlrpc_usage custom check is present in all the supported
branches and it's applied to all branches able to run php80:
- MOODLE_311_STABLE
- MOODLE_400_STABLE
- master (aka, 4.1 and up)
Note that the whole patch has not been backported, only the
environmental check (xml file and check implementation).
This optional environmental check will look if:
- the site is running php72.
- the site has igbinary extension enabled.
- the igbinary extension version is a buggy one >=3.2.2 <= 3.2.4
- the bug is reproducible.
And will warn if all the conditions are met.
Due to Moodle 2.7 and Moodle 3.4 not having a common compatible php version
between them to upgrade from Moodle 3.4 from Moodle 2.7 you'll need to upgrade
to a higher version first or upgrade php at the same time as upgrade,
this encourages the former.
Unfortunately it has come to light that the version sniffing is just not
reliable at all, operating system vendors backport security patches to
older versions - so in many cases we reporting a problem which is not a
problem. False positives and the solution to self-compile or something
like php will be causing more harm than good.
Eloy Lafuente (stronk7)