esc_sql in 3.6 changes how /r /n and maybe other characters handled
|Reported by:||sc0ttkclark||Owned by:|
In Pods, we've been using esc_sql (maybe wrongly, after reading #21767) in 3.x, in conjunction with stripslashes_deep, when working with $_POST data.
By default, WP slashes all $_POST data on load, so we come back around and set a scoped var with the $_POST data, stripslashes_deep on the array, and use the values in the code. Once ready to save, in certain areas we've been using esc_sql.
Now I'm not yet sure what's going on well enough to fix it on my side for 3.6+, but it appears that this change 3 weeks ago may have a big part to do with it: 24718
It seems now at some point in 3.6, \r and \n become just "r" and "n".
We've been sanitizing data before it hits wp_update_post and other areas it looks like, so there's bound to be issues on our side here that we'll need to resolve now.
I'm posting this ticket at the request of @markjaquith who wanted to better understand what we're dealing with right now. I'll post updates as I determine what fixes I needed to make in case it helps other plugin developers who come across this issue.
If you read anything that would appear as a WP bug in this ticket, feel free to jump in and help figure out what needs to be done, otherwise you can close this as invalid if it ends up being a pilot error.
Code to reproduce:
$content = "Testing it out\n\nTest"; $postdata = array( 'ID' => $post_ID, 'post_content' => esc_sql( $content ) ); /* WP 3.x: $postdata[ 'post_content' ] = "Testing it out\n\nTest"; WP 3.6: $postdata[ 'post_content' ] = "Testing it out\\n\\nTest"; */ wp_update_post( $postdata );