
Hi @gminc
Thanks for the bug report.
The ACF gallery field uses the native WP media popup to display the field data, then it uses CSS to hide the usual main / side bar layout and only show the sidebar.
The issue may be that the WP popup contains a bug in regards to user permissions, so can you open up the normal WP popup (via the_content WYSIWYG) and try to edit the image in question using different user accounts?
Does the WP popup allow you to edit the image?
Thanks
E
Temporary solution:
add_action( 'admin_init', 'wpuxss_admin_scripts' );
function wpuxss_admin_scripts()
{
global $pagenow;
if (( $pagenow == 'admin.php' ) && ($_GET['page'] == 'acf-options') )
{
wp_enqueue_script( 'wplink', home_url('/wp-includes/js/wplink.js') );
wp_enqueue_script( 'popup', home_url('/wp-includes/js/tinymce/plugins/wpdialogs/js/popup.js') );
}
}
Hello Elliot,
I am experiencing similar problem with ACF 4.2.2 (Option page 1.2.0) right now. When I deactivate Formidable 1.07.01 the problem is gone. The problem is only for Options page and for WYSIWYG link button.
Uncaught TypeError: Object [object Object] has no method 'wpdialog'
in the wp-includes/js/tinymce/wp-tinymce.php line 24
Good man! – I will test it out when I’m back on that project… cheers for that – appreciate the response.

Hi @rockethouse
Just wanted to follow up and let you know I have made some changes to the WYSIWYG field in hope that it will solve your original issue.
All the add_filter functions for acf_the_content have been moved to the root of the wysiwyg field file, so you should be able to unhook them in your functions.php file.
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 @Daniel Milner
Yep, the get_field / the_field functions contain a parameter to disable formatting. If you disable the formating, the value will be returned as is from the database (without executing shortcodes / formatting).
Check out the odcs for more info.

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

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
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
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”).
I guess I have a similar issue, Jetpack shortcodes (http://jetpack.me/support/shortcode-embeds/) do not render in ACF fields, wysiwyg or text. Is there any workaround?

Hi @digisavvy
So just to clarify, changing the page template correctly triggers the AJA function to load in the new field group, however, it doesn’t hide the origional field group?
A few questions.
Can you post some screenshots of your fiedl groups showing the location rules?
Are you registering these field groups via PHP?
Can you check your console log for any JS errors during hte page load / AJA call?
Thanks
E

Hi @JAVOB
I suspect the issue is due to the way that ACF instantiates the WP tinymce. Due to the requirements of the repeater and flexible content field, the WYSIWYG field must be duplicate-able at run time, which the default WP WYSIWYG does not offer.
I have a feeling that if install and use the WP WYSIWYG field (add-on) your shortcode button will work as expected. If not, the issue most likely lies within the shortcode plugin as it expects only 1 wysiwyg on the page.
Try out the add-on but be aware it won’t work within a repeater / flexible content field.
Thanks
E
I’m having the same issue using WP 3.5.3 and ACF 4.2.2. There are no JS errors that I can see through dev tools or FireBug.
It may be worth mentioning that just last week I experienced a conflict with WPMU Dev’s Whitelabel WP Videos plugin causing ACF wysiwyg field buttons to go missing (defaulting to HTML view) without Chrome or FireBug complaining about any JS errors.
(sidenote: it wasn’t actually the WPMUDev plugin itself; more precisely it was the fact that I had them enabled in the “Help” pulldown tab of the admin area).
That is where I am going to start looking as I try to figure this out.
Thanks for a super addition to WP!

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
Hi @elliot I have tried as you told me but even so still not working, writing the shortcode in the default content editor.
For more than hidden content editor.
Can you help me with a solution?

Hi,
no, I have no other plugins installed. I tested that on a clean wordpress installation.
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 @Malin
Thanks for the screenshots. I’ll add this to the to-do and do some testing.
Do you have any 3rd party plugins or code which connect to the WP WYSIWYG? Or anything that may effect the tinyMCE JS object?
Thanks
E
of course:
2 flexible fields

I want to move one of them

and text formatting disappears


Hi @JAVOB
Thanks for the feedback.
Just 1 question. Can you first click into the ACF WYSIWYG field and type a few characters, then click the shortcode button.
Does the shortcode appear in the correct WYSIWYG when it is correctly focused?
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!
We use cookies to offer you a better browsing experience, analyze site traffic and personalize content. Read about how we use cookies and how you can control them in our Privacy Policy. If you continue to use this site, you consent to our use of cookies.