[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:  reopened
 Priority:  normal                               |   Milestone:  6.5.4
Component:  Upgrade/Install                      |     Version:  6.5
 Severity:  normal                               |  Resolution:
 Keywords:  needs-testing needs-dev-note has-    |     Focuses:
  patch has-testing-info                         |  administration
-------------------------------------------------+-------------------------

Comment (by hellofromTonya):

 Replying to [comment:30 kevinwhoffman]:
 > - An onboarding framework in WordPress core may benefit from knowing
 where to direct a user when onboarding is complete (e.g. the plugin's
 `main_url`) without having to rely on plugin-specific logic to determine
 the appropriate value of `url`.

 Kevin, are you envisioning the possibility of a 4th step in the plugin
 workflow?
 Install > Activate > Onboard | Set Up | Configure > 4th step after
 onboard.

 == Disabling onboarding for one or all plugins

 I'm not understanding how adding separate configuration URL params
 achieves this goal. It shifts complexity into Core while also making it
 harder and unreliable for plugins, users, and hosts. How so?

 I'll walk through each of the scenarios for more context.

 If the goal is to provide a mechanism for users, plugins, hosts, etc to
 disable onboard for any combination of or maybe all plugins, a different
 approach will be needed. For example, another filter may be added to
 disable or skip all.

 > - A user or developer who installs WooCommerce on every site may want to
 skip the onboarding wizard by filtering the value of `onboarding_url`
 without affecting other use cases for a `url`. This is a scenario where
 the best onboarding experience for that user is to not have to click
 through a wizard at all.

 Noting the example from past comment:
 {{{
 onboarding_url - admin.php?page=wc-admin&path=%2Fsetup-wizard
 main_url - admin.php?page=wc-admin
 configuration_url - admin.php?page=wc-settings
 }}}

 Onboarding may be triggered for one or more of these specific URLs for
 some plugins, i.e. until the onboarding is completed or dismissed.

 For example, WooCommerce's `onboarding_url` and `main_url` both launch the
 setup wizard.

 Thus for these plugins, a user would need to filter each of the URL params
 in order to disable the wizard. Plus it's not guaranteed if another
 plugin's priority or place in the priority queue is higher / later in the
 call stack.

 > - Similarly a multisite developer may want to disable the onboarding
 wizard (see [https://wordpress.org/support/topic/disable-wizard-for-
 multisite/ real-world example]).

 Same problems as noted above.

 * They'll need to know which plugins' URL params trigger their onboarding
 (such as in the case of WooCommerce where both the `onboarding_url` and
 `main_url` trigger the wizard.
 * It's not guaranteed a plugin's filtering to disable is called last in
 the hook queue to disable it, making it unreliable.

 == Hosts change URL to direct to their experience

 > - A host with an ecommerce offering may want to direct the user to a
 host-specific version of onboarding to ensure they get the most out of
 their ecommerce solution on that host.

 Similarly a host can filter the configuration data's `url` for a specific
 plugin to change the `url` to point to where they want users to land.

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