You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you are updating an activated and installed plugin using a .zip file (more likely to be a commercial plugin, but you could do this with a free plugin from wordpress.org too), then on rare occasions, the plugin could be deactivated after the update is completed.
Describe how other contributors can replicate this bug
Install and activate an older version of a plugin that you intend to update with a newer version using a .zip file that you download from wordpress.org or a commercial site if it's a paid plugin.
In a browser, repeatedly load a page that uses the plugin on the site it's installed on during all the later steps.
Run "wp plugin install --force plugin_filename.zip --activate". In theory, the --activate flag is redundant (WP-CLI keeps the activation status), so you should see "Warning: Plugin 'plugin_name' is already active." when it tries to activate the plugin.
Run "wp plugin list" - displays that the plugin is now inactive!
This is an extremely rare event, but note that I haven't put the site into maintenance mode during the above steps, so this could leave it open to this scenario:
Step 3 itself outputs sub-steps to installing the updated zip file - one of them is to delete the plugin entirely from the filestore. It's possible then that a user surfed a page on the site that would go through the plugin code and WordPress detected that the plugin was deleted and then deactivated the plugin but WP-CLI itself didn't know it had been.
I suspect this issue is very hard to reproduce!
Describe what you would expect as the correct outcome
"wp plugin install --force --activate" should result in an updated and activated plugin.
Let us know what environment you are running this on
OS: Linux 5.4.0-1086-gke #93-Ubuntu SMP Mon Oct 17 13:32:57 UTC 2022 x86_64
Shell: /bin/bash
PHP binary: /usr/bin/php7.4-zend
PHP version: 7.4.33.2
php.ini used: /etc/php/7.4-zend/cli/php.ini
MySQL binary: /usr/bin/mysql
MySQL version: mysql Ver 8.0.33-0ubuntu0.22.04.2 for Linux on x86_64 ((Ubuntu))
SQL modes: STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir: phar://wp-cli.phar/vendor
WP_CLI phar path: [redacted]
WP-CLI packages dir:
WP-CLI cache dir: [redacted]
WP-CLI global config: [redacted]
WP-CLI project config:
WP-CLI version: 2.8.1
Provide a possible solution
I'm wondering if "wp plugin install --force --activate" should always attempt to activate the plugin after the update even if it thinks that it is already activated? This is justified IMHO - it's what --force --activate would imply to me.
The text was updated successfully, but these errors were encountered:
Bug Report
Describe the current, buggy behaviour
If you are updating an activated and installed plugin using a .zip file (more likely to be a commercial plugin, but you could do this with a free plugin from wordpress.org too), then on rare occasions, the plugin could be deactivated after the update is completed.
Describe how other contributors can replicate this bug
This is an extremely rare event, but note that I haven't put the site into maintenance mode during the above steps, so this could leave it open to this scenario:
Step 3 itself outputs sub-steps to installing the updated zip file - one of them is to delete the plugin entirely from the filestore. It's possible then that a user surfed a page on the site that would go through the plugin code and WordPress detected that the plugin was deleted and then deactivated the plugin but WP-CLI itself didn't know it had been.
I suspect this issue is very hard to reproduce!
Describe what you would expect as the correct outcome
"wp plugin install --force --activate" should result in an updated and activated plugin.
Let us know what environment you are running this on
Provide a possible solution
I'm wondering if "wp plugin install --force --activate" should always attempt to activate the plugin after the update even if it thinks that it is already activated? This is justified IMHO - it's what --force --activate would imply to me.
The text was updated successfully, but these errors were encountered: