How the Scan Works

A scan has two phases. Understanding them helps you read confidence levels and the “Found by” notes in the results.

1. Runtime check#

The scan opens the post editor for each post type that uses the block editor, in a simulated, unsaved state: an admin request with a dummy post of ID 0. It replays what WordPress does before the editor renders, fires enqueue_block_editor_assets and the add_meta_boxes actions, and records:

• every meta box registered for that post type, which plugin or theme registered it, and the compatibility flags it passes;
• every script and style the editor loads outside the canvas iframe, and which plugin or theme each file belongs to.

Nothing is written to the database, all output is discarded, and every global the simulation touched is restored. Post types that never open in the post editor (attachments, templates, template parts, navigation, global styles, fonts) are skipped.

If a plugin’s editor code crashes or exits during the simulation, the scan recovers automatically and carries on. For that post type it falls back to the next best data source:

Source	Shown as	Where it comes from
Simulation	Simulation	This scan’s editor simulation
Editor visit	Editor visit	Recorded whenever an administrator opens the real block editor; written only when the set of meta boxes or assets changes
Earlier simulation	Earlier simulation	The last successful simulation from an earlier scan

2. Static check#

Plugin and theme files (PHP, JS, CSS and block.json) are read and checked against rules taken from the official developer notes. Rules have scopes:

• Editor asset rules (the iframe checks) only run on files that actually load in the editor. When runtime data exists, that is the list of files recorded by the runtime check. Without runtime data, the plugin falls back to a static guess (files named in block.json editorScript, files referenced from PHP that hooks enqueue_block_editor_assets, and built scripts with a .asset.php sibling) and lowers the confidence of those findings by one step.
• Script bundle rules (React 19 and component prop checks) run on built scripts, including front-end bundles.
• All-files rules (list table selectors, block.json checks) run on every matching file.

What is scanned and what is skipped#

• Every installed plugin, active or not (inactive plugins are marked Inactive in the summary), plus the active theme and its parent theme. Editor Readiness Scanner itself is left out, because its rules file contains the very patterns it looks for.
• Must-use plugins are only reported for meta boxes they register; their files are not read.
• Files over 2 MB are never read. Minified files over 256 KB are skipped unless they are editor assets.
• node_modules, bower_components, .git, .svn, .hg, .github, tests, test and __tests__ folders are skipped.
• JS and CSS under a src/ folder that has a build/ or dist/ sibling are skipped, because the built copy is what loads and scanning both would report every problem twice.
• Up to 50,000 files per plugin or theme.
• Per rule and file, the first 3 matches are listed; the finding notes the total number of matches.

Where the rules come from#

The rules are data, shipped in rules/rules.json inside the plugin. New WordPress releases mean new rule entries, delivered as plugin updates while your license is active. If a rule entry is ever invalid, the summary page shows a warning naming the rule, and that rule is skipped.