[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