This adds some extra details to the message:
* The current PHP or WordPress version.
* The plugin's minimum required PHP or WordPress version.
* A link to the support documentation on how to update PHP.
Props stuffradio, johnbillion, garrett-eclipse, sabernhardt, williampatton, SergeyBiryukov.
Fixes#48245.
Built from https://develop.svn.wordpress.org/trunk@48172
git-svn-id: http://core.svn.wordpress.org/trunk@47941 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The new names make the purpose more clear. It also adds consistency with the `$allowed_options` global variable.
Also in this change, the `wp-deprecated` dependency has been removed from the password strength meter in favor of a `window.console.log()` call to avoid adding 3 dependencies for one deprecated notice.
Props SergeyBiryukov, ocean90, desrosj
Fixes#50413.
Built from https://develop.svn.wordpress.org/trunk@48142
git-svn-id: http://core.svn.wordpress.org/trunk@47911 1a063a9b-81f0-0310-95a4-ce76da25c4cd
“The WordPress open source community cares about diversity. We strive to maintain a welcoming environment where everyone can feel included.”
With this commit, all occurrences of “whitelist” and “blacklist” (with the single exception of the `$new_whitelist_options` global variable) are removed. A new ticket has been opened to explore renaming the `$new_whitelist_options` variable (#50434).
Changing to more specific names or rewording sentences containing these terms not only makes the code more inclusive, but also helps provide clarity. These terms are often ambiguous. What is being blocked or allowed is not always immediately clear. This can make it more difficult for non-native English speakers to read through the codebase.
Words matter. If one contributor feels more welcome because these terms are removed, this was worth the effort.
Props strangerstudios, jorbin, desrosj, joemcgill, timothyblynjacobs, ocean90, ayeshrajans, davidbaumwald, earnjam.
See #48900, #50434.
Fixes#50413.
Built from https://develop.svn.wordpress.org/trunk@48121
git-svn-id: http://core.svn.wordpress.org/trunk@47890 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Partially reverts [48059] as there's no full consensus on the removal of the text prefix. Further actions should be taken to improve consistency and accessibility of the admin notices. Keeps some improvements to the translatable strings from [48059].
Fixes#47656.
Built from https://develop.svn.wordpress.org/trunk@48115
git-svn-id: http://core.svn.wordpress.org/trunk@47884 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
