Can ACF support the native render callback in block.json?

[CreativeDive]

Hello @lgladdy,

I read about it here: WordPress/gutenberg#42430

It seems that block.json supports a render callback by default.

src/block.json

{
    "name": "test/my-block",
    "render": "file:./render.php"
}

src/render.php

<div <?php echo get_block_wrapper_attributes(); ?>>
    <?php echo $attributes['text']; ?>
</div>

I'm wondering if we can use this render callback instead of ACF's own "renderTemplate": "index.php" in the future if ACF supports it?

Could this be a solution to make ACF block markup identical in editor and frontend? 👈 👈 👈

Have you ever been able to test whether this can replace the additional block wrapper?

[lgladdy]

The upcoming render property in WordPress 6.1 is for the <ServerSideRender /> component as detailed here: https://developer.wordpress.org/block-editor/reference-guides/packages/packages-server-side-render/

It's not applicable to ACF Blocks, also note:

ServerSideRender should be regarded as a fallback or legacy mechanism, it is not appropriate for developing new features against.

[CreativeDive]

@lgladdy Thanks for the clarification. I thought this might be a way to solve this issue with the extra wp block wrapper div. Too bad it's not like that.

[lgladdy]

@CreativeDive reopening this one as it looks like this might not be the case after all from the 6.1 block api changes guide: https://make.wordpress.org/core/2022/10/12/block-api-changes-in-wordpress-6-1/

I’m not sure we’d really get any benefit from supporting it, but we really should take a look at least!

[CreativeDive]

@lgladdy nice to know. My hope was that we can eliminate the extra div around the ACF block template in the editor based on this example:

<div <?php echo get_block_wrapper_attributes(); ?>>
    <?php echo $attributes['text']; ?>
</div>

If that would work, then it would finally be done and you could do without hacky workarounds for the correct display in the block editor.

[lgladdy]

@CreativeDive I'd be very surprised if they've done anything different to us! get_block_wrapper_attributes() will just auto-build a style="" and class="" for you based on the border/padding/color etc you pick from support options; you can use that already in ACF Blocks.

You might well be able to test this before me - but you'll need to make a standard non-acf block here to see what markup you get back!

[CreativeDive]

@lgladdy I'm absolutely not familiar with the native react code, but I've tried to test it in this way:

block.json

{
	"$schema": "https://schemas.wp.org/trunk/block.json",
	"apiVersion": 2,
	"name": "wphave/non-acf",
	"title": "hello",
	"icon": "index-card",
	"category": "design",
	"supports": {
        	"align": [
			"wide",
			"full"
		]
	},
	"render": "file:./render.php",
	"editorScript": "file:./block.js"
}

block.js

( function ( blocks, element, serverSideRender, blockEditor ) {
    var el = element.createElement,
        registerBlockType = blocks.registerBlockType,
        ServerSideRender = serverSideRender,
        useBlockProps = blockEditor.useBlockProps;

    registerBlockType( 'wphave/non-acf', {
        apiVersion: 2,
        title: 'Example',
        icon: 'megaphone',
        category: 'design',

        edit: function ( props ) {
            var blockProps = useBlockProps();
            return el(
                'div',
                blockProps,
                el( ServerSideRender, {
                    block: 'wphave/non-acf',
                    attributes: props.attributes,
                } )
            );
        },
    } );
	
} )(
    window.wp.blocks,
    window.wp.element,
    window.wp.serverSideRender,
    window.wp.blockEditor
);

render.php

<div <?php echo get_block_wrapper_attributes(); ?> id="test">
    PHP RENDER
</div>

It seems this is NOT 😒 a solution to eliminate the extra div.

[CreativeDive]

It seems useBlockProps() have all the attributes attached which makes the block selectable in the editor. Unfortunately, my knowledge of react does not go any further here. But is there a way to pass these attributes to the ACF block wrapper DIV? And if so, would that DIV be the outer DIV at this point?

[CreativeDive]

Theoretically it works, but practically not! 😅 No way to get this block selectable in this way.

block.json

( function ( blocks, element, serverSideRender, blockEditor ) {
    var el = element.createElement,
        registerBlockType = blocks.registerBlockType,
        ServerSideRender = serverSideRender,
        useBlockProps = blockEditor.useBlockProps;	
	
    registerBlockType( 'wphave/non-acf', {
        apiVersion: 2,
        title: 'Example',
        icon: 'megaphone',
        category: 'design',
        attributes: {
                blockId: {
                        type: 'string',
                        default: ''
                }
        },

        edit: function ( props ) {
			
                var blockProps = useBlockProps();			
                props.attributes.blockId = blockProps.id;
            
                return el( ServerSideRender, {
                        block: 'wphave/non-acf',
                        attributes: props.attributes,
                } );
        },
    } );
	
} )(
    window.wp.blocks,
    window.wp.element,
    window.wp.serverSideRender,
    window.wp.blockEditor
);

render.php

<div tabindex="0" id="<?php echo $attributes['blockId']; ?>" role="document" aria-label="Block: Example" data-block="<?php echo str_replace('block-', '', $attributes['blockId']); ?>" data-type="wphave/non-acf" data-title="Example" class="block-editor-block-list__block wp-block wp-block-wphave-non-acf">
    PHP RENDER
</div>

[cabrailsford]

@CreativeDive I was playing around with ACF/non-ACF blocks the last few days, and I hit upon a possible way for you to not render the extra inner div in the editor. Mind you, this only works for divs without additional classes, but it could work in some instances for you.

In your render template, you could use:

if ( ! $is_preview ) {
	printf(
		'<div %s%s>',
		get_block_wrapper_attributes(),
		! empty( $block['anchor'] ) ? ' id="' . esc_attr( sanitize_title( $block['anchor'] ) ) . '"' : '',
	);
}

// Block content goes here.

if ( ! $is_preview ) {
	echo '</div>';
}

By doing so, you prevent the inner div from displaying in the editor, but can use the same classes on the frontend and backend (e.g. .wp-block-your-block-name), and utilize the classes supplied to the block from WP.

[CreativeDive]

@cabrailsford Thanks for that. Yes, I'm playing with that too. It's the only solution I see here to eliminate the extra wrapper div. It's very frustrating when you work with nested blocks like:

<WP DIV>
    <ACF DIV>
        block content 
            <ACF InnerBlocks DIV>
                <WP DIV>
                     <ACF DIV>
                        ...

Practically there is always something that doesn't work properly, like in the frontend when working with alignments, flexbox, ...:
I'm very very tired of adding more and more extra css rules just for the block editor 😒

<ACF DIV>
     block content 
        <ACF InnerBlocks DIV>
           <ACF DIV>
                ...

I've been looking for a way to resolve this different markup for a long time, right @lgladdy 😅

But it is not possible, at least for ACF, to eliminate this extra div. Your mentioned way is basically a good way but there are side effects like, you can't add PHP generated class names to the <WP DIV>. And other side effects I mentioned here: #739

A JS filter that allows us to add PHP generated class names to the <WP DIV> would be very helpful here, but is it technically possible @lgladdy ?

[CreativeDive]

@cabrailsford Something like this could be working. But this is very limited, because the class names will only outputted to the <WP DIV> if you change a block field.

<?php

$my_acf_block_classes = 'hello world yooo';

$block_id = isset( $block['id'] ) ? $block['id'] : '';
$block_id = str_replace( '_', '-', $block_id );

?>

<script>		
	(function( $ ) {

		function blockClassNames( $block ) {
		
			var block_id = '<?php echo esc_html( $block_id ); ?>';
			var wpBlock = $('#' + block_id);
			var wpBlockClasses = wpBlock.attr('class');
			var acfBlockClasses = '<?php echo esc_html( $my_acf_block_classes ); ?>';	
			
			wpBlock.attr('class', '');
			wpBlock.addClass( wpBlockClasses + ' ' + acfBlockClasses );

		}

		// Adds custom JavaScript to the block HTML
		var initializeBlock = function( $block ) {
			blockClassNames( $block );
		}

		// Initialize dynamic block preview (editor)
		if( window.acf ) {
			window.acf.addAction( 'render_block_preview', initializeBlock );
		}

	})( jQuery );
</script>

[CreativeDive]

@cabrailsford Here is a modified solution to pass the ACF block classes to the parent <WP DIV>. The class names are also present when the editor is initially loaded. However, this is only an experimental solution. At the moment the class names are removed again when you click away from the block.

render.php

Output a hidden <div> in the block editor view only and pass the ACF block classes to the "data-block-acf-class" attribute.

if( is_admin() ) { ?>
	<div data-block-classes="acf-block-classes" data-block-acf-class="hello world yoo" style="display: none"></div>
<?php }

editorScript.js

function blockClassNames( block ) {

	block.each(function() {

		var classes = $(this).find('[data-block-classes="acf-block-classes"]');

		var block_id = $(this).attr('id');
		var wpBlock = $('#' + block_id);
		var wpBlockClasses = wpBlock.attr('class');
		var acfBlockClasses = classes.attr('data-block-acf-class');

		if( ! acfBlockClasses ) {
			return false;
		}

		wpBlock.attr('class', '');
		wpBlock.addClass( wpBlockClasses + ' ' + acfBlockClasses );

	});

}

$(document).on('click', '.acf-block-body', function() {
	blockClassNames( $(this) );
});

// Initialize frontend script AND mobile/tablet preview in block editor
$(document).ready(function() {
	blockClassNames( $('.acf-block-body') );
});

// Adds custom JavaScript to the block HTML
var initializeBlock = function( $block ) {
	blockClassNames( $block );
}

// Initialize dynamic block preview (editor)
if( window.acf ) {
	window.acf.addAction( 'render_block_preview', initializeBlock );
}

Technically, it's similar to getting the class name from the <InnerBlocks /> tag. Therefore it should be possible to build a fully working solution like this to pass the ACF block classes as well.

@lgladdy is this something ACF can provide for us?