Add --force flag to plugin activate to re-run activation hooks

[Copilot]

Summary

This PR adds a --force flag to wp plugin activate command that forces re-running activation hooks even if the plugin is already active. When both --activate and --force flags are used with wp plugin install, the force behavior is passed through to the activate command.

Implementation Checklist

• Add --force flag to wp plugin activate command that forces re-running activation hooks
  • Update the docblock to document the new --force flag
  • Modify the activate() method to check for the --force flag
  • When --force is set and plugin is already active, deactivate then reactivate to trigger hooks
  • Fix --all and --force interaction to allow force re-activation with --all flag
• Update wp plugin install to pass --force to activate when both flags are present
  • Modify CommandWithUpgrade::install() to pass force flag when calling activate
• Add tests for the new functionality
  • Test wp plugin activate --force on an already active plugin
  • Removed duplicate test from plugin-install.feature (covered in plugin-activate.feature)
• Run tests to validate changes
  • PHP Lint check passed
  • PHP CodeSniffer passed
  • PHPStan static analysis passed
• Address code review feedback
  • Clarified documentation for --force flag behavior
  • Added error suppression in test activation hooks
  • Simplified install test per reviewer feedback
  • Fixed --all --force interaction bug
  • Removed duplicate test
• Fix failing tests
  • Corrected expected output for already-active plugin scenario
  • Updated install test to use simpler approach
• Security check completed (CodeQL - no issues found)

Use Case

This is particularly useful when a plugin is activated but in a weird state. For example, WP Super Cache installs an advanced-cache.php dropin when activated. If that file gets deleted, the plugin remains activated but doesn't work properly. Running wp plugin activate wp-super-cache --force will now re-run the activation hooks and recreate the dropin file.

Files Changed

• src/Plugin_Command.php: Added --force flag handling to activate() method with proper --all interaction
• src/WP_CLI/CommandWithUpgrade.php: Modified install() to pass force flag to activate
• features/plugin-activate.feature: Added comprehensive test for force activate
• features/plugin-install.feature: Removed duplicate test

Total changes: 4 files changed, 52 insertions(+), 43 deletions(-)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Activation hooks are not run with --activate --force and already activated plugins</issue_title>
<issue_description>## Feature Request

When running wp plugin install plugin --activate --force

It won't run activation hooks if the plugin is already activated:

extension-command/src/Plugin_Command.php

Lines 352 to 356 in 12618c7

	// Don't reactivate active plugins, but do let them become network-active.
	if ( ! $network_wide && 'active' === $status ) {
	WP_CLI::warning( "Plugin '{$plugin->name}' is already active." );
	continue;
	}

It would be nice if --force also triggered the activation hooks, because it is possible for a plugin to be activated but in a weird state where the activation hooks can fix it.

As an example:

WP Super Cache installs an advanced-cache.php dropin when activated. If something deletes that file, the plugin can be activated but now not work properly. Running wp plugin install wp-super-cache --activate --force will output:

Installing WP Super Cache (1.11.0)
Downloading installation package from https://downloads.wordpress.org/plugin/wp-super-cache.1.11.0.zip...
Unpacking the package...
Installing the plugin...
Removing the old version of the plugin...
Plugin updated successfully.

Which makes it seem like a full replacement, but it won't recreate advanced-cache.php because it doesn't actually run the activation hooks anywhere above. If you deactivate the plugin first and then run the command, it will run the activation hooks and recreate it. But then you have any side effects that might come from deactivating it. I think it would make sense if the existing --force option also bypassed the check above and cause it to run the activation hooks again as part of Installing the plugin...</issue_description>

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

@danielbachhuber I'm open to this, but a little uncertain about it. The change in behavior might be unexpected for existing usage.

Should we also add a --force flag for wp plugin activate ?

@schlessera @swissspidy Thoughts?</comment_new>
<comment_new>@mrsdizzie
Looking down a bit, the --activate flag does already cause an initial deactivation if switching an active plugin to network mode, so there is somewhat mixed behavior in the current implementation.

extension-command/src/Plugin_Command.php

Lines 352 to 361 in 12618c7

	// Don't reactivate active plugins, but do let them become network-active.
	if ( ! $network_wide && 'active' === $status ) {
	WP_CLI::warning( "Plugin '{$plugin->name}' is already active." );
	continue;
	}
	// Plugins need to be deactivated before being network activated.
	if ( $network_wide && 'active' === $status ) {
	deactivate_plugins( $plugin->file, false, false );
	}

But you are right, the actual --force behavior should belong to wp plugin activate and it should just be triggered when wp plugin install is used with both --activate --force</comment_new>
<comment_new>@swissspidy

I'm open to this, but a little uncertain about it. The change in behavior might be unexpected for existing usage.

Same here. I wonder what could break here, as it would mean running the activation hook for a plugin that's already active. Plus, would we need to do the same sandboxing as activate_plugin() does?

Should rather be the job of plugins like WP Super Cache to detect whether they are correctly set up and provide guidance to users on how to fix issues?

@mrsdizzie It isn't really about needing a solution to a particular plugin issue, it is more about the expected behavior of a "force install and activate" command. With this output:

Installing the plugin...

I would expect it to behave the same as if installing a new plugin. Specifically, I'd expect --force to ignore all types of "does this already exist and should we skip it" checks, but it only ignores some (replacing the existing files).

Maybe it is just confusing having the two flags --force and --activate but having them not be related to each other at all. If wp plugin activate had a --force flag you would assume it caused activation hooks to be run always, but it is more ambiguous here what --force will do in this example.

In any case, deactivating the plugin first will cause the hooks to be run again and I'll use that as a work around -- so this isn't a huge problem without a solution. When switching network states, this command already deactivates and the reactivates the plugin, so I assume something similar would happen even if this was implemented.</comment_new>
<comment_new>@swissspidy
I definitely see how that's ambiguous, especially with the wording that doesn't indicate that it's installing an already active plugin. Perhaps we could at least add some info message or something?

Just wary of actually running the hook as it could potentially cause issues

Related: https://core.trac.wordpress.org/ticket/52281

• Fixes Activation hooks are not run with --activate --force and already activated plugins #390

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[codecov]

Codecov Report

❌ Patch coverage is 84.21053% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/WP_CLI/CommandWithUpgrade.php	77.77%	2 Missing ⚠️
src/Plugin_Command.php	90.00%	1 Missing ⚠️

📢 Thoughts on this report? Let us know!