ACF blocks and iframed post editor

[CreativeDive]

Hey @lgladdy

I've noticed this merge from WordPress/gutenberg#46212. But with the latest Gutenberg plugin I have no iframe in the post editor.

You mentioned several times that switching to iframe could cause issues with ACF. So I wanted to ask if you know anything about this possible change?

[lgladdy]

Hey @CreativeDive.

We tend to wait until we get the first build of each WordPress release before we test purely because things change so much in the Gutenberg plugin that it's not viable for us to support every build, so I've not actually tested this yet.

That said, this PR seems to be an iframe for the overall block editor, rather than each block being it's own isolated iframe. I suspect this means that if you're using the new asset loading system you'll be okay... but we'll dive into testing with WordPress 6.2 Beta 1 on Feb 7th to confirm that!

[CreativeDive]

@nick6352683 For now, as a workaround; if you add a Metabox to the page WordPress won't use the iFrame; so you can just add a blank field group to the post types you're using ACF Blocks on.

Originally posted by @lgladdy in #787 (comment)

Hey @lgladdy,

That means, if we don't use metaboxes added by ACF, will the iframe be present in the default post editor? That is interesting! I thought the use of the iframe depended on whether you were using a block theme or not. In my case I have a block theme but also metaboxes.

[lgladdy]

@CreativeDive Seems to be the case, yeh! So long as [isBlockBasedTheme](https://github.com/WordPress/gutenberg/blob/20e4f489417dc690f38ba7a40781365ca2eaf6e4/packages/edit-post/src/components/visual-editor/index.js#L342) here also is true - but I've not gone too deep into figuring that out yet.

We've opened a ticket here: WordPress/gutenberg#47924 with Gutenberg, and are working with the author of the iframed post editor PR to figure out the best workaround here.

[CreativeDive]

@lgladdy thanks for clarifying. Using wp_is_block_theme() is true in my case. I've a block based theme but no iframe.

I'm wondering how reliable it will be if WordPress has to maintain two different types of editor embedding, with and without an iframe?

Do I understand correctly that metaboxes basically don't work with the iframe post editor?

[CreativeDive]

Quick update for everyone here. We're working with the WordPress team who are building a back compatibility system for blocks which can't work inside the iframe.

This only affects ACF's edit mode for ACF Blocks as things like select2 and date picker scripts are unable to inject their overlays inside the iframe.

Longer term, we'll need to move ACF's edit mode out of the actual block and into something like a modal. But we'll focus on making sure we're good to go with WP6.2 at release for now.

Originally posted by @lgladdy in #787 (comment)

@lgladdy I would like to know what we as users can expect in the near future? The iframe post editor will be the new standard, but if you use metaboxes you have to use the old version of the editor. But I don't understand why that is the case?

Is there a reason why metaboxes don't work with the iframe?

There is already talk about a block API v3 that supports blocks only that do not use third-party libraries WordPress/gutenberg#47980 . If so, will ACF blocks only work with Block API v2 forever (if metaboxes are present or third-party libraries are used)? At some point, the Block API v2 will no longer be supported and will be deprecated.

I'd really like to use the iframe post editor because it's the new standard. It has more advantages than the older version. But it doesn't work because I'm using metaboxes.

Now what solution can there be to use ACF blocks to take advantage of the iframe post editor and have metaboxes at the same time?

[lgladdy]

Now what solution can there be to use ACF blocks to take advantage of the iframe post editor and have metaboxes at the same time?

Is there a reason why metaboxes don't work with the iframe?

Metaboxes in the block editor are a backwards compatibility layer. There is no solution our side to make this work - it's disabled by the Gutenberg team to avoid there being issues with two scrolling viewports, between the iframe, and the outer frame which hosts meta boxes.

As for your other questions, I don't know the answers yet. We can definitely support the v3 Block API, but you won't be able to use things like jQuery scripts inside of it; you'll need to write native React scripts to run inside for anything custom.

We already parse user content to React elements with JSX enabled, it's only edit mode which won't work inside there, and we can likely come up with a solution to bring edit mode into a modal to solve this issue.

For now though, our focus is purely on making sure we're compatible on some level when WordPress 6.2 ships. That PR you linked to is something we've been working on with the Gutenberg team to ensure we can be compatible.

[CreativeDive]

@lgladdy thank you for the response here.

What I don't understand. The settings of the metaboxes have no influence on the content of the editor. Am I wrong? The fields I use in metaboxes are only for global post or page related options.

I fear there will be a massive problem here in the future.

It seems that metaboxes that we can create with ACF will be completely deprecated in the future.

The Block API v2 will eventually be deprecated and probably the way the metaboxes work too.

Then I think the only way is to use a solution like this: https://rudrastyh.com/gutenberg/plugin-sidebars.html

It will be a major pain point when users with many customers have to offer a new solution that may not be able to transfer the old settings to the new solution.

The question remains, is it a possible solution for ACF to offer users the above solution in the future?

I feared the time would come when React would be fully needed. It seems it will happen.

On the other hand, I find it questionable to ask all users to write their solutions in React. There are many other solutions and we are no longer allowed to use them because Wordpress says so?

I was planning on replacing jQuery with React anyway. But it will take a lot of time. At this point, when React JSX doesn't even run natively in the browser, there's a very big hurdle to pushing users worldwide to adopt React.

[lgladdy]

@CreativeDive We'll do whatever we need to to make sure we support all our users, with the least work possible for them to maintain support for the newest WordPress builds.

The vast majority of ACF Block users aren't injecting their own scripts and using our callbacks and actions in the blocks, and those users aren't affected at all here.

I'm certainly not concerned here at all. The future will likely look a little different, but will be functionally virtually the same as now.

[CreativeDive]

@lgladdy I'm also not worried about using custom scripts in ACF blocks. I see this as a fixable problem.

I'm very concerned about what will happen with metabox support.

The fact is that WordPress will always adapt to the new requirements. Then it is easy to foresee which problems will arise in the future with older versions such as metaboxes or block api v2.

[CreativeDive]

@lgladdy If you integrate metaboxes into the sidebar or basically make the metaboxes area below the editor accessible via a modal, that wouldn't be a problem, would it? So I find it questionable not to support the iframe when using metaboxes. Am I seeing something wrong here?

[CreativeDive]

@lgladdy I started testing with the iframe. I completely disabled all metaboxes for a specific post type and the iframe is there. These are the results:

Adding an ACF block with a custom jQuery script doesn't work right after adding the block to the editor. There are no errors in the console and jQuery is also loaded in the editor.

But after saving and refreshing the page, the block scripts work as expected.

Is it possible that the following ACF action doesn't fire immediately after inserting the block when using the iframe?

window.acf.addAction( 'render_block_preview/type=accordion', initializeBlock );

[lgladdy]

There's really no point testing anything ACF blocks and WP 6.2 yet until the back compat PR is merged as it will completely change the context blocks execute in, hopefully in time for beta 2.

[CreativeDive]

@lgladdy Ok I understand. I think it's something with $(document).on('click', ... ) {} and the iframe. It seems that the click event doesn't fire when the block is inserted directly. But it works if the block is already there after the editor page is refreshed. I'll stop testing for now and wait for the compat PR too.

[lgladdy]

document changes context depending on if it's running in the iframe or not, so this is to be expected I think. This is the crux of the issue, as libraries like date picker are no longer able to find the element they're trying to attach to.

You can find more info here: https://make.wordpress.org/core/2021/06/29/blocks-in-an-iframed-template-editor/

[CreativeDive]

If you want to stick with jQuery for now, maybe something like this would be a solution:

Instead of:

$(document).on('click', ...

Something like this is working for the iframe editor case only:

$('iframe[name="editor-canvas"]').contents().on('click', ...

Tested and works with the iframe post editor.

[CreativeDive]

WordPress/gutenberg#48076.

The best way forward seems to use the block api version to check compatibility. For the next release, we will iframe the post editor only if all blocks in the library are api version 3 or higher.

It seems we have to update all the blocks to v3 to get the iframed post editor in the future.

[CreativeDive]

As a note, I don't know why and if that's expected. In WP 6.2 stable the editor is loaded without an iframe. But when the Gutenberg plugin is enabled, the iframe is still there even though it shouldn't load. Since the iframe can now only be loaded if the blocks v3.

[CreativeDive]

Nice progress here: WordPress/gutenberg#49655

[nick6352683]

@CreativeDive Unless things change once again, whether this gets fixed or not, to all of my themes with php, I'm permanently adding a Metabox on the side, with a textarea field called "Notes" for all posts and pages. This field does nothing but gives an opportunity for whoever has editing capabilities to add notes in the backsite, which will never be rendered on the front.

So, if the core developer's decide to revert to exactly how things were with WP 6.2 beta1 (which is a possibility), it won't affect me.

[CreativeDive]

@nick6352683 Right now it looks like you'll never be able to use the iframe post editor if you use old metaboxes. Personally, I don't use many metaboxes anymore. But still a few. So I'll probably solve that via the core fields. I've already learned a lot about the core fields implementation via javascript API. It's actually quite simple once you put your mind to it for a while.

[onetrev]

@CreativeDive It's a year later now so maybe things have changed again in how you handle this... But, just to clarify are you creating "custom components" instead of using ACF fields? And you are doing that instead of using ACF Blocks? Or, are my assumptions all wrong? :)

One thing that has changed in the last year is the Block Bindings API released WP 6.5 means you can now avoid custom fields in some circumstances and thereby avoid the iframe problems from this issue. Sometimes.

I know ACF Blocks is moving to become more native in next couple of releases, and in doing that it would solve the classic meta boxes issues. It will also be awesome to have! 🎉

[CreativeDive]

@onetrev Thank you for the interest. As experience increases, so do the requirements. 😄 In the meantime I have switched entirely to native blocks. You simply can't ignore React anymore. It's a different world.