[wp-trac] [WordPress Trac] #56119: `wp_unslash()` and `wp_slash()` do not (un)slash the same data.

[WordPress Trac]

#56119: `wp_unslash()` and `wp_slash()` do not (un)slash the same data.
-------------------------------------------+------------------------------
 Reporter:  peterwilsoncc                  |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  new
 Priority:  normal                         |   Milestone:  Awaiting Review
Component:  Formatting                     |     Version:
 Severity:  normal                         |  Resolution:
 Keywords:  reporter-feedback 2nd-opinion  |     Focuses:
-------------------------------------------+------------------------------

Comment (by SergeyBiryukov):

 I think `wp_slash_strings_only()` was deprecated because it appeared to be
 the same as `wp_slash()` as of [48433], though the difference in object
 handling was probably not considered.

 Good catch on the inconsistence in object handling! Looks like that was
 the case ever since `wp_slash()` and `wp_unslash()` were both introduced
 in [23555].

 Looking at #21767, it seems that:
 * `wp_slash()` was introduced as a replacement for `addslashes()` and
 `add_magic_quotes()`.
 * `wp_unslash()` was introduced as a replacement for `stripslashes()` and
 an alias for `stripslashes_deep()`.
 * `wp_unslash()` intentionally unslashes objects: comment:53:ticket:21767.

 I guess the question to answer would be: do we need to slash objects in
 `wp_slash()`, or would that be unexpected? This comment seems tangentially
 related: comment:17:ticket:21767, and this commit too: [24731].

 I think `wp_slash()` and `wp_unslash()` may not necessarily have been
 intended to be the opposite, but that would probably make sense if there
 are no unexpected site effects.

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