Supporting third party libraries inside the iframe block editor

[lgladdy]

Description

Hey 👋

I'm one of the developers of Advanced Custom Fields, and I'm looking to bring WordPress 6.2 support in our next release but I'm hitting a major blocker with the iframed block editor now it's merged for desktop views. It's possible I'm missing something obvious here, so please let me know if so - but my two major issues are:

• We need a way to include ACF's core CSS into blocks which use ACF
• We need a way for third party libraries (including those shipped in core) to work inside the block editor, specifically things like jquery-ui-datepicker and select2

Styles

There doesn't seem to be a way to register a script as "block global" that I can see to make sure our edit mode CSS is always available inside blocks. There's a potential workaround here for us using the block_type_metadata filter to force-add our CSS inside every ACF block, which might be fine - but I wanted to check if there was something more global we should use here instead.

We also need to get the core WordPress admin/editor styles available in the block too, so things like buttons work correctly. In my testing, adding buttons or editor as a editorScript handler didn't help here, but I've not gone too deep into this yet, as worse case we can ship our own block editor specific styles for things like this.

Scripts

This is our biggest issue. When the iframed block editor originally launched for tablet and mobile preview mode, we had to disable edit mode inside the visual editor and were hoping this issue would be resolved by the talk of a compatibility mode for blocks which can't work inside the iframe, but I can't seem to find any documentation on that, and it doesn't seem to be in the PR that was merged.

Essentially the issue is ACF has an edit mode, which brings the sidebar editing into the actual block editor. This is useful for larger content editing that users are likely to do in blocks as we render server side for preview, here's an example image:

Because our fields support select2, date, time and color pickers, these are third party libraries (with date and color pickers being part of core). We're aware of the need to update targeting of elements to support the iframe as per the blog post in 2021 - but we can't do this third party libraries as we can't edit them.

I can't see an easy way of solving this, short of disabling the iframe for now until we can rewrite ACF's edit mode to not be part of the actual block (and use a modal in the root context), disabling ACF's edit mode altogether in block and requiring users to edit long text in the sidebar, or disabling the iframe through the use of a quirk of maybeIframe where we could add a hidden Metabox to the page; but this would disable the iframe globally for anyone who has ACF installed, and that seems overkill for this issue.

I'm wondering if the best workaround here would be for there to be a flag we could set on block.json to disable the iframe for ACF blocks (and for other folks who have this issue) and that gets parsed as part of maybeIframe?

Step-by-step reproduction instructions

Build a block which contains a date picker element.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[CreativeDive]

@ellatrix I have a question about the post editor iframe. I noticed that the new iframe doesn't load in WP 6.2 when using metaboxes. I want to know if this behavior is expected and if so, why metaboxes are not compatible with the iframe?

Is this a bug? I hope because it would be very nice if we could also have the iframe even though we use metaboxes.

[lgladdy]

@CreativeDive My understanding is that it would introduce a confusing second scrolling viewport, so it's not viable. Metaboxes are backwards compatibility layer as well, so it's logical that trigger a back combat mode in the block editor.

It's definitely not a bug as I mentioned in my original post, it's intentional in this code.

[CreativeDive]

@lgladdy Yes, it seems so. I see a very big problem here. Most of the users worldwide still use metaboxes with WordPress. Metaboxes are used to specify fields commonly used in custom post types. For example, if you have a recipe post type, the data will be entered here. Metaboxes are important because they allow us to easily customize the output of data and the template over and over again. Blocks have one big disadvantage here. If I use a recipe block instead, then the structure is fixed. Settings and arrangements can be different per block. If I want to change something later, it will be difficult. When hundreds of recipes need to be adjusted, it becomes difficult. This is exactly the benefit of using metaboxes.

I don't know how to feel about the metaboxes apparently not being supported in the future. It will be a big problem for quite a number of users.

[saas786]

As far as I am aware, the iframed Site Editor and Post Editor were designed to isolate and sandbox the main editing area, not to contain classic metaboxes.

Classic metaboxes are still widely used, including by myself, even with the Block Editor.
Therefore, there should be an option to continue using the iframed Block Editor and classic metaboxes simultaneously, as it was before the iframed isolation.

[lgladdy]

@CreativeDive @saas786 I think it would be worth raising this issue separately if it's not already opened, as it's not really related to this one!

[CreativeDive]

@lgladdy Good idea. I can't find an existing issue so I think I'll add a new one.

[saas786]

@CreativeDive

Adding a new comment on: #34105

Which is the relevant and also higlights the issues prior to iframed Post Editor.

[ellatrix]

Yes, the problem is that it would create two scroll boxes: one iframe with the content and one meta box area. Both cannot be visible at the same time. And we cannot just put the meta boxes inside the iframe. The only solution is to have a button somewhere to open the meta boxes in a modal, or replace the content with meta boxes. This is a design issue to be figured out. Cc @joen

We also delayed figuring out the meta boxes because it is a legacy API that plugins should ideally move away from. Cc @mtias

In the meantime I decided to fall back to the non iframed editor if plugins add legacy meta boxes.

[CreativeDive]

@ellatrix
Yes, it is clear as you describe it. Of course, the best-case scenario would be that not everyone uses legacy metaboxes. But if we are honest, that will take many years.

So I am wondering when we can expect a solution that has already been prepared here #34421? This solution seems ideal to me.

[lkraav]

How does this affect Pods @sc0ttkclark?

[sc0ttkclark]

All of the Pods blocks are completely React and utilize components from WP for every field it currently supports.

Pods does have other custom fields that it shows through the meta box integration which utilize jQuery but that has been reduced over the past few releases.

[annezazu]

Noting that it looks like we are reverting for 6.2: #48076

Perhaps we can move this out of the 6.2 board as a result cc @ndiego for thoughts.

[ndiego]

@annezazu yeah agreed. I added #48076 to the board for tracking purposes.

[wpsoul]

I asked for this year ago. Just few topics related why custom script should be allowed in iframes

#41065 #38673

[ellatrix]

This has been fixed since #49655 (in WP 6.3): you can now use the enqueue_block_assets action to enqueue assets. There's more information here: https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#post-editor-iframed. If you need assets to only enqueue in the editor, you could use the is_admin function.

However, regarding the script, I really don't recommend loading editing UI in the iframe. Instead, you should probably render a block preview inside the block and make the user edit the block settings in a modal, or in the block inspector.

Let's close this issue, but feel free to create a new issue if your have additional questions or concerns with the new API.