[wp-trac] [WordPress Trac] #61269: Plugin Dependencies: Add filter to restore auto-redirect after plugin activation

[WordPress Trac]

#61269: Plugin Dependencies: Add filter 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           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+---------------------

Old description:

> To address the problems (see below) while minimizing risks in a minor,
> this ticket proposes adding a mechanism (i.e. a filter) for plugins to
> register their onboarding | set up | configure URL for Core to handle the
> auto-redirects after activation. This filter will be forward-compatible
> by design as the entry point into the onboarding framework (see #61040).
>
> @costdev @jorbin are co-collaborators on this proposal, following
> discussions with and data gathering from @beaulebens @adrianduffell
> @nerrad @illuminea @smub to better understand the impacts and user
> insights.
>
> == 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.x minor, give plugins a mechanism (filter) to register their
> URL for Core to handle the redirect. To minimize risks in a minor, the
> scope is essentially an "opt-out" by using a filter that will become part
> of the onboarding framework.
>
> * In 6.6 major, the mechanism becomes the entry point into the onboarding
> framework.
>
> * Then deal with the scope and impacts of a possible new onboarding
> framework and/or workflow in a major release, i.e. to give time for
> discussion, consideration, experimentation, feedback, adoption, etc.
>
> == Proposal Technical Details
>
> * In 6.5.4:
>   * add a new filter `plugin_configuration_data_{$slug}` for the
> onboarding/configuration URL, with an initial parameter value of `array(
> 'url' => '' )`.
>   * if filtered, it auto-redirects to that URL after activation.
> * In 6.6 (as part of #61040):
>   * the filter is the entry point into the onboarding framework.
>   * the filter's array is extended for the needs of the onboarding
> framework.
>   * explore combining Install/Activate on the Plugins > Add New Plugin
> screen to mitigate the 3-click approach created by the new button.
>
> == Pros 🟢 and Cons 🔴 Summary
>
> * 🟢 Temporarily restores a way to trigger auto-loading onboarding in a
> minor (without a revert).
> * 🟢 AJAX is retained, thus does not impact users or plugins authors when
> activating plugins not using the filter.
> * 🟢 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.
> * ⚪️ Is forward-compatible by design, with a clear direction for the
> future.
> * 🟢 Less risk in a minor, while shifting design decisions to a major.
> * 🟢 Less opinionated in a minor, moving the design decisions to a major.
> * 🔴 Gives plugins a way to prevent users from completing the users
> intended action
>
> == Why not revert?
> Good question, one that was thoughtfully and seriously considered.
>
> A full revert of the Plugins Dependencies (PD) feature will potentially
> cause a backwards compatible (BC) break. Why? It shipped public
> functions, classes, etc that are available for invoking and extending in
> plugins. If any plugins are currently invoking or extending, the user
> will experience a fatal error.
>
> A partial revert of the AJAX will impact users using a plugin that
> adopted the feature.
>
> Thus, a revert also impacts users.
>
> In contrast, this ticket's proposal of adding a filter is a pragmatic,
> forward-compatible approach to benefit users (including extenders).
>
> == References
>
> Follow-up to:
> * #60992 [58081] [58083] (6.5.3)
> * #22316 [57545] (6.5.0).
>
> Related to #61040.

New description:

 To address the problems (see below) while minimizing risks in a minor,
 this ticket proposes adding a mechanism (i.e. a filter) for plugins to
 register their onboarding | set up | configure URL for Core to handle the
 auto-redirects after activation. This filter will be forward-compatible by
 design as the entry point into the onboarding framework (see #61040).

 @costdev @jorbin are co-collaborators on this proposal, following
 discussions with and data gathering from @beaulebens @adrianduffell
 @nerrad @illuminea @smub to better understand the impacts and user
 insights.

 == 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.x minor, give plugins a mechanism (filter) to register their
 URL for Core to handle the redirect. To minimize risks in a minor, the
 scope is essentially an "opt-out" by using a filter that will become part
 of the onboarding framework.

 * In 6.6 major, the mechanism becomes the entry point into the onboarding
 framework.

 * Then deal with the scope and impacts of a possible new onboarding
 framework and/or workflow in a major release, i.e. to give time for
 discussion, consideration, experimentation, feedback, adoption, etc.

 == Proposal Technical Details

 * In 6.5.4:
   * add a new filter `plugin_configuration_data_{$slug}` for the
 onboarding/configuration URL, with an initial parameter value of `array(
 'url' => '' )`.
   * if filtered, it auto-redirects to that URL after activation.
 * In 6.6:
   * the filter is the entry point into the onboarding framework.
   * the filter's array is extended for the needs of the onboarding
 framework.
   * evaluate combining Install/Activate on the Plugins > Add New Plugin
 screen to mitigate the 3-click approach created by the new button.

 == Pros 🟢 and Cons 🔴 Summary

 * 🟢 Temporarily restores a way to trigger auto-loading onboarding in a
 minor (without a revert).
 * 🟢 AJAX is retained, thus does not impact users or plugins authors when
 activating plugins not using the filter.
 * 🟢 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.
 * ⚪️ Is forward-compatible by design, with a clear direction for the
 future.
 * 🟢 Less risk in a minor, while shifting design decisions to a major.
 * 🟢 Less opinionated in a minor, moving the design decisions to a major.
 * 🔴 Gives plugins a way to prevent users from completing the users
 intended action

 == Why not revert?
 Good question, one that was thoughtfully and seriously considered.

 A full revert of the Plugins Dependencies (PD) feature will potentially
 cause a backwards compatible (BC) break. Why? It shipped public functions,
 classes, etc that are available for invoking and extending in plugins. If
 any plugins are currently invoking or extending, the user will experience
 a fatal error.

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

 Thus, a revert also impacts users.

 In contrast, this ticket's proposal of adding a filter is a pragmatic,
 forward-compatible approach to benefit users (including extenders).

 == References

 Follow-up to:
 * #60992 [58081] [58083] (6.5.3)
 * #22316 [57545] (6.5.0).

 Related to #61040.

--

Comment (by afragen):

 Well thought out and well reasoned. This proposal should require minimal
 updating to existing plugins to take advantage and return to their prior
 workflows.

 Plugin devs will need to remember to conditionally activate this new
 filter when the onboarding process has not been completed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61269#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform