[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