Hi @kamullis
This should help:
http://www.advancedcustomfields.com/resources/faq/wysiwyg-field-appears-without-toolbar-buttons/
Thanks
E
Hi @motyla
You can use this doc to add custom toolbars to the WYSIWYG field:
http://www.advancedcustomfields.com/resources/tutorials/customize-the-wysiwyg-toolbars/
Thanks
E
Thanks again for the bug report.
I have successfully reproduced the error and have included some logic to use both the functions mentioned above!
You can download the latest github version to see the code in action.
Thanks
E
Hi, you can use advanced tinymce plugin to do this.
But the question is:
Do you already know how to build own buttons in custom tinymce editor (different than the default one)?
Hi @dynamyc
What code are you using to output the WYSIWYG value on the front end?
Also, what code are you using to register to the shortcode?
Can you confirm the shortcode works in the normal the_content editor?
Thanks
E
Hi @dynamyc
Can you take a screenshot of the WYSIWYG buttons and attach it to a comment.
It is most likely 1 of 2 things:
1. You have not ‘opened’ the ‘kitchen sink’
2. You have a tinyMCE plugin which is overriding the buttons set by ACF
Thanks
E
Elliot,
I had a similar issue with the recent update as well. Client’s site has repeaters within repeaters and they complained that the fields would extend beyond as well as beneath the containing borders causing the wysiwyg fields to be unusable.
My initial thought was “your screen is just too small”. Looked into it a little more in-depth and compared it to a cloned site on the version 1.0.1 repeater plugin. It turns out that there was a change in the 1.1.0 css that was causing the issue.
On line 5 of the input.css file you have
table-layout: fixed;
If I comment out this line, the editor displays as expected (expected by the client).
For my client I’m overriding this style attribute with a custom filter in my functions.php.
function admin_css() { ?>
<style type="text/css">
.repeater > table{
table-layout:auto!important;
}
</style>
<? }
add_action('admin_head', 'admin_css');
That should hold them over and even help with future updates, but could you explain the reason for this simple style change? Is my modification going to come back and bite me?
Thanks,
Hi @lexxlevi
Yes, it is possible and is explain in this thread:
http://wordpress.stackexchange.com/questions/50331/advanced-custom-fields-wysiwyg-more-tag
I’m not sure how this would work with using 3 more tags at once, but this will be up to you to test.
Thanks
E
Hi @jrstaatsiii
The screenshot shows the main metabox taking upi t’s full available width within the main column.
The right hand of the browser shows the white space created below the ‘publish’ metabox.
Doesn’t look like there is much space to fit the nested repeaters.
Perhaps you could provide another screenshot that shows where the extra space is that you expect the WYSIWYG to appear?
Thanks
E
Hi @jrstaatsiii
This issue is caused by the tinyMCE editor requiring more space than you are giving it.
I can’t imagine that this was not an issue prior to the 4.3.0 update. If so, are you able to downgrade and show a screenshot?
I’m not sure what the solution is here. You need a certain amount of width of the WYSIWYG field to display all it’s toolbar buttons, and your nested situation is causing the limited amount of space.
Not sure I can provide a solution for this one.
Sorry
Thanks
E
Hi @patricksaad
I have a feeling that the add_editor_style hook will set some default values in the tinyMCE JS object.
It is possible that ACF would also use theye by default (I haven’t tested this myself) but I wonder If I can add some filter to allow for this as well!
Thanks
E
Hello
It’s an Iframe so CSS is out of the question … might be doable with JS though, but I thought there would be a PHP way to do it since there’s already a WordPress hook for the Editor style (add_editor_style). I ended up using a plugin to add Direction buttons on the Editor Toolbar, but I’m still curious whether there’s away to do it without using another plugin.
I will as soon as I figure out how to do it myself 🙂
Hi @tomjhume
Can you try this again, but first place the cursor into the WYSIWYG editor you want the image to go into?
Thanks
E
Hi @patricksaad
Can this be achieved with CSS or does it require JS?
Thanks
E
Hi @thesrpr
Yes, they should appear on the ACF WYSIWYG editor, however I can’t confirm it.
Perhaps you could give it a go and let me know what you find.
Thanks
E
Hi @LingoSam
It may be that the acf WYSIWYG field does not pass the value through the the_content filter.
This filter is used to look at the WP post_content and modify it.
Perhaps this will help:
$value = get_field('wysiwyg_field_name');
echo apply_filters('the_content', $value);
Hope that helps.
Thanks
E
Hi @coerv
A good question. I just found a similar thread over here:
http://wordpress.stackexchange.com/questions/50331/advanced-custom-fields-wysiwyg-more-tag
You can see that the answer involves getting the value, and applying an excerpt filter to it.
You should be able to use this same code, but obviously change get_field to get_sub_field to find the WYSIWYG value.
Does this help?
Thanks
E
After some research, I think the issue is acually a bug with WP 3.7
Are you able to update WP to 3.7.1? This should fix the issue
Thanks
E
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 !
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.