UPDATE, @niq1982 code doesn’t work if you are using a get_field() where you actually specify the post_id (e.g. get_field(‘field_name’, $somePostID) ).
I was able to fix this by checking if the $original_post_id is indeed a revision of the $post_id.
function fix_acf_field_post_id_on_preview($post_id, $original_post_id)
{
// Don't do anything to options
if (is_string($post_id) && str_contains($post_id, 'option')) {
return $post_id;
}
// Don't do anything to blocks
if (is_string($original_post_id) && str_contains($original_post_id, 'block')) {
return $post_id;
}
// This should only affect on post meta fields
if (is_preview()) {
if ( $original_post_id !== $post_id ) {
// Check if $post_id is a revision
$parent_post_id = wp_is_post_revision( $post_id );
if ( $parent_post_id === $original_post_id ) {
return get_the_ID();
}
}
}
return $post_id;
}
add_filter('acf/validate_post_id', __NAMESPACE__ . '\fix_acf_field_post_id_on_preview', 10, 2);
I’m having this problem on pages and it seems to happen seemingly randomly depending on who the last person was to change the draft post. Simply re-saving the draft sometimes fixes the problem.
I did implement @niq1982 fix and that seems to solve the issue. Hopefully somebody fixes this soon because it makes it nearly impossible to draft post for review with any level of confidence.
I am using WP 6.4.1/ ACF PRO 6.2.3.
This is an OLD question, but I stumbled upon it when trying to answer how to add items to the pre-defined Basic menu. Here is the code I’ve used, which was written using the information found at ACF.
/********************************
ADD ADDITIONAL TOOLBAR SET TO ACF WYSIWYG
********************************/
if ( function_exists( 'get_field' ) ) {
add_filter( 'acf/fields/wysiwyg/toolbars' , 'qd_toolbars' );
function qd_toolbars( $toolbars )
{
//INJECT/ADD AN OPTION INTO THE BASIC TOOLBAR
$toolbars['Basic' ][1] = array_merge( array_slice( $toolbars['Basic' ][1], 0, 3, true ), array( 'subscript','superscript' ), array_slice( $toolbars['Basic' ][1], 3, null, true ) );
//FIND MORE INFO ABOUT THIS OPERATION AT http://www.advancedcustomfields.com/resources/customize-the-wysiwyg-toolbars/
// Add a new toolbar called "Very Simple"
// - this toolbar has only 1 row of buttons
$toolbars['Very Simple' ] = array();
$toolbars['Very Simple' ][1] = array('bold' , 'italic' , 'underline', 'link', 'unlink' );
// return $toolbars - IMPORTANT!
return $toolbars;
}
}
I can confirm that I have this problem as well. Rolling back to 5.9.3 solved the problem.
I discovered an answer to this at https://www.billerickson.net/disabling-gutenberg-certain-templates/. It does not use the “hide on screen” settings, but it did accomplish what I was trying to achieve.
@garethdaine, that isn’t an option for me as I’m using the ACF Blocks for Gutenberg.
We are also experiencing this with WordPress 5.0.2 & 5.0.3 and ACF 5.8.0-beta3. Our sub-fields within repeaters do not seem to save correctly. Returning to the edit page displays blank fields and the data is not displayed on the front end of the site. No errors are reported in the PHP error log.
Any word on looking into this problem?
I came across an article to do this outside of ACF, so this post can be closed.
We updated a site today and this error seems to be finally fixed. Was there a change somewhere in a recent update that might have resolved this?
I was able to solve this with the following code:
/* SHOW FIELD SET ON PASSWORD PROTECTED PAGES */
add_filter('acf/location/rule_types', 'acf_location_rules_types');
function acf_location_rules_types( $choices ) {
$choices['Post']['visibility'] = 'Post Visibility';
return $choices;
}
add_filter('acf/location/rule_values/visibility', 'acf_location_rules_values_visibility');
function acf_location_rules_values_visibility( $choices ) {
//var_dump($choices);
$choices['password'] = 'Password Protected';
return $choices;
}
add_filter('acf/location/rule_match/visibility', 'acf_location_rules_match_visibility', 10, 3);
function acf_location_rules_match_visibility( $match, $rule, $options )
{
$the_post = get_post($options->post_id);
$pw = $the_post->post_password;
if(isset($pw)){
if(!empty($pw)){
$match = true;
}
}else{
$match = false;
}
return $match;
}
Any luck in either replicating this or identifying something in the 5.5.4 update that would cause the server to maybe timeout or something when identifying images contained in folders with a lot of files?
One thing I’ll note is that it also seems to be server specific. It doesn’t happen at my server at Rackspace, but does happen for my client’s server.
I thought this was a server specific issue at first, but realized that rolling back to 5.5.3 resolves the issue… so while it may be a server value that is different between the two environments, it does not seem to be just a server issue. I’m assuming that something changed in 5.5.4 in regards to how images are reference, checked, or retained upon save that might be causing the issue. Perhaps a timeout is occurring that is causing the link/reference to be dropped.
@acf-support I don’t seem to see any code there that triggers validation to be run.
When I attempt this code, acf.screen is undefined when I change the Parent Page dropdown. Is there something I’m missing as well?
jQuery(function ($) {
$(document).on('change', '#parent_id', function () {
acf.screen.parent_page = $(this).val();
$(document).trigger('acf/update_field_groups');
});
});
+1
I’m very interested in this too. Has anyone figured out a good workaround?
I ran into this problem too, so I went over to w3schools and used their uniqid generator to generate a unique ID for me. I then just pasted that, along with field_
into my code. Hopefully this hint saves somebody some time.
I ran into this problem too, so I went over to w3schools and used their uniqid generator to generate a unique ID for me. I then just pasted that, along with field_
into my code. Hopefully this hint saves somebody some time.
I can confirm that ACF 5.3 resolved this issue. Thanks for the quick fix!
Were the developers able to replicate this issue? Was it corrected in 5.2.9?
You may find this answer useful. It shows you how to clear your user metadata to restore the default meta box locations.
http://wordpress.stackexchange.com/a/38648/40585
I seem to be having the same issue. Did you find any resolution?
I can confirm that Rackspace Cloud Sites still result in Error. Could not connect to update server
.
Is there any way that you could include more verbose error messaging in the next plugin update so that we can all provide more qualified feedback?
@elliot, no difference here. Hosting within Rackspace’s Cloud Sites.
Just out of curiosity, does this have something to do with the grandfathered ACF licenses? We had purchased ACF4.# and when 5 came out, we were given an unlimited license for free. It doesn’t have anything to do with those keys, does it?
Any word on this update? I have a site that will need this functionality.
If this isn’t going to be ready anytime soon, can you give me some suggestions on how I might make it work with custom location rules? http://www.advancedcustomfields.com/resources/tutorials/custom-location-rules/
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 Cookie Policy. If you continue to use this site, you consent to our use of cookies.