Due to the high number of follow-up tickets and associated security concerns, it was decided to reschedule the fatal error recovery feature for WordPress 5.2, in order to address these issues properly. The feature will continue to be developed, with iterations being merged into trunk early in the 5.2 release cycle.
Fixes#46141. See #44458, #45932, #45940, #46038, #46047, #46068.
Built from https://develop.svn.wordpress.org/trunk@44717
git-svn-id: http://core.svn.wordpress.org/trunk@44548 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `WP_Shutdown_Handler` name plus related function names were premature when originally committed, as there can be multiple shutdown handlers in PHP, and WordPress makes use of that feature. This changeset modifies the name to a more appropriate `WP_Fatal_Error_Handler`, and related to that changes the following names:
* The drop-in to override the handler is now called `fatal-error-handler.php`.
* The internal function `wp_register_premature_shutdown_handler` is now called `wp_register_fatal_error_handler()`.
In addition to these naming changes, a new constant `WP_DISABLE_FATAL_ERROR_HANDLER` is introduced that can be set in `wp-config.php` to entirely disable the fatal error handler. That constant's value is and should be accessed indirectly via a new `wp_is_fatal_error_handler_enabled()` function and is filterable via a new `wp_fatal_error_handler_enabled` hook. Note that disabling the fatal error handler will skip the new functionality entirely, including the potentially used `fatal-error-handler.php` drop-in.
The new set of constant, filter and function provide for an easier-to-use mechanism to disable the fatal error handler altogether, rather than requiring developers to implement a drop-in for purely that purpose.
Props afragen, flixos90, joyously, knutsp, markjaquith, ocean90, schlessera, spacedmonkey.
Fixes#46047. See #44458.
Built from https://develop.svn.wordpress.org/trunk@44674
git-svn-id: http://core.svn.wordpress.org/trunk@44505 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
While caching here seemed like a good idea in theory, in practice the cache would be often stale causing development issues.
We exclude common folders (such as `node_modules`) from the scanning to avoid directories which are not useful to the end-user, so as long as those exclusion lists are held up this shouldn't cause too much of a degredation in the future.
We may consider adding caching here again in the future if it's determined that it is really needed.
Props precies, ibenic, mariovalney, schlessera, and all the others who commented on the ticket(s).
This partually reverts [41806].
See #6531.
Fixes#42573.
Built from https://develop.svn.wordpress.org/trunk@42242
git-svn-id: http://core.svn.wordpress.org/trunk@42071 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The theme and plugin editors now list all files in the selected theme or plugin, recursing through subdirectories as necessary.
Props WraithKenny, schlessera, chsxf, MikeHansenMe, Daedalon, valendesigns, westonruter, pento.
Fixes#6531.
Built from https://develop.svn.wordpress.org/trunk@41806
git-svn-id: http://core.svn.wordpress.org/trunk@41640 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Invalidate PHP opcache after file is updated to ensure `include` will ''include'' the written changes.
* Define `WP_ADMIN` when activating plugin in sandbox so plugin code targeting admin will be loaded.
* Do actions that get triggered when loading the admin to ensure plugin code runs that could cause errors on plugin editor screen (and lock out access).
* Fix ability to re-activate a plugin after editing a PHP file other than the main plugin file, and ensure PHP fatal error will be displayed in such cases.
* Consolidate duplicated code into `plugin_sandbox_scrape()` and re-use in `activate_plugin()`.
* Show an error notice instead of a success notice when a file is updated but a plugin was deactivated due to a fatal error.
* Update style of warning when editing an active plugin to be styled as an actual warning notice.
See #12423, #21622.
Fixes#39766.
Built from https://develop.svn.wordpress.org/trunk@41560
git-svn-id: http://core.svn.wordpress.org/trunk@41393 1a063a9b-81f0-0310-95a4-ce76da25c4cd
"Install" is not a noun, and while it might be acceptable to use the verb as a noun, it is not correct. Using the correct
noun, "installation", increases clarity, especially for non-native English speakers.
This change fixes the usage in user-facing text and in developer documentation.
Fixes#41620
Built from https://develop.svn.wordpress.org/trunk@41289
git-svn-id: http://core.svn.wordpress.org/trunk@41129 1a063a9b-81f0-0310-95a4-ce76da25c4cd
At the heart of the matter, the `$menu_slug` parameter in `add_menu_page()` and `add_submenu_page()` is not sanitized with `sanitize_key()`. When the screen object is later built for the admin page, the screen ID is derived from that `$menu_slug` value, though passed through `sanitize_key()`, which can produce unexpected results in comparison check.
Changing the sanitization code to provide actual parity is out of the question at this juncture, so updating the docs to describe how to avoid this edge case is the next best option.
Props GregRoss.
Fixes#35305.
Built from https://develop.svn.wordpress.org/trunk@40967
git-svn-id: http://core.svn.wordpress.org/trunk@40817 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`register_setting` can now be passed an array arguments to specify meta-data about the setting,
much like using the `register_meta` API. Of note, it will now accept a `show_in_rest` arg to
hint the inclusion of the setting in the REST API. `get_registered_settings()` is available
as a utility to get all registered settings.
Props rmccue, aaroncampbell.
Fixes#37885.
Built from https://develop.svn.wordpress.org/trunk@38635
git-svn-id: http://core.svn.wordpress.org/trunk@38578 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Also use 'back-compat' in some inline comments where backward compatibility is the subject and shorthand feels more natural.
Note: 'backwards compatibility/compatibile' can also be considered correct, though it's primary seen in regular use in British English.
Props ocean90.
Fixes#36835.
Built from https://develop.svn.wordpress.org/trunk@37431
git-svn-id: http://core.svn.wordpress.org/trunk@37397 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Known functions, classes, and methods are now auto-linked in Code Reference pages following #meta1483.
Note: Hook references are still linked via inline `@see` tags due to the unlikelihood of reliably matching for known hooks based on a RegEx pattern.
See #32246.
Built from https://develop.svn.wordpress.org/trunk@37342
git-svn-id: http://core.svn.wordpress.org/trunk@37308 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Plugins installed in the plugins/ folder can be activated by users. This puts the plugin in an "active" state. Plugins in the mu-folder/ are "must-use" plugins that are always loaded. They can't be activated, and thereby can't be "active." Because of this, using the `is_plugin_active()` or `is_plugin_active_for_network()` returns false when checking for these plugins. This clarifies that behavior in the functions' docs.
Built from https://develop.svn.wordpress.org/trunk@36397
git-svn-id: http://core.svn.wordpress.org/trunk@36364 1a063a9b-81f0-0310-95a4-ce76da25c4cd
