Support

Account

Register Login

Forum Replies Created

  • Yes, assigning defaults via block.json under attributes, as the WordPress documentation describes, is not reliable at all.

    I really wish ACF would do more to explain what is supported and what isn’t.

    I have resorted to using block variations to assign default attributes to my ACF blocks, because specifying them in block.json is useless:

    wp.domReady(function () {

// USE BLOCK VARIATIONS TO ASSIGN DEFAULTS TO ACF BLOCKS

            wp.blocks.registerBlockVariation(
                'acf/map', [{
                    isDefault: true,
                    attributes: {
                        style: {
                            dimensions: {
								minHeight: '450px',
                            },
                        },
                    }
                }]
            );
});

    I place this in a .js file, then add this to functions:



    add_action('enqueue_block_editor_assets', 'block_modifications');
function block_modifications()
{
    wp_enqueue_script('block-modifications', get_template_directory_uri() . '/assets/js/block-modifications.js', array(
        'wp-blocks',
        'wp-dom-ready',
        'wp-edit-post'
    ), filemtime(get_template_directory() . '/assets/js/block-modifications.js'), true);
}

    There is probably a less hacky way of doing this. It would be so much simpler if we could just set the defaults inside the block’s json file in the way the official WP docs describe.

  • I also need this. I display a list of Material Symbols in a select2 field, and since the update they show as raw HTML: <span class="material-symbols-outlined">bakery_dining</span>.

  • All good.

    A default link colour can be defined in block.json under attributes like this:

    "style": {
	"type": "object",
	"default": {
		"elements": {
			"link": {
				"color": {
					"text": "var:preset|color|blue"
				}
			}
		}
	}
},

    Seems to follow a different format to textColor and backgroundColor.

  • Yes that fixed it! Thanks!

  • That’s good to know!

    I think ACF should use the same way of providing styles as Gutenberg where possible. It makes for a more seamless experience if things like padding, margins, colors, line height (or any settings you can apply to core blocks) are assigned in the same way when using ACF custom blocks.

    Also, something I have been thinking about is that ACF blocks seem to use two separate wrappers for the same block. There is the main block wrapper, then several levels down the ACF container appears with many of the style properties duplicated. It seems like a lot of unnecessary markup. It results in things like double padding and repeated background colors, because the padding and other styles are applied to both the main block wrapper and the ACF wrapper.

    Hope that makes sense, I like the block editor but it has really made things confusing.

  • Hi Igladdy, thanks the reply!

    I have tried it on both ACF 5.9 and ACF 5.10.

    In ACF 5.9 it works fine. I noticed that in ACF 5.9, when I do a var_dump of the block, the array for padding is a bit different:

        [style] => Array
        (
            [spacing] => Array
                (
                    [padding] => Array
                        (
                            [top] => 200px
                            [right] => 200px
                            [bottom] => 200px
                            [left] => 200px
                        )

                )

            [typography] => Array
                (
                    [lineHeight] => 2.1
                )

        )

    Whereas with ACF 5.10 it’s like this:

    [style] => Array
        (
           [paddingTop] => 200px
           [paddingRight] => 200px
           [paddingBottom] => 200px
           [paddingLeft] => 200px
           [typography] => Array
                (
                    [lineHeight] => 2.1
                )
        )

    I changed the way the PHP template finds the padding to compensate for this, eg:

    if(isset($block['style']['paddingTop'])) {$inlineStyles .= 'padding-top:' . $block['style']['paddingTop'] . ';' ;}

    But it won’t save as described above.

  • @chrisdark have you found out how to make this work with repeater subfields?

    It seems that only top-level ACF fields appear in a template when you create a new page. Any subfields will not show in the editor – at least not initially.

    I used icons_0_custom_icon to generate the first row of the repeater. icons is the name of the repeater, 0 refers to the first row and custom_icon is the name of the subfield.

    It does work, just not initially. At first, the preset subfield data does not appear in the block editor. However, if you click on the block, the inspector/sidebar shows the correct data and it only appears in the editor if you make any sort of adjustment to the data in the inspector.

    Wish there was a way that worked properly. :/

  • Thanks! That has helped a lot, although the way I implemented it is probably all wrong, but the end result is that it works.

  • Thank you so much, James! That fixed things perfectly. 🙂

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