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
Prior to about 2013, many class methods lacked even access modifiers which made the `@access` notations that much more useful. Now that we've gotten to a point where the codebase is more mature from a maintenance perspective and we can finally remove these notations. Notable exceptions to this change include standalone functions notated as private as well as some classes still considered to represent "private" APIs.
See #41452.
Built from https://develop.svn.wordpress.org/trunk@41161
git-svn-id: http://core.svn.wordpress.org/trunk@41001 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Introduces some consistency in the usage of the button CSS classes, fixes the
focus style for accessibility and responsiveness of the buttons.
- Adds the `button` class to all primary buttons make them responsive
- Removes all `secondary-button` classes and replaces it with button when needed. `button-secondary` shouldn't be used and exists just for backward compatibility reasons
- Replaces classes inside `submit_button()` with a shorthand for some buttons, and use an empty string for the default `button` class. Passing `button` is unnecessary
- Adjusts `get_submit_button()` to remove empty items
Props iseulde, dimchik, chris_d2d, mhowell, afercia.
Fixes#27314, #37138, #37448.
Built from https://develop.svn.wordpress.org/trunk@38672
git-svn-id: http://core.svn.wordpress.org/trunk@38615 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Update DocBlock to use third-person singular verb and to include a period at the end.
* Use `submit_button()` for the submit button.
* Escape the ID attribute.
* Apply the same to `WP_List_Table::search_box()`.
See #37230.
Built from https://develop.svn.wordpress.org/trunk@38146
git-svn-id: http://core.svn.wordpress.org/trunk@38087 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Gone are the days of isolation and feelings of "meh", brought on by The Bleak Screen of Sadness. For a shiny knight has arrived to usher our plugins and themes along their arduous journey of installation, updates, and the inevitable fate of ultimate deletion.
Props swissspidy, adamsilverstein, mapk, afragen, ocean90, ryelle, j-falk, michael-arestad, melchoyce, DrewAPicture, AdamSoucie, ethitter, pento, dd32, kraftbj, Ipstenu, jorbin, afercia, stephdau, paulwilde, jipmoors, khag7, svovaf, jipmoors, obenland.
Fixes#22029, #25828, #31002, #31529, #31530, #31773, #33637, #35032.
Built from https://develop.svn.wordpress.org/trunk@37714
git-svn-id: http://core.svn.wordpress.org/trunk@37680 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The plugin details modal can be invoked from several screens. There's now a new
`.open-plugin-details-modal` CSS class to be used in combination with the
`.thickbox` CSS class that adds everything needed for accessibility.
- Adds an ARIA role `dialog` and an `aria-label` attribute to the modal
- Adds a `title` attribute to the iframe inside the modal
- Constrains tabbing within the modal
- Restores focus back in a proper place when closing the modal
Also, improves a bit the native Thickbox implementation: it should probably be
replaced with some more modern tool but at least keyboard focus should be moved
inside the modal.
Fixes#33305.
Built from https://develop.svn.wordpress.org/trunk@36964
git-svn-id: http://core.svn.wordpress.org/trunk@36932 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Many new users do not know the difference between managing installed plugins and those found in the plugin directory. This helps with discoverability. The link is not provided in multisite installs because we assume that somebody with that kind of power in a network is experienced enough not to need it. This can always be reconsidered later.
props mordauk for the initial patch.
fixes#29865.
Built from https://develop.svn.wordpress.org/trunk@35808
git-svn-id: http://core.svn.wordpress.org/trunk@35772 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These plugins are only shown to users with the `manage_network_plugins` capability, which is Super Admins by default. This new feature lowers the blood pressure of Super Admins who may browse or search the Plugins listing screen of an individual site, having forgotten that a particular plugin is network-active. Showing inactive network-only plugins here also reduces friction when searching the Plugins listing screen on individual sites.
This change introduces a `show_network_active_plugins` filter which controls whether the network-active plugins and inactive network-only plugins are shown. This can be used to enable this functionality for regular site admininstrators, or, indeed, to disable this functionality for Super Admins.
Fixes#20104
Built from https://develop.svn.wordpress.org/trunk@35151
git-svn-id: http://core.svn.wordpress.org/trunk@35117 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The `_network_option()` parameter order will be changing to accept `$network_id` first. The `_site_option()` functions will remain in use throughout core as our way of retrieving a network option for the current network.
See #28290.
Built from https://develop.svn.wordpress.org/trunk@34912
git-svn-id: http://core.svn.wordpress.org/trunk@34877 1a063a9b-81f0-0310-95a4-ce76da25c4cd
These shouldn't be able to have their primary column reassigned by default. Also removes the `has-row-actions` class as these list tables always have row actions visible and the JS for visual toggling conflicts. The `column-primary` class remains.
props stephdau.
see #25408.
Built from https://develop.svn.wordpress.org/trunk@32686
git-svn-id: http://core.svn.wordpress.org/trunk@32656 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This becomes the column that contains the row actions, and allows for a more flexibility, particularly with custom post types and list tables. To (re)define the primary column, use the `list_table_primary_column` filter, which receives the column name and the screen ID as arguments.
props stephdau, DaveAl, jesin.
see #25408.
Built from https://develop.svn.wordpress.org/trunk@32644
git-svn-id: http://core.svn.wordpress.org/trunk@32614 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Shiny updates depends upon information from the update_plugins site transient in order to set data- attributes which are used by JavaScript. Since /wp-admin/plugins.php?plugin_status=upgrade uses `$plugin['upgrade']` rather than `$plugins['all']`, we need to fill that information in both places.
Fixes#31738.
Built from https://develop.svn.wordpress.org/trunk@31872
git-svn-id: http://core.svn.wordpress.org/trunk@31851 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* `WP_List_Table` is the base class that implements `__get()` and `__call()` for BC
* Adds unit tests to confirm that subclasses properly inherit magic methods
* Add modifiers to subclasses: `WP_Links_List_Table`, `WP_Media_List_Table`, `WP_MS_Sites_List_Table`, `WP_MS_Themes_List_Table`, `WP_MS_Users_List_Table`, `WP_Plugin_Install_List_Table`, `WP_Plugins_List_Table`, `WP_Posts_List_Table`, `WP_Terms_List_Table`, `WP_Theme_Install_List_Table`, `WP_Themes_List_Table`
See #27881, #22234.
Built from https://develop.svn.wordpress.org/trunk@28493
git-svn-id: http://core.svn.wordpress.org/trunk@28319 1a063a9b-81f0-0310-95a4-ce76da25c4cd
The exceptions to this are update_post_meta() and add_post_meta() which are often used by plugins in POST handlers and will continue accepting slashed data for now.
Introduce wp_upate_post_meta() and wp_add_post_meta() as unslashed alternatives to update_post_meta() and add_post_meta(). These functions could become methods in WP_Post so don't use them too heavily yet.
Remove all escape() calls from wp_xmlrpc_server. Now that core expects unslashed data this is no longer needed.
Remove addslashes(), addslashes_gpc(), add_magic_quotes() calls on data being prepared for handoff to core functions that until now expected slashed data. Adding slashes in no longer necessary.
Introduce wp_unslash() and use to it remove slashes from GPCS data before using it in core API. Almost every instance of stripslashes() in core should now be wp_unslash(). In the future (a release or three) when GPCS is no longer slashed, wp_unslash() will stop stripping slashes and simply return what is passed. At this point wp_unslash() calls can be removed from core.
Introduce wp_slash() for slashing GPCS data. This will also turn into a noop once GPCS is no longer slashed. wp_slash() should almost never be used. It is mainly of use in unit tests.
Plugins should use wp_unslash() on data being passed to core API.
Plugins should no longer slash data being passed to core. So when you get_post() and then wp_insert_post() the post data from get_post() no longer needs addslashes(). Most plugins were not bothering with this. They will magically start doing the right thing. Unfortunately, those few souls who did it properly will now have to avoid calling addslashes() for 3.6 and newer.
Use wp_kses_post() and wp_kses_data(), which expect unslashed data, instead of wp_filter_post_kses() and wp_filter_kses(), which expect slashed data. Filters are no longer passed slashed data.
Remove many no longer necessary calls to $wpdb->escape() and esc_sql().
In wp_get_referer() and wp_get_original_referer(), return unslashed data.
Remove old stripslashes() calls from WP_Widget::update() handlers. These haven't been necessary since WP_Widget.
Switch several queries over to prepare().
Expect something to break.
Props alexkingorg
see #21767
git-svn-id: http://core.svn.wordpress.org/trunk@23416 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Sergey Biryukov
Felix Arntz
desrosj
Gary Pendergast
John Blackbourn
Andrea Fercia
Drew Jaynes
Pascal Birchler
Dominik Schilling
Konstantin Obenland
Helen Hou-Sandí
Scott Taylor
Jeremy Felt
Aaron Jorbin
Andrew Nacin
Ryan Boren