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.
git-svn-id: https://develop.svn.wordpress.org/trunk@46197 602fd350-edb4-49c9-b593-d223f7449a82
* 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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45926 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45611 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45546 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45115 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@45114 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44978 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44973 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44717 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44674 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@44524 602fd350-edb4-49c9-b593-d223f7449a82
Add a `_doing_it_wrong()` message describing the correct usage of the function.
Props kraftbj, azaozz, SergeyBiryukov, YuriV.
Fixes#44142.
git-svn-id: https://develop.svn.wordpress.org/trunk@43361 602fd350-edb4-49c9-b593-d223f7449a82
WordPress' code just... wasn't.
This is now dealt with.
Props jrf, pento, netweb, GaryJ, jdgrimes, westonruter, Greg Sherwood from PHPCS, and everyone who's ever contributed to WPCS and PHPCS.
Fixes#41057.
git-svn-id: https://develop.svn.wordpress.org/trunk@42343 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@42242 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@41806 602fd350-edb4-49c9-b593-d223f7449a82
* 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.
git-svn-id: https://develop.svn.wordpress.org/trunk@41560 602fd350-edb4-49c9-b593-d223f7449a82
"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
git-svn-id: https://develop.svn.wordpress.org/trunk@41289 602fd350-edb4-49c9-b593-d223f7449a82
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.
git-svn-id: https://develop.svn.wordpress.org/trunk@40967 602fd350-edb4-49c9-b593-d223f7449a82
