[wp-trac] [WordPress Trac] #48955: WP 5.3.1 changes cause potential backwards compatibility breakage with kses
WordPress Trac
noreply at wordpress.org
Tue Dec 24 00:38:59 UTC 2019
#48955: WP 5.3.1 changes cause potential backwards compatibility breakage with kses
--------------------------+---------------------
Reporter: iCaleb | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 5.3.3
Component: Security | Version: 5.3.1
Severity: normal | Resolution:
Keywords: needs-patch | Focuses:
--------------------------+---------------------
Comment (by jnylen0):
Replying to [comment:21 aduth]:
> What about plugins which respect the documented string type, and would
likewise break if a feature enhancement to support arrays was adopted?
>
> (examples)
>
> Arguably, it was never the case that `wp_kses` would have worked as
expected with an array value filtered by any of the plugins above.
>
> The reason I keep harping on about the documentation is that it serves
as a contract against which backwards-compatibility should be measured.
This is a fair point, and the examples you listed (which look like they
will mostly either do nothing or cause a warning and perhaps some minor
breakage) are a good argument against changing the long-documented
behavior. However I don't think accidentally breaking an undocumented
behavior that is being actively used is necessarily the right idea,
either.
> If a plugin comes to rely on an incidental, undocumented behavior, it's
unfortunate if that behavior changes over time. [...] Given the choice, we
should seek to uphold support for the documented behavior.
Making functions conform more closely to their documented behavior is
good, but that doesn't mean incidental, undocumented behavior that people
are relying on has to stop working.
Another path to take (already suggested above) would be to restore the
array behavior but add a deprecation notice when an array is passed to any
of the relevant functions. I'm thinking now that this is probably the best
solution.
> we should be especially cautious with added feature support for these
functions, given their sensitive nature and the expanded complexity of
supporting additional combinations of arguments.
Also a fair point, but you'd be trading a hypothetical concern against
something that is known to be a problem today:
Replying to [comment:2 iCaleb]:
> We're seeing quite a few errors stem from this unfortunately on a number
of sites, with some PHP errors coming from popular plugins.
From Caleb's same comment, "deprecation notices followed by strict type
checking later on" seems like a sensible way to handle this, addressing
broken sites in the short term and predictability/complexity in the longer
term.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/48955#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list