This adds a one-off notice to the dashboard in the event WordPress has automatically deactivated a plugin due to incompatibility with the new version of WordPress.
Introduces the new private function `deactivated_plugins_notice()` to display the notice in the dashboard. Introduces the new auto-loaded option `wp_force_deactivated_plugins` to store a list of automatically deactivated plugins; the option is used on both a site and network level.
Follow up to [51180].
Props desrosj, jorbin, azaozz, SergeyBiryukov, peterwilsoncc.
See #53432.
Built from https://develop.svn.wordpress.org/trunk@51266
git-svn-id: http://core.svn.wordpress.org/trunk@50875 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This affects:
* `validate_plugin_requirements()`
* `validate_theme_requirements()`
Historically, the `Requires PHP` header was introduced in #meta2952 for the Plugin Directory first, so at the time it made sense to have it defined in the same place as `Requires at least`, which only existed in `readme.txt`.
Since parsing of PHP and WordPress requirements was later added to WordPress core, the core should retrieve all the necessary data from the main plugin or theme file and not from `readme.txt`, which only contains the data meant for the Plugin or Theme Directory.
The recommended place for `Requires PHP` and `Requires at least` headers is as follows:
* The plugin's main PHP file
* The theme's `style.css` file
The place for the `Tested up to` header remains in `readme.txt` for the time being, as it's not used by WordPress core.
Follow-up to [44978], [45546], [47573], [47574], [meta5841], [meta9050].
Props afragen, Otto42, joyously, williampatton, audrasjb.
Fixes#48520. See #48515, #meta2952, #meta4514, #meta4621.
Built from https://develop.svn.wordpress.org/trunk@51092
git-svn-id: http://core.svn.wordpress.org/trunk@50701 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This allows third-party plugins to avoid accidentally being overwritten with an update of a plugin of a similar name from the WordPress.org Plugin Directory.
Additionally, introduce the `update_plugins_{$hostname}` filter, which third-party plugins can use to offer updates for a given hostname.
If set, the `Update URI` header field should be a URI and have a unique hostname.
Some examples include:
* `https://wordpress.org/plugins/example-plugin/`
* `https://example.com/my-plugin/`
* `my-custom-plugin-name`
`Update URI: false` also works, and unless there is code handling the `false` hostname, the plugin will never get an update notification.
If the header is present, the WordPress.org API will currently only return updates for the plugin if it matches the following format:
* `https://wordpress.org/plugins/{$slug}/`
* `w.org/plugin/{$slug}`
If the header has any other value, the API will not return a result and will ignore the plugin for update purposes.
Props dd32, DavidAnderson, meloniq, markjaquith, DrewAPicture, mweichert, design_dolphin, filosofo, sean212, nhuja, JeroenReumkens, infolu, dingdang, joyously, earnjam, williampatton, grapplerulrich, markparnell, apedog, afragen, miqrogroove, rmccue, crazycoders, jdgrimes, damonganto, joostdevalk, jorbin, georgestephanis, khromov, GeekStreetWP, jb510, Rarst, juliobox, Ipstenu, mikejolley, Otto42, gMagicScott, TJNowell, GaryJ, knutsp, mordauk, nvartolomei, aspexi, chriscct7, benoitchantre, ryno267, lev0, gregorlove, dougwollison, SergeyBiryukov.
See #14179, #23318, #32101.
Built from https://develop.svn.wordpress.org/trunk@50921
git-svn-id: http://core.svn.wordpress.org/trunk@50530 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This avoids accidentally overriding some variables in the scope of `activate_plugin()`, e.g. `$silent` or `$network_wide`.
Plugins expecting to have access to `$network_wide` directly on inclusion should receive it as an argument of the activation hook callback instead, on any of these actions:
* `activate_plugin`
* `activate_{$plugin}`
* `activated_plugin`
Follow-up to [28644].
Props Mike_Cowobo, dd32, DrewAPicture, mensmaximus, SergeyBiryukov.
Fixes#31104.
Built from https://develop.svn.wordpress.org/trunk@50787
git-svn-id: http://core.svn.wordpress.org/trunk@50396 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This change renames `$new_whitelist_options` to `$new_allowed_options`. This makes the variable’s purpose more clear, and promotes using more inclusive language.
For backwards compatibility, the new variable is passed by reference to the old one.
Follow up to [48121].
Props ayeshrajans, desrosj, jorbin, SergeyBiryukov.
See #50413.
Fixes#50434.
Built from https://develop.svn.wordpress.org/trunk@48477
git-svn-id: http://core.svn.wordpress.org/trunk@48246 1a063a9b-81f0-0310-95a4-ce76da25c4cd
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
