WordPress 6.7 "post editor" iframing with meta boxes

In trying to putAfter the post editor is iframed, theThe presence of the metaframe becomes a blocking condition that prevents editor content from loading in the iframe and makes these benefits of the iframe unavailable:

• Isolate block and theme CSS from editor UI
• Accuracy of media queries and viewport-related CSS units

These benefits are important to support CSS reuse in the editor and front-end, as well as to simplify block and theme development. Even though metaframes exist, community members have been working to bring them into the post editor, but after theattempt(preceded by a clause of condition or reason) not untilrecognize How to adjust the interface to separate the meta box from the post content.

present .Split view implementedThis change supports simultaneous visibility of editor content and meta boxes. This change ensures a consistent WYSIWYG experience between the editor and the front-end view. Additionally, it makes metaframes easier to use than before and allows for intuitive referencing of any part of the post content when using any metaframe and vice versa.

Remaining exceptions for iframes

Currently, the last condition that prevents an iframe from always being used is whether any block uses itsapiVersionLess than registered3. However, even this condition may be removed in a future release, and if the site uses theGutenberg plugin and the block-based theme is active, it already has an exception.

Edge conditions and compatibility

Plugin developers adding metaframes should be aware of two things. First, metaframe containers now clip overflow elements, so if some of the popup UI (e.g. dropdown menus) extends upwards from the metaframe container, they will be cut off. However, if they are rendered to a part of the DOM outside of the container, this will not be an issue. Second, if your plugin also adds any rich text formatting and the editing UI is anchored to the text selection, then their implementation must be compatible with iframes. This is not a new requirement, but may be overlooked for plugins that only extend the post editor.

overflow clipping

To make sure this isn't a problem, you can either make any UI that resembles a popup window open down in the metaframe, or by rendering the popup window to a part of the DOM that isn't inside the metaframe container. For example, the latter is the default workaround for the and componentsPopover(math.) genusDropdownutilizationDropDownMenuthey (for inanimate objects)@wordpress/componentswill ensure that the UI is not cropped even if it extends beyond the top of the metaframe container.

Rich Text Format UI Anchoring

If the plugin implements custom code to anchor or position the UI, then this may just be worrisome. If the plugin already uses theuseAnchorcome from (a place)@wordpress/rich-texteverything, then it should work fine. If not, see Gutenberg's ownLink Editor UIcomponent for a typical example of its usage.