How to Prepare Your Plugin or Theme for WordPress 7.0

Never test on production. Spin up 7.0 in an isolated environment using one of the official routes: the WordPress Beta Tester plugin (set channel to “Bleeding edge”), a direct download of the release, the WP-CLI updater, or a WordPress Playground instance in the browser for a zero-setup throwaway site. Install your plugin or activate your theme there.

Turn on WP_DEBUG and WP_DEBUG_LOG. Exercise every major flow — settings screens, blocks, front-end output, REST endpoints, cron tasks. Watch the debug log and the browser console. PHP 7.4 is now the floor, so deprecation notices from old polyfills will surface here too.

Open every block.json your plugin ships. Confirm "apiVersion": 3. Anything lower means the post containing that block loses the enforced editor iframe — and your block may render or measure differently inside the iframe than outside it. Move to v3 and test each block inside the iframed editor.

For every block that can be nested inside a pattern, add "role": "content" to each attribute that represents editable content. Without it, those attributes are hidden in List View and become uneditable inside contentOnly patterns — which are now the default for many patterns.

Set Requires PHP: 7.4 in your plugin or theme header. Delete any polyfills or version branches you kept for PHP 7.2 and 7.3. If a theme declares html5 script theme support, remove it — that value is gone in 7.0.

The iframed editor is the single most likely source of a subtle 7.0 bug. Inside the iframe, global styles, third-party scripts, and element measurement behave differently. Open a post with only your blocks, confirm the editor is iframed, and check that toolbars, popovers, and any measurement-dependent UI still work.

Update the Tested up to: header to 7.0. Write a changelog entry that names 7.0 compatibility explicitly — users and reviewers look for it. Tag the release, push to the plugin repository, and you are done.