Support

Account

Home Forums Gutenberg How to save block data in Beta4 when field group key == name?

Solved

How to save block data in Beta4 when field group key == name?

  • The minority of us registers the custom fields programmatically.
    I used to do that and the common pattern for me was to assign the same unique key and name for a particular registered field.
    Unfortunately, with ACF Pro 5.8 Beta4 the data in a field group created in the mentioned way is not going to be saved…

    Can someone competent check the ACF source code and explain why does it happen? If only I change the value of the name attribute, it works. Also, my code worked perfectly in Beta3. Probably something bad started to happen when ACF processes the input into serialized data.

    PS: At the same time, when I save the post and click to view it, the editor complains about leaving the site (as if the process had not been completed). Every time.

    A sample code registering the field group:

    add_action( 'acf/init', 'my_acf_blocks_init' );
    function my_acf_blocks_init() {
    	/**
    	 * Register block
    	 */
    	acf_register_block_type( array(
    		'name'            => 'mylink',
    		'title'           => __( 'My Link', 'my-acf' ),
    		'description'     => __( 'A block for entering a link name and a custom URL.', 'my-acf' ),
    		'render_callback' => 'my_acf_block_render_callback',
    		'category'        => 'formatting',
    		'icon'            => 'external',
    		'keywords'        => array(),
    		'supports'        => array( 'align' => false ),
    	) );
    
    	/**
    	 * Define block fields
    	 */
    	acf_add_local_field_group( array(
    		'key' => "mylink-block",
    		'title' => __( 'Block :: My Link', 'my-acf' ),
    		'location' => array(
    			array(
    				array(
    					'param' => 'block',
    					'operator' => '==',
    					'value' => 'acf/mylink',
    				),
    			),
    		),
    		'fields' => array(
    			array(
    				'label' => __( 'Link', 'my-acf' ),	
    				'key' => 'mylink',  // Here
    				'name' => 'mylink', // and here it fails...
    				'type' => 'group',
    				'layout' => 'block',
    				'sub_fields' => array(
    					array(
    						'key' => "mylink-name",
    						'label' => _x( 'Name', 'link', 'my-acf' ),
    						'name' => 'name',
    						'type' => 'text',
    					),
    					array(
    						'key' => "mylink-url",
    						'label' => __( 'URL', 'my-acf' ),
    						'name' => 'url',
    						'type' => 'text',
    					),
    				),
    			)
    		),
    	) );
    }
  • I don’t know how or why it has been working for you in the past, but for quite some time field keys have had to start with “field_”. This is an often overlooked thing and is only mentioned under “Field Settings” most of the way down the page https://www.advancedcustomfields.com/resources/register-fields-via-php/

    Early versions of ACF 4 allowed field keys that did not start with “field_” but it was changed shortly by 4.1 or 4.2, I think, that was a long time ago.

    And field group keys must start with “group_”

  • 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;
    }
Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

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.