As certain plugins may not support updates, this count needs to accurately reflect that in the navbar.
Fixes 50808.
Props knutsp, audrasjb, pbiron, dd32, apedog, afragen, chriscct7, garyc40, whyisjake, SergeyBiryukov.
Built from https://develop.svn.wordpress.org/trunk@48703
git-svn-id: http://core.svn.wordpress.org/trunk@48465 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This removes the toggle UI when updates aren't available. When plugins use the filter, the UI is updated to show that they are being controlled via code. And then removed entirely when not available.
See #50798.
Fixes#50280.
Props elrae, pbiron, SergeyBiryukov, audrasjb, azaozz, StephenCronin, whyisjake, dd32, TimothyBlynJacobs, desrosj.
Built from https://develop.svn.wordpress.org/trunk@48669
git-svn-id: http://core.svn.wordpress.org/trunk@48431 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
Building on core update mechanisms, this adds the ability to enable automatic updates for themes and plugins to the WordPress admin.
Fixes: #50052.
Props: afercia, afragen, audrasjb, azaozz, bookdude13, davidperonne, desrosj, gmays, gmays, javiercasares, karmatosed, knutsp, mapk, mukesh27, netweb, nicolaskulka, nielsdeblaauw, paaljoachim, passoniate, pbiron, pedromendonca, whodunitagency, whyisjake, wpamitkumar, and xkon.
Built from https://develop.svn.wordpress.org/trunk@47835
git-svn-id: http://core.svn.wordpress.org/trunk@47611 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The transient is only used in the `wp_dashboard_plugins_output()` function, which is deprecated and unused since [40607].
The function itself also sets the same transient, so it can be removed from `WP_Plugins_List_Table`.
Props aftabmuni.
Fixes#49340.
Built from https://develop.svn.wordpress.org/trunk@47167
git-svn-id: http://core.svn.wordpress.org/trunk@46967 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
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
When a plugin states it requires a specific minimum PHP version (as defined in the `requires_php` field included in the plugin update API response), a user should not be allowed to update that plugin when the server does not satisfy the minimum PHP version.
When this scenario is encountered, the update buttons and links are disabled and links to educational resources about PHP are displayed to the user with a notice.
Props afragen, schlessera, desrosj.
Fixes#43987.
Built from https://develop.svn.wordpress.org/trunk@44937
git-svn-id: http://core.svn.wordpress.org/trunk@44768 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
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
WPCS 1.0.0 includes a bunch of new auto-fixers, which drops the number of coding standards issues across WordPress significantly. Prior to running the auto-fixers, there were 15,312 issues detected. With this commit, we now drop to 4,769 issues.
This change includes three notable additions:
- Multiline function calls must now put each parameter on a new line.
- Auto-formatting files is now part of the `grunt precommit` script.
- Auto-fixable coding standards issues will now cause Travis failures.
Fixes#44600.
Built from https://develop.svn.wordpress.org/trunk@43571
git-svn-id: http://core.svn.wordpress.org/trunk@43400 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The WPCS `WordPress.WhiteSpace.PrecisionAlignment` rule throws warnings for a bunch of code that will likely cause issues for `wpcbf`. Fixing these manually beforehand gives us better auto-fixed results later.
See #41057.
Built from https://develop.svn.wordpress.org/trunk@42228
git-svn-id: http://core.svn.wordpress.org/trunk@42057 1a063a9b-81f0-0310-95a4-ce76da25c4cd
- Remove plugins icons from the plugin list table, as there were performance issues loading the icons when the site had lots of plugins.
- Depending on which icons the plugin has uploaded, prefer them in this order: `svg`, `128x128`, `256x256`.
- Improve the style of the fallback icon for plugins that don't have an icon defined.
Props Travel_girl, danieltj, afercia, karmatosed,hugobaeta, empireoflight, brentjett, melchoyce, pento.
Fixes#30186.
Built from https://develop.svn.wordpress.org/trunk@41755
git-svn-id: http://core.svn.wordpress.org/trunk@41589 1a063a9b-81f0-0310-95a4-ce76da25c4cd
To mirror theme list table behaviour, the plugin icon now appears next to plugins in the plugin list tables. For plugins that don't have an icon, or non-W.org plugins, a fallback dashicon is shown.
Props melchoyce, afercia, paulwilde, pento, obenland.
Fixes#30186.
Built from https://develop.svn.wordpress.org/trunk@41695
git-svn-id: http://core.svn.wordpress.org/trunk@41529 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `aria-current` attribute is a simple, effective way to help assistive
technologies users orientate themselves within a list of items. Continues the
introduction in core of the `aria-current` attribute after [41359] and [41371].
Props joedolson, flixos90, afercia.
Fixes#32399.
Built from https://develop.svn.wordpress.org/trunk@41683
git-svn-id: http://core.svn.wordpress.org/trunk@41517 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This introduces the following meta capabilities:
* `activate_plugin`
* `deactivate_plugin`
* `deactivate_plugins`
The singular `activate_plugin` and `deactivate_plugin` capabilities are used along with the corresponding plugin name when
determining whether or not a user can activate or deactivate an individual plugin.
The plural `deactivate_plugins` capability is used in place of the existing `activate_plugins` capability when determining
whether a user can deactivate plugins.
Each of these new meta capabilities map to the existing `activate_plugins` primitive capability, which means there is no
change in existing behaviour, but plugins can now filter the capabilities required to activate and deactivate individual
plugins.
Fixes#38652
Built from https://develop.svn.wordpress.org/trunk@41290
git-svn-id: http://core.svn.wordpress.org/trunk@41130 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Helen Hou-Sandí
Sergey Biryukov
whyisjake
John Blackbourn
desrosj
Andrew Ozz
Felix Arntz
Gary Pendergast
Andrea Fercia