With this change, fatal errors recorded before a plugin was deactivated or a theme was switched away from do not persist. This ensures that re-enabling it re-checks for fatal errors correctly.
Props aandrewdixon, dhanukanuwan, henrywright.
Fixes#46812.
Built from https://develop.svn.wordpress.org/trunk@45115
git-svn-id: http://core.svn.wordpress.org/trunk@44924 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to this change, resuming or activating a plugin or theme that is still broken would result in a redirect loop if in recovery mode. If outside recovery mode, it would cause the error template to be displayed.
Furthermore this applies to breaking a plugin or theme when editing from the backend.
Props aandrewdixon, azaozz, dhanukanuwan, henrywright, ocean90, ohiosierra, PandelisZ, xkon.
Fixes#46045, #46751.
Built from https://develop.svn.wordpress.org/trunk@45114
git-svn-id: http://core.svn.wordpress.org/trunk@44923 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduce `validate_plugin_requirements()` for validating a plugin's WordPress and PHP version requirements.
Introduce `wp_is_wp_compatible()` and `wp_is_php_compatible()` for checking compatibility with the current WordPress or PHP version.
Props afragen, joyously, DrewAPicture, TimothyBlynJacobs, desrosj, flixos90, SergeyBiryukov.
See #43992.
Built from https://develop.svn.wordpress.org/trunk@44978
git-svn-id: http://core.svn.wordpress.org/trunk@44809 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Using the new fatal handler introduced in [44962], an email is sent to the admin when a fatal error occurs. This email includes a secret link to enter recovery mode. When clicked, the link will be validated and on success a cookie will be placed on the client, enabling recovery mode for that user. This functionality is executed early before plugins and themes are loaded, in order to be unaffected by potential fatal errors these might be causing.
When in recovery mode, broken plugins and themes will be paused for that client, so that they are able to access the admin backend despite of these errors. They are notified about the broken extensions and the errors caused, and can then decide whether they would like to temporarily deactivate the extension or fix the problem and resume the extension.
A link in the admin bar allows the client to exit recovery mode.
Props timothyblynjacobs, afragen, flixos90, nerrad, miss_jwo, schlessera, spacedmonkey, swissspidy.
Fixes#46130, #44458.
Built from https://develop.svn.wordpress.org/trunk@44973
git-svn-id: http://core.svn.wordpress.org/trunk@44804 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
Further, introduce a new `delete_plugin` action hook, to be fired ''before'' a plugin deletion attempt. Both changes bring parity with other such transactional hooks in core that fire before and after certain actions, including on plugin activation/deactivation and install/uninstall, among others.
Props johnjamesjacoby.
Fixes#26904.
Built from https://develop.svn.wordpress.org/trunk@35669
git-svn-id: http://core.svn.wordpress.org/trunk@35633 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `_network_option()` parameter order will be changing to accept `$network_id` first. The `_site_option()` functions will remain in use throughout core as our way of retrieving a network option for the current network.
See #28290.
Built from https://develop.svn.wordpress.org/trunk@34912
git-svn-id: http://core.svn.wordpress.org/trunk@34877 1a063a9b-81f0-0310-95a4-ce76da25c4cd
`admin-filters.php`
`ms-admin-filters.php`
There are random actions and filters littered among files like `misc.php`. These files contain functions that won't work outside of admin context and are typically only loaded in files that have already loaded the admin bootstrap.
See #32529.
Built from https://develop.svn.wordpress.org/trunk@32653
git-svn-id: http://core.svn.wordpress.org/trunk@32623 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Affects DocBlocks for the following core elements:
* Markdown-indent a code snippet in the description for `wp_salt()`
* Backtick-escape inline code in the return description for `get_avatar()`
* Various markdown formatting in the description for `add_filter()`
* Markdown-indent a code snippet in the description for `apply_filters()`
* Backtick-escape inline code in the `@see` description for `apply_filters_ref_array()`
* Backtick-escape inline code in the description for `do_action()`
* Backtick-escape variables in the parameter and return descriptions for `do_action_ref_array()`
* Various markdown formatting in the description for `get_plugin_data()`
Props rarst.
See #30473.
Built from https://develop.svn.wordpress.org/trunk@30544
git-svn-id: http://core.svn.wordpress.org/trunk@30533 1a063a9b-81f0-0310-95a4-ce76da25c4cd
