The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
For several releases, WordPress has been moving its editors into an iframeiframeiFrame 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., starting with the template editor back in 5.8. In WordPress 7.1, the post editor takes the final step: it is now always iframed.
Every editor except the post editor — the site editor, the template editor, and all blockBlockBlock 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. template, and device previews — has been iframed unconditionally for some time. The post editor was the exception, and until now, whether it was iframed depended on the environment: whether the GutenbergGutenbergThe 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/pluginPluginA 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. was active and the blocks in use.
In WordPress 7.0, the decision was based on the block APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. versions of the blocks actually inserted in the post. If every inserted block was API version 3 or higher, the post editor was iframed; if any lower-version block was present, the iframe was dropped to preserve compatibility.
The Gutenberg plugin has been ahead of coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. here: since Gutenberg 22.6, when the plugin is active the post editor is forced to be iframed regardless of the theme type or the block API versions in use, so that compatibility issues surface early and can be reported before the change reaches core.
This conditional behavior kept older blocks working, but it also meant the post editor could switch between iframed and non-iframed modes depending on a post’s content.
What’s changing in WordPress 7.1
Starting in WordPress 7.1, the post editor is always iframed, regardless of the theme type, the block API versions of the registered blocks, or the block API versions of the blocks in the content.
Starting in WordPress 7.1, the post editor is always iframed, regardless of the theme type, the block API versions of the registered blocks, or the block API versions of the blocks in the content. The site editor, template editor, and device previews have been iframed for a long time, so much of this ground is already well tested. Even so, please test that your custom blocks — and any plugins that extend blocks — work correctly in the fully iframed post editor. See WordPress/gutenberg#74042 for more details.
The site editor, template editor, and device previews have been iframed for a long time, so much of this ground is already well tested. Even so, please test that your custom blocks — and any plugins that extend blocks — work correctly in the fully iframed post editor.
Most blocks already work in the iframed editor without any changes. The issues that do come up almost always trace back to the same root cause: the iframe has its own document and window, separate from the adminadmin(and super admin) page where editor scripts run. Code that reaches for the global document or window to touch the editor canvas will be looking at the wrong document.
The usual fixes are:
Get the canvas document from an element inside it, via ownerDocument and its defaultView, rather than the global document/window.
Use useRefEffect to attach and clean up event listeners on canvas elements.
