We are using default settings for WYSIWYG
We have not set any custom caps, however we are using Woocommerce – which does, i think.
If you have problems recreating the issue – this was my case also. Other admin users of the site reported the problem, but my user did not have any issues – so I did not believe them … until I created a new admin user and logged in as that guy – then I saw that they where telling the truth..
Now after using CCleaner to clear everything – my user is also gets the error.
1. we have a repeater field that has a post obj field as a sub field.
2. we have tested it with Woocommerce’s ‘products’ as post object.
3. we have tested it with a personal created CTP called Deals as post object.
4. Happened on the woo single product
5. happened on another single CTP as well (when testing if this was woo related)
6. Problem does not occur when repeater field is disabled..
Possible workaround is to use relationship field instead of repeater field.
THanks guys
Just to clarify, the issue only happens when using the current repeater field add-on?
Is there any other pattern you can think of that could cause this issue?
Perhaps the post_Type capabilities, user settings for WYSIWYG…
Hi @elliot
My project is a blog where they will periodically be posting featured weddings. It is a custom with these types of blogs that they will have a list of acknowledgements at the bottom of the post that tells the reader where they got the cake, the flower arrangements and things like that.
I thought the repeater field would be perfect since the size and contents of the list could differ greatly from post to post.
Since this can still be easily input via a custom field with a WYSIWYG editor, it’s not worth the time/trouble to figure out how to make the repeater fields searchable for me at this time.
I -am- still using the repeater field for these same blog posts so that the blogger can create a photo gallery (though in hindsight my client would’ve been better off if I went with the Gallery plugin for this project instead).
—
Once I found out the way that repeater fields are stored in the database, mycustomfield_0_mysubfield, mycustomfield_1_mysubfield, and soforth, I thought if I could somehow return a list of those meta_keys so that I could put them in my array of custom fields it might work…
eg. $custom_fields = array(‘mycustomfield_0_mysubfield’, ‘mycustomfield_1_mysubfield’);
But it would differ depending on the post… so I’m not sure if that would work. Here is my code: pastebin
Hi @dashaluna
The WP WYSIWYG automatically adds in p tags when the value is returned by the get_field function.
This is due to the filters which are run on the WYSIYWG field value which follow the same rules as the standard WP the_content.
To get around the issue, you can load the value without any formatting like so:
the_field('field_name', false, false);
The 3rd false tells ACF to not format the value.
Hope that helps.
An option for the field would be ideal – this is actually a fairly problematic issue for some circumstances.
Hi @elliot,
My issue was that I wanted to add a second description field in my category pages on Woocommerce (with a Wysiwyg editor). The field was correctly displayed in the back-office, however in the front-office it didn’t work with the following code : <?php the_field(‘description_categorie_2’); ?>
And your code in the section “Finding the term related to the current post” (here http://www.advancedcustomfields.com/resources/how-to/how-to-get-values-from-a-taxonomy-term/) didn’t work either.
But ayottepl gave me a clever tip to resolve it
Have a great day !
Hi @hamergil
This must be a limitation with eh WYSIWYG javascript.
Thanks for the bug report. I will attempt to find out the issue and fix it.
Thanks
E
Bonjour Ayottepl,
Je constate que tu es français donc j’en profite pour te poser une question puisque j’ai un problème presque similaire : je suis en train de faire ma boutique sur Woocommerce et dans mon cas je voudrais ajouter une seconde description de catégorie tout en bas de mes pages de catégorie.
J’ai donc paramétré un champ Wysiwyg et créé la règle suivante :
Term est égal à Catégories
Dans mon template archive-product.php, j’ai ajouté le code suivant : <?php the_field(‘description_categorie_2’); ?>
L’éditeur Wysiwyg s’affiche parfaitement dans l’admin, je peux éditer mon texte et l’enregistrer sans problème, mais côté front-office rien se passe ! J’avoue que je suis débutante en php et je n’y connais pas grand chose (donc j’ai eu un peu de mal à comprendre comment tu as résolu ton problème :D). Si jamais tu as une idée pour mon problème je t’en serais grandement reconnaissante parce que comme toi je m’arrache les cheveux depuis des jours et des jours….
Bonne journée,
Elsa
Found it! The ACF Plugin folder was missing the JS folder… something must have happened in the transfer. Thanks for your help!
Hi @anagio
Perhaps this question would be better asked to the developer of the field type?
Just to clarify, this is not a core field type, but a 3rd party one.
Thanks
E
Hi @lee@infectiousstudios.com
Sounds like you have a JS error on the page. Please debug the issue via the console log.
You can use this guide to help:
http://www.advancedcustomfields.com/resources/faq/wysiwyg-field-appears-without-toolbar-buttons/
Thanks
E
Thanks mate.
I’ll add this to the to-do
Yep, that’s the one! I’ve attached a screenshot of the option, just to clarify.
Thanks,
Chris
Hi @chrishutchinson
Interesting! Just to clarify, you are talking about the user specific option to disable Rich Content Editing?
Thanks
E
Hi @aleish76
The remove_filter will not work with the current ACF 4.2.2, but will work with ACF 4.3.0 which you can find in github and will be released shortly.
Thanks
E
Hi Elliot,
It looks like it’s working correctly now. Thanks again for your help and for the quick troubleshooting. This is one of the best plugins for WordPress!
Hi @elliot,
I tried to unhook the filter as rockethouse suggested at the beginning of the conversation and it doesn’t seem to work for me. It should be as easy as putting this: remove_filter( ‘acf_the_content’, ‘wpautop’ ); in my functions.php, isn’t?
No joy though 🙁
Thanks for all your work.
Hi @topdrawinc
Thanks for your help.
I have tracked down the issue and have fixed the WYSIWYG blank issue and pushed to github
Thanks
E
Hi Elliot,
I’m not getting any JS errors in the console log when I edit a post where the WYSIWYG fields fail. Are you seeing the same behaviour on your end?
Thanks for your help!
Hi, new code fixes the problem… My custom role had the depreciated user_level capability missing. $role->add_cap( ‘level_1’ ); fixed the problem.
However I noticed that with the new code, WYSIWYG fields in both front-end and back-end show as empty. The field is being saved but the WYSIWYG field is being rendered as empty.
Thanks!
Hi @topdrawinc
Can you please open your console log and report any JS errors on the edit page where your WYSIWYG fields fail?
Thanks
E
Hi @ildaniel8
You can load the value without any formating like so:
the_field($field_name, false, false);
You can read-up on the docs if you wish, but the 2 false params will prevent formatting.
Thanks
E
Thanks again for the quick response. Unfortunately, I’m still having an issue with this. I downloaded the code from GitHub and tried it, and now all WYSIWYG fields are showing as blank when I load a post to edit it.
The existing data is still being saved, because the data is there when the edit post screen is loading. As soon as the WYSIWYG editor loads, everything disappears. I couldn’t test the drag and dropping since there is no data in the fields.
Can you please take a further look?
Thanks!
Used the WP WYSIWYG Plugin and it solved my issue.
Two birds with one stone really!
