I just updated my WP installation to 4.3 and the ACF WYSIWYG is still acting strange, but a little different than before.
It’s no longer changing the code saved. Whether I’m using paragraph tags, inline, or hard returns, it stays the same. However, it’s still getting rendered to the page oddly. For example, putting everything on one line adds an empty paragraph before my closing shortcodes.
And this may have been buggy before I updated, but I just noticed that I can’t toggle between the visual and text editors. If I click the one that’s turned off, nothing happens. My selection apparently still gets sent to the cookie, though, because if I refresh the page, I’ll see the editor I tried to switch to.

Hello again,
So I’ve talked to Elliot and the reason he’s not using wp_editor is that it’s not compatible with repeater and flexible fields.
However there is a filter you can use to modify the tinyMCE settings in ACF
acf.add_filter('wysiwyg_tinymce_settings', function( mceInit, id ){
// do something to mceInit
// return
return mceInit;
});

Alright so I took another quick look and I can’t find any reference to the native wp_editor in the included wysiwyg field in ACF Pro core.

Hi John,
Unfortunately no.. I’m not that deeply involved with the ACF development.
However you might look at the changelogs and search for references to wysiwyg.
Oh, I assumed ACF was using wp_editor(). Maybe I was confused by the ACF WordPress WYSIWYG Field.

Alright thanks.
There’s a lot of posts recently about the behaviour of the wysiwyg field. I’m considering talking directly to Elliot about this and see if there’s a deeper reason why he’s not using the default wp_editor function or if it’s something that could be introduced in an update. I think that would solve most issues people currently have including yours 🙂

Hi @adrian-b
I’ve seen a lot of posts regarding the wysiwyg field as of late.. It would seem that ACF for some reason does not use wp_editor() to create the editor.. why that is I’m not sure but it could be simply because the wysiwyg field was introduced before wp_editor().
I think I will take it up with elliot regarding possibly making the effort to switch to the native function rather than a custom editor.

It sure does look like ACF wysiwyg is handling things differently.
I’m fairly sure the wysiwyg field is not created using wp_editor() (not 100% sure why but it’s possible wp_editor was introduced after the wysiwyg field).
Just to make sure, do you have the latest version of ACF and WordPress? Do you run any filters or hooks on the ACF fields which could interfere?
Correct. The standard WYSIWYG doesn’t appear to have this problem. Here’s an example with the standard WYSIWYG on top and the ACF editor in the History tab below.
Same content in both originally – http://grab.by/JGx6
How content is saved after hitting publish/update – http://grab.by/JGxe
Original with all tags/shortcodes inline – http://grab.by/JGxk
After updating – http://grab.by/JGxs
Original with hard returns – http://grab.by/JGxy
After updating – http://grab.by/JGxA
@hube2 Thanks once again for your help, but I have noticed another ‘bug’ the Wysiwyg Editor fields don’t seem to be displaying content with paragraph tags anymore either with the activation of the filter plugin.
I currently have the call looking like this …
the_field(‘column_1′, $term);
// $term = $taxonomy.’_’.$term_id to get the correct category content
I found this http://goo.gl/Y8Jw5E and tried reversing it like this …
the_field(‘column_1’, true, true, $term);
But that broke it 🙁
but I tried this and it worked …
$wysiwyg = get_field('column_1', $term);
echo apply_filters('the_content', $wysiwyg);
I hope this may help others in the future.
Would this work in reverse?
the_field(‘wysiwyg_field’, true, true);
Thanks! And like I mentioned earlier, I was able to add in an option within the admin for adding values to the body class with about 8 lines of code but I wasn’t sure how to submit code changes like that. Also, the classes can be controlled through a JS filter but it isn’t quite as clean as an actual field setting:
http://hereswhatidid.com/2015/08/customize-acf-wysiwyg-input-styles/

Yeah using it for repeater wysiwyg provides a challenge. I think that Elliot created the wysiwyg field before wp_editor() became available as I can’t see that he’s using it in core. Or perhaps there’s another reason.
In any case looking through the code it does not seem to be any available undocumented hooks for working with the classnames.
I will assign @elliot to this topic and perhaps he has some more feedback.
I just wrote a blog post on how I was able to use the wrapper CSS Class field on the WYSIWYG to modify the body class within the rendered iframe:
http://hereswhatidid.com/2015/08/customize-acf-wysiwyg-input-styles/
I also have a fix in place that would add a new property to all WYSIWYG fields that lets you directly specific the classes rather than using the filter but I’m waiting on that to be reviewed.
Let me know what you think, thanks!

Hi @tizgrape
Do you experience this when trying to use the media button in a wysiwyg field?
I’ll second this request! Jim, I like your idea of the option to use a text field as the label. One downside to that is if there is no text field with the FC block. For example, I have FC fields that are just one wysiwyg field.
Extending your idea, I’d add a conditional option to add a text field for the custom label. Or, just create a standard text field for the custom label.
I actually created a quick hack of the acf plugin to do this. Would love this added to ACF as a feature. I posted it here:

I actually came across this:
https://wordpress.org/plugins/advanced-custom-fields-custom-wysiwyg-styles/
Albeit, I have heavily modified it to do some of the things I need it to do for my custom setup, but the basics work and are there to build upon.
Works nicely! I may repost my version into a more generic-use plugin for this, because there are some issues that the author didn’t account for in his code.
Don’t wait around for me though, you’ll probably be best to take that plugin and modify it for yourself too.
Definitely interested in this as well. Would be great to be able to specify a unique editor-styles.css for each WYSIWYG field either through front end options or a filter.
Guess 1 :
@elliot In my case, it seems it is the great number of TinyMCE WYSIWYG that slows things down. I’ve looked at the code in acf-input.js and there’s a different tinymce.init for every field (which is logical), but since mine were had all the same params, I’ve tried to “cache” all the ones with the same params to init them all at the same time in the same call, but the only effect that had was to prevent loading the CSS files again and again. Which didn’t correct the problem completely even though I saw a really small difference in loading time.
Guess 2 :
My other guess is the WOFF fonts. I don’t know why, but in my Chrome developer tools, I see those loading right after as if they were the one to block the loading. Couldn’t figure out why the server wouldn’t cache them, which should rule out that guess as well.
Guess 3 :
Before activating script debug mode, it seemed to block ad a load-scripts.php call with a lot of scripts in it. But after activating the debug mode, I’ve seen it didn’t seem to be this one that was causing the slowdown, but much more the 54 calls to tinymce.js… Why 54? I don’t know. I only had 25 tinymce fields in view at the time.
Guess 4 :
(╯°□°)╯︵ ┻━┻
I currently have the same issue. I am also using a lot more conditionals than it should be because tabs seem to have a problem with them. When there is, let’s say, a field to check (true/false) that makes a tab and its sub-fields appear, the tab appears but the sub-tabs aren’t checked on by the conditionals. In other words, if they are set to appear at another conditional inside the tab, they still are showing.
Ex.:
– Show content boxes (checkbox = checked)
— Tab showing wysiwyg boxes (appears as per conditional)
— Content box wysiwyg (showing as per conditional)
— Show alternate content (checkbox = not checked)
— Alternate content box wysiwyg (showing, conditional not respected)
I had to add a conditional that applies to each sub field that checks both checkboxes (inside and outside the tab) which adds a lot more than necessary and slows down everything.
Maybe using Zepto instead of jQuery would help out fiddling a little less with the dom? Is all the dom play necessary?
I uninstalled and removed ACF. I tried this with a previous version of ACF and this don’t work. After updating to the latest version still not working. Also, I tried to create another WYSIWYG field with different name and doesn’t work either.
Yes, in main post content editor this works fine. It only happens in WYSIWYG editor of my ACF’s field 🙁
Yes, I have WordPress latest version too.
Hi Jonathan,
I tested it with twentyfifteen and only ACF Pro 5.2.8 enabled and it’s still removing all my content when I try to save a WYSIWYG field. Any ideas of how can we debug this?
Thanks

Okay so I’ve tried it now on a WYSIWYG field.. I tested the car emoji ? 🙂
It works just fine for me.. the content is saved regardless of how I place the emoji. Could you try disabling all other plugins and test it again? And perhaps try it with the default twentyfifteen theme. Just to eliminate any outside interference

Hi @andreu
When you say that all the field content is removed do you mean that your emojis are removed or that if you’ve pasted in a block of text in the wysiwyg-field and save it the whole thing gets removed leaving you with an empty editor?
If so, does the same thing happen if you paste in text NOT containing any emojis?
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.