Support

Account

Forum Replies Created

  • 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.

Viewing 7 posts - 1 through 7 (of 7 total)