AI生成エロ動画

Hi there! What a week! WordPress 7.1 Beta 1 (and Beta 2) arrived with a huge array of updates. We’ll unpack them together over the next four weeks, right up to the final release on August 19, 2026. One thing shouldn’t wait, though: the security release WordPress 7.0.2. Go update your production sites now — this newsletter will still be here when you’re back. In this edition, you’ll also find the first speaker lineup for WordCamp US, a fourth page-builder migration story, WooCommerce 11.0 on the horizon, and plenty of block development goodness: from iframed editors to on-brand maintenance pages. Grab your favorite Saturday beverage and dig in. Yours, Birgit WordCamp US 2026: Four Tracks, Three Workshops, 33 Speakers The first wave of WCUS 2026 speakers is live — and it reads like a who’s-who of WordPress in practice. WordCamp US just published its opening lineup for August 16–19 in Phoenix: 34 confirmed speakers so far, including K Adam White, Brian Coords, Jamie Marsland, Kathy Zant, Miriam Schwab, and Robert Abela, all experienced developers, educators, security specialists, community builders. The program runs four tracks. AI in Action leads with sessions on agentic workflows, AI search, and guardrails for AI-assisted development. Honing Your Skills covers the practical side: maintenance, privacy compliance, creator commerce, security. Technical WordPress digs into block migrations at scale, WP-CLI automation, and plugin pipelines. Beginning WP101 is the on-ramp for newcomers — or for clients you’re bringing along. Three hands-on workshops round out the program, where you build something real in the room and leave with it. The full session schedule isn’t out yet, but the speaker list alone is a useful signal. If someone on that page is a voice you follow, a tool you depend on, or a corner of WordPress you’re actively navigating, you now have a specific reason to be in the room. us.wordcamp.org/2026/tickets — $100 General Admission · $750 Micro-Sponsor (includes listing on the sponsors page) Full speaker list → Developing Gutenberg and WordPress WordPress 7.1 Beta 1 was release on July 15, 2026. is now available for testing. The release post offers instructions how to sent up a test side and shows an extensive list of new features. The security team released WordPress 7.0.2 with the urgent appeal to update right away. The security fixes were also backported in 6.9.5 and 6.8.6. The security fix was also included in WordPress 7.1 Beta 2, so testing sites are also protected during this release cycle. Huzaifa Al Mesbah, from the Core Test team, published the accompanying Help Test WordPress 7.1 post. A few WordPress 7.1 Dev Notes are already available: Consistent navigation in WordPress 7.1 with persistent toolbar The Classic block stays in the inserter for WordPress 7.1 The latest episode is Gutenberg Changelog #132 – Proposals for Core, Calls for Testing, WordPress 7.1 and Gutenberg 23.4 and 23.5 Plugins, Themes, and Tools for #nocode site builders and owners In about 10 days, WooCommerce 11.0 release is schedule. Brain Coords has the skinny for you in what’s coming for developers in WooCommerce. Performance leads the release with 28 PRs — product object caching becomes the default for new stores, speeding up variable products by 9–12%. You’ll also find email verification connecting guest orders to accounts, new phone validation hooks, video embeds in the block email editor, and the final removal of the Product Editor beta. The beta is ready for your testing now. Jamie Marsland followed his instincts and build Jamie’s Front-End Editor for Content Teams, a plugin that lets your editors click any paragraph or heading on the live page and start typing — no block editor required. With the latest updates, you can now edit text, links, buttons and images right on the live page. No wp-admin, no block editor, just click and change it in place. Built on the Interactivity API with no build step, it preserves block markup on save, records edits as native block notes for an audit trail, and lets you restrict chosen roles to front-end-only editing. Let Marsland what you think. Last week, I shared three migration stories from page builders to the Core block editor and block themes. Here’s a fourth perspective: The team at WP Expert, an Ottawa agency founded by Frederic Sune, put together a comprehensive post on migrating agency sites from page builders to Gutenberg, should you go on that journey, too. You’ll find the strategic arguments (better Core Web Vitals, smaller attack surface, less technical debt) alongside a practical playbook covering backups, staging, block theme selection, pattern development, and SEO safeguards. The post also explores what block-based architectures mean for an agency’s business model, from premium modernization packages to fewer layout-related support tickets. An FAQ rounds it out. Theme Development for Full Site Editing and Blocks Brian Coords tackles a common WooCommerce pain point: custom product templates for block themes. He combines two core WordPress features — the plugin template registration API from 6.7 and the venerable single_template_hierarchy filter — to serve custom templates for product collections, like all products in a category. His example plugin falls back to your Single Product template unless you override it. Clone the repo and give it a try; custom Product fields are next on his list. On the WordPress Developer Blog, Troy Chaplin shows you how to build an on-brand maintenance mode for block themes. You add one small hook to your theme’s functions.php once, then design and manage the maintenance page entirely in the Site Editor with full access to your Global Styles. Renaming or deleting the template toggles maintenance mode on and off, no code needed. An SEO-friendly variant adds 503 headers so crawlers know the downtime is temporary. “Keeping up with Gutenberg – Index 2026” A chronological list of the WordPress Make Blog posts from various teams involved in Gutenberg development: Design, Theme Review Team, Core Editor, Core JS, Core CSS, Test, and Meta team from Jan. 2024 on. Updated by yours truly.  The previous years are also available: 2020 | 2021 | 2022 | 2023 | 2024 | 2025 Building Blocks and Tools On WP Mayor, Jean Galea untangles when to reach for WP-CLI, the REST API, or the Abilities API. His mental model: they’re layers, not rivals. WP-CLI lives on the server for bulk work, REST serves off-server callers like headless front ends, and the Abilities API tells AI agents what they’re allowed to do, complete with schemas and permission checks. Galea also shares how his own sites lean on all three at once. Get up to speed how to make your custom blocks plugin work in the iframed post editor, if you haven’t yet. After five years of ruminating and communicating the switch is coming to WordPress 7.1. In his post, Ryan Welcher explains why the post editor is going full iframe in WordPress 7.1 and what that means for your custom blocks. You’ll find the fixes for the most common breakage — global window and document references, editor styles enqueued into the wrong document, stale admin-scoped CSS, and third-party libraries — plus a companion demo plugin with broken/fixed block pairs, Playground blueprints for testing both states, and a handy pre-flight checklist. The video volunteers at WordCamp Portugal uploaded all recordings to WordPressTV and two of the talks caught my eye: Imran Sayed walks you through the fastest way to build Gutenberg blocks with modern tools, scripts, and AI. If custom block development has felt complex or time-consuming, you’ll appreciate his focus on practical, real-world workflows you can adopt immediately — moving fast without over-engineering. The recording is available on WordPress.tv, and the presentation slides are linked below the video for easy reference. Jorge Costa shows you how to use the AI building blocks already shipped in WordPress core (the WP AI Client, the Abilities API, and the MCP adapter) to bring AI-powered features into your own plugins, themes, and sites. He also tackles the bigger question: when agents can spin up entire projects on any stack, why is WordPress still the right bet? Slides are linked alongside the recording. Check out the not so new any more Talk Devy to Me series on Ryan Welchers YouTube Channel! In the latest epsiode, Antonio Sejas demos Studio Code, the agentic AI assistant built into WordPress Studio’s desktop app and CLI. You can spin up sites, run performance audits, add content, and install plugins and themes through natural language conversation — all locally, so nothing you break goes public. Sejas explains how it works under the hood before building something live with the host. Studio Code is free while in beta, so now’s a good time to experiment. If you rather want to read about the updates in WordPress Studio, Fredrik Rombach Ekelund shares three big updates to WordPress Studio: a new default Native PHP runtime makes your local sites load 30–50% faster while using a third of the memory, the Studio CLI now installs with one dependency-free command — no Node.js or npm required — and Claude Sonnet 5 is the new default model in Studio Code, improving multi-step work like tracing bugs across files. A Sandbox runtime remains available for testing untrusted code. Need a plugin .zip from Gutenberg’s master branch?Gutenberg Times provides daily build for testing and review. Now also available via WordPress Playground. There is no need for a test site locally or on a server. Have you been using it? Email me with your experience. Questions? Suggestions? Ideas? Don’t hesitate to send them via email or send me a message on WordPress Slack or Twitter @bph. For questions to be answered on the Gutenberg Changelog, send them to changelog@gutenbergtimes.com Featured Image:

WordPress 7.0.2 went out today with two important security updates. One is a type of pre-authorization RCE we (fortunately!) have only seen a few times in WordPress’ 23-year history; the last, I believe, in the PHPMailer class five years ago. Major kudos to Adam Kues of Searchlight Cyber for finding the batch REST API RCE, to TF1T, dtro, and haongo on the facilitated SQL injection! Thanks to responsible disclosure, the WordPress.org Security team was able to coordinate with hosts and CDNs to mitigate the attack at the network layer. Please upgrade anyway! But it’s a huge relief to know the vast majority of WordPress sites were protected by defense-in-depth even before the updates went out. I really appreciate how people and organizations that otherwise might not be on the best of terms come together in times like this. (Full credits in the release post.) Everyone buries the hatchet to protect as many people as possible as quickly as possible. I’ve said it before, I’ll say it again: security is going to be a big topic this year as the technology industry digests the incredible advances in AI models. It’s a good time to review your plans and processes, sweat the details, invest in maintenance, and hug a sysadmin.

WordPress 7.0.2 is now available. The 7.0.2 security release addresses one critical and one high severity security issue. Because this is a security release, it is recommended that you update your sites immediately. Due to the severity, the WordPress.org team have enabled forced updates via the auto-update system for sites running affected versions. To manually update you can visit your WordPress Dashboard, click “Updates”, and then click “Update Now”, or you can download WordPress 7.0.2 from WordPress.org. On sites that support automatic background updates, the update process will begin automatically. Security updates included in this release The security team would like to thank the following people for responsibly reporting vulnerabilities and allowing them to be fixed in this release: A facilitated SQL injection issue reported as a team by TF1T, dtro, and haongo A REST API batch-route confusion and SQL injection issue leading to Remote Code Execution reported by Adam Kues at Assetnote / Searchlight Cyber For more information on this release, please visit the HelpHub site. Backports WordPress 6.9 is affected by both vulnerabilities. Version 6.9.5 has been released containing fixes for both. WordPress 6.8 is only affected by the first vulnerability. Version 6.8.6 has been released containing a fix. The beta release of WordPress 7.1 is affected by both vulnerabilities. Version 7.1 beta2 has been released containing fixes for both. Versions of WordPress prior to 6.8 are not affected. CVE and GHSA references CVE-2026-60137 / GHSA-fpp7-x2x2-2mjf CVE-2026-63030 / GHSA-ff9f-jf42-662q Thank you to these WordPress contributors This release was led by John Blackbourn and Barry Abrahamson. In addition to the security researchers mentioned above, WordPress 7.0.2 would not have been possible without the significant contributions of the following people: Aaron Jorbin, Alex Concha, annezazu, Barry, David Baumwald, Dominik Schilling, Ehtisham Siddiqui, Joe Dolson, Joe Hoyle, John Blackbourn, Jonathan Desrosiers, Marius L. J., Matt Mullenweg, Mohammad Jangda, Peter Wilson, Sergey Biryukov, vortfu, Weston Ruter, plus representatives from Altis, Automattic, Bluehost, Cloudflare, GoDaddy, Hostinger, and WP Engine.

If you run a WordPress site, then you know that spam is a real annoying problem whether it comes to contact forms, WordPress comments, or user registrations. The good news is that stopping spam in WordPress is a lot easier than you probably think, and… Read More » The post Ultimate WordPress Spam Protection Guide – Step by Step (2026) first appeared on WPBeginner.

For years, the post editor has lived a double life. The Site Editor renders your blocks inside an iframe. The post editor — where most people actually spend their time — renders them directly in the admin page. That split ends with WordPress 7.1: the post editor canvas will always be an iframe, on every theme, no matter what apiVersion your blocks declare. The Gutenberg plugin has been enforcing exactly this for months. If you ship blocks, assume the iframe. If your block never touches the global document or window, you can probably stop reading after you’ve changed "apiVersion": 2 to "apiVersion": 3 in block.json. For everyone else — and especially anyone shipping blocks that wrap third-party libraries — the iframe changes where your code runs versus where your markup lives. That gap is where things break. Quick reference guide: Are your blocks ready? The timeline, in one table ReleaseWhat happensJune 21, 2021The iframed editor was announced on make.wordpress.orgWordPress 6.9 (Dec 2025)Console warning (with SCRIPT_DEBUG) when a block registers with apiVersion 2 or lower. The block.json schema now only validates apiVersion: 3.WordPress 7.0 (Apr 2026)The iframe decision now looks at blocks actually inserted in the post, not every registered block. All inserted blocks on v3+ → canvas is iframed. Insert a single v1/v2 block → the iframe is removed on the fly. Nothing is enforced yet.Gutenberg 22.6+The iframe is enforced regardless of theme — this is the feedback-gathering phase.WordPress 7.1 (Aug 19, 2026)The iframe is enforced on every theme, regardless of apiVersion. The conditions are gone, not tightened. The WordPress 7.0 change is subtle but important: before 7.0, one apiVersion: 2 block registered by any active plugin — even one never used in the post — kept the entire editor out of the iframe for everyone. Now only inserted blocks count. Your v3 block gets the iframe until the user inserts a legacy one, at which point the editor quietly reloads the canvas without the iframe. The companion plugin ships a legacy-api-v2 block so you can watch this happen — insert it into an otherwise-v3 post and the iframe disappears. In 7.1, that escape hatch closes. Worth knowing, as an aside: the “every theme” decision landed in WordPress 7.1 Beta 1, and it’s deliberately being tested in public. Gutenberg merged “Post editor: always iframe” (#74042) on July 10, 2026, deleting the theme and apiVersion conditions outright. The 7.1 release lead signed off on that merge on the condition that the team could “move to the softer approach” if Beta 1 feedback surfaced real problems — the softer approach being enforcement on block themes only, with everything else staying on the 7.0 rules. No specific mechanism is committed to; the plan is to respond to what the beta actually turns up.Which is a reason to test harder, not to wait and see. If that rollback happens, the iframed and non-iframed editors both stay in the wild longer — and your block has to work in both regardless of which way it goes. It’s also worth noting that blocks that will break with the 7.1 changes are most likely already breaking in the Site Editor. Why the iframe is a good thing This isn’t change for change sake. Rendering the canvas in an iframe gives the editor a real document boundary: Admin CSS stops leaking into your content. No more #wpadminbar-adjacent style resets, no more admin styles subtly changing how blocks render in the editor versus the front end. Viewport units and media queries finally work. vw, vh, and @media rules resolve against the canvas, not the admin page — so tablet/mobile previews and zoomed-out views actually behave like the front end. What you see is much closer to what you get. The canvas document is built from your theme’s styles, not the admin’s. The issue this raises for block developers? Your editor JavaScript runs in the admin page, but your block’s DOM lives in a different document. Every assumption baked into document.querySelector(...) and window.addEventListener(...) just became wrong. What actually breaks (and how to fix it) Everything below is demonstrable with the companion plugin — each pattern ships as a broken/fixed pair of blocks: iframe-editor-examples on GitHub. 1. Global window and document references The classic: a block that reads the viewport or listens for resize. JavaScript// Broken in the iframed editor useEffect( () => { const update = () => setWidth( window.innerWidth ); update(); window.addEventListener( 'resize', update ); return () => window.removeEventListener( 'resize', update ); }, [] );// ❌ Broken in the iframed editor useEffect( () => { const update = () => setWidth( window.innerWidth ); update(); window.addEventListener( 'resize', update ); return () => window.removeEventListener( 'resize', update ); }, [] ); Editor scripts load in the admin page, so window is the admin window. In the iframed editor this reports the wrong width and never reacts to the canvas resizing — switch to the Tablet preview and the number doesn’t move. The fix is to derive the document and window from your block’s own DOM element: JavaScript// Fixed — works iframed or not import { useRefEffect } from '@wordpress/compose'; const ref = useRefEffect( ( element ) => { const { defaultView } = element.ownerDocument; const update = () => setWidth( defaultView.innerWidth ); update(); defaultView.addEventListener( 'resize', update ); return () => defaultView.removeEventListener( 'resize', update ); }, [] ); const blockProps = useBlockProps( { ref } );// ✅ Fixed — works iframed or not import { useRefEffect } from '@wordpress/compose'; const ref = useRefEffect( ( element ) => { const { defaultView } = element.ownerDocument; const update = () => setWidth( defaultView.innerWidth ); update(); defaultView.addEventListener( 'resize', update ); return () => defaultView.removeEventListener( 'resize', update ); }, [] ); const blockProps = useBlockProps( { ref } ); Two things to notice: element.ownerDocument is whatever document the block is rendered into — the iframe’s document when iframed, the admin document when not. ownerDocument.defaultView is that document’s window. Code written this way is context-agnostic: it doesn’t care whether the iframe exists. useRefEffect (from @wordpress/compose) instead of useRef + useEffect: it re-runs the callback when the ref changes, so if the block ever moves between documents, your listeners re-attach to the right window. 2. “Close on outside click” and other document-level events This one is my favorite because it fails weirdly. A dropdown that closes when you click outside, implemented the way every React tutorial teaches it: JavaScript// Broken in the iframed editor useEffect( () => { const closeOnOutsideClick = ( event ) => { if ( ! containerRef.current.contains( event.target ) ) { setIsOpen( false ); } }; document.addEventListener( 'click', closeOnOutsideClick ); return () => document.removeEventListener( 'click', closeOnOutsideClick ); }, [] );// ❌ Broken in the iframed editor useEffect( () => { const closeOnOutsideClick = ( event ) => { if ( ! containerRef.current.contains( event.target ) ) { setIsOpen( false ); } }; document.addEventListener( 'click', closeOnOutsideClick ); return () => document.removeEventListener( 'click', closeOnOutsideClick ); }, [] ); In the iframed editor, clicks inside the canvas happen in the iframe’s document. They never bubble to the admin document, so the listener never fires. The result: click another block in the canvas and the dropdown stays open — but click the admin sidebar and it closes. Same code, same block, works perfectly in the non-iframed editor. This is the kind of bug report you’ll get from users that “can’t be reproduced” — because whoever tested it happened to have a v2 block sitting in their post, which quietly dropped the iframe and made everything work. Fix: same principle, attach to element.ownerDocument instead of document (see the plugin for the full useRefEffect version). 3. Editor styles enqueued into the wrong document If you’re styling your block’s editor experience with enqueue_block_editor_assets, those styles load in the admin page — outside the iframe. They silently stop applying the moment the canvas is iframed: PHP// Loads in the admin page — never reaches the iframed canvas. function myplugin_enqueue_editor_styles() { wp_enqueue_style( 'myplugin-editor', plugins_url( 'editor.css', __FILE__ ) ); } add_action( 'enqueue_block_editor_assets', 'myplugin_enqueue_editor_styles' );// ❌ Loads in the admin page — never reaches the iframed canvas. function myplugin_enqueue_editor_styles() { wp_enqueue_style( 'myplugin-editor', plugins_url( 'editor.css', __FILE__ ) ); } add_action( 'enqueue_block_editor_assets', 'myplugin_enqueue_editor_styles' ); The fix is to register editor styles through block.json, which WordPress injects into the canvas document, iframed or not: JSON{ "editorStyle": "file:./index.css" }{ "editorStyle": "file:./index.css" } (add_editor_style() also gets copied into the iframe, if you need theme-level editor styles.) The demo plugin makes this visual: the same block carries a green banner from editorStyle and a red banner from enqueue_block_editor_assets. Count the banners — two means no iframe, one means you’re iframed. 4. Stale CSS written for the leaky editor The section above is about CSS loading into the wrong document. This one is the sneakier inverse: the stylesheet loads into the right document — injected straight into the canvas, exactly as intended — and still gets it wrong, because of what it was written to describe. These are the rules that quietly stop matching, or start over-matching, once the canvas becomes its own document. It’s the code that’s been sitting in themes and plugins for years, “working,” right up until the iframe is enforced. Selectors keyed on admin body classes The most common one, and it fails exactly like the “close on outside click” bug — silently. CSS/* The canvas body no longer carries these classes */ .wp-admin .my-block { padding: 2rem; } body.block-editor-page .my-block__title { font-size: 2rem; }/* ❌ The canvas body no longer carries these classes */ .wp-admin .my-block { padding: 2rem; } body.block-editor-page .my-block__title { font-size: 2rem; } Inside the iframe, the canvas <body> is a clean document — no wp-admin, no block-editor-page. The selector matches nothing and your editor styling just evaporates. Same block, same stylesheet, works perfectly in the non-iframed editor. CSS/* Scope to the block, not the admin chrome */ .my-block { padding: 2rem; } .my-block__title { font-size: 2rem; }/* ✅ Scope to the block, not the admin chrome */ .my-block { padding: 2rem; } .my-block__title { font-size: 2rem; } .editor-styles-wrapper does still wrap the canvas content inside the iframe, so .editor-styles-wrapper .my-block keeps working if you need genuinely editor-only styling — but the admin ancestor was almost never necessary in the first place. Offsets that compensate for admin chrome CSS/* Subtracting the admin sidebar and adminbar from the viewport */ .my-fullwidth { width: calc( 100vw - 160px ); } /* 160px = admin menu */ .my-toolbar { position: fixed; top: 32px; } /* 32px = #wpadminbar *//* ❌ Subtracting the admin sidebar and adminbar from the viewport */ .my-fullwidth { width: calc( 100vw - 160px ); } /* 160px = admin menu */ .my-toolbar { position: fixed; top: 32px; } /* 32px = #wpadminbar */ This is the flip side of the win from earlier: now that 100vw resolves against the canvas instead of the admin page, there’s no sidebar to subtract — so the calc() overshoots, and top: 32px pushes your toolbar below an admin bar that doesn’t exist in this document. CSS/* The canvas is the viewport now — no compensation needed */ .my-fullwidth { width: 100vw; } .my-toolbar { position: fixed; top: 0; }/* ✅ The canvas is the viewport now — no compensation needed */ .my-fullwidth { width: 100vw; } .my-toolbar { position: fixed; top: 0; } Specificity walls built to fight leakage CSS/* Cranked up to beat leaking admin styles */ .editor-styles-wrapper .my-block p { font-family: Georgia, serif !important; line-height: 1.6 !important; box-sizing: border-box !important; }/* ❌ Cranked up to beat leaking admin styles */ .editor-styles-wrapper .my-block p { font-family: Georgia, serif !important; line-height: 1.6 !important; box-sizing: border-box !important; } The iframe already stops admin CSS from leaking in — that’s one of the reasons it’s a good thing. These !importants and resets have no admin styles left to override, but they do now override the theme styles the iframe loads into the canvas. The result: your editor preview drifts away from the front end — the exact opposite of what the iframe is for. CSS/* Let theme styles through; set only what your block truly owns */ .my-block p { font-family: Georgia, serif; }/* ✅ Let theme styles through; set only what your block truly owns */ .my-block p { font-family: Georgia, serif; } Two things to notice: The pattern is the same as the JavaScript fixes: stop describing the admin, start describing your block. A selector that names .wp-admin, #wpadminbar, or .block-editor-page is reaching for chrome that isn’t in the canvas document anymore. Most of these were workarounds for problems the iframe solves. Deleting them is usually the fix. 5. Third-party libraries that assume one global context The biggest real-world hazard. Masonry layouts, sliders, lightboxes, maps — a generation of libraries was written assuming there is exactly one document: JavaScript// Inside some-legacy-lib.js const targets = document.querySelectorAll( selector ); // finds nothing in the iframe// Inside some-legacy-lib.js const targets = document.querySelectorAll( selector ); // finds nothing in the iframe Your block calls the library, the library queries the admin document, finds zero matches, and silently does nothing. No error, no warning — the block just stops being enhanced. Your options, in order of preference: Pass elements, not selectors. If the library accepts an element (lib.init( element )), hand it the block’s element from useRefEffect and you’re usually fine. Patch the library. For unmaintained dependencies, patch-package is the pragmatic answer: edit the module in node_modules to resolve document/window from the element (node.ownerDocument), run npx patch-package <pkg>, commit the patch, add a postinstall script. The official migration guide walks through a real patch for @panzoom/panzoom. Guard and bail. If the library is loaded inside the iframe (front-end scripts are), check for it on defaultView before using it: if ( ! defaultView.jQuery ) return; So what does apiVersion: 3 actually do? Less than you might think — and that’s the point. Declaring "apiVersion": 3 in block.json doesn’t change how your block renders; it’s a signal that your block is iframe-ready. All core blocks have been on v3 since WordPress 6.3. For most blocks the migration is literally a one-line change… followed by the actual work: testing that nothing in your edit component (or the libraries it pulls in) touches the global document/window. And to be clear about 7.1: the iframe will be enforced there regardless of apiVersion. Staying on v2 doesn’t opt you out anymore — it just means you get the console warning and the breakage. How to test today You don’t need to wait for 7.1. What you’re testing is that your block works in both states — iframed and not — because both will exist in the wild for a while yet. Iframed: install the Gutenberg plugin 22.6+. It enforces the iframe regardless of theme, so this is the fastest way to live in the future. 7.1 Beta 1 does the same — I’ve confirmed it forces the iframe on a classic theme, which is the merged behavior shipping in August. Not iframed: run WordPress 7.0 without the plugin and insert a v1/v2 block alongside yours — the canvas drops the iframe on the fly. The companion plugin’s legacy-api-v2 block exists for exactly this. Any theme will do: core 7.0 has no theme check in the iframe decision at all, so you don’t need to hunt down a classic theme to reproduce this. Confirm which state you’re in: element.ownerDocument !== document, or look for iframe[name="editor-canvas"] in devtools. The Site Editor has been iframed for years — if your block already behaves there, you’re most of the way home. The companion plugin ships a wp-env setup, an example override file that adds Gutenberg for enforced mode (copy it to .wp-env.override.json), and two Playground blueprints — one per state, so you can flip between iframed and not in two tabs without installing anything. The block author’s checklist Set "apiVersion": 3 in every block.json. Check your editor code for window. and document. — every hit is a suspect. Replace with element.ownerDocument / .defaultView via useRefEffect. Check for enqueue_block_editor_assets — move canvas-affecting styles to editorStyle in block.json. Check your editor CSS for .wp-admin, #wpadminbar, and .block-editor-page , admin chrome offsets and !important Audit third-party libraries: pass elements not selectors, patch what you must. Test both states, not both themes: iframed (Gutenberg 22.6+ active) and not iframed (no plugin, v1/v2 block inserted). Watch the console with SCRIPT_DEBUG on — the deprecation warnings tell you which registered blocks are still on v1/v2. Resources Iframed Editor Changes in WordPress 7.0 — the dev note this all builds on Post editor: always iframe (#74042) — the merged PR that makes 7.1 always-iframed, and the discussion behind the beta-feedback plan Roadmap to 7.1 — the original block-themes-first plan, superseded by #74042 Preparing the Post Editor for Full iframe Integration — the 6.9 groundwork Migrating Blocks for iframe Editor Compatibility — the official migration guide Block API Versions — what each version means Enqueueing editor assets Editor styles for themes Companion demo plugin: iframe-editor-examples