It’s been a while since I checked in on this issue. I’m now using ACF 5.3.1 (pro). It appears that this issue may have been solved. Does anyone have a word on it?
Almost every day I wish this was a feature. It would be so helpful for usability.
@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.
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.
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.
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.
I’ve been mulling over a temporary solution. One options page with a repeater which allows the user to define and order elements, then on a second options page use the PHP export to create the single item’s fields and register them inside a loop populated by the repeater.
It’s a bit complex but until repeaters can collapse it’s something I’ll have to do. I have repeaters where each item has a dozen or more subfields. It’s too hard for users to drag and drop each item.
I could really really use this. I’m always making repeaters with a dozen or so subfields and would really like to make reordering easier for my users.
I checked the variables on line 77 of acf-options-page-update.php and they both return correctly, “1.1.0”.
I was having this issue but I haven’t had it in a bit now. Was it server-side?
