Reply To: Regression: Backslashes stripped in WYSIWYG

• figureone

• September 17, 2013 at 5:58 am

Gah, I should have paid more attention to the commented out section, I didn’t even notice that you had tried my suggestion. Sorry about that.

Is there any chance you can provide more details on the server setups that have problems? I can try to recreate those setups and see if there’s a better way to detect which specific configurations require stripslashes_deep() and which do not. I’d be willing to invest some time to finding a solution.

I hesitate to turn magic quotes on on my server because it’s been deprecated in PHP 5.3 and removed in PHP 5.4 (the community has decided it’s a bad way to solve the sanitization problem). I also can’t see a solution where I can hook in after stripslashes_deep() has run in your code, because I have no way of knowing where slashes were removed from. My current solution is to hack your plugin and comment out that line, but (a) that leaves me in the lurch whenever you roll out updates, and (b) it still leaves others with the problem of data loss of backslashes in their ACF wysiwyg content (at least if they’re running newer versions of PHP).

I suppose a fall back solution is to expose a WordPress option that lets us end users choose whether to have that particular call to stripslashes_deep() enabled. That way you can leave it enabled by default to appease your legacy users, and I (and others) can disable it without hacking the plugin code.

Let me know which way you’d prefer to go, and I can either (a) research the problem setups with more info from you, or (b) submit a pull request with the code to expose a WordPress option (it would probably appear when editing a field definition that’s set to “Wysiwyg Editor,” under “Show Media Upload Buttons” and “Conditional Logic”).