For a number of years, most of the WordPress error messages have been prefixed with "Error:". However, these messages appear in a context where it's already clear an error occurred. Whether it's an error, a warning, or any other classification, that's not so relevant for users. The content of the message is the relevant part. The "Error:" prefix doesn't add great value while it does add unnecessary complexity for the message readability.
Also, revises some of these messages to improve clarity and removes HTML from translatable strings.
Props garrett-eclipse, ramiy, SergeyBiryukov, afercia, sabernhardt, quadthemes, audrasjb.
See #47003, #43037, #42945, #15887.
Fixes#47656.
Built from https://develop.svn.wordpress.org/trunk@48059
git-svn-id: http://core.svn.wordpress.org/trunk@47826 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids the performance overhead of the function call every time `dirname( __FILE__ )` was used instead of `__DIR__`.
This commit also includes:
* Removing unnecessary parentheses from `include`/`require` statements. These are language constructs, not function calls.
* Replacing `include` statements for several files with `require_once`, for consistency:
* `wp-admin/admin-header.php`
* `wp-admin/admin-footer.php`
* `wp-includes/version.php`
Props ayeshrajans, desrosj, valentinbora, jrf, joostdevalk, netweb.
Fixes#48082.
Built from https://develop.svn.wordpress.org/trunk@47198
git-svn-id: http://core.svn.wordpress.org/trunk@46998 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Due to a confusion with `add_menu_page()`, which takes the `$icon_url` parameter, while `add_submenu_page()` does not, some plugins were passing in a string instead of integer as `$position`, causing backward compatibility issues.
A `_doing_it_wrong()` message is now added to alert developers of the wrong parameter type.
Props david.binda, desrosj, 123host, dennis_f, MattyRob.
Reviewed by desrosj.
Fixes#48249.
Built from https://develop.svn.wordpress.org/trunk@46570
git-svn-id: http://core.svn.wordpress.org/trunk@46367 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add a position argument to the `add_submenu_page` function similar to the one already in `add_menu_page`. When adding sub menus enables setting the position in the sub menu where the item should appear.
In addition, add the position argument to functions that call `add_submenu_page` under the hood: `add_management_page`, `add_options_page`, `add_theme_page`, `add_plugins_page`, `add_users_page`, `add_dashboard_page`, `add_posts_page`, `add_media_page`, `add_links_page`, `add_pages_page` and `add_comments_page`.
Props welcher, birgire, alexvorn2.
Fixes#39776.
Built from https://develop.svn.wordpress.org/trunk@46197
git-svn-id: http://core.svn.wordpress.org/trunk@46009 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Add missing translator comments.
* Fix placement of some translator comments. Translator comments should be on the line directly above the line containing the translation function call for optimal compatibility with various `.pot` file generation tools. The CS auto-fixing, which changed some inconsistent function calls to multi-line function calls, is part of the reason why this was no longer the case for a select group of translator comments.
Includes minor code layout fixes.
Polyglots, rejoice! All WordPress core files now have translator comments for all strings with placeholders!
Props jrf, subrataemfluence, GaryJ, webdados, Dency, swissspidy, alvarogois, marcomartins, mihaiiceyro, vladwtz, niq1982, flipkeijzer, michielatyoast, chandrapatel, thrijith, joshuanoyce, FesoVik, tessak22, bhaktirajdev, cleancoded, dhavalkasvala, garrett-eclipse, bibliofille, socalchristina, priyankkpatel, 5hel2l2y, adamsilverstein, JeffPaul, pierlo, SergeyBiryukov.
Fixes#44360.
Built from https://develop.svn.wordpress.org/trunk@45926
git-svn-id: http://core.svn.wordpress.org/trunk@45737 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Noteable changes:
- The `magic_quotes_runtime` and `magic_quotes_sybase` settings were removed in PHP 5.4, so no longer need to be set.
- Some functions that use external libraries can generate errors that can't be tested for, so are globally allowed to silence errors.
- Quite a few functions would cause errors if `safe_mode` was set. This setting was removed in PHP 5.4.
- Only a handful of `header()` calls needed corresponding `headers_sent()` checks for unit tests to pass, but more may need to be added as the nightlies builds are tested.
See #46732.
Built from https://develop.svn.wordpress.org/trunk@45611
git-svn-id: http://core.svn.wordpress.org/trunk@45422 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows for blocking plugin activation if it requires a higher version of PHP or WordPress, and does not have a `readme.txt` file.
If the headers are defined in both `readme.txt` and the main plugin file, precedence is given to the plugin file.
Props afragen, Otto42, Ipstenu.
Fixes#46938.
Built from https://develop.svn.wordpress.org/trunk@45546
git-svn-id: http://core.svn.wordpress.org/trunk@45357 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
