After an effort to iframe the post editor, the presence of meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. boxes was a holdout condition that kept the editor content from loading in an iframe iFrame is an acronym for an inline frame. An iFrame is used inside a webpage to load another HTML document and render it. This HTML document may also contain JavaScript and/or CSS which is loaded at the time when iframe tag is parsed by the user’s browser. and made these benefits of the iframe unavailable:
- Isolation of block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. and theme CSS Cascading Style Sheets. from the editor UI User interface
- Accuracy of media queries and viewport relative CSS units
Those benefits are important to support CSS reuse across the editor and front-end and generally ease block and theme development. It’s been an ongoing effort to bring them to the Post editor even when meta boxes are present yet it has taken a few attempts to determine how to adapt the interface to separate the meta boxes from the post content.
Now a split view is implemented that supports both editor content and meta boxes being visible together. This change ensures consistent WYSIWYG What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience between the Editor and front-end views. Additionally, it makes the meta boxes are more readily available than before and allows visually referencing any part of the post content while working with any meta box or vice versa.
Remaining exception to the iframe
For now, the last condition which prevents the iframe from always being used is whether any blocks are registered with their apiVersion less than 3. Yet even this condition may be removed in a future release and it already has an exception if your site uses the Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and a block based theme is active.
Edge cases and compatibility
Developers of plugins that add meta boxes should be wary of two things. One, the meta box container now clips overflowing elements so some popover-like UI such as dropdown menus will be cut off if they extend upward from the meta box container. However, if they’re rendered into a part of the DOM outside the container this won’t be an issue. Two, if your plugin also adds any rich text formats with editing UI that’s anchored to the text selection then their implementation has to be compatible with the iframe. This isn’t a new requirement but may have been overlooked for plugins only extending the Post editor.
Overflow clipping
To ensure this isn’t an issue any popover-like UI can be made to open downward in the meta box or by rendering the popover into a part of the DOM that is not within the meta box container. The latter, for instance, is how the Popover, Dropdown and DropDownMenu components from @wordpress/components work by default and using them will ensure there is no clipping even if the UI extends beyond the top of the meta box container.
Rich Text Format UI anchoring
This is may only be of concern if your plugin implemented custom code to anchor or position the UI. If your plugin is already using the recommended useAnchor hook available from @wordpress/rich-text everything should just work. In case it’s not, you can reference Gutenberg’s own link editing UI component for a canonical example of its usage.
Props @fabiankaegy and @faguni22 for review and proofreading.
#6-7, #dev-notes, #dev-notes-6-7
