Fix plugin deactivation during force install with explicit --activate flag

[Copilot]

Summary of Changes

Successfully addressed all review feedback from @copilot-pull-request-reviewer[bot]:

Code Changes (commits 1b639da and c13bbd5)

Problem: When activate() is called from install command and the plugin is already active, activate_plugin() returns WP_Error('plugin_already_active'), which was treated as a failure.

Solution:

1. Restructured activation logic (lines 389-410):

   • --force flag always deactivates before reactivating (runs activation hooks)
   • This behavior is consistent regardless of chained_command state
   • When not using --force and chained_command is true, fall through to activate_plugin()

2. Handle 'plugin_already_active' error (lines 419-425):

   • When called from install (chained_command = true)
   • And activate_plugin() returns WP_Error('plugin_already_active')
   • Treat as success (not failure) since desired state is achieved
   • This handles race conditions during install where WordPress preserves activation

Test Changes (commit c13bbd5)

Previous tests: Used --force --activate which doesn't exercise the fix (force always deactivates first)

Updated tests: Install already-active plugins with --activate (no --force):

• Single-site: wp plugin install hello-dolly --activate on already-active plugin
• Multisite: wp plugin install hello-dolly --activate-network on already-network-active plugin
• These actually trigger the code path where activate_plugin() returns 'plugin_already_active'

Verification

✅ All linting checks pass
✅ Code style (phpcs) passes
✅ Static analysis (phpstan) passes
✅ Replied to all review comments

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Updating an activated installed plugin using a .zip file can leave the plugin deactivated after the update</issue_title>
<issue_description>## Bug Report

• Yes, I reviewed the contribution guidelines.
• Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

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

1. 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.
2. In a browser, repeatedly load a page that uses the plugin on the site it's installed on during all the later steps.
3. 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.
4. 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 wp-cli/extension-command#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.</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Updating an activated installed plugin using a .zip file can leave the plugin deactivated after the update #365

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.