Support

Account

Register Login

Home › Forums › Bug Reports › Regression: Backslashes stripped in WYSIWYG

Solving

Regression: Backslashes stripped in WYSIWYG

  • Hi Elliot,

    There seems to be a regression to the fix we arrived at in this thread:
    http://old.support.advancedcustomfields.com/discussion/comment/15573#Comment_15573

    The latest code shows that the stripslashes_deep() call is back:
    https://github.com/elliotcondon/acf/blob/36422e64320045e665b4b98349c4d2bfda7edaa2/core/fields/_functions.php?#L188

    Can you remember if there was a reason you brought it back? I can confirm that it causes problems by removing any backslashes in wysiwyg field content any time the page is saved. I’m running WordPress 3.6 with ACF 4.2.2.

    In my particular case, I have field content that contains a lot of LaTeX code, and LaTeX special characters are identified by a backslash + name (e.g., \times for the multiplication symbol). When all backslashes are stripped out, the LaTeX markup is destroyed.

  • Hi @figureone

    The issue is that some servers have the magic quotes option turned on which conflicts with the strip slashes function.

    I can remember 100% what the issue was, but I remember all my attempts to apply different logic deepening on the magic quote option failed each time.

    Sorry, but making any changes to this will massively effect thousands of clients.

    Perhaps you can hook into the update_value filter and write some code to counteract the issue?

    Thanks mate
    E

  • Thanks for being so responsive, Elliot!

    I’ll let you know if I come up with a solution that (a) doesn’t unnecessarily strip backslashes from wysiwyg field content, and (b) works properly with older PHP setups that have magic quotes enabled.

    If you don’t mind, I’ll leave this issue open until I can report back.

    Cheers,
    -paul

  • Hey Elliot, sorry for the delay.

    How about using the PHP native function for detecting whether magic quotes is enabled on a particular setup?
    http://php.net/manual/en/function.get-magic-quotes-gpc.php

    If magic quotes is enabled, you can use the stripslashes_deep() call, and skip it otherwise. For example:

    if ( get_magic_quotes_gpc() ) {
  $value = stripslashes_deep( $value );
}

    In place of the offending line:
    https://github.com/elliotcondon/acf/blob/36422e64320045e665b4b98349c4d2bfda7edaa2/core/fields/_functions.php?#L188

  • Hi @figureone

    I had previously used that code (that is why it is commented out).
    I had to remove it due to multiple issues on many servers.

    Although the code makes logical sense, it did not work across all servers and many WYSIWYG started double escaping or even removing completely special characters.

    I’m not confident enough to put this back in, and I do apologies that this doesn’t leave you with much option, but perhaps you could chat to your server and change your magic quotes setting?

    Thanks
    E

  • 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”).

  • Hi @figureone

    I can’t remember off the top of my head what the server setups were, however I do remember when I trialed that code I had many bug reports due to it. That is why I commented out the if statement.

    I wish I could be of more help here and I apreciate you are willing to help, however I don’t have any time at the moment to look into this issue for you. It seems that at the moment you are the only one experiencing this issue which is unfortunate but is still the reality.

    I do not wish to modify this core code of ACF. It will only bring me headaches from users all over the world on hundreds of different server setups. I think the problem was that the if statement returned a wrong result from some servers – not sure why, but it did.

    Not sure what to do about this one…

    Just to clarify, this is only an issue with the WYSIWYG field… perhaps you could hook into the update_value of this field, before ACF (priority of 0) and apply some code to the value??

    Sorry mate

    Thanks
    E

  • Hey @elliot,

    I understand server setups are varied, so lets not waste any more time trying to tackle the problem by identifying which ones have problems with magic quotes.

    Instead, let me show you how ACF doesn’t work on one of the most common server setups, Ubuntu 12.04 LTS (it’s the standard image on Amazon EC2 and linode). Here are some steps I took to reproduce the ACF bug under this setup:

    * I created a test VM environment (Ubuntu 12.04 LTS, PHP 5.3.10, MySQL 5.5.32).
    You can do this easily in vagrant–Ubuntu 12.04 Precise 32bit is the default vagrant box. Instructions on setting up a vagrant virtual machine on your computer is available here:
    http://docs.vagrantup.com/v2/getting-started/

    * I installed a vanilla copy of WordPress 3.6.1 and ACF 4.2.2.

    * I created a new ACF Field Group, and added one Wysiwyg Editor field to the field group. I left all defaults as-is, so the field group appears on all posts on the site.

    * I then edited the sample post included with WordPress (“Hello world!”), and added the following content to the new ACF field:
    Hi! This is ACF content. It just might strip out \ backslashes, which could be \nasty.

    * I then saved the post (by clicking “Update”), and confirmed that the backslashes (“\”) were removed from the above text.

    In short, I think you haven’t heard about this issue from others because the backslash is a lightly used character, and tracing this issue back to ACF is time consuming. But any data loss issue should be treated seriously.

    The easiest solution for you, I think, is to implement another option in the Settings panel for a Wysiwyg field. This setting would simply toggle whether stripslashes_deep() gets called or not. If we do it that way, we don’t have to use get_magic_quotes_gpc() at all, so you shouldn’t get any reports from other users on older PHP setups. This option would default to the current behavior if you wish, so it doesn’t change the default behavior, but it would give me and any others running newer PHP setups the ability to prevent ACF from haphazardly removing backslashes from all ACF wysiwyg content.

    I can provide the pull request with this code, so you don’t have to take extra time writing it. I simply need some sort of assurance that you’ll implement it before I take the time to write the code.

    Cheers,
    -Paul
    PhD Information Science
    College of Education
    University of Hawaii

  • Hi @figureone

    Thanks mate. I really appreciate your help on this one, even though I can’t offer a quick solution.

    Yes, I think the best solution is to offer an option for the field. But perhaps we could do this as a ‘non UI’ option such as a filter for the wysiwyg field.

    Something like:

    
<?php 

apply_filter('acf/fields/wysiwyg/strip_slashes', 'my_wysiwyg_strip_slashes', 10, 1);

function my_wysiwyg_strip_slashes( $strip_slashes )
{
	// default is true
	$strip_slashes = false;
	
	return $strip_slashes;
}

?>

    I’ll add this to the to-do and re-read over this entire thread to make sure I haven’t missed something.

    As for timings, I’m extremely busy for the next 2 weeks, but then I’m going back to full time dev on ACF! So this will definitely be introduced into the core soon.

    Thanks a million
    Cheers
    E

  • Awesome, I think a back-end filter would be fine, since trying to describe what’s going on here in a UI option might be difficult for nontechnical users to understand.

    For the short term, I’m covered by simply commenting out the stripslashes_deep() call in the ACF code, so it’s not a big rush. Let me know when the filter makes it into core, though! At that point I can roll out a custom filter in all of my relevant themes.

    Cheers,
    -paul

  • Hi,
    I’m having the same problem with what I think is the same line of code (#188) in the _functions.php file.

    In my case, the backslashes get stripped from plain text fields where I need to store regular expressions.

    Your suggestion about hooking to the ‘update_field’ filter won’t work because you are calling streepslashes_deep() BEFORE the apply_filters() call.

    I think the option of the backend filter is a quick one, but it may also be useful to pass more info to the filter, e.g., the field type and name, field group, etc., so the programmer can have more context info in order to make the decision either to return false or true.

    Thanks in advance,

    Adrián

  • Hi @figureone

    I will be adding in the extra filter soon, but just to reply to your statement about filter timings, you can infact hook in BEFORE the core update_value filter.

    ACF hooks into this on line 26 of _functions.php with a priority of 5. You can hook in before 5 and run beforehand!

    Thanks
    E

  • An option for the field would be ideal – this is actually a fairly problematic issue for some circumstances.

  • I have a third party validation script that uses REGEX and it is getting stripped. Maybe a new field for RAW or SCRIPTS so filters aren’t applied? I am just a front-end dev, so maybe I am talking out my arse. First time this has been an issue for, so probably a low priority.

    It there something I can add the my functions.php in the meantime? I’d rather not edit core files as clients tend to update without asking.

  • Hi Elliot, just checking in to see if you have an update on this issue.

    As a refresher, the current version of ACF will delete backslashes in any wysiwyg field upon saving. This issue exists because the ACF codebase has an extra call to stripslashes_deep() to deal with old PHP versions running magic quotes.

    In my case, this destroys LaTeX markup in those fields, because every LaTeX variable starts with a backslash. Others have chimed in saying that their regular expressions get mangled.

    Your proposed solution seems fine to me. More details on it in your comment here:
    http://support.advancedcustomfields.com/forums/topic/regression-backslashes-stripped-in-wysiwyg/#post-4335

    Thanks!

  • Hi Elliot,

    Same problem here, and probably in many websites with computer/Internet related content – windows paths, windows registry keys, latex markup, some regular experessions, code snippets with escaping sequences are destroyed if someone uses ACF WYSIWYG to store them.

    Not to mention ASCII arts! :-))

    Solution mentioned by figureone seems fine for me also.

    Any plans for fix in near future?

    Thanks in advance
    Marek

  • Hi Elliot,

    Unfortunately your suggested solution (hook into update_value before core update_value) CANNOT WORK.

    Core acf/update_value is action, not filter, So, I may hook but cannot change anything.

    _function.php line 26:
    add_action(‘acf/update_value’, array($this, ‘update_value’), 5, 3);

    You call acf/update_value as filter but later, from inside core acf/update value, AFTER stripslashes_deep.

    So there is completely no way to fix this issue without editing your code.

    Marek.

  • This issue is causing a headache for me as well. Would love to know when/if a solution is found.

    I am storing JavaScript in a textarea field and need to keep my escapes else the code is rendered invalid.

  • Just a quick update. The issue is that line 188 in _functions.php. A lot of us need a way to disable that action for certain fields.

    For now I am commenting out that line on a production site and I’d like to get away from this.

  • Anything new on this Issue? I have the same problem as ryanburnette. I developed a Javascript Content Editor which saves the content in an JSON Object but all the data is invalid (not parseable) if the slahes (escaped quotes) got stripped.

    At the moment i commented out the line too but the problem is i use this in a theme with ACF equipped so if a user has it’s own ACF Plugin installed i have a problem since he will have strip slashes active.

    Any Ideas? I guess best would be to leave a note that the theme will only work with the pre equipped ACF but iam highly unsatisfied with this solution. 🙁

    Any Ideas would be great, thanks Michael

  • Honestly the best solution is a ‘code’ field type in ACF. The stripslashes_deep() that runs on text fields and textareas is important. Having a field where it is assumed that code is entered and input is stored *as-is* would make the most sense. It should probably come with a disclaimer, but a lot of us need it.

  • Yes that would be great. For the time being i guess i will add my own custom meta boxes and try to save the code ‘as-is. This is all running in the background (hidden) and the user won’t take note.

  • Yes, that would be nice. I only wonder if that opens up security loopholes *eyebrow raise*

  • Hi,
    Since I receive notifications about new posts in this thread and there is no reply from Elliot I decided to share my solution which is probably the only way to fix this problem without editing plugin code. It is extremely dirty hack but it works for me and is still better then editing AFC code. Put it in your functions.php

    I attach as zipped .php file because I am affraid that this text field may delete backslashes or something 🙂

    Marek

    acf-fix.zip.zip

  • @busybrian Yes it does present a security risk which is why it should come with a disclaimer. Still, we need a code field in ACF.

Viewing 25 posts - 1 through 25 (of 30 total)
1 2

The topic ‘Regression: Backslashes stripped in WYSIWYG’ is closed to new replies.