[wp-trac] [WordPress Trac] #41593: Document every function parameter that expects slashed data

WordPress Trac noreply at wordpress.org
Sat Nov 4 19:23:36 UTC 2017


#41593: Document every function parameter that expects slashed data
----------------------------+-----------------------------
 Reporter:  johnbillion     |       Owner:
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  Future Release
Component:  General         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  docs
----------------------------+-----------------------------

Comment (by jdgrimes):

 [attachment:scratch_50.php] is a raw collection of unit tests that I wrote
 for a few of the functions that expect slashed data. These can be used as
 a basis for patches as we go along here.

 ----

 ==  Next Steps ==

 There is a bit more research that can be done here, but before we can
 really move too far forward there are some decisions that will need to
 start being made.

 - How do we want to document these parameters that expect slashes,
 exactly? We'll have to decide that before patches can be made.
 - Should we consider possible reasons why it might be good/OK to change
 slashing expectations in some cases?
 - Do we want to commit `// WPCS: slashing OK` whitelisting comments to
 core, in the interest of making it easier to run this sniff over it in the
 future, and ensure more functions expecting slashed data aren't
 unintentionally added? And what steps do we want to take to reduce the
 need for these comments (using `(int)` casts [discussed above], calling
 `wp_slash()` where it may not be needed, etc.)?
 - Do we want to work on a single ticket, or split this up into several
 tickets for different functions/groups of functions?

 Once some of these things are answered, we basically need to go through
 all of the functions, write unit tests, make the decisions that need to be
 made, and prepare a patch that will document the function parameters as
 needing slashing and also fix all of the places in core that don't abide
 by that.

 Perhaps some of this should be brought up at a core meeting? Now that some
 of the initial investigative work is done, it would be great to get more
 people involved. I think this is an effort that would be good to tackle
 early in 5.0.

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


More information about the wp-trac mailing list