Cached blocks don't load scripts & styles

[ouun]

If a block that loads styles & scripts in assets() is cached, the files won't load.
Not sure where this should happen when the block.json exists, e.g.:

• Defined in the block.json metadata: https://developer.wordpress.org/block-editor/reference-guides/block-api/block-metadata/
• By the Block Class in render()

Happy to create a PR here, but I need a hint how this should be handled.

Thanks again, @Log1x.

[Log1x]

It should be happening here: https://github.com/Log1x/acf-composer/blob/master/src/AcfComposer.php#L196-L216

It's nothing asset specific though, it just runs the method before rendering which in testing was in time for it to enqueue scripts within hooks – but I don't personally use it so it's entirely possible it isn't and/or was never working as intended.

[Log1x]

How are you using the method at the moment? Can you try something like this if you're not already:

public function assets(array $block): void
{
    add_action('enqueue_block_editor_assets', function () {
        bundle('block-example')->enqueue();
    });
}

Assuming that works, maybe we should wrap it in enqueue_block_editor_assets by default? Would make more sense in the code too.

[ouun]

@Log1x Thanks for getting back to me and sorry for the delay in responding. I am having some issues here in a different context, but I think we can resolve them all together.

I am already wrapping the bundle in enqueue_block_assets. I think this is the right one. Pretty well summerised for WP 6.2 vs. 6.3 here, too.

1.) Cached blocks do not load assets.

As described above, cached blocks do not load assets.

2.) Site Editor not loading assets.

The Site Editor is also used for non-FSE themes, e.g. for editing Synced Blocks. The Site Editor is different from the Block Editor which does not load in iFrame as long as there are Blocks < v3. The Site Editor always loads in iFrame. So the behaviour is different in some situations. For example, I had some trouble getting the (JS) editor hooks to load correctly in both editors.

Findings:

• It seems that acf_block_render_template in handleBlocks() is either not executed at all (without cached blocks) or too late for enqueue_block_assets (with cached blocks). This is the case for both editors (iframed & not iframed).

• In ACF /pro/blocks.php we find the following:

    // Call render_callback.
    if (is_callable($block['render_callback'])) {
        call_user_func($block['render_callback'], $block, $content, $is_preview, $post_id, $wp_block, $context);
        // Or include template.
    } elseif ($block['render_template']) {
        do_action('acf_block_render_template', $block, $content, $is_preview, $post_id, $wp_block, $context);
    }

acf_render_block_callback is called without cache & acf_block_render_template with cache. In both cases assets()is not executed correctly in the iframed Site Editor.

• In Site Editor no block assets are loaded for cached blocks at all and for not-cached blocks it seems to be too late.

Possible solution:

In handleBlocks() I have extracted the call to assets() from acf_block_render_template hook:

We could either load the assets directly with the enqueue_block_assets hook here:

add_action('enqueue_block_assets', function () {
    foreach ($this->composers() as $composers) {
        foreach ($composers as $composer) {
            method_exists($composer, 'assets') && $composer->assets([]);
        }
    }
});

Or we can allow the user to set the hooks as needed in assets():

 add_action('acf/init', function () {
    foreach ($this->composers() as $composers) {
        foreach ($composers as $composer) {
            method_exists($composer, 'assets') && $composer->assets([]);
        }
    }
}, 101);

Not sure how to pass $block to assets() here. But do we really need it here as we can also access $this in assets(). This also makes 'enqueue_assets' => fn ($block) => method_exists($this, 'assets') ? $this->assets($block) : null, in Block.php obsolete.

I hope this is useful and we get this fixed too.

[Log1x]

I think the first solution is solid and definitely makes sense. I can't recall why being able to pass $block into assets was requested, but I agree with you, I don't think it's entirely necessary in the context.

I should be able to mess with this later this week unless you want to beat me to it with a PR. I appreciate you looking into this.

[ouun]

Possible brakpoints:

• Using enqueue_block_assets is the correct way for WP >6.3. Can we assume the users are up-to-date?
• For those who have already wrapped assets into actions like enqueue_block_assets in assets(), they need to update their code. Otherwise assets won't load anymore.

I can start a PR but I think you will need to decide how to handle or communicate the above.