Support

Account

Register Login

Forum Replies Created

  • Great that you got it working! I’m sure there will many users in similar situations

  • It sounds like you might have some CSS overriding the textColor. I don’t see anywhere in the Gutenberg docs that there should be a linkColor – blocks.json it meant to align ACF with WP standards. So links will follow textColor or what you’ve defined in the CSS.

    Any reason why you don’t just make a CSS definition of the link color in that block?

  • Slightly modified

    {
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 2,
    "name": "acf/clb-custom-info-card",
    "title": "Info Card",
    "description": "A custom info card block.",
    "style": [ "clb_custom_info_card.css", "clb-custom-info-card-style" ],
    "category": "common",
    "icon": "admin-comments",
    "keywords": ["testimonial", "quote"],
    "acf": {
        "mode": "preview",
        "renderTemplate": "clb_custom_info_card.php"
    },
    "align": "full"
}

    Save it as card-block.json and place in theme subfolder /acf-blocks/ – or where you like. Just adjust paths.

    Filename can be changed, but must end with -blocks.json (discovered this after lots of debuging)

    Style value can break the loading if the file can’t be found. It should be relative to the card-block.json

    In your functions.php you can load it with

    register_block_type(
    get_template_directory() . '/acf-blocks/card-block.json'
);

    I placed it in a subfolder to the theme /acf-blocks/ with clb_custom_info_card.cssin the same folder.

    You can declare expected attributes with a static default value by adding this node in the json.

    "attributes": {
    "my_custom_attribute": {
        "type": "string",
        "default": "a_default_value"
     }
  }

  • If you paste your block registration array – or the entire function here, I’ll see if I can put something together for you.

    I’m sure it will make sense when you see it 🙂

  • I did some testing with using block.json to register a block and declare your clb-custom-anchor explicitly and it worked. It doesn’t seem possible to do the same way with acf_register_block_type.

    Using block.json is the new standard, so it makes sense to do it that way. Have you looked into it? The transsition isn’t that bad. If you json_encode you settings from the acf_register_block_type array it’s mostly usable with the block.json format.

  • It does seem strange. I’m battling similar issues and I suspect they are related. At this point it seems that it is in fact WP that filters the attributes and not ACF, but I’m not completely sure. I’ll let you know when I get closer to a conclusion…or a workaround.

  • Try reloading the page after first save – or leave editing and go back.
    The AJAX save of WP doesn’t return the new block content with the added attribute, but if you reload after first save it’s there.

  • I can into the same problem with the suggested solution from ACF. But further research showed that only attributes set directly in the $block scope are reset. Setting it in $block[‘data’] makes it persistent

    function mypre_add_anchor_to_blocks( $attributes ) {

	error_log('attributes');
	error_log( print_r( $attributes, true ) );

    if( !isset($attributes['data']['customvalue']) || empty($attributes['data']['anchor']) ) {
        $attributes['data']['customvalue'] = 'block-' . uniqid();
    }
    return $attributes;
}
add_filter('acf/pre_save_block', 'mypre_add_anchor_to_blocks');

    Notice – on first save of the page you need to reload the admin page with the editor to make the block include the new attribute.

  • Very confusing. If only they knew someone with some coding and web experience who could help them sort it out 🙂

  • It just dawned on me that the whole issue might really be related to ACF filtering attributes that aren’t defined in the group and instead of going through the hoops of my function above, you could achieve the same with the ACF suggested function you already tried – just by placing the value in ['data]sub-node. Like this

    function mypre_add_anchor_to_blocks( $attributes ) {

	error_log('attributes');
	error_log( print_r( $attributes, true ) );

    if( !isset($attributes['data']['anchor']) || empty($attributes['data']['anchor']) ) {
        $attributes['data']['anchor'] = 'block-' . uniqid();
    }
    return $attributes;
}
add_filter('acf/pre_save_block', 'mypre_add_anchor_to_blocks');

  • ACF removes attributes added directly to the normal attribute scope. I’m guessing it happens if it isn’t created in the field group.

    Below code adds the attribute blockId to the data scope of the block, so instead og getting from $block['blockId']you can use $block['data']['blockId']

    Hook is wp_insert_post_data

    You can probably do without the placeholder array, but I kept for debugging purposes.

    add_filter( 'wp_insert_post_data', function ( $data, $postarr ) {

	// Blocks to add attribute
	$blocks_check 	= ['acf/my-block-name','core/paragraph', 'core/heading'];

	// Get saved page blocks
	$blocks_data 	= parse_blocks( wp_unslash( $data['post_content'] ) );

	// Placeholder array
	$blocks_changed = array();

	// Loop through blocks
	foreach ( $blocks_data as $block ) {

		// Check if block is in array of blocks to add attribute
		if (!isset($block['blockName']) || !in_array($block['blockName'], $blocks_check)) {
			$blocks_changed[] = $block;
			continue;
		}

		// Add attributes
		$block_changed = $block;
		$block_changed['attrs']['data']['blockId'] = ( !empty( $block['attrs']['data']['blockId'] ) ? $block['attrs']['data']['blockId'] : 'id_' . uniqid() );
		$blocks_changed[] = $block_changed;
	}

	//Add to error log
	//error_log( print_r( $blocks_changed, true ) );

	// Update post content
	$data['post_content'] = serialize_blocks( $blocks_changed );

	// Return data
	return $data;

}, 99, 2);

  • Can the attribute name be something else than ID or Anchor? Just to avoid whatever it is ACF is doing.
    As I understand you need a unique identifier that doesn’t change on save. And it doesn’t need to be accessible for change in the editor. Right?

  • OK – let me look into it. It should be doable by checking for an existing ID before making a new one.

  • https://wordpress.stackexchange.com/a/311390

  • Do you mean WP-admin in general or is it an issue with ACF?

    Since WP 4.7 the admin language is defined per user – on the account edit. So your admin can be in English and other users can se whatever language they like.

  • For some reason my reply doesn’t show. So here it is again, sorry if it shows double
    ….
    I’m not sure if you need the ID to always be the same or just unique, but if you are simply after an ID value in the template, maybe you can use something I made for a somewhat similar case. I just needed an ID for the template, without saving all the blocks again.

    I faced the same issues and the suggested solution didn’t really work as expected. Instead I used a WP filter that doesn’t get changed by ACF

    I used it to check for old align_content and align_text that are also changed in ACF 6.x, and at the same time I set the ID – if they aren’t already available.

    None of the attributes are actually saved with the block. They are dynamic and meant to be bridge old attributes that ACF removes and be available in the template.

    function acf_legacy_attributes_missing( $parsed_block, $source_block, $parent_block ) {

	$parsed_block['attrs']['align_content_acf_legacy']	= ( !empty( $parsed_block['attrs']['align_content'] ) 	? $parsed_block['attrs']['align_content']	: '' );
	$parsed_block['attrs']['align_text_acf_legacy'] 	= ( !empty( $parsed_block['attrs']['align_text'] ) 	 	? $parsed_block['attrs']['align_text'] 		: '' );
	$parsed_block['attrs']['id'] 						= ( !empty( $parsed_block['attrs']['id'] ) 	 		 	? $parsed_block['attrs']['id'] 				: 'block_id_' . uniqid() );
    return $parsed_block;
}
add_filter( "render_block_data", "acf_legacy_attributes_missing", 10, 3 );

  • I’m not sure if you need the ID to always be the same or just unique, but if you are simply after an ID value in the template, maybe you can use something I made for a somewhat similar case. I just needed an ID for the template, without saving all the blocks again.

    I faced the same issues and the suggested solution didn’t really work as expected. Instead I used a WP filter that doesn’t get changed by ACF

    I used it to check for old align_content and align_text that are also changed in ACF 6.x, and at the same time I set the ID – if they aren’t already available.

    None of the attributes are actually saved with the block. They are dynamic and meant to be bridge old attributes that ACF removes and be available in the template.

    function acf_legacy_attributes_missing( $parsed_block, $source_block, $parent_block ) {

	$parsed_block['attrs']['align_content_acf_legacy']	= ( !empty( $parsed_block['attrs']['align_content'] ) 	? $parsed_block['attrs']['align_content']	: '' );
	$parsed_block['attrs']['align_text_acf_legacy'] 	= ( !empty( $parsed_block['attrs']['align_text'] ) 	 	? $parsed_block['attrs']['align_text'] 		: '' );
	$parsed_block['attrs']['id'] 						= ( !empty( $parsed_block['attrs']['id'] ) 	 		 	? $parsed_block['attrs']['id'] 				: 'block_id_' . uniqid() );
    return $parsed_block;
}
add_filter( "render_block_data", "acf_legacy_attributes_missing", 10, 3 );
Viewing 17 posts - 1 through 17 (of 17 total)