Looks like this issue is back…
– WP 4.1 with ACF PRO 5.1.5
– Totally clean install to test this issue
– ACF is the only plugin
– Theme is bare except for WP_DEBUG enabled in functions.php
– No PHP errors on admin page or JS errors in console
The field group holds a repeater field with a WYSIWYG field inside. When editing a post, re-sorting the repeater causes the WYSIWYG field to remove all paragraph and line breaks. This only happens when the WYSIWYG is in Visual mode (Text mode preserves the breaks OK).
I made a quick 1 min. screencast showing the issue here: https://www.youtube.com/watch?v=JoC71DGS1eM
Any ideas? Thank you!
Just to supply more information on this,
I’m receiving the following before the first field in the field group is displayed.
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/acf.php on line 532 Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/acf.php on line 532
I’m receiving the following errors on the following lines. I can see fully the first field that renders completely fine and the the 2nd doesn’t. Theres a total of 6 fields in the field group.
The 2nd field should be a repeater which includes a wysiwyg and 2 text fields.
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 98
field-
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 98
" data-type="
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 98
" data-id="
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 98
">
<div class="field_meta">
<table class="acf widefat">
<tr>
<td class="field_order"><span class="circle">
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 102
1</span></td>
<td class="field_label">
<strong>
<a class="acf_edit_field row-title" title="Edit this Field" href="javascript:;">
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 105
</a>
</strong>
<div class="row_options">
<span><a class="acf_edit_field" title="Edit this Field" href="javascript:;">Edit</a> | </span>
<span><a title="Read documentation for this field" href="http://www.advancedcustomfields.com/docs/field-types/" target="_blank">Docs</a> | </span>
<span><a class="acf_duplicate_field" title="Duplicate this Field" href="javascript:;">Duplicate</a> | </span>
<span><a class="acf_delete_field" title="Delete this Field" href="javascript:;">Delete</a></span>
</div>
</td>
<td class="field_name">
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 114
</td>
<td class="field_type">
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 115
Notice: Undefined index: in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 115
</td>
<td class="field_key">
Notice: Uninitialized string offset: 0 in /wp-content/plugins/advanced-custom-fields/core/views/meta_box_fields.php on line 116
Any advice greatly appreciated.
Eureka!
Thanks to @ractoon and this snippet i managed to solve it:
http://www.ractoon.com/2014/11/acf5-pro-color-picker-custom-palettes/
This is how my function looks right now:
In my child themes functions.php i declare the colors:
// Adds client custom colors to WYSIWYG editor and ACF color picker.
$client_colors = array(
"222222",
"8dc4d5",
"e1523d",
"eeeeee",
"323232"
);
Then in my main themes functions.php:
global $client_colors;
array_push($client_colors, "FFFFFF", "000000");
function change_acf_color_picker() {
global $parent_file;
global $client_colors;
$client_colors_acf = array();
foreach ( $client_colors as $value ) {
$client_colors_acf[] = '#'.$value;
}
$client_colors_acf_jquery = json_encode($client_colors_acf);
echo "<script>
(function($){
acf.add_action('ready append', function() {
acf.get_fields({ type : 'color_picker'}).each(function() {
$(this).iris({
color: $(this).find('.wp-color-picker').val(),
mode: 'hsv',
palettes: ".$client_colors_acf_jquery.",
change: function(event, ui) {
$(this).find('.wp-color-result').css('background-color', ui.color.toString());
$(this).find('.wp-color-picker').val(ui.color.toString());
}
});
});
});
})(jQuery);
</script>";
}
add_action( 'acf/input/admin_head', 'change_acf_color_picker' );
One problem remains though: when i click(not drag circle) on the colorpicker, it seems to hold the old color value from when i’ve grabbed the circle and dragged it around. This becomes obvious when i drag the vertical slider.
Okay, the mystery…er..a workaround for this was found by a co-worker of mine.
Firs the fix and then some details in case acf folks need some variables for bug fixing.
Workaround
Our WYSIWYG fields were set to ‘basic’. When they were set to ‘full’ all of a sudden the div’s mentioned above in the first post showed up in the text editor tab. Which they hadn’t in the text editor tab in the ‘basic’ editor.
Deleting the opening and closing divs fixed it.
Debugging Details
Here’s a sample of what the div’s looked like in the editor. Note there’s more than one set in this one. Not the case for all examples.
<div class="page" title="Page 13">
<div class="section">
<div class="layoutArea">
<div class="column">
<strong>A call to action (with a little humor)</strong>
</div>
</div>
<div class="layoutArea">
<div class="column">
“On paper, Toxoplasma gondii looks as if it ought to be the most famous parasite on earth. This single-celled pathogen infects over half the world’s population, including an estimated 50 million Americans. Each of Toxoplasma’s victims carries thousands of the parasites, many residing in the brain. As if that were not enough
of an accomplishment, Toxoplasma is equally adept at infecting all other warm-blooded animals, as disparate as chickens and kangaroos.”
Opening paragraph of “A Common Parasite Reveals Its Strongest Asset: Stealth” By Carl Zimmer, The New York Times, June 20, 2006
This is his conclusion:
“Dr. Milton M. McAllister, a parasitologist at the University of Illinois at Chicago, has called for controlling the spread of Toxoplasma by cats. He notes that oocysts from cats can also infect wildlife. Toxoplasma has even been detected in sea otters, suggesting it can reach the ocean.
‘It’s perfectly safe to keep a cat,’ he said. ‘Just keep it inside.’”
<strong>How does this change your view of things?</strong>
“On Oct. 16, 2002, at 4 p.m., I walked out of my apartment in Secunderabad, India, leaving the door wide open, the lights on and my laptop humming. I don’t remember doing this. I know I did it because the building’s night watchman saw me leave. I woke up the next day in a train station four miles away, with no idea who I was or why I was in India. A policeman found me, and I ended up strapped down, hallucinating in a mental hospital for three days. ”
Opening paragraph of “Crazy Pills” By David Stuart MacLean, New York Times Op-Ed, August 7, 2013.
His conclusion:
“Lariam is a drug whose side effects impair the user’s ability to report those side effects (being able to accurately identify feelings of confusion means that you probably aren’t that confused). The side effects leave no visible scars, no objective damage. But if Lariam were a car, if psychological or neurological side effects were as visible as broken bones, it would have been pulled from the market years ago.
It’s a prescription I wish I had left unfilled.”
</div>
</div>
</div>
</div>
Hi @arpad
What code are you using to modify the toolbars?
Here is an article to help: http://www.advancedcustomfields.com/resources/customize-the-wysiwyg-toolbars/
Thanks
E
Damn, I should have taken a closer look at how ACF handles conditionals. I had the impression it loaded just what was needed, not everything. But it seems that with conditionals all the fields are still there, just hidden.
This of course means that some calls are made for fields I don’t use. And some scripts runs brutally slow.
I chose conditionals, because it made the interface behave as I wanted it to. But what I should have done where to create new layouts for each content type, since those load as needed rather than always.
As soon as I moved the relationship field to its own layout, the AJAX-calls stopped. I then found the next bottleneck, which where the wysiwygs. I have a 40 second latency between loading tinymce and rendering/continuing.
It seems the code for handling conditionally hidden elements is less than complete. Really, stuff should be truly inactive when they are conditionally hidden. It’s bad enough that they get posted, they should not be scripted as well.
But, to be fair, it makes a kind of sense – if you see conditionals not as a way of choosing what kind of content to add, but as a way to make variations in the kind you have already chosen.
Could I ask, as a minimum, that this is reflected in the documentation? It would prevent the kind of gotchas I’m experiencing now. I’m among those that tend to RTFM before I start, so it would have been a great help avoiding this situation.
I echo what birdwell said, it would be awesome if the sourcecode when using the WYSIWYG would save formatting (similar to the built in wordpress html one). It’s a little frustrating to test out some html to then have it compressed into one jumbled mess.
Yea, I too am in desperate need to get this functionality to be compatible with advanced custom fields. A wysiwyg editor wouldn’t be an option since I just need a background image set with the image… would be so much easier if I could just pick the image from another site.
to hide title from backend you can/need to set up a custom post-type that has that setting.
at your “register_post_type” function change/replace/add this line:
'supports' => array('revisions'),
then only revisions shows at backend, no title, no exerpt, wysiwyg, … , leave blank to show nothing except your acf
of course you can use any needed value out of this instead or additional to revisions (list is not complete, look at wp reference)
array( 'title', 'editor', 'author', 'thumbnail', 'excerpt', 'comments' )
@vmtx
Thanks a lot. Could you explain more.
You need to add the Markdown extra OR Jetpack’s Markdown Jetpack will be enought?
Do it works with Flexible WYSIWYG?
Hi Eliot,
Just want to say I appreciate your making this plugin. On the site I’m currently developing the client wants to use tons of HTML within the content editor. With the code modal box (without line breaks, in other words, and within a relatively small window) it was nearly impossible to edit.
Having the WP wysiwyg available is helpful in dealing with it.
I’m using it on ACF 4 btw
I had this issue after migrating from local development to a Media Temple Grid server. @JonathanSoper’s fix worked for me (Thanks, Jonathan).
EDIT: I also had to modify ‘core/fields/wysiwyg.php’. I changed this line:
$plugins['code'] = apply_filters('acf/get_info', 'dir') . 'js/tinymce.code.min.js';
to this:
$plugins['code'] = get_bloginfo('url') . '/wp-content/plugins/advanced-custom-fields/js/tinymce.code.min.js';
But editing plugin files is less than ideal. Any chance we might see a fix for this at some point, @Elliot Condon?
Thanks!
Yep, I’m also experiencing this problem.
ACF PRO Version 5.1.3
WP 4.0
A wysiwyg field in a flexible content field row looses the formatting after ordering the rows.
Seems to be back after a fix in ACF 4.3.0:
WYSIWYG field: Fixed JS bug where formatting is removed when drag/drop it's repeater row
Fix would be awesome!
I can confirm that this bug is still active for me also (ACF PRO 5.1.2). So when viewing a WP attachment permalink page, that attachment image also gets inserted into wysiwyg option fields that I have in my footer file for any odd reason. Any clue?
Images will also not attach through the wysiwyg editor in a field. Text changes will save as normal.
Note: This issue went away when we reverted to 5.1.0
Hi!
You’ve probably set the return value for the image field to be URL rather than image object. So you should not use that markup for the image. Here’s a complete version of what you’re doing:
<?php
//check for the repeater first. We dont want to do a while loop if there are none!
if(have_rows('favorite_cars')){
//Loops through the repeater
while (have_rows('favorite_cars')) {
the_row();
//fetches the post object field. Assumes this is a single value, if they can select more than one you have to do a foreach loop here like the one in the example above
$car_object = get_sub_field('select_car');
$title = get_sub_field('car_title');
$summary = get_sub_field('car_summary');
if($car_object){
//Fetch the image field from the carsandtrucks post
$image = get_field('main_image', $car_object->ID);
}
//Echo out the image. Since you set it to only return the image URL you can only use this for src. Change the field settings to object if you want to use the version i previously posted.
echo '<img src="' . $image . '" />';
echo '<h2 class="favorite-car-title"><' . $title . '</div>';
//Depending on what kind of field the summary is you want the <p> tag around it.. If the field is a wysiwyg field or a textarea with automatic p-tags, remove the <p> and </p> from the code.
echo '<div class="favorite-car-summary"><p>' . $summary . '</p></div>';
}
}
?>
Its such a small thing so don’t worry about compensation!
someone that can throw some light on how to make ajax-generated acf forms to work properly with the media, WYSIWYG, conditional, etc (all the fields that require JS initialization)??
I am trying to get some customer support to solve this, but yet no luck as they keep providing the code above, that is attached to the php function handling the ajax call, the one that generates the acf form. But it is still not working.
Media upload fields, WYSIWYG, conditional logic and repeater (I guess any field that requires some sort of JS initialization) are not working properly if the form is generated via ajax. For example I still get this simple error for media fields, which clearly indicates that js snippet they are providing is not initializating the media field correctly:
TypeError: wp.media is undefined
xxx.xxx.xxx/wp-content/plugins/advanced-custom-fields-pro/js/input.min.js?ver=5.0.9 line 1
I wonder if someone out there has managed to do this really essential thing, as for all the people out there using ajax to generate forms this is very much needed, and if this is impossible to do with acf, please I encourage acf team to state it clearly in the features before people waste their money and time on this and can give a try to other plugins for front-end edition via ajax.
There are problems with WYSIWYG and image field.
My code:
jQuery(document).ajaxComplete(function($){
acf.do_action('append', $('#post'));
$(document).trigger('acf/setup_fields', $('#post'));
});
taxonomy fields don’t have such problems
Same here!
I use image, text and WYSIWYG fields – only text fields seem to be affected. Funnily enough text fields within my nested repeater are shown.
EDIT:
Tried to change the field type from text to WYSIWYG but values still won’t show. Still it’s weird that i can see all none text fields (except for the first one).
EDIT2:
Seems like all fields – no matter what type – created after 5.1.1 won’t be shown.
Same here, I had some wysiwyg fields named ‘content’ that were not displaying. They were within a flexible content field, I had others that were named ‘content’ as well, and they were showing, in the same flexible content group. Rolled back to 5.1.0 and all is well again.
I’m am noticing this also within a Flexible content field. It looks like select WYSIWYG fields’ content are not displaying when I try to output them to the page:
<?php echo get_sub_field('section_content'); ?>
Hi @paulwarren
Thanks for the bug report.
I have a strong feeling that this issue is resolved in ACF PRO (ACF v5) because the implementation of the WYSIWYG field is much much smarter (and the above highlighted code no longer exists).
Are you able to give ACF PRO a go? If you have purchased an add-on in the past, you will see a free version in your store account
Hi, I’m seeing this problem too. It’s confusing behaviour if you go back to re-edit & save a WYSIWYG field, as the stripped-tags version of the content over-rides the intended content. Is there a temporary way to fix it using acf_the_content
filter for now?
Looking at a solution to this with ACFPRO as well.
Would like to choose which WYSIWYG editors to remove P tags from.
Thanks
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.