Notice of plugins disabled in WP upgrade. #1431
Conversation
src/wp-admin/includes/plugin.php
Outdated
| if ( false === $deactivated_plugins ) { | ||
| // Option not in database, add an empty array to avoid extra DB queries on subsequent loads. | ||
| update_option( 'wp_deactivated_plugins', array() ); | ||
| return; | ||
| } |
There was a problem hiding this comment.
May be better to add an upgrade_580() to https://github.com/WordPress/wordpress-develop/blob/master/src/wp-admin/includes/upgrade.php#L689. Something like:
function upgrade_580() {
// Do add_option() to not overwrite existing option.
add_option( 'wp_deactivated_plugins', array() );
}
|
Looks good imho. Just trying to think if there might be something unexpected on multisite installs, or if this should be disabled there. |
|
Docs fix and renaming the option pushed in e693d51 and ba0d814 respectively. Moving back to figuring out how to deactivate on MS sub-site installs with cleaner code than https://gist.github.com/peterwilsoncc/689be020e5aa6561b0189cba59090c26 |
|
In 7fb3635 I've added a check to disable the plugin if it's active when the DB upgrade script runs, this is mainly for use on multisite it should be disabled by the time the code runs on a single site install. I'm not very happy with the code but haven't been able to think of an alternative approach that might be neater. A question to ask is whether this is even worth doing given the code has to be so ugly. The maintenance of a multisite install is considered advanced WordPress so maybe it's best handled by a dev-note and falling back to site-health pausing the plugin if the site's maintainer fails to take action. |
src/wp-admin/includes/upgrade.php
Outdated
| 'version_deactivated' => $gutenberg_version, | ||
| 'version_compatible' => '10.8', | ||
| ); | ||
| if ( is_plugin_active_for_network( 'gutenberg/gutenberg.php' ) ) { |
There was a problem hiding this comment.
Something about this blog feels weird to me. I'm wondering if it's possible for a site to have activated a plugin and then for the plugin to have been activated network-wide and if so, what would happen here. This might be a nonissue ( that network activating a plugin causes it to be deactivated on individual sites) or this might be such an edge case that we don't need to worry about.
I think it also might make sense to abstract this out a bit into something like a wp_set_deactivated_plugin function
| * @since 5.8.0 | ||
| * @access private | ||
| * | ||
| * @global string $pagenow |
There was a problem hiding this comment.
Looks like the @global $wp_version is also being used in the function.
I originally had pictured this as a one off check/disable that we could remove after the plugin raised its minimum WP requirement. But, I think this is much better for reuse long term. With that in mind, I think it would be fine to include what we have here and refine later, or to circle back to multisite in 5.8.1 or 5.9 to try and come up with a more elegant solution. The function is marked as |
|
To get something in to RC 1, I've just pushed the following:
|
Trac ticket: https://core.trac.wordpress.org/ticket/53432
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.