[wp-trac] [WordPress Trac] #21767: Remove stripslashes from API functions

WordPress Trac noreply at wordpress.org
Thu Dec 13 18:30:51 UTC 2012


#21767: Remove stripslashes from API functions
-------------------------------------------------+-------------------------
 Reporter:  alexkingorg                          |       Owner:
     Type:  task (blessed)                       |      Status:  new
 Priority:  normal                               |   Milestone:  3.6
Component:  General                              |     Version:  3.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |
  tests 3.6-early                                |
-------------------------------------------------+-------------------------

Comment (by ryan):

 Here's a somewhat unorganized dump of my current notes on this:


 For 3.6, leave GPC slashed.



 Introduce wp_gpc_unslash() (or whatever we want to call it) to
 conditionally unslash strings and arrays of strings if GPC is slashed.



 Change core to expect unslashed data everywhere. Functions/methods/files
 that deal directly with GPC should do something along the lines of
 $post_data = wp_gpc_unslash( $_POST ) at the top. Functions that do not
 directly use GPC will have all slash adds and strips removed.



 Plugins should move to using wp_gpc_unslash() before passing GPC strings
 to core API.



 Plugins no longer have to worry about slashing data pulled from the DB
 before passing it back to core. Since most don't anyway, their code
 suddenly starts working correctly.



 Plugins should start expecting all data passed to filters to be unlashed.
 Most do already, so this too starts working according to expectations.



 The only abstraction is wp_gpc_unslash(). No fussing with abstraction of
 the GPC super globals themselves. The super globals are well known and
 just fine as an API. We just need to stop littering them with slashes.



 With GPC staying slashed and core moving to expecting unslashed, this
 leaves one major back compat pain point: double slashing of data coming in
 from GPC.



 So, we do a big push during 3.6 to get plugins using wp_gpc_unslash().
 Many won't update, but those are the ones that are probably already
 insecure and badly slashed. The goal would be to get the most popular ones
 updated and establish the pattern.



 In 3.7, turn off GPC slashing. All plugins using wp_gpc_unslash() keep
 working just fine. This allows us to push the bigger back compat pain --
 bare SQL queries directly using GPC -- until after we've established the
 wp_gpc_unslash() back compat pattern and worked out any double slashing
 issues.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21767#comment:36>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list