Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #61269, comment 39


Ignore:
Timestamp:
05/24/2024 08:39:06 PM (2 months ago)
Author:
costdev
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #61269, comment 39

    initial v1  
    55While 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.
    66
    7 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.
     7I'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), noting ''there'' that how it behaves is subject to change with further evolution of the user experience, and extenders are strongly encouraged to work with us on this. 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.