This changeset introduces a `WP_Shutdown_Handler` class that detects fatal errors and which extension (plugin or theme) causes them. Such an error is then recorded, and an error message is displayed. Subsequently, in certain protected areas, for example the admin, the broken extension will be paused, ensuring that the website is still usable in the respective area. The major benefit is that this mechanism allows site owners to still log in to their website, to fix the problem by either disabling the extension or solving the bug and then resuming the extension.
Extensions are only paused in certain designated areas. The frontend for example stays unaffected, as it is impossible to know what pausing the extension would cause to be missing, so it might be preferrable to clearly see that the website is temporarily not accessible instead.
The fatal error recovery is especially important in scope of encouraging the switch to a maintained PHP version, as not necessarily every WordPress extension is compatible with all PHP versions. If problems occur now, non-technical site owners that do not have immediate access to the codebase are not locked out of their site and can at least temporarily solve the problem quickly.
Websites that have custom requirements in that regard can implement their own shutdown handler by adding a `shutdown-handler.php` drop-in that returns the handler instance to use, which must be based on a class that inherits `WP_Shutdown_Handler`. That handler will then be used in place of the default one.
Websites that would like to modify specifically the error template displayed in the frontend can add a `php-error.php` drop-in that works similarly to the existing `db-error.php` drop-in.
Props afragen, bradleyt, flixos90, ocean90, schlessera, SergeyBiryukov, spacedmonkey.
Fixes#44458.
Built from https://develop.svn.wordpress.org/trunk@44524
git-svn-id: http://core.svn.wordpress.org/trunk@44355 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Instead of turning the return value of `stream_get_wrappers()` into a regex to match the scheme, we can instead extract the scheme and search the return value of `stream_get_wrappers()`.
Props schlessera, swissspidy.
Fixes#45553.
Built from https://develop.svn.wordpress.org/trunk@44506
git-svn-id: http://core.svn.wordpress.org/trunk@44337 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This should make cron spawning faster by ensuring requests to wp-cron.php return immediately regardless of transport method. It is enabled only on recent PHP versions with fastcgi, due to historical bugs and availability of `fastcgi_finish_request()`. This needs testing on a range of platforms, to help determine if it's safe to use in other contexts also.
Props vnsavage, johnbillion, jnylen0.
See #18738, #41358
Built from https://develop.svn.wordpress.org/trunk@44488
git-svn-id: http://core.svn.wordpress.org/trunk@44319 1a063a9b-81f0-0310-95a4-ce76da25c4cd
As many WordPress sites use a static homepage rather than a blog, this link gives a natural next step for new sites owners wanting to configure their site in this manner.
Props professor44, joyously, nielslange, mukesh27, melchoyce.
Fixes#45019.
Built from https://develop.svn.wordpress.org/trunk@44485
git-svn-id: http://core.svn.wordpress.org/trunk@44316 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add the function `wp_get_ready_cron_jobs()` to return a modified version of the cron array limited to jobs ready to be run, ie with a timestamp of `time()` or earlier.
The new function includes the filter `pre_get_ready_cron_jobs` to allow for custom cron storage systems. This rounds out the functionality added in #32656.
Props Pento for code review.
Fixes#45797.
Built from https://develop.svn.wordpress.org/trunk@44483
git-svn-id: http://core.svn.wordpress.org/trunk@44314 1a063a9b-81f0-0310-95a4-ce76da25c4cd
After [42832], [42891] and [43006], this changeset refines the core notice informing about an outdated PHP version:
* The link to the Update PHP information page can now be adjusted using either a `WP_UPDATE_PHP_URL` environment variable, or a new `wp_update_php_url` filter.
* If that URL is different from the default one that points to https://wordpress.org/support/update-php/ or its localized equivalent, a note indicates that the linked resource has not been provided by WordPress itself, and the default URL is still linked to as an additional resource.
* The URL for the default information page has been updated to use the slug `update-php` instead of `upgrade-php`.
* `@since` annotations have been updated.
Going forward, admin areas that display information related to the PHP version should use the new function `wp_get_update_php_url()`.
Props afragen, fierevere, flixos90, markjaquith, miss_jwo, nerrad, pento, schlessera, SergeyBiryukov, spacedmonkey.
Fixes#45686. See #41191.
Built from https://develop.svn.wordpress.org/trunk@44476
git-svn-id: http://core.svn.wordpress.org/trunk@44307 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The order of the type and variable name in the `param` tags for the `wp_get_default_privacy_policy_content` filter is incorrectly reversed. This moves the two into the correct order.
Props ishitaka, mukesh27.
Fixes#45416.
Built from https://develop.svn.wordpress.org/trunk@44475
git-svn-id: http://core.svn.wordpress.org/trunk@44306 1a063a9b-81f0-0310-95a4-ce76da25c4cd
An integer comparison is performed against `control.currentErrorAnnotations`, but `control.currentErrorAnnotations` is actually an array. This fixes that comparison so the content saves correctly.
Props barryceelen.
Fixes#43657.
Built from https://develop.svn.wordpress.org/trunk@44474
git-svn-id: http://core.svn.wordpress.org/trunk@44305 1a063a9b-81f0-0310-95a4-ce76da25c4cd
