Plugin Dependencies: Change AJAX activation handler to restore auto-redirect after plugin activation

[hellofromTonya]

To address the problems (see the Problem Statements) while minimizing risks in a minor, this ticket proposes changing (disabling) the AJAX activation handler introduced in 6.5.0. This change will restore the pre-6.5 behavior of clicking the "Activate" button, i.e. navigates the users to button's href, i.e. to the plugins.php UI. See the proposal for more details.

This approach is an alternative to #61269 filtered configuration data approach. It's not a revert; rather, it's a minor change to fix the regression. In doing so, it shifts into a major release the feature's workflow refinement and considerations of how configuration fits into it.

As mentioned in #61269, a partial revert was considered.

A partial revert of the AJAX will impact users using a plugin that adopted the feature.

What was not mentioned: a revert caused concerns of potential issues due to it being unclean / messy. At the time, it appeared to be too risky in a minor.

Problem Statements

Plugin companies and their users (which are also this project's users) are significantly impacted.

It's unknown if the majority of users want or do not want auto-redirect.

It's now known that impacted plugin's users do want this ability. The size of their user bases is data to suggest the significance of the impact.

A new onboarding framework needs the benefits of major release cycle to understand the impacts, form a scope, do experiments, and then move through the product | enhancement stages.

More Context

As of WP 6.5.0, users are no longer able to quickly go from install to onboarding | set up | configure. Plugin companies are significantly impacted, reporting decreases of 18-30% in users moving to the next step (which helps users use the plugin). The 6.5.3 new "Refresh now" user action (an additional user action) appears to reduce the impacts, though are still significant.

An enhancement ticket is open for exploring an onboarding framework (see #61040).

The Plugins Dependencies (aka PD) feature made a technical and design decision for its workflow. In talking with @costdev, the feature did not set out to ban redirects after activation. @jorbin summarized the feature's problem statement as:

The problem PD aims to solve is that when a plugin has a dependency on another, users are left to their devices which leads to inconsistent user experiences and potential for site breakage by deactivating plugins that are relied upon

Notice, the problem statement does not mention or include redirects or onboarding. The hard removal of autoloading onboarding seems to be a byproduct of the decided workflow.

Please note, the decision was thoughtfully made. With no issue reports or feedback during the calls for testing and 6.5 alpha, beta, and RC cycles, there did not seem to be an issue.

Fast forward to today, feedback has been shared showing the decision is causing a significant impacts.

In hindsight with what is known today, the onboarding framework and PD feature should have shipped together.

Proposal

With this new understanding, this ticket proposes to:

• In a 6.5.4 minor, change the AJAX activation handler to essentially disable AJAX control of it, thereby allowing the browser to navigate to the URL in the Activate button's href. This change is not a revert of the AJAX, but rather only restoring the button's href native behavior.

• In a major, refine the user workflow while considering how configuration fits and how plugins interact with it, e.g. onboarding framework #61040. A major release is best suited for this scope of work as time is needed for discussion, consideration, experimentation, feedback, adoption, etc.

The Plugins Dependency (PD) feature will continue to function. With the proposed change, after clicking the Activate button, if there are more plugins in the dependency chain, users will need to navigate back to the previous screen to continue in the PD workflow. This extra step for users is not ideal, but can be refined in a future effort (major release).

Proposal Technical Details

Remove the activation button's click handler from the AJAX, in favor of using the button's href.

For the modal, the button's href stays within the modal instead of navigating back to the parent document's Plugins UI. To resolve this, add a click handler targeting the button in the modal's footer and then assign the button's href to the parent.

Pros 🟢 and Cons 🔴 Summary

• 🟢 Does not lock in the approach for the future (in comparison with #61269 filter).
• 🟢 Has the same end result as the filter approach in #61269.
• 🟢 Impacts the majority of users activating plugins who are early adopters of PD, given the majority of early adopters require flagship plugins with large user bases that require user setup for usage.
• 🟢 Does not require changes in plugins.
• 🟢 Least amount of code changes.
• 🟢 Plugins Dependency (PD) feature continues to work.
• 🟢 AJAX is retained minus the activation handler.
• 🟢 Less risk in a minor, while shifting design decisions to a major.
• 🟢 Less opinionated in a minor, moving the design decisions to a major.
• 🔴 Impacts users adding plugins that adopted PD, i.e. users will have one more step to navigate back to continue the plugin chain workflow.
• 🔴 Carries dead code in Core (until the workflow is refined in the future).

References

Follow-up to:

• #60992 [58081] [58083] (6.5.3)
• #22316 [57545] (6.5.0).

Related to #61040 and #61269.

Props:
@costdev is a co-collaborator on this proposal, following discussions with and data gathering from @jorbin @beaulebens @adrianduffell @nerrad @illuminea @smub to better understand the impacts and user insights. Feedback from @swissspidy and @azaozz sparked a fresh new look at an AJAX approach.

[hellofromTonya]

Testing Instructions

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

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

Set up

Patch: ​https://github.com/WordPress/wordpress-develop/pull/6670
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

Steps to Test in the Add Plugins UI:

1. Navigate to Plugins > Add New Plugin.
2. In the plugins search box, type the name of the plugin you're testing (e.g. woocommerce) and press enter. The UI should populate with that and associated plugins.
3. In the plugin's card, press the "Activate" button.

Expected Results:
After triggering the Activate button:

• The browser should navigate to either:
  • the plugins.php UI
  • or, if if the plugin has a redirect in it, the plugin's configure page / onboarding wizard
• The "Refresh now" admin notice and button should not appear.

Steps to Test in the More Details modal:

Note: Deactivate the plugin first.

1. Navigate to Plugins > Add New Plugin.
2. In the plugins search box, type the name of the plugin you're testing (e.g. woocommerce) and press enter. The UI should populate with that and associated plugins.
3. In the plugin's card, click on the "More Details" link below the "Activation" button.
4. Press the "Activate" button (may need to scroll down to the button).

Expected Results:
After triggering the Activate button:

• The browser should navigate to either:
  • the plugins.php UI
  • or, if if the plugin has a redirect in it, the plugin's configure page / onboarding wizard
• The "Refresh now" admin notice and button should not appear.
• The plugin should be activated.

Steps to Test another plugin that requires the plugin you're testing

Note: Deactivate the plugin first.

Example: When searching for WooCommerce plugins to add, notice there are several dependent upon WooCommerce, such as WooCommerce Stripe Payment Gateway.

The instructions will be for WooCommerce. But it's the same steps for others such as Elementor.

1. Navigate to Plugins > Add New Plugin.
2. In the plugins search box, type woocommerce and press enter. The UI should populate with that and associated plugins.
3. For one of the plugins requiring WooCommerce (such as WooCommerce Stripe Payment Gateway): 4.1 Press the "Install Now" button. 4.2 After installed, notice unable to activate the plugin. This is by design as it requires WooCommerce. 4.3 In the "Additional plugins are required" section, click WooCommerce's "More Details" link. 4.4 In the modal, press the "Activate" button. Expected: WooCommerce's onboarding wizard should load. 4.5 In your browser, click the button to navigate back to the Add Plugins UI. Expected: WooCommerce Stripe Payment Gateway plugin's Activate button is available. 4.6 Activate the plugin.

Expected Results:
After triggering WooCommerce activation button:

• The browser should navigate to Woo's onboarding wizard.
• The "Refresh now" admin notice and button should not appear.
• The plugin should be activated.

After navigating back to the Add Plugins UI, plugins requiring WooCommerce are now able to be activated.

[hellofromTonya]

Test Report for WooCommerce

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

• Onboarding wizard: Yes.

• Previous behavior before 6.5: auto-redirected to Woo's onboarding wizard.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 8.3
• WordPress: 6.5.3 with this PR applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: WooCommerce 8.9.1

Note: 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

Actual Results for Test in the Add Plugins UI:

After clicking the Activate button:

• ✅ the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirects to WooCommerce's onboarding wizard.

Actual Results for Test in the More Details modal:

After clicking the Activate button:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirect to WooCommerce's onboarding wizard.

Actual Results for Test another plugin that requires the plugin you're testing

After clicking WooCommerce's Activate button in the modal:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirect to WooCommerce's onboarding wizard.

After navigating back to the Add Plugins UI:

• ✅ able to activate plugins requiring WooCommerce.

[hellofromTonya]

Test Report for Elementor

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

• Onboarding wizard: Yes.

• Previous behavior before 6.5: auto-redirected to Element's onboarding wizard.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 8.3
• WordPress: 6.5.3 with this PR applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: Elementor 3.21.8

Actual Results for Test in the Add Plugins UI:

After clicking the Activate button:

• ✅ the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirects to Elementor's onboarding wizard.

Actual Results for Test in the More Details modal:

After clicking the Activate button:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirect to Elementor's onboarding wizard.

Actual Results for Test another plugin that requires the plugin you're testing

After clicking Elementor's Activate button in the modal:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirect to Elementor's onboarding wizard.

After navigating back to the Add Plugins UI:

• ✅ able to activate plugins requiring Elementor.

[hellofromTonya]

Test Report for OptinMonster

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

• Onboarding wizard: Yes.

• Previous behavior before 6.5: auto-redirected to plugin's onboarding wizard.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 8.3
• WordPress: 6.5.3 with this PR applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: OptinMonster 2.16.2

Actual Results for Test in the Add Plugins UI:

After clicking the Activate button:

• ✅ the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirects to OptinMonster's onboarding wizard.

Actual Results for Test in the More Details modal:

After clicking the Activate button:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirect to OptinMonster's onboarding wizard.

Actual Results for Test another plugin that requires the plugin you're testing

Did not test, as there are no plugins requiring it.

[hellofromTonya]

Test Report for BuddyPress

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

• Onboarding wizard: No.

• Previous behavior before 6.5: redirected to admin dashboard with a custom modal overlay.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 8.3
• WordPress: 6.5.3 with this PR applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: BuddyPress 12.5.0

Actual Results for Test in the Add Plugins UI:

After clicking the Activate button:

• ✅ the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirects to the admin dashboard with the BuddyPress modal overlay.

Actual Results for Test in the More Details modal:

After clicking the Activate button:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirects to the admin dashboard with the BuddyPress modal overlay.

Actual Results for Test another plugin that requires the plugin you're testing

Did not test, as there are no plugins requiring it.

[hellofromTonya]

Test Report for Contact Form 7

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

• Onboarding wizard: No.

• Previous behavior before 6.5: none from the plugin.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 8.3
• WordPress: 6.5.3 with this PR applied
• Browser: Firefox 126.0
• Theme: default
• Plugins:
  • Contact Form 7, v 5.9.5
  • Contact Form 7 – Dynamic Text Extension, v 4.4.3

Actual Results for Test in the Add Plugins UI:

After clicking the Activate button:

• ✅ the "Refresh now" admin notice and button do not appear.
• ✅ navigates back to the button's href, i.e. to plugins.php.

Actual Results for Test in the More Details modal:

After clicking the Activate button:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ navigates back to the button's href, i.e. to plugins.php.

Actual Results for Test another plugin that requires the plugin you're testing

After clicking Contact Form 7's Activate button in the modal:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ navigates back to the button's href, i.e. to plugins.php.
• ✅ the plugin is activated.

After navigating back to the Add Plugins UI:

• ✅ able to activate the Contact Form 7 – Dynamic Text Extension plugin (that required Contact Form 7).

[hellofromTonya]

Test Report with WooCommerce - works as expected ✅

[illuminea]

This alternative direction looks promising too. We at Elementor are happy with both approaches to handling the change made in 6.5, since the end result is the same - bringing back the onboarding experience flow for plugin users, which is very valuable for them.

[hellofromTonya]

Test Report for Yoast SEO

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

• Onboarding wizard: Yes.

• Previous behavior before 6.5: auto-redirected to wp-admin/admin.php?page=wpseo_installation_successful_free.

Environment

• OS: macOS
• Web Server: nginx
• PHP: 8.3
• WordPress: 6.5.3 with this PR applied
• Browser: Firefox 126.0
• Theme: default
• Plugins: Yoast SEO 22.8

Actual Results for Test in the Add Plugins UI:

After clicking the Activate button:

• ✅ the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirects to Yoast SEO's onboarding wizard.

Actual Results for Test in the More Details modal:

After clicking the Activate button:

• ✅ at the bottom of the modal, the "Refresh now" admin notice and button do not appear.
• ✅ auto-redirects to Yoast SEO's onboarding wizard.

Actual Results for Test another plugin that requires the plugin you're testing

Did not test, as there are no plugins requiring it.

[hellofromTonya]

Patch:

Plugins I've tested with the patch (test reports in the ticket):

• Single plugin with onboarding ✅
• Plugin that depends upon a plugin with onboarding ✅
• Multiple plugins that depend upon a plugin with onboarding ✅
• Single plugin with redirect to a settings or welcome page ✅
• Single plugin with no previous redirect ✅
• Plugin requiring a plugin with no previous redirect ✅

The patch works as expected.

Confirmed it has the same end-result behavior as #61269 ✅

What is the end-result behavior?

• Restores the ability for plugins to auto-redirect to take users to the next step of configuring the plugin for live usage.
• If other plugins to add, users need to navigate back to Add Plugins UI to continue in the PD workflow chain.

[hellofromTonya]

IMO this approach is preferred over #61269.

Why?

Overall, I like this approach better because it does not lock in the next phase for refining and maybe expanding the PD workflow. Instead, it shifts those considerations away from the regression and into a major to gain the benefits of a full cycle.

Like @swissspidy (​see the discussion thread in the Make/Core post), I too am concerned about a new filter being added in a minor release, especially before its intended usage is explored and defined. Right now, the configuration / onboarding next step in the workflow is in the ideation stage (see #61040). There's a strong likelihood and intent the configuration filter will remain as the entry point. But .. What if the direction shifts? It's the what ifs and unknowns that make it risky in a minor.

This approach in this ticket:

• is less code, meaning less code is changing. That can lower risks of side-effects and for future iterations.
• restores the previous native behavior of clicking the Activate button vs shifting control into Core for redirecting vs adding new code to control the redirect through AJAX.

Reverting back to the original AJAX behavior, as this PR accomplishes, is the simplest fix for a minor.

[hellofromTonya]

Summary of feedback from today's Dev Chat, held in Making WordPress slack core channel:

Link to start of the thread: ​https://wordpress.slack.com/archives/C02RQBWTW/p1717013066479629

@afragen shared:

I believe the simplest approach is in 61319

@mikachan shared:

I don't have much background knowledge here, but after reading @hellofromtonya’s latest comment on #61319, I agree that this sounds like the best approach (less code, restores the previous native behavior of the Activate button) :+1:

@ironprogrammer shared:

I like that this addresses the originally reported regression w/o adding anything new. Better adherence to the scope that is expected in a minor release.

@joemcgill asked:

Would it be good to get feedback from the folks who were critical of the initial approach?

Well, it sounded like you looked into the alternate approach after feedback from

@swissspidy and @azaozz, so it may be good to get their feedback on the new approach. Generally speaking, I think we need to be pretty confident in the approach before shipping it in a minor release so getting extra PR feedback and testing is good practice

for which I shared both were pinged requesting their feedback (​here and ​here).

[ironprogrammer]

Thanks for the patch, @costdev, and thorough test scenarios, @hellofromTonya! 🎉 The tests above cover several plugins, but here's one more confidence check with WC.

Test Report

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

Restores expected Activate button behavior (prior to 6.5) when activating a plugin with a setup workflow redirect.

Environment

• Hardware: MacBook Pro Apple M1 Pro
• OS: macOS 14.5
• Browser: Safari 17.5
• Server: nginx/1.25.5
• PHP: 8.2.19
• MySQL: 8.0.27
• WordPress: 6.6-alpha-57778-src
• Theme: twentytwentyfour v1.1
• Plugin used for testing: WooCommerce (WC)

Actual Results

• ✅ Activation from Add Plugins page redirects to WC setup wizard.
• ✅ Activation from Add Plugins > More Details modal redirects to WC setup wizard.

Regression Checks (no changes expected)

• ✅ Activation from Installed Plugins page (main list) redirects to WC setup wizard.
• ✅ After activation via wp-cli, first wp-admin pageload redirects to WC setup wizard.

Additional Notes

• Used wp transient set _wc_activation_redirect 1 between tests to mimic a ​new WC install.
• This patch mitigates the previously raised concern when the More Details modal was triggered prior to refresh, as the setup wizard redirect is now immediate.

[azaozz]

may be good to get their feedback on the new approach

Been thinking about/looking at this for some time now. As mentioned above it is quite unfortunate that testing of the feature plugin and later in WP 6.5 beta and RC did not reveal this problem.

There have been several good ideas and approaches on how to fix it. Imho best is to "reverse" the fix from #60992, i.e. after a plugin has been installed and activated show a (one time) reminder message that one or more "dependent" plugins can now be activated. It may not be strictly necessary but thinking it is a "nice to have" enhancement to remind the users to continue especially if they had to install the dependency plugin after attempting to install/activate a dependent plugin.

This will remedy all shortcoming of an AJAX activation (like not showing menu items added by the just activated plugin right away, etc.), and also will restore redirects after activation.

I'm a +1 for the patch here. It is the first part of the above. The second part (one-time reminder to activate dependent plugins) can be added in WP 6.6.

[kevinwhoffman]

Compared to #61269, the benefit of this approach is that it would restore a direct path to onboarding without requiring plugin authors to 1) be aware of a new filter and 2) release a plugin update that implements the new filter. However this direct path via redirect is also one that takes control away from the user and goes against established usability heuristics described in comment:37:ticket:61040.

Question

Assuming 6.5.4 restores the previous redirect behavior implemented via register_activation_hook, is core willing to take steps to prevent these redirects in 6.6+ when an onboarding framework is introduced?

If no, core is not willing to prevent redirects in the future...

Then we are signaling that post-activation redirects are coming back to stay. Plugin authors will be disincentivized to adopt a future onboarding framework that gives control back to the user through a workflow like Install > Activate > Configure or Install & Activate > Open. As long as users can be forced into an onboarding flow without a choice, then it is in the commerical interest of many plugins to continue forcing redirects.

If yes, core is willing to prevent redirects in the future...

Then we would be making the right long-term decision for users, but we should also be aware of the impact of changing behavior so much within such a short period of time. We would be setting up a potential timeline like the following:

6.5 - Redirects are broken
6.5.3 - Redirects are kind of restored through the admin notice refresh
6.5.4 - Redirects work again like they used to before 6.5
6.6+ - Redirects no longer work at all because a new onboarding framework is in place that requires a filter to be implemented

Recommendation

I believe this fix is in the best short-term interest of users and plugin developers in lieu of a standardized onboarding flow. This fix will quickly restore a path to onboarding that plugin developers and users depend on. However, I would also suggest that restoring redirects is framed as a temporary fix until an onboarding framework is in place, and that we set expectations for plugin developers that forcing redirects is not a long-term solution.

[lopo]

Tested the patch with Yoast SEO, and I can confirm that it fully restores the intended behavior.
I think we would favor this solution compared to the other one, as it would be immediately available to our users.

[hellofromTonya]

#61269 was marked as a duplicate.

[hellofromTonya]

Thank you everyone for testing and giving feedback. The power of open source!

There's consensus to move forward with this ticket and patch for the minor. It direct solves the regression without adding additional scope.

As it's now well-tested, removing the needs-testing keyword.

As ​the PR has multiple approvals and thumbs up from committers and the PD feature contributors/leads, marking it for commit.

Does it need a dev note? Unlike #61269 which added a filter, this ticket / patch does not. There are no changes plugins need to do. Thus a dev note is not needed to advise plugins of what to change.

Assigning to myself to do the commit to trunk. Then will reopen for 2nd committer sign-off to backport to 6.5-branch.

[hellofromTonya]

Replying to azaozz:

Imho best is to "reverse" the fix from #60992, i.e. after a plugin has been installed and activated show a (one time) reminder message that one or more "dependent" plugins can now be activated. It may not be strictly necessary but thinking it is a "nice to have" enhancement to remind the users to continue especially if they had to install the dependency plugin after attempting to install/activate a dependent plugin.

@swissspidy also ​suggested the reverting of [58081] and [58083].

A revert is not essential or a blocker for the minor. But it does make sense to shift that work out of the minor cycle, especially given 2 factors:

1. Dead code: It'll be dead code with 6.5.4 in that the Refresh now code will never be reached or render.
2. Still in ideation stage: The next workflow step of what happens after activation is still in the ideation stage. That stage needs to consider things such as: how does configuration / onboarding / setup fit into the user workflow of adding plugins to go live? Will there be a Configure button / step (when there is configuration / onboarding) or Refresh now button / step (when no configuration)?

I agree with you @azaozz that it does make sense to revert the 6.5.3 changes, moving them to be part of the next phase work (though likely too late for 6.6 given beta 1 is next week).

[hellofromTonya]

Replying to kevinwhoffman:

Question

Assuming 6.5.4 restores the previous redirect behavior implemented via register_activation_hook, is core willing to take steps to prevent these redirects in 6.6+ when an onboarding framework is introduced?

The onboarding framework ticket is open and will move into 6.7 for consideration. It's in the ideation stage. The question of redirects can be answered there. Just noting, I don't necessarily think the direction needs to move towards only considering banning redirects. Rather, I think it needs to consider:

• (a) what the plugins are saying about their huge user bases wanting to go from activation to configuration with little friction to get their site live with the plugin(s)
• (b) how that fits into the add plugin user workflow.

There are many possibilities of how to achieve the workflow that works best for the majority of users while still achieving the goal of providing a consistent, guided workflow for the chain of dependencies.

But those possibilities are best explored in a major and in the onboarding framework ticket #61040 or another new ticket (if needed).

Recommendation

I believe this fix is in the best short-term interest of users and plugin developers in lieu of a standardized onboarding flow. This fix will quickly restore a path to onboarding that plugin developers and users depend on.

WooHoo, thanks for considering this alternative and giving your support for it.

However, I would also suggest that restoring redirects is framed as a temporary fix until an onboarding framework is in place, and that we set expectations for plugin developers that forcing redirects is not a long-term solution.

I respectfully disagree. I don't think this regression fix nor the minor should be opinionated. Rather, it's goal is to fix the regression. I also think the question of banning / preventing redirects is still open and unanswered, as I noted above. That may very well the direction it goes. But given the pushback of impacts and plugins with huge user bases saying their users (the WP project's users) want to go from activation to onboarding, I think it's too early to say this is a temporary fix.

The way to frame is: it's restoring to resolve the regression and the next step or phase in the workflow will continue in #61040.

What do you think?

[kevinwhoffman]

Replying to hellofromTonya:

However, I would also suggest that restoring redirects is framed as a temporary fix until an onboarding framework is in place, and that we set expectations for plugin developers that forcing redirects is not a long-term solution.

I respectfully disagree. I don't think this regression fix nor the minor should be opinionated. Rather, it's goal is to fix the regression. I also think the question of banning / preventing redirects is still open and unanswered, as I noted above. That may very well the direction it goes. But given the pushback of impacts and plugins with huge user bases saying their users (the WP project's users) want to go from activation to onboarding, I think it's too early to say this is a temporary fix.

The way to frame is: it's restoring to resolve the regression and the next step or phase in the workflow will continue in #61040.

What do you think?

You're right, I should not have worded that recommendation as a way to frame this regression fix, but I do think we should set some general expectations for plugin developers that the post-activation behavior may change as a result of an ongoing discussion around onboarding in #61040. While a dev note may not be needed for this fix because no action is needed today, the frequent changes to post-activation behaviors from 6.5 onwards should be addressed with some vision for the future.

But given the pushback of impacts and plugins with huge user bases saying their users (the WP project's users) want to go from activation to onboarding, I think it's too early to say this is a temporary fix.

I agree that the large plugins and their users need this fix, but the shared desire for plugin developers and users to go from activation to onboarding does not necessarily reflect a shared desire to be redirected without a choice. The commercial interests of plugins to onboard as many users as possible is at odds with user control, predictability, and consistency across the plugin ecosystem.

By fixing the regression in this manner, let's acknowledge the trade-offs: In order to restore a more direct path to onboarding in 6.5.4, we are intentionally removing user control while re-introducing unpredictability and inconsistency into the Add Plugins workflow. In 6.5.4, pressing "Activate" will once again result in different behaviors across plugins with no indication as to which plugins do or do not redirect.

Given the circumstances, I believe these are acceptable trade-offs in the short-term. By acknowledging them here, I hope to provide some direction as to where we go next and the problems we aim to solve in #61040.

[hellofromTonya]

In 58250:

Upgrade/Install: Restore Activate button's href native behavior.

Restores the Activate button's href native behavior by changing the AJAX activation handler introduced in 6.5.0. It restores the pre-6.5 behavior of clicking the "Activate" button, i.e. navigates the user to the button's href (i.e. to the plugins.php UI).

Why?

Feedback was given after shipping [57545] in 6.5.0 (but was unknown during the development and testing cycles) revealed significant impacts for plugins who's users valued the onboarding / configuration experiences.

6.5.3's [58081] and [58083] added a new user action / step to the workflow. Though helpful, it did not fully resolve the impacts.

For the minor, this commit seeks to restore only the "Activate" button's href pre-6.5 native behavior to resolve the regression.

The next phase of the Add Plugins workflow can then continue in a major release to gain the benefits of a full major to move it from ideation through the development phases. (See #61040). The questions of redirect, how / should configuration be in the workflow, etc. can best be explored and experimented with in a major.

Follow-up to [57545], [58081], [58083].

Props costdev, jorbin, hellofromTonya, afragen, kevinwhoffman, azaozz, adrianduffell, beaulebens, hmbashar, illuminea, ironprogrammer, jjj, lopo, louiswol94, mikachan, nerrad, mukesh27, peterwilsoncc, pooja1210, smub, swissspidy.

Fixes #61319.
See #22316, #60992.

[hellofromTonya]

Reopening for 2nd committer sign-off to backport to the 6.5 branch.

Committed via https://core.trac.wordpress.org/changeset/58250. Thank you everyone for contributing 🌟

[hellofromTonya]

Whoopsie, forgot to reopen the ticket for 2nd committer sign-off.

[jorbin]

[58250] looks good for backport to the 6.5 branch

[hellofromTonya]

In 58254:

Upgrade/Install: Restore Activate button's href native behavior.

Restores the Activate button's href native behavior by changing the AJAX activation handler introduced in 6.5.0. It restores the pre-6.5 behavior of clicking the "Activate" button, i.e. navigates the user to the button's href (i.e. to the plugins.php UI).

Why?

Feedback was given after shipping [57545] in 6.5.0 (but was unknown during the development and testing cycles) revealed significant impacts for plugins who's users valued the onboarding / configuration experiences.

6.5.3's [58081] and [58083] added a new user action / step to the workflow. Though helpful, it did not fully resolve the impacts.

For the minor, this commit seeks to restore only the "Activate" button's href pre-6.5 native behavior to resolve the regression.

The next phase of the Add Plugins workflow can then continue in a major release to gain the benefits of a full major to move it from ideation through the development phases. (See #61040). The questions of redirect, how / should configuration be in the workflow, etc. can best be explored and experimented with in a major.

Follow-up to [57545], [58081], [58083].

Reviewed by jorbin.
Merges [58250] to the 6.5 branch.

Props costdev, jorbin, hellofromTonya, afragen, kevinwhoffman, azaozz, adrianduffell, beaulebens, hmbashar, illuminea, ironprogrammer, jjj, lopo, louiswol94, mikachan, nerrad, mukesh27, peterwilsoncc, pooja1210, smub, swissspidy.

Fixes #61319.
See #22316, #60992.

[hellofromTonya]

In 58257:

Plugins: Revert r58081 show an admin notice on successful activation.

With a new direction in the 6.5.4 to restore the Activate button's href (see [58250]), the changesets committed for 6.5.3 (see #60992) are now dead code and will not render the admin notice on successful plugin activation.

This commit is a clean revert of r58081.

Follow-up to [58250].

Props swissspidy, azaozz, costdev, jorbin, hellofromTonya, afragen.
Fixes #61331.
See #60992, #61319.

[hellofromTonya]

In 58258:

Plugins: Revert r58083 show an admin notice on successful activation.

With a new direction in the 6.5.4 to restore the Activate button's href (see #61319 / [58250]), the changesets committed for 6.5.3 (see #60992) are now dead code and will not render the admin notice on successful plugin activation.

This commit is a clean revert of r58083.

Follow-up to [58250], [58257].

Reviewed by jorbin.
Reverts [58083] on the 6.5 branch.

Props swissspidy, azaozz, costdev, jorbin, hellofromTonya, afragen.
Fixes #61331.
See #60992.

[hellofromTonya]

Follow-up testing in preparation for 6.5.4.

The auto-redirect for the next step (wizard, getting started, configuration, welcome, etc.) is restored for the following plugins:

• OptinMonster ✅
• WPForms Lite ✅
• WPForms Pro ✅
• WP Mail SMTP ✅
• Easy Digital Downloads (EDD) ✅
• MonsterInsights ✅
• Charitable ✅
• ExactMetrics ✅
• UserFeedback Lite ✅
• Website Builder by SeedProd ✅
• RafflePress Lite ✅
• Envira Gallery ✅
• All in One SEO (AIOSEO) ✅
• SearchWP ✅
• Smash Balloon ✅
• Sugar Calendar ✅
• WP Simple Pay ✅
• Duplicator ✅
• NextGEN Gallery by Imagely ✅
• BuddyPress ✅
• bbPress ✅
• Paid Membership Pro ✅