Plugin Dependencies: Refresh plugin-install.php instead of redirecting on activation

[jorbin]

After [58250], upon activation of a plugin the user is redirected to plugin.php. If a user is in the midst of installing multiple plugins, it means they will need to renavigate back to where they were either via the back button or the menu. This navigation can be prevented by reloading the page instead.

[oglekler]

We have 2 days before Beta 1 and no concrete understanding on how to proceed, so, I am moving this ticket to the next milestone for further consideration.

For discussion on Slack:

hellofromtonya, May 31st, 2024
  5:58 PM
This idea was discussed yesterday in the #6-5-release-leads channel. It's a good one to consider. So instead of using the Activate button's native href behavior, do a page refresh. That way users stay in the Add Plugins UI if a plugin doesn't redirect to their configuration experience.


  5:59
It could help with one of the concerns in 6.5.4 -> to not impact users activating plugins that require plugins other than those with an onboarding / configuration.

This restores AJAX activation and instead performs a page refresh upon successful activation.

This PR has a known issue. It should not be committed unless this line is removed from the PR description.

[costdev]

I've pushed up ​PR 6717.

Known issue:

• If a plugin redirects on page load, such as to onboarding, the browser's back button will navigate to the page before the one that was used to activate the plugin.
  • Pushing a new entry to the browser's history can help resolve this. However, a new entry should only be pushed after the page reload, and only if a redirect is performed. It was proving difficult for me to identify how this could be advanced, so I pushed the reload up as PR for further investigation.

@jorbin @hellofromTonya @afragen It's my current view that finding a workable approach for this may take more time. At the moment, I'm thinking this isn't achievable for 6.6.

However, we could commit the PR and treat the known issue as a bug to fix during 6.6 Beta. This would give us more time without punting the ticket. If it isn't fixed as we approach 6.6 RC, we could then just revert it. I'm just mentioning this as a possibility, even though I'm leaning towards omitting from 6.6 at this time.

[costdev]

Note that with the page refresh instead of a redirect to plugins.php?action=activate..., plugins such as Google Listings & Ads will no longer redirect to their onboarding as they have specific checks for $_GET['action'], 'activate' === $_GET['action'] or $_POST['checked'] for bulk activation.

This means the page refresh approach will require plugins such as this to change their code.

[hellofromTonya]

Replying to costdev:

Note that with the page refresh instead of a redirect to plugins.php?action=activate..., plugins such as Google Listings & Ads will no longer redirect to their onboarding as they have specific checks for $_GET['action'], 'activate' === $_GET['action'] or $_POST['checked'] for bulk activation.

This means the page refresh approach will require plugins such as this to change their code.

Plugins with certain checks will not redirect to their configuration on page refresh / reload, as Colin noted.

Tested Google Listings & Ads plugin: Does its configuration / onboarding autoload?

• 6.5.4 RC1: Yes ✅ (after clicking "Activate" button)
• 6.4.x and older: Yes ✅ (after activation)
• 6.5.3: No ❌ (after clicking "Refresh now" or reloading "Add Plugins" UI)
• ​PR 6717 patch: No ❌ (after activation and "Add Plugins" UI reloads)

[hellofromTonya]

Replying to costdev:

However, we could commit the PR and treat the known issue as a bug to fix during 6.6 Beta. This would give us more time without punting the ticket. If it isn't fixed as we approach 6.6 RC, we could then just revert it. I'm just mentioning this as a possibility, even though I'm leaning towards omitting from 6.6 at this time.

There are 2 significant known issues with page reload approach that impact users and plugins:

• Impacts users: One-click Go Back navigation does not work, meaning the user can no longer use the browser's native "go back" button to navigate back to the Add Plugins UI from where a plugin might redirect to their welcome | configuration | onboarding. (I often use this approach to skip configuration to return to installing/activating workflow. I imagine users do too as browser's "go back" is a common and universal tool.)

• Impacts plugins (and their users if not fixed): Page reload does not trigger auto-redirect for some plugins, which will require changes in these affected plugins to restore their auto-redirect experience.

IMO knowing these challenges exist and impacts both users and plugins are red flags and indicators the approach is not ready for commit. I'm also concerned if this approach is doable and viable.

[jorbin]

I briefly explored doing this server side. This approach isn't quite perfect because it redirects to the modal as a full screen page but it doesn't have the two issues that the approached patch has. I would be up for exploring it and fixing the one issue during beta if another committer is ok with it.

diff --git a/src/wp-admin/plugins.php b/src/wp-admin/plugins.php
index 7045f16661..dcb2d594e4 100644
--- a/src/wp-admin/plugins.php
+++ b/src/wp-admin/plugins.php
@@ -78,11 +78,14 @@ if ( $action ) {
                                update_site_option( 'recently_activated', $recent );
                        }

+
                        if ( isset( $_GET['from'] ) && 'import' === $_GET['from'] ) {
                                // Overrides the ?error=true one above and redirects to the Imports page, stripping the -importer suffix.
                                wp_redirect( self_admin_url( 'import.php?import=' . str_replace( '-importer', '', dirname( $plugin ) ) ) );
                        } elseif ( isset( $_GET['from'] ) && 'press-this' === $_GET['from'] ) {
                                wp_redirect( self_admin_url( 'press-this.php' ) );
+                       } elseif ( str_contains( wp_get_referer(), 'wp-admin/plugin-install.php' ) ) {
+                               wp_redirect( wp_get_referer() );
                        } else {
                                // Overrides the ?error=true one above.
                                wp_redirect( self_admin_url( "plugins.php?activate=true&plugin_status=$status&paged=$page&s=$s" ) );

[hellofromTonya]

Tested @jorbin's diff

• Google Listings & Ads within its plugin card (not the "more details" modal): activates, its onboarding/configuration auto-loads, and can use the browser's "go back" to 1-click navigate back to the Add Plugins UI ✅ (much better than the JS approach).

• WooCommerce Payment Gateway (which does not have an auto-load onboarding experience) within the its "more details" modal: activates ✅, but reloads to the full modal page - bad user experience ❌

Yes, indeed the server-side approach does resolve the impacts of the JS approach. However, some questions:

• Is it possible and viable to reload from the modal back to the Add Plugins parent page?

• Does it impact the workflow if JS is disabled?

• Will it redirect / impact the View details links in the Plugins list table, ( i.e. which shouldn't redirect to the Add Plugins UI?

[costdev]

Interesting approach @jorbin!

Some thoughts:

1. I'm curious if there are any other circumstances in which the referrer could be plugin-install.php to plugins.php?action=activate. I don't suspect any at this time, but something that would be good to evaluate in case of potential gotchas.
2. Certainly the known issue for modals is a big one still to be solved - all the larger as dependencies are intended to be installed and activated via modal.
3. The server-side approach affects a non-JS workflow (i.e. Javascript is disabled), which should be avoided where possible. It may be the case that a solution to (2) will negate this concern.

Mindful of the time remaining before 6.6 Beta 1 commit freeze, are there currently any thoughts on resolving the modal issue?

[jorbin]

After discussion in the #core-upgrade-install room, it was decided that taking users out of their existing flow is actually a bug in the user experience. Reclassifying and restoring to 6.6.

This PR implements an alternative approach to #6717.

• Adds a $context parameter to wp_get_plugin_action_button() to conditionally modify the button's markup.
• Passes 'plugin-information-modal' as the context when generating the button inside the modal.
• When generating the Activate button, adds a redirect_to query arg with the URL-encoded referer as the value.
• When the referer is plugin-install.php, redirects to the redirect_to query arg's value, if present, or to the referrer.
  • redirect_to covers modal-based activation.
  • referer covers card-based activation.
• Ensures the JS-generated Activate button contains the redirect_to query arg, only if in the modal.

Note: Remember to build the PR branch and perform a hard refresh on plugins.php or plugin-install.php before testing.

[costdev]

Following discussion, iteration and some initial testing in #core-upgrade-install, I've opened ​PR 6732 with the latest iteration that shows promise for further review and testing.

[hellofromTonya]

Testing Instructions

These steps define how to reproduce the issue, and indicate the expected behavior.

Set up

Patch: ​https://github.com/WordPress/wordpress-develop/pull/6732
Note: After applying the patch, it needs to be built (i.e. to build the JS and its minified version) which is done by:

npm install
npm run build:dev

Notes

• The Add Plugins UI is wp-admin/plugin-install.php URL.
• The browser's native "Go back" arrow ← or button is typically to the left of the URL search field.
• Try different combinations of plugins and activate > install workflows.
• Try testing in single sites and, if possible, in multisite environments.

Test 1: Steps to test for a plugin without autoredirect and no dependencies

1. Navigate to Plugins > Add New Plugin.
2. In the plugins search box, type the name of the plugin to test (e.g. Contact Form 7) and press enter. The UI should populate with that and associated plugins.
3. In the plugin's card, press the "Install" button.
4. Once installed, then press the "Activate" button.
5. Once activated, then navigate to Plugins > Installed Plugins and deactivate the plugin.
6. Repeat steps 1-3 except in step 3, click the "More Details" link the plugin's card to open a modal. Steps 3-4 (Install and Activate) will be done in the modal.

Expected Results:

• The plugin should activate and the button should show the status of Active.
• After activation, the page should refresh / reload, but not redirect (i.e. it'll reload to stay on the Add Plugins UI).

Test 2: Steps to test for a plugin with autoredirect but no dependencies

Please deactivate and delete the plugins installed from previous tests.

1. Navigate to Plugins > Add New Plugin.
2. In the plugins search box, type the name of the plugin to test (e.g. OptinMoster or Yoast SEO) and press enter. The UI should populate with that and associated plugins.
3. In the plugin's card, press the "Install" button.
4. Once installed, then press the "Activate" button.
5. After activation and redirect, use your browser's "Go back" arrow/button to return.
6. Then navigate to Plugins > Installed Plugins and deactivate the plugin.
7. Repeat steps 1-6 except in step 3, click the "More Details" link the plugin's card to open a modal. Steps 3-4 (Install and Activate) will be done in the modal.

Expected Results:

• After activation, the plugin's setup wizard should load.
• In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• Upon returning to the Add Plugins UI, the plugin's status should show Active.

Test 3: Steps to test for a plugin without autoredirect when it requires another plugin with autodirect

Please deactivate and delete the plugins installed from previous tests.

Examples:

• Main plugin (without autoredirect): WooCommerce Stripe Payment Gateway
• Dependent plugin (with autoredirect): WooCommerce

Steps:

1. Navigate to Plugins > Add New Plugin.
2. In the plugins search box, type the name of the plugin to test (e.g. woocommerce) and press enter. The UI should populate with that and associated plugins.
3. In the "Additional plugins are required" section, activate the "More Details" link to open the modal.
4. In the modal, press the "Install" button.
5. Once installed, then press the "Activate" button.
6. After activation and redirect, use your browser's "Go back" arrow/button to return.
7. In the plugin's card, press the "Install" button.
8. Once installed, press the "Activate" button.
9. Then navigate to Plugins > Installed Plugins and deactivate the plugin.
10. Repeat steps 7-8 except in step 7, click the "More Details" link the plugin's card to open a modal. Steps 7-8 (Install and Activate) will be done in the modal.

Expected Results:
For the dependent plugin (e.g. WooCommerce):

• After activation, its setup wizard should load.
• In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• Upon returning to the Add Plugins UI, the plugin's status should show Active.

For the main plugin (e.g. WooCommerce Stripe Payment Gateway):

• After activation, the Add Plugins UI page should reload.
• After reloading, the plugin's status should show Active.

Test 4: Steps to test for a plugin with autoredirect when it requires another plugin with autodirect

Please deactivate and delete the plugins installed from previous tests.

Examples:

• Main plugin (with autoredirect): Google Listings & Ads
• Dependent plugin (with autoredirect): WooCommerce

Steps:

1. Navigate to Plugins > Add New Plugin.
2. In the plugins search box, type the name of the plugin to test (e.g. woocommerce) and press enter. The UI should populate with that and associated plugins.
3. In the "Additional plugins are required" section, activate the "More Details" link to open the modal.
4. In the modal, press the "Install" button.
5. Once installed, then press the "Activate" button.
6. After activation and redirect, use your browser's "Go back" arrow/button to return.
7. In the plugin's card, press the "Install" button.
8. Once installed, press the "Activate" button.
9. Then navigate to Plugins > Installed Plugins and deactivate the plugin.
10. Repeat steps 7-8 except in step 7, click the "More Details" link the plugin's card to open a modal. Steps 7-8 (Install and Activate) will be done in the modal.

Expected Results:
For the dependent plugin (e.g. WooCommerce):

• After activation, its setup wizard should load.
• In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• Upon returning to the Add Plugins UI, the plugin's status should show Active.

For the main plugin (with autoredirect) (e.g. Google Listings & Ads):

• After activation, should redirect to its setup wizard or main setup page.
  • In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
  • Upon returning to the Add Plugins UI, the plugin's status should show Active.

[hellofromTonya]

Why is this ticket considered a bugfix?

The goal (has been and still) is to keep the user on the Add Plugins UI after activating a plugin without auto-redirect (meaning the plugin does not contain code to redirect users to its onboarding / getting started / configuration experience).

[58250] redirected users back to the Plugins > Installed Plugins table listing page. This change was made intentionally to restore pre-6.5 behavior. The decision was made to do this ticket's fix in a major to gain the benefits of a beta/RC cycles for feedback just in case there are unknown impacts.

[hellofromTonya]

Test Report for WooCommerce plugins

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/6732

Plugins tested: all of the plugins in the 1st page of woocommerce search results. They are listed in each test section.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: See the listing in each test.

Notes:

• May need to reset WooCommerce

As I've been testing and retesting, I also needed to reset the transient in my command line tool (with the plugin not installed):

wp transient set _wc_activation_redirect 1

• How I tested:

I varied my workflow, testing different keystrokes and combinations in and out of the modal.

I also tested each plugin in 6.4.4 and 6.5.4 first before testing with the patch to compare the results.

Actual Results for Test 1: plugin without autoredirect and no dependencies

With WooCommerce (v 8.9.2) installed and activated, I tested the following plugins (in the order left-to-right, top-to-bottom in the search results):

• Customer Reviews for WooCommerce - v 5.50.0
• Checkout Field Editor (Checkout Manager) for WooCommerce - v 2.0.2
• Product Feed PRO for WooCommerce by AdTribes – WooCommerce Product Feeds - v 13.3.2
• WooCommerce Cart Abandonment Recovery - v 1.2.27
• YITH WooCommerce Wishlist - v 3.34.0
• Discount Rules for WooCommerce – Create Smart WooCommerce Coupons & Discounts - v 2.6.3
• Table Rate Shipping Method for WooCommerce by Flexible Shipping - v 4.25.0
• WooCommerce Weight Based Shipping - v 5.9.1
• Advanced Product Fields (Product Addons) for WooCommerce - v 1.6.7
• LiteSpeed Cache - v 6.2.0.1
• Flexible Checkout Fields for WooCommerce – WooCommerce Checkout Manager - v 4.1.6
• Advanced Order Export For WooCommerce - v 3.5.3

Actual Results
For all of the plugins listed above:

• ✅ The plugin should activate and the button should show the status of Active.
• ✅ After activation, the page should refresh / reload, but not redirect (i.e. it'll reload to stay on the Add Plugins UI).

Actual Results for Test 2: a plugin with autoredirect but no dependencies

Plugins:

• WooCommerce - v 8.9.2
• Mailchimp for WooCommerce - v 4.0.2
• FiboSearch – Ajax Search for WooCommerce - v 1.28.0
• Payment Plugins for PayPal WooCommerce - v 1.0.47
• Pinterest for WooCommerce - v 1.3.24

Actual Results

• ✅ After activation, the plugin's setup wizard should load.
• ✅ In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• ✅ Upon returning to the Add Plugins UI, the plugin's status should show Active.

Actual Results for Test 3: plugin without autoredirect when it requires another plugin with autodirect

Main plugins:

• WooCommerce Stripe Payment Gateway - v 8.3.1
• WooCommerce PayPal Payments - v 2.7.1
• PDF Invoices & Packing Slips for WooCommerce - v 3.8.3
• WooCommerce Square - v 4.6.2
• Google Analytics for WooCommerce - v 2.7.1
• WooCommerce Shipping & Tax - v 2.6.0
• Facebook for WooCommerce - v 3.2.3
• Variation Swatches for WooCommerce - v 2.1.0
• WooCommerce PDF Invoices, Packing Slips, Delivery Notes and Shipping Labels - v 4.5.1
• Dokan – Best WooCommerce Multivendor Marketplace Solution – Build Your Own Amazon, eBay, Etsy - v 2.7.1
• Advanced Shipment Tracking for WooCommerce - v 3.6.6
• CTX Feed – WooCommerce Product Feed Manager Plugin - v 6.4.35
• Wallet for WooCommerce - v 1.5.4

Dependent plugin: WooCommerce - v 8.9.2

Actual Results

For the dependent plugin (e.g. WooCommerce):

• ✅ After activation, its setup wizard should load.
• ✅ In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.

Upon returning to the Add Plugins UI, the plugin's status should show Active.

For each main plugin listed above:

• ✅ After activation, the Add Plugins UI page should reload.
• ✅ After reloading, the plugin's status should show Active.

Actual Results for Test 4: plugin with autoredirect when it requires another plugin with autodirect

Main Plugins:

• Google Listings & Ads - v 2.7.1
• Germanized for WooCommerce - v 3.16.9
• Payment Plugins for Stripe WooCommerce - v 3.3.71
• WooPayments: Integrated WooCommerce Payments - v 7.7.0
• Booster for WooCommerce - v 7.2.0

Dependent plugin: WooCommerce - v 8.9.2

Actual Results

For the dependent plugin (e.g. WooCommerce):

• ✅ After activation, its setup wizard should load.
• ✅ In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• ✅ Upon returning to the Add Plugins UI, the plugin's status should show Active.

For each main plugin listed above:

• ✅ After activation, should redirect to its setup wizard or main setup page.
• ✅ In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• ✅ Upon returning to the Add Plugins UI, the plugin's status should show Active.

[hellofromTonya]

Test Report for single plugins with auto-redirect (no deps)

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/6732

Plugins tested, all of which have auto-redirects after activation:

• All in One SEO (AIOSEO) - v 4.6.4
• bbPress - v 2.6.9
• BuddyPress - v 12.5.0
• Donation Forms by Charitable - v 1.8.1.7
• Duplicator – Migration & Backup Plugin - v 1.5.9
• *Easy Digital Downloads (EDD) - v 3.2.12
• Event Tickets and Registration - v 5.10.0
• ExactMetrics - v 7.27.0
• *Gallery Plugin for WordPress - Envira Photo Gallery - v 1.8.12
• Giveaways and Contests by RafflePress - v 1.12.14
• MonsterInsights - v 8.27.0
• NextGEN Gallery by Imagely - v 3.59.3
• OptinMonster - v 2.16.2
• *Paid Membership Pro - v 3.0.4
• SearchWP Live Ajax Search - v 1.8.2
• Smash Balloon Social Photo Feed - v 6.3.1
• Smash Balloon Social Post Feed - v 4.2.5
• *Stripe Payment Forms by WP Simple Pay - v 4.10.0
• The Event Calendar - v 6.5.0.1
• *Website Builder by SeedProd - v 6.17.4
• WPForms Lite - v 1.8.8.3
• *WP Mail SMTP - v 4.0.1
• *Yoast SEO - v 22.8

* indicates the plugin only redirects after the first activation. Deactivating and then reactivating will not load it again. Neither will deleting the plugin and repeating.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: See above.

Notes

My workflow in these tests:

Started with 6.4.4:

1. Navigated to the Add Plugins UI.
2. Typed the name of the plugin the search box.
3. Install > Activate using the plugin's card.
4. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to the Add Plugins UI screen.
5. Clicked the Go Back again to return to the plugins.php screen.
6. Deactivated the plugin.
7. Activated the plugin.
8. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to plugins.php screen.
9. Deactivated and deleted the plugin.

Then tested with 6.5.4:

1. Navigated to the Add Plugins UI.
2. Typed the name of the plugin the search box.
3. Install > Activate using the plugin's card.
4. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to the Add Plugins UI screen.
5. Clicked the Go Back again to return to the plugins.php screen.
6. Deactivated the plugin.
7. Activated the plugin.
8. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to plugins.php screen.
9. Deactivated the plugin.
10. Clicked the "View details" click.
11. Activated the plugin in the modal.
12. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to plugins.php screen.
13. Deactivated the plugin.
14. Navigated to the Add Plugins UI.
15. Searched again for the plugin.
16. In the plugin's card, clicked the "View Details" click.
17. In the modal, clicked the Activate button.
18. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to Add Plugins UI screen.
19. Clicked Go Back again to return to plugins.php screen.
20. Deactivated and deleted the plugin.

Then tested with 6.6 with the patch applied:
Same steps as 6.5.4.

Actual Results for Test 2: a plugin with autoredirect but no dependencies

• ✅ After activation, the plugin's setup wizard should load.
• ✅ In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• ✅ Upon returning to the Add Plugins UI, the plugin's status should show Active.
• ✅ All plugins in the list worked the same in 6.4.4, 6.5.4, and 6.6 with the patch.

Exception:

• bbPress
  • 6.4.4 plugins.php screen - does not redirect with 1st activation, but does with the next activation or on refresh.
  • ❌ 6.6 with the patch: does not redirect when activating in the Add Plugins UI, but does when returning to plugins.php screen or when a redirect happens such as activating another plugin within Add Plugins UI. For the latter, the other plugin being activated does not complete its activation.

[hellofromTonya]

bbPress - does not redirect after activation, but does when starting the activation of another plugin

[hellofromTonya]

I think the current approach needs adjustment and is not yet ready.

Why?

Found bbPress, a well-known plugin with a long history, does not work with it.

For plugins that hook into load-plugins.php to do their redirect:

• ​The current approach causes a worse user experience. When it happens, it'll confuse not only users, but also anyone debugging / triaging it (extenders, support teams, contributors, etc).
• These plugins work with 6.5.4 and < 6.5.0.

Plus, in the back of my mind, what other implementations may not work with it?

[hellofromTonya]

After talking with @johnjamesjacoby, @costdev and I brainstormed another approach. He has a promising proof of concept that he'll refine a wee bit more and then push. Monday, I'll redo my tests with it. Hopefully (fingers crossed), this adjusted approach will be viable and ready for more broad testing.

[hellofromTonya]

Test Report for bbPress

Patch tested: new approach for PR 6732 ​as of this commit

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugin: bbPress - v 2.6.9

Notes

My workflow in these tests:

I did not retest on 6.4.4 or 6.5.4, as I already did those baselines in previous test report. Started with 6.4.4:

Tested 6.6 with the PR applied:

1. Navigated to the Add Plugins UI.
2. Typed the name of the plugin the search box.
3. Install > Activate using the plugin's card.
4. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to the Add Plugins UI screen.
5. Clicked the Go Back again to return to the plugins.php screen.
6. Deactivated the plugin.
7. Activated the plugin.
8. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to plugins.php screen.
9. Deactivated the plugin.
10. Clicked the "View details" click.
11. Activated the plugin in the modal.
12. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to plugins.php screen.
13. Deactivated the plugin.
14. Navigated to the Add Plugins UI.
15. Searched again for the plugin.
16. In the plugin's card, clicked the "View Details" click.
17. In the modal, clicked the Activate button.
18. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to Add Plugins UI screen.
19. Clicked Go Back again to return to plugins.php screen.
20. Deactivated and deleted the plugin.

Actual Results for Test 2: a plugin with autoredirect but no dependencies

Testing Add Plugins UI plugin card:

• ✅ After activation, bbPress redirected to its Welcome page.
• ✅ In your browser, using its "Go back" arrow or button returns you (in one-click) to the Add Plugins UI.
• ✅ Upon returning to the Add Plugins UI, the plugin's status shows Active.

For the Add Plugins UI in the plugin's "More Details" modal:

• ✅ After activation, bbPress redirected to its Welcome page.
• ✅ In your browser, using its "Go back" arrow or button returns you (in one-click) to the Add Plugins UI.
• ✅ Upon returning to the Add Plugins UI, the plugin's status shows Active in the card and modal.

For the plugins.php table list, using Activate under the plugin listing:

• ✅ After activation, bbPress redirected to its Welcome page.
• ✅ In your browser, using its "Go back" arrow or button returns you (in one-click) to plugins.php table list.
• ✅ Upon returning, the plugin's status shows Active in the "View details" modal and within the Add Plugins UI plugin card and its modal.

For the plugins.php table list, using Activate in the plugin's "View details" modal:

• ✅ After activation, bbPress redirected to its Welcome page.
• ✅ In your browser, using its "Go back" arrow or button returns you (in one-click) to plugins.php table list.
• ✅ Upon returning, the plugin's status shows Active in the "View details" modal and within the Add Plugins UI plugin card and its modal.

Summary

✅ The new adapted patch resolves the issue found with bbPress, i.e. for plugins hooking into load-plugins.php for their redirect.

TODO:

• Search for and test other plugins using this same approach.
• Retest all plugins listed in my 2 previous test reports, i.e. to validate no impacts from the changes.

Observation

For the 1st activation, bbPress does not redirect to its Welcome UI in 6.4.4, 6.5.4, 6.6-trunk, or with this patch for 6.6. It does redirect after the first activation. Will report upstream in bbPress' Trac.

[hellofromTonya]

(Re)Test Report for single plugins with auto-redirect (no deps)

Retesting all of the plugins from the previous test report with the new changes from the patch.

Patch tested: new approach for ​PR 6732 as of this commit

Plugins retested, all of which have auto-redirects after activation:

• All in One SEO (AIOSEO) - v 4.6.4
• BuddyPress - v 12.5.0
• Donation Forms by Charitable - v 1.8.1.7
• Duplicator – Migration & Backup Plugin - v 1.5.9
• Easy Digital Downloads (EDD) - v 3.2.12
• Event Tickets and Registration - v 5.10.0
• ExactMetrics - v 7.27.0
• Gallery Plugin for WordPress - Envira Photo Gallery - v 1.8.12
• Giveaways and Contests by RafflePress - v 1.12.14
• MonsterInsights - v 8.27.0
• NextGEN Gallery by Imagely - v 3.59.3
• OptinMonster - v 2.16.2
• Paid Membership Pro - v 3.0.4
• SearchWP Live Ajax Search - v 1.8.2
• Smash Balloon Social Photo Feed - v 6.3.1
• Smash Balloon Social Post Feed - v 4.2.5
• Stripe Payment Forms by WP Simple Pay - v 4.10.0
• Sugar Calendar - v 3.0.0
• The Event Calendar - v 6.5.0.1
• Website Builder by SeedProd - v 6.17.4
• WPForms Lite - v 1.8.8.3
• WP Mail SMTP - v 4.0.1
• Yoast SEO - v 22.8

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: See above.

Notes

My workflow in these tests:

I did not retest on 6.4.4 or 6.5.4, as I already did those baselines in previous test report.

Tested 6.6 with the PR applied:

1. Navigated to the Add Plugins UI.
2. Typed the name of the plugin the search box.
3. Install > Activate using the plugin's card.
4. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to the Add Plugins UI screen.
5. Clicked the Go Back again to return to the plugins.php screen.
6. Deactivated the plugin.
7. Activated the plugin.
8. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to plugins.php screen.
9. Deactivated the plugin.
10. Clicked the "View details" click.
11. Activated the plugin in the modal.
12. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to plugins.php screen.
13. Deactivated the plugin.
14. Navigated to the Add Plugins UI.
15. Searched again for the plugin.
16. In the plugin's card, clicked the "View Details" click.
17. In the modal, clicked the Activate button.
18. After redirect to plugin's experience, clicked the browser's Go Back button, which returned me to Add Plugins UI screen.
19. Clicked Go Back again to return to plugins.php screen.
20. Deactivated and deleted the plugin.

Actual Results for Test 2: a plugin with autoredirect but no dependencies

For all 4 workflows:

• ✅ After activation, the plugin's setup wizard should load.
• ✅ In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
• ✅ Upon returning to the Add Plugins UI, the plugin's status should show Active.

[hellofromTonya]

(Re)Test Report for WooCommerce plugins

Retesting all of the plugins from the previous test report with the new changes from the patch.

Patch tested: new approach for ​PR 6732 as of this commit

Plugins tested: all of the plugins in the 1st page of woocommerce search results. They are listed in each test section.

• WooCommerce 8.9.3
• WooCommerce Stripe Payment Gateway 8.3.1
• Google Listings & Ads 2.7.2
• WooCommerce PayPal Payments 2.7.1
• PDF Invoices & Packing Slips for WooCommerce 3.8.3
• WooCommerce Square 4.6.2
• Essential Addons for Elementor – Best Elementor Templates, Widgets, Kits & WooCommerce Builders 5.9.24
• Google Analytics for WooCommerce 2.1.0
• WooCommerce Shipping & Tax 2.6.0
• Payment Plugins for Stripe WooCommerce 3.3.71
• Germanized for WooCommerce 3.16.9
• Customer Reviews for WooCommerce 5.50.1
• WooPayments: Integrated WooCommerce Payments 7.7.0
• Checkout Field Editor (Checkout Manager) for WooCommerce 2.0.2
• Facebook for WooCommerce 3.2.3
• Product Feed PRO for WooCommerce by AdTribes – WooCommerce Product Feeds 13.3.3
• WooCommerce Cart Abandonment Recovery 1.2.27
• Mailchimp for WooCommerce 4.1
• Variation Swatches for WooCommerce 2.1.0
• YITH WooCommerce Wishlist 3.34.0
• FiboSearch – Ajax Search for WooCommerce 1.28.0
• Payment Plugins for PayPal WooCommerce 1.0.48
• WooCommerce PDF Invoices, Packing Slips, Delivery Notes and Shipping Labels 4.5.2
• Discount Rules for WooCommerce – Create Smart WooCommerce Coupons & Discounts 2.6.3
• Dokan – Powerful WooCommerce Multivendor Marketplace Solution – Build Your Own Amazon, eBay, Etsy 3.11.3
• Table Rate Shipping Method for WooCommerce by Flexible Shipping 4.25.0
• Advanced Shipment Tracking for WooCommerce 3.6.6
• LiteSpeed Cache 6.2.0.1
• WooCommerce Weight Based Shipping 5.9.1
• Advanced Product Fields (Product Addons) for WooCommerce 1.6.8
• Advanced Order Export For WooCommerce 3.5.3
• Perfect Brands for WooCommerce 3.3.9
• Flexible Checkout Fields for WooCommerce – WooCommerce Checkout Manager 4.1.7
• CTX Feed – WooCommerce Product Feed Manager Plugin 6.4.36
• Variation Swatches for WooCommerce by CartFlows 1.0.8
• Booster for WooCommerce 7.2.0

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: See the listing.

Notes

• May need to reset WooCommerce

As I've been testing and retesting, I also needed to reset the transient in my command line tool (with the plugin not installed):

wp transient set _wc_activation_redirect 1

• How I tested:

1. Installed all of the plugins by going to Add Plugins UI, searching for woocommerce and installing all plugins in the 1st page of results.
2. Activated each plugin in its card.
3. Wiped the db and reinstalled via npm run env:install.
4. On the Add Plugins UI: activated each plugin within its "More Details" modal.
5. Repeated step 3.
6. On plugins.php (Plugins table listing): activated each plugin by clicking its Activate link before the plugin listing.
7. Repeated step 4.
8. On plugins.php (Plugins table listing): activated each plugin within its "View details" modal.

For each activation step, I noted:

• After activation, where did Core or the plugin redirect to?
• If a different page, does the browser Go Back return to the right page?

Actual (Re)Test Results

For all 4 workflows:
✅ After activation, the plugin's setup wizard should load.
✅ In your browser, using its "Go back" arrow or button should (in one-click) return you to the Add Plugins UI.
✅ Upon returning to the Add Plugins UI, the plugin's status should show Active.

[hellofromTonya]

Test Report for pressing Activate during activation

What happens if the user presses the Activation button more than once, i.e. while it's activating?

Patch tested: ​PR 6732 as of this commit

Steps to Test

1. Go to Plugins > Add Plugins UI, i.e. wp-admin/plugin-install.php.
2. In the search field, type bbpress.
3. In its card, press and release the Activate button multiple times. What happens?

Try it on 6.4.4 and 6.5.4 to compare the results.

Also try different plugins such as WooCommerce, WPForms, Elementor, Yoast SEO.

Expected Results

• ✅ Plugin should activate.
• ✅ Its Welcome redirect should happen after activation.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: See the listing.

Actual Results

Tested the following plugins:

• bbPress 2.6.9
• BuddyPress 2.6.9
• WooCommerce 8.9.3
• WPForms 1.8.8.3

✅ Yes, they all activate.

✅ ❌ highly inconsistent if their config / welcome / onboarding redirect happens. Happened the most on 6.4.4 and rarely on 6.6 with the patch.

[hellofromTonya]

Observation:

The "Install" button can only be pressed once. Then it changes its state to Installing with a rotating indicator that tells the user -> it's installing.

Why isn't the Activate button the same? Why doesn't it change state once it's pressed to prevent multiple presses while informing the user that it's "Activating"? cc @costdev

[hellofromTonya]

Replying to hellofromTonya:

Observation:

The "Install" button can only be pressed once. Then it changes its state to Installing with a rotating indicator that tells the user -> it's installing.

Why isn't the Activate button the same? Why doesn't it change state once it's pressed to prevent multiple presses while informing the user that it's "Activating"? cc @costdev

​Chatted in Slack -> the Install button is AJAXified, whereas the Activate is not.

Copying @costdev comments here:

The Install Now button is AJAXified, the Activate button is just a link. With PD, when it was AJAXified, the Activate button changed to Activating... -> Activated! -> Active

Since we removed the AJAX for the Activate button, it's just a link with no JS to change its state

Nevertheless, changing the state using JS is still possible, and certainly an enhancement we could make in 6.7 for example. Relatively straightforward and for non-JS, it'll be what you see now, so it's graceful.

[hellofromTonya]

Test Report - Do plugins redirect back to the Add Plugins with search results?

When the user searches for a plugin to install and activate, after its activation and if the plugin does not have its own redirect, does Core reload (i.e. redirect the user back to) the Add Plugins with the search results being displayed?

Patch tested: ​PR 6732 as of this commit

Steps to Test

1. Go to Plugins > Add Plugins UI, i.e. wp-admin/plugin-install.php.
2. In the search field, type core rollback.
3. In its card, install and activate it.
4. After activation, what page is loaded?

Expected Results

• ✅ Should return to Add Plugins UI with the search results showing:

  wp-admin/plugin-install.php?s=core%2520rollback&tab=search&type=term
  

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: Core Rollback

Actual Results

✅ Yes, it activates.

❌ doesn't reload the same page after activation.

Instead, the URL is wp-admin/plugin-install.php?s=core+rollback which is the Add Plugins UI with the search field populated with core rollback. Pressing enter repopulates the search results.

Shared these findings in ​the patch here for discussion of what might need to change in the code.

[costdev]

@hellofromTonya doesn't reload the same page after activation.
Instead, the URL is wp-admin/plugin-install.php?s=core+rollback which is the Add Plugins UI with the search field populated with core rollback. Pressing enter repopulates the search results.

I've pushed ​a commit to the PR which should resolve this.

Further details from the commit message:

Without URL-encoding, only the first ?arg=value is retained, and any &argX=valueX is lost. Wrapping wp_get_referer() in urlencode() preserves these additional query arguments.

I had a call to urlencode() there previously, but I removed it to avoid unnecessary double-encoding. In this case, encoding is necessary.

[hellofromTonya]

(Re)Test Report - Page reload after activating a plugin with no redirect

Retesting after fix for issue found in this test report.

Patch tested: ​PR 6732 as of this commit which is the fix for the bug being retested.

Scenarios - Test Paths

For plugins that do not have a redirect within them, the current page where the plugin gets activated should reload after activation.

Where? Add Plugins plugin-install.php UI

1. Search Results tab - when search for a plugin via the Search Plugins field
2. Beta Testing tab
3. Featured tab
4. Popular tab
5. Recommended tab
6. Favorites tab

Steps to Test: Search Result tab

1. Go to Plugins > Add Plugins UI, i.e. wp-admin/plugin-install.php.
2. In the search field, type core rollback.
3. In its card, install and activate it.
4. After activation, what page is reloaded?

Expected Results

• ✅ Should return to Add Plugins UI with the search results showing:

  wp-admin/plugin-install.php?s=core%2520rollback&tab=search&type=term
  

Steps to Test: Beta Testing tab

1. Click on the Beta Testing tab (assuming you are already on the Plugins > Add Plugins UI from the last test).
2. Install and activate one of the plugins, e.g. Performance Lab.
3. After activation, what page is reloaded?

Expected Results

• ✅ Should reload (return to) Add Plugins UI > Beta Testing tab:

  wp-admin/plugin-install.php?tab=beta
  

Steps to Test: Featured tab

1. Click on the Featured tab (assuming you are already on the Plugins > Add Plugins UI from the previous test).
2. Install and activate one of the plugins, e.g. Health Check & Troubleshooting.
3. After activation, what page is reloaded?

Expected Results

• ✅ Should reload (return to) Add Plugins UI > Featured tab:

  wp-admin/plugin-install.php?tab=featured
  

Steps to Test: Popular tab

1. Click on the Popular tab (assuming you are already on the Plugins > Add Plugins UI from the previous test).
2. Install and activate one of the plugins, e.g. Contact Form 7.
3. After activation, what page is reloaded?

Expected Results

• ✅ Should reload (return to) Add Plugins UI > Popular tab:

  wp-admin/plugin-install.php?tab=popular
  

Steps to Test: Recommended tab

1. Click on the Recommended tab (assuming you are already on the Plugins > Add Plugins UI from the previous test).
2. Install and activate one of the plugins, e.g. Health Check & Troubleshooting.
3. After activation, what page is reloaded?

Expected Results

• ✅ Should reload (return to) Add Plugins UI > Recommended tab:

  wp-admin/plugin-install.php?tab=recommended
  

Steps to Test: Favorites tab

1. Click on the Favorites tab (assuming you are already on the Plugins > Add Plugins UI from the previous test).
2. Type a WPORG username such as johnbillion and then press the Get Favorites button.
3. Install and activate one of the plugins, e.g. Query Monitor.
4. After activation, what page is reloaded?

Expected Results

• ✅ Should reload (return to) Add Plugins UI > Favorites tab:

  wp-admin/plugin-install.php?tab=favorites&user=johnbillion&_wpnonce=39d077365b
  

Note: The nonce will be different in your test.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 7.4
• WordPress: 6.6 trunk with the patch applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: See test instructions (I used the examples)

Actual Results

✅ Yes, the page reloads and the URL is correct for all the test scenarios.

Summary

​The fix resolves the issue.

[hellofromTonya]

Update: This Test Report comment:34 only tested in the plugin's card, not in its modal. Upon testing Activation in the modal, the same issue still exists.

❌ doesn't reload the same page after activation when activating within the modal.

[hellofromTonya]

With the last scheduled 6.6 beta happening in ~1 hour and commit freeze in effect, ran out of time to resolve the issues for this ticket/patch.

Punting to 6.7.

[costdev]

Adding needs-unit-tests to note that the PR doesn't currently have them. Once we're confident in an approach, I can add unit tests.