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

WordPress Trac noreply at wordpress.org
Fri May 24 12:58:23 UTC 2024


#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 kevinwhoffman):

 The ticket description says:
 > As of WP 6.5.0, users are no longer able to quickly go from install to
 onboarding | set up | configure.

 If the goal of onboarding is to ensure a smooth and efficient transition
 for users, reduce time to value, and increase user engagement and
 retention, then it's reasonable to say that setup/configuration are
 synonyms for onboarding when positioned immediately after activation. Thus
 an `onboarding_url` parameter can satisfy all of the above.

 > Therefore, to choose one of the suggested names for the parameter now
 would mean only communicating one use case or behaviour, and I think it's
 best that we allow plugin authors to make the decision about what the URL
 should be and when.

 The parameter name ''should'' indicate the use case or purpose, but not
 the behavior. If we have an all-purpose `url` parameter and rely on the
 plugin to define the appropriate value from one use case to another, then
 we limit the potential for WordPress core, developers, users, and hosts to
 benefit from a standardized set of parameters that they can rely on for
 specific purposes.

 For example:

 - An onboarding framework in WordPress core may benefit from knowing where
 to direct a user when onboarding is complete without (e.g. the plugin's
 `main_url`) without having to rely on plugin-specific logic to determine
 the appropriate value of `url`.
 - 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.
 - Similarly a multisite developer may want to disable the onboarding
 wizard (see [https://wordpress.org/support/topic/disable-wizard-for-
 multisite/ real-world example]).
 - 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.

 The discussion around AJAX plugin activation (#60992), the discussion to
 date about the onboarding framework (#61040), and this entire ticket have
 been about facilitating an entry point to an onboarding experience in
 whatever form makes sense from one plugin to the next. The common thread
 across all conversations is that we're trying to improve the experience
 immediately after plugin activation, where an `onboarding_url` can be
 defined or modified to provide an onboarding experience that is
 appropriate for each user based on their needs, abilities, and context.
 These are known onboarding challenges with a long history of cowpath
 solutions, so let's name this parameter accordingly in a way that does not
 limit what's possible in the future.

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


More information about the wp-trac mailing list