[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 20:35:27 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 costdev):

 I agree that we should consider whether it's appropriate to document the
 filter's behaviour in the docblock.

 This filter, like all others, can be used in a variety of places and ways
 in Core, but all usage will reference the same docblock. How it's used
 today may change, which is already true of all filters and should be
 expected.

 While I understand the reasoning behind the suggestion, I would be careful
 about using backward compatibility language here, as UI and workflows
 aren't something I personally consider to be within the scope of the BC
 promise (otherwise markup, attributes, element tags, order of elements,
 etc could ''never'' change - which would be a nightmare for a11y I'm sure
 we'd all agree). The only backward compatibility promises that we make
 with filters are that their hook name and parameters will not be changed
 (unless deprecated), and that they will remain available for extender
 usage even if deprecated. What happens with the filtered data is another
 matter.

 I'd suggest that we answer "What am I filtering?" in the docblock, and
 "What does filtering this do?" in the 6.5.4 communications (dev note,
 release post, etc). If this seems insufficient to prevent tutorials and
 the like from communicating the wrong message to extenders, I'd recommend
 that we reach out to MarComms, Outreach, and possibly project leadership,
 to see if they can help with that communication.

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


More information about the wp-trac mailing list