[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 18:33:12 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 hellofromTonya):

 Replying to [comment:36 jorbin]:
 > My goal with suggesting the specific backward compatibility language and
 switch from `url` to `redirect_url` is to lessen the surpise when the
 redirect is no longer automatic and instead is a button press or something
 else.

 Recently you shared with me that UI and workflows are not part of the BC
 promise. The filter and its parameter(s) are in the BC promise. @costdev
 designed the filter and `url` parameter with these in mind.

 The auto-redirect after plugin activation is part of the UI and workflow.
 Core's control of the "how" and "when" are part of the UI and workflow.
 Its usage of the data registered by plugins and the entry point for
 plugins to register with Core are public facing and part of the BC
 promise. The intent and effect of Core using that configurable data is the
 same and part of the BC promise.

 It's not a promise to auto-direct after plugin activation nor is it a
 promise of the workflow or mechanism. The UI and workflow may change.

 If it becomes a button press or something else, the effect is the same ->
 Core provides the mechanism for loading the registered onboarding | set up
 | configure URL to move the user to the next step.

 Does that make sense, @jorbin?

 What about the filter's documentation?
 I agree with you - it can be made more clear. To help mitigate confusion
 and possible surprise later, care needs to be given to how this change is
 communicated in Make/Core, the release, this ticket, etc.

 What do you think?

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


More information about the wp-trac mailing list