[wp-trac] [WordPress Trac] #61319: Plugin Dependencies: Change AJAX activation handler to restore auto-redirect after plugin activation

[WordPress Trac]

#61319: Plugin Dependencies: Change AJAX activation handler to restore auto-
redirect after plugin activation
-----------------------------+--------------------
 Reporter:  hellofromTonya   |      Owner:  (none)
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  6.5.4
Component:  Upgrade/Install  |    Version:  6.5
 Severity:  normal           |   Keywords:
  Focuses:  administration   |
-----------------------------+--------------------
 To address the problems ([#ProblemStatements: 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.
 [#proposal 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
 [https://core.trac.wordpress.org/browser/tags/6.5/src/js/_enqueues/wp/updates.js#L2646
 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61319>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform