One of the error levels PHP previously emitted was E_STRICT, on code
that was not strictly correct to ensure interoperability and forward
compatibility. PHP 7.0 converted the majority of existing E_STRICT
warnings to E_NOTICE, and since PHP 8.0, all E_STRICT notices have
changed to E_NOTICE.
Because all of the E_STRICT notices are upgraded to E_NOTICE since PHP
8.0, PHP 8.4 deprecates the E_STRICT constant.
The E_STRICT constant is deprecated in PHP 8.4. Using the constant
anywhere in PHP code now emits a deprecation notice in PHP 8.4 and
later.
The E_STRICT constant will be removed in PHP 9.0.
PHP core and core extensions since PHP 8.0 and later do not emit
E_STRICT notices at all. It is safe to assume that any PHP applications
that run on PHP 8.0 and later will never encounter E_STRICT notices, and
error reporting and handling can be safely updated to ignore E_STRICT
notices.
See: https://php.watch/versions/8.4/E_STRICT-deprecated
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
While searching for no longer needed PHP 5.x & 7.0 checks, the
`phpversionhelp` lang string and, subsequently, the `memorylimithelp`
lang string and the `install_helpbutton()` and
`install_print_help_page()` functions were discovered. According to
comments on MDL-2787 and MDL-64482 they are no longer in use since
Moodle 1.x (approximately), neither reachable since some good versions
ago. With MDL-17458 (commit 3b09331066a91c51a2de1676ca8179ca7c90f64b),
the function `print_compatibility_row()` was gone, and it seems like it
was the only place calling `install_helpbutton()`. And
`install_helpbutton()` was the only place where a link to the help mode
(e.g. `install.php?help=$helpfield`) ever surfaced. As both lang
strings and functions are particular to the installer and never could
have been used outside of it, we are going for direct deletion instead
of regular deprecation.
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
* Use the page title separator constant when displaying the page title
during upgrade and installation.
* No need to display the site name during install when because it hasn't
been set at this point.
In MDL-73145, a new $CFG setting was added to let define the preset
to be installed.
This patch replaces the method call to the new one that has been
moved from tool_admin_presets plugin to core_adminpresets component.
A new setting, $CFG->setsitepresetduringinstall, has been added to
config file, to let admins define the site admin preset to be applied
during the Moodle installation.
Besides, a new parameter, "--sitepreset" has been also added
to admin/cli/install.php, to let define it too when running the
upgrade process using CLI.
During a CLI upgrade when there are new settings in core or in
a plugin, the settings are set to the defined defaults
automatically. There is no ouput shown on the CLI about which
new settings have been introduced or what default values the
setting are set to.
This patch outputs the name of the new setting and what the
default value being is set is to the CLI during an upgrade.
Objects and arrays are expanded into a human readable format.
This plugin also makes the function that sets the defaults to
be more robust so it isno longer required to be called multiple
times to ensure all settings are set.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
List of changes:
* New OOP API using PHP namespace \core\session\.
* All handlers now update the sessions table consistently.
* Experimental DB session support in Oracle.
* Full support for session file handler (filesystem locking required).
* New option for alternative session directory.
* Official memcached session handler support.
* Workaround for memcached version with non-functional gc.
* Improved security - forced session id regeneration.
* Improved compatibility with recent PHP releases.
* Fixed borked CSS during install in debug mode.
* Switched to file based sessions in new installs.
* DB session setting disappears if DB does not support sessions.
* DB session setting disappears if session handler specified in config.php.
* Fast purging of sessions used in request only.
* No legacy distinction - file, database and memcached support the same functionality.
* Session handler name included in performance info.
* Fixed user_loggedin and user_loggedout event triggering.
* Other minor bugfixing and improvements.
* Fixed database session segfault if MUC disposed before $DB.
Limitations:
* Session access time is now updated right after session start.
* Support for $CFG->sessionlockloggedinonly was removed.
* First request does not update userid in sessions table.
* The timeouts may break badly if server hosting forces PHP.ini session settings.
* The session GC is a lot slower, we do not rely on external session timeouts.
* There cannot be any hooks triggered at the session write time.
* File and memcached handlers do not support session lock acquire timeouts.
* Some low level PHP session functions can not be used directly in Moodle code.
This prevents PHP warnings displayed due to recent modifications in
make_temp_dir() and make_cache_dir(). These functions now expect that
the root temp/cache dir already exists. So they must be available before
the lang_installer installs the lang pack during install.
This function populates default message preferences for all existing providers
when the new message processor is added.
The change also includes update of message_set_default_message_preference to
make possible using it for particular message processor update.
install_populate_default_messaging_prefs() is no longer needed and depricted.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
This makes the order of plugins returned by get_plugin_types not important as
all messaging defaults population is done at the end.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
upgrade_core also attempts to populate the preferences, but since during the
first installation it is called before message outputs are set, we need to
force preferences setting at the end.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
The new messaging default settings can be set in messages.php and deployed
during installation. This also ensures the removing of settings on plugin
uninstallation and contains the update script to populate current default
settings on the existing system when the new feature is introduced.
For security reason we have to avoid using library functions in upgrade
function, so we set defaults the blind way. At this point we do not expect
plugins to have individual messaging defaults presets anyway. The site
defaults are the same as were set for each user using
message_set_default_message_preferences function.
Signed-off-by: Ruslan Kabalin <ruslan.kabalin@luns.net.uk>
