We just had the same problem with a transition from ACF+Repeater, etc., to Pro. All our field groups but one were duplicated. The one that was not duplicated had only a single text field; each of the others had repeater, WYSIWYG and/or related post link fields.
The bad news is that in at least one case, there are two fields missing from one of the repeater fields in the older version of the field group. The portal_box field in field_group #5209 has only three fields; the one in field_group #5255 contains all five of the fields that should be there. (See attachments.) As a result, part of the portal box is not displaying.
We have no multi-language support. Here’s a list of our active plugins:
ManageWP – Worker (v4.1.6) by ManageWP
Gravity Forms (v1.9.9) by rocketgenius
Admin Quick Jump (v1.4) by James Kemp
Advanced Custom Fields Pro (v5.2.6) by elliot condon
Advanced Post Types Order (v3.6.2) by Nsp Code
BackWPup (v3.1.4) by Inpsyde GmbH
Categories Images (v2.5) by Muhammad Said El Zahlan
Cookies for Comments (v0.5.5) by Donncha O Caoimh
Duplicate Post (v2.6) by Enrico Battocchi
WordPress Editorial Calendar (v3.5) by Colin Vernon, Justin Evans, Joachim Kudish, Mary Vogt, and Zack Grossbart
Enable Media Replace (v3.0.3) by Måns Jonasson
Google Analytics by Yoast (v5.4.2) by Team Yoast
Google Calendar Events (v0.7.2) by Ross Hanney
Gravity Forms – Placeholders add-on (v1.2.1) by Joan Piedra
Gravity Forms MailChimp Add-On (v3.6) by rocketgenius
Image Watermark (v1.5.0) by dFactory
McWebby Magnific Popup (v00.01.00) by Donna McMaster
McWebby Custom Post Types (v00.02.01) by Donna McMaster (declares post types)
Media Tags (v3.2.0.2) by Paul Menard
Members (v0.2.4) by Justin Tadlock
Simple Sitemap (v1.65) by David Gwyer
Sucuri Security – Auditing, Malware Scanner and Hardening (v1.7.9) by Sucuri, INC
Category Order and Taxonomy Terms Order (v1.4.2) by Nsp-Code
ThreeWP Activity Monitor (v2.12) by edward mindreantre
WooCommerce Bulk Discount (v2.3.1) by Rene Puchinger
WooCommerce Dynamic Pricing (v2.9.6) by Lucas Stark
WooCommerce (v2.3.10) by WooThemes
WooThemes Helper (v1.5.5) by WooThemes
WordPress SEO (v2.1.1) by Team Yoast
WP Migrate DB Pro (v1.4.7) by Delicious Brains
WP SEO Humility (v0.1) by Donna McMaster
Must-use Plugins:
ManageWP – Worker Loader (v) by ManageWP
McWebby Debug Log (v0.1.0) by Donna McMaster
Thanks @elliot this lead me to the solution.
i can share now this code:
function my_acf_input_admin_footer() {
?>
<script type="text/javascript">
acf.add_filter('wysiwyg_tinymce_settings', function( mceInit, id ){
// do something to mceInit
mceInit.setup = function( ed ){
ed.on('init', function () {
// Note these lists may not be complete & that other tinymce plugins can add their own shortcuts anyway.
var ctrls = [ 'u', '1', '2', '3', '4', '5', '6', '7', '8', '9', 's', 'k', 'Alt+F', 'P' ];
var modKeys = [ 'c', 'r', 'l', 'j', 'q', 'u', 'o', 'n', 's', 'm', 'z', 't', 'd', 'h', 'o', 'x', 'a', 'w', '1', '2', '3', '4', '5', '6', '7', '8', '9' ];
// Overwrite shortcuts with no-op function. Key sequences will still be captured.
for (var i = 0; i < ctrls.length; i++ ) {
//this.addShortcut('ctrl+' + ctrls[i], '', function () {}); //use if tinyMCE <=4.1.7
this.addShortcut('Meta+' + ctrls[i], '', function () {});
}
for (var i = 0; i < modKeys.length; i++ ) {
//this.addShortcut('alt+shift+' + modKeys[i], '', function () {});//use if tinyMCE <=4.1.7
this.addShortcut('access+' + modKeys[i], '', function () {});
}
});
};
// return
return mceInit;
});
</script>
<?php
}
add_action('acf/input/admin_footer', 'my_acf_input_admin_footer');
can be inserted into function.php or a own plugin and should work. and provide the disable of tinymce shortcuts. (at my example it removes: headings, underline, and more. bold and italic shortcuts would still work)
I will update this post with the other options that wish to use. as soon i tested it
EDIT:
TinyMCE <= 4.1.7, and >= 4.1.8 use different code
Hi @mediawerk
It is possible to modify all tinymce settings through the JS filter:
‘wysiwyg_tinymce_settings’
You can see how to use this filter here: http://www.advancedcustomfields.com/resources/adding-custom-javascript-fields/
Thanks
E
To add to the above, I thought it might help to post up some images showing the problem. I decided to use a text field instead of a WYSIWYG editer, to keep the images compact and clear.
To begin with, I create 5 rows, each containing a c-logic checkbox and a text field. The checkbox determines whether the text field is visible or not. I save/update the page and the result looks like this:-
I then uncheck the checkboxes to hide the text fields and update the page again:-
Then, I insert a new row between rows 2 and 3 and populate the new text field with “new row” :-
Now, if I press update and then make all the rows visible, I get the following:-
As you can see, the rows and their data have not moved down as expected. Row 3 has been wiped and replaced with the new row.
Thanks
The fields were WYSIWYG.
I did get this sorted out. In case anyone else has the same issue on a site hosted at WP Engine, I’ll put the fix below.
In WP Engine’s control panel, under SSL, I had to use the following:
Uncheck “Force http:// for non-SSL pages” – if this is checked I was getting a redirect trying to log in.
Select “Use SSL for WP-login” – don’t select the one that includes WP-admin. WP-login only does keep WP-admin https too so I’m not sure what the difference is, but the one that includes WP-admin sets the “Site Address (URL)” to use https://, WP-login only does not.
With these settings, the admin pages are still https, but internal site links in ACF WYSIWYG fields do not get automatically converted to https when resaving. This was happening on 3 sites at WP Engine so I don’t think it was a one off weird configuration or anything.
I’ve testing the wysiwyg field on category taxonomy and it’s working in both ACF4 & 5.
My guess is that there is some kind of interference from another plugin.
Do you have any other plugins on the site that effect the WYSIWYG editors on the site?
Here is the solution I have used to remove the stray p tags when using shortcodes in the ACF WYSIWYG (put that in your functions file).
function wpex_clean_shortcodes($content){
$array = array (
'<p>[' => '[',
']</p>' => ']',
']<br />' => ']'
);
$content = strtr($content, $array);
return $content;
}
add_filter('acf_the_content', 'wpex_clean_shortcodes');?>
So far, I have not had any problems with this solution.
Hi,
Here is an almost similar thread on how to access acf field from the product category page.
I hope this helps.
Hi @elliot thank you for your input.
I did follow your recommendation as a temp solution.
Do you see this being implemented in a future release?
Having the embed code in both the post’s editor and the ACF WYSIWYG field isn’t ideal.
Cheers and thanks again!
@tmconnect like i say at opening post: modify only the toolbar is not enough for me. thats why your post dont help. and if you read carefully you will see that problem is made by ACF, thats why i also cant use tiny_mce_before_init filter. that work for/with default wysiwyg.
@elliot any toughts, comment or help for this problem?
or is someone else able to help me, without to modify corefiles?
I’m having load issues using a repeater field with conditionals as stated above. The main problem is the JS load time crashes the browser, and I also get a lot of “connection lost” errors.
I changed all text fields to text areas versus wysiwyg, and also elminated a couple of conditionals. This helped a little bit, but still not good.
I’m thinking of rebuilding using the ACF Pro with the Flexible content. Can you tell me if you think this would solve my issue?
You can modify the toolbars with the acf/fields/wysiwyg/toolbars
filter like this
function my_toolbars( $toolbars ) {
$toolbars['Full'] = array();
$toolbars['Full'][1] = array('bold', 'italic', 'underline', 'bullist', 'numlist', 'alignleft', 'aligncenter', 'alignright', 'alignjustify', 'link', 'unlink', 'hr', 'spellchecker', 'wp_more', 'wp_adv' );
$toolbars['Full'][2] = array('styleselect', 'formatselect', 'fontselect', 'fontsizeselect', 'forecolor', 'pastetext', 'removeformat', 'charmap', 'outdent', 'indent', 'undo', 'redo', 'wp_help' );
// remove the 'Basic' toolbar completely (if you want)
unset( $toolbars['Basic' ] );
// return $toolbars - IMPORTANT!
return $toolbars;
}
add_filter('acf/fields/wysiwyg/toolbars' , 'my_toolbars');
Hope this helps
You can modify the toolbars with the acf/fields/wysiwyg/toolbars
filter like this
function my_toolbars( $toolbars ) {
$toolbars['Full'] = array();
$toolbars['Full'][1] = array('bold', 'italic', 'underline', 'bullist', 'numlist', 'alignleft', 'aligncenter', 'alignright', 'alignjustify', 'link', 'unlink', 'hr', 'spellchecker', 'wp_more', 'wp_adv' );
$toolbars['Full'][2] = array('styleselect', 'formatselect', 'fontselect', 'fontsizeselect', 'forecolor', 'pastetext', 'removeformat', 'charmap', 'outdent', 'indent', 'undo', 'redo', 'wp_help' );
// remove the 'Basic' toolbar completely (if you want)
unset( $toolbars['Basic' ] );
// return $toolbars - IMPORTANT!
return $toolbars;
}
add_filter('acf/fields/wysiwyg/toolbars' , 'my_toolbars');
Hope this helps
Maybe this alternate solution is a little bit faster. It simply change the default option of the colorpicker when there are acf fields on the page.
function change_acf_color_picker() {
// Adds client custom colors to WYSIWYG editor and ACF color picker.
$client_colors = array(
"#222222",
"#8dc4d5",
"#e1523d",
"#eeeeee",
"#323232",
"#ffffff",
"#000000"
);
echo "<script>
(function($){
try {
$.wp.wpColorPicker.prototype.options = {
palettes: " . json_encode($client_colors) . "
};
}
catch (e) {}
})(jQuery)
</script>";
}
add_action( 'acf/input/admin_head', 'change_acf_color_picker' );
I’ve solved this myself by adding the following to my theme’s functions.php:
function acf_apply_content_filter_for_api($value, $post_id, $field){
return str_replace( ']]>', ']]>', apply_filters( 'the_content', $value) );
}
function add_content_filter_ACF(){
if(!is_admin()){
remove_all_filters('acf/format_value/type=wysiwyg');
add_filter('acf/format_value/type=wysiwyg', 'acf_apply_content_filter_for_api', 10, 3);
}
}
add_action('init', 'add_content_filter_ACF');
Sorry to hijack this thread but I’m looking at the exact same issue. Civil footnotes is a basic plugin that allows content authors to write footnotes. The plugin hooks on to the_content and generates a list of numbered footnotes by searching for anything matching the (( this is a footnote )) pattern.
Here’s the plugin: https://gist.github.com/Jolora/a947b856d3440f8cc029
I was wondering if you could give a clue as to how I would go about getting this plugin to also search any WYSIWYG ACF fields, including those inside flexible content fields.
Any help would be appreciated please. Thanks!
I’m in the same boat!! This plug-in is terrific!
I’m having the same issue — and i’m trying to access the Image-URL via ‘meta:’ in a post-based slider. My workaround is create a custom field text type that cntains the URL text of the image — but I’d really like to use the wysiwyg image controls.
Accessing it via the Meta tags only returns the image ID.
Did you figure this one out?
Hi @kraft
Thanks for the info.
All the $_POST data should be fine, as ACF is rendering the form via do_shortcode
and all input names within the form look correct.
perhaps the issue is explained by the code on line https://github.com/Automattic/jetpack/blob/master/modules/contact-form/grunion-contact-form.php#L180.
If you are running the the_content filter during the function, perhaps you have some code which is looking for an embeded form, which you then use as a validation method to continue processing the form.
ACF save’s the shortcode (string) value within the post meta, not the $post->post_content so this validation would fail each time.
Perhaps as a temp solution @angel-meraz could place the embed code within the post’s content as well as the ACF WYSIWYG field?
Hi @angel-meraz
Thanks for the info.
I have attached a screenshot of what I see – a working shortcode.
The form is rendered correctly, so perhaps there is something else which I do not understand.
If the issue is with ‘saving’ the data which is posted from the form, this may not be related to the WYSIWYG field at all, but something to do with the 3rd party plugin.
Are you able to contact the form developers and ask them what the solution is? I’m sure that someone else has used ACF with their form before and they have a solution
Thanks
E
I updated the test site, followed your recommendation and I can confirm that the Jetpack Form shortcode does not work when inserted via an ACF field.
The code used to display the ACF field is:
<?php $wysiwyg = get_field('editor');
if ( $wysiwyg ) {
the_field('editor');
} else {
echo 'ACF field is empty';
} ?>
The shortcode used to display the Jetpack Form in both tests is:
[contact-form to='[email protected]' subject='Shortcode Test 1'][contact-field label='Name' type='name' required='1'/][contact-field label='Comment' type='textarea' required='1'/][/contact-form]
Yup, we’re experiencing a bit of this as well, although not as extreme
– A flexible content canvas that contains multiple flexible content blocks, each of which can have 20 – 30 ACF fields of all types (checkboxes, repeaters, wysiwyg, taxonomy choice, etc)
On the more complex pages (15 or so content blocks), it can take up to 20 or 30 seconds to update. Would really like to get a handle on this as we’re right on the line between tolerable and intolerable.
Hey @elliot thank you for looking into this.
Basically, the problem is that the form is not submitting.
If the shortcode were entered through the native WordPress WYSIWYG editor after submitting it should display a message, create a data entry inside Jetpack’s Feedback menu tab and send an email. None of that happens when the shortcode is inserted through an ACF field.
Please take a look a this tests and try to submit the forms:
Test 1 http://galo.prompt-dev.com/
Test 2 http://galo.prompt-dev.com/jetpack-form-shortcode-test-2/
Any pointers are welcome.
Dear Elliot, I have a bad news on this.
since the last update o mqTranslate this warning has appeared
DEPRECATION NOTICE
As of February 19th, 2015, mqTranslate has been deprecated in favor of qTranslate X.
I’ve made some test but unfortunately, WYSIWYG fails again with qTranslate-X and qTranslate-Plus. (it blanks the fields on saving -> data loss).
Could you have a look? If you need any more information, I am happy to help.
Many thanks
M.
Probably you’re right and it has nothing to do with the_content
filter.
I adopted that idea from similar posts of people having the same issue.
Problem is -although the form is being displayed- it just doesn’t works. But if the shortcode was placed in the default WYSIWYG WordPress editor it would.
In the example test page provided ( http://galo.prompt-dev.com ) the Jetpack form is being inserted via an ACF WYSIWYG field.
What could it be then?
Thanks, Elliot. This is helpful. What are the other parameters we can use here? For example, can we target a specific field by name or all fields within a specific repeater?
To get some insight, here is our current code that works well, but not sure if it is the best way about it. For example, if you decide to change the class names (which you did in a recent update, this approach will break):
acf.add_action('load', function($el){
// Loop through each ACF field
acf.get_fields().each(function(){
// Specific for Repeaters
var table = $(this).parents('.acf-table-wrap'), // Get the table wrapper for the repeater
row = table.parent('.acf-row'), // Get the acf-row containing everything
hidden = table.find('[data-name="<?php echo self::UNIQUE_ID_FIELD_NAME; ?>"] input'); // Get the unique_id hidden field
// Check if the unique_id field has a value
if(hidden.length != 0 && hidden.val().length != 0){
// We are looking at a parent item since the unique_id is set
var remove_row = row.find('.acf-repeater-remove-row'),
input = $(this).find('.acf-input'), // Get the input wrapper for the field
field_name = $(this).data('name'),
field_type = $(this).data('type'),
field = null,
data = null;
if(field_type == 'wysiwyg'){
field = input.find('.acf-editor-wrap');
data = field.find('textarea').val();
} else {
switch(field_name){
case '<?php echo self::ACF_TOPIC_TITLE; ?>':
field = input.find('input');
data = field.val();
break;
}
}
if(field != null){
// Hide the entire WYSIWYG field
field.hide();
// Hide remove icon/ability
remove_row.css('visibility', 'hidden');
// Display the data from the WYSIWYG field
input.append(data);
}
}
// End Repeaters
});
});
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.