Thank you for the explanation.
This is going to be solved: https://github.com/AdvancedCustomFields/acf/issues/150
OK, although I don’t like it, it cannot be discussed, so finally I’ve updated my keys to be named with “field_” prefix and run SQL replace on post_content.
I’m leaving here a temporary function I’ve used as it may be helpful for someone:
add_action( 'init', 'myprefix_update_fields_keys' );
function myprefix_update_fields_keys() {
global $wpdb;
if ( current_user_can('administrator') && isset( $_GET['upkeys'] ) && $_GET['upkeys'] == 1 ) :
echo "Replacement started!<br>";
$p = 'myprefix-';
$fields = array(
"{$p}myblock-title",
"{$p}myblock-content",
// Many other fields
);
foreach ( $fields as $field ) :
$wpdb->query(
"
UPDATE $wpdb->posts
SET post_content = REPLACE(post_content, '\"$field\"', '\"field_$field\"')
WHERE post_content LIKE '%\"$field\"%'
"
);
endforeach;
echo "Replacement ended!";
endif;
}
I have made some test and it seems that ACF calls get_option() when the block inserted into the content does not actually contain the field keys predicted during registration via acf_add_local_field_group().
It happens when I save an empty block or a block with hidden fields.
So when I add an empty block which looks within the code like:
<!-- wp:acf/header {"id":"block_5c8ac410e890e","name":"acf/header","align":"","mode":"edit"} /-->
the plugin looks for the missing fields in wp_options table, for example:
SELECT option_value
FROM wp_options
WHERE option_name = 'block_5c8ac410e890e_my-header-content'
LIMIT 1
where my-header-content is the name of a field type group in this case.
It’s quite surprising for me – why ACF thinks that I store any block data in wp_options?
Then, when I add some content into the subfield of my-header-content field, the plugin no longer queries wp_options for my-header-content and the block structure grows into:
<!– wp:acf/header {“id”:”block_5c8ac410e890e”,”data”:{“field_my-header-content”:{“field_my-header-content-lead”:”This is our lead”,”field_my-header-content-text”:””},”field_my-header-aside”:{“field_my-header-aside-settings”:””},”field_my-header-background”:{“field_my-header-background-image”:””,”field_my-header-background-video”:””,”field_my-header-background-color”:”white”,”field_my-header-background-has-pattern”:”0″}},”name”:”acf/header”,”align”:””,”mode”:”edit”} /–>
Well, after all I think I’ll report it on Github…
BTW, I discovered that I can set default alignment at a block type registration level but still not in a template.
acf_register_block_type( array( ..., 'align' => 'full', ... ));
Hi, I think that parsing blocks is the only way as the field values are not stored in the database but within the post content.
Look at this:
<!-- wp:acf/overview {"id":"block_5c582992decfd","data":{"my-overview-content":{"my-overview-content-lead":"Here we've got our report overview with all these fancy links."},"my-overview-background":{"my-overview-background-image":""}},"name":"acf/overview","mode":"preview","className":"is-style-default"} /-->
Maybe you can write a nice & useful function get_block_field() and share here. 🙂
It seems that we’ve got it as a parameter in beta3!
function render_callback( $block, $content = '', $is_preview = false, $post_id = 0 ) {...}
Hi, thanks for pointing to acf_maybe_get_POST()
! As I don’t want to edit core files, I wrote a helper which works for me so far within the block template:
function my_acf_post_id() {
if ( is_admin() && function_exists( 'acf_maybe_get_POST' ) ) :
return intval( acf_maybe_get_POST( 'post_id' ) );
else :
global $post;
return $post->ID;
endif;
}
Definitely, I agree that a block instance should contain the post ID or it should be accessible in another elegant way.
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.