WP-CLI

Command#

wp editor-readiness scan [--format=<format>] [--upcoming] [--fail-on=<status>]

Option	Values	Description
--format	table (default), json, csv	table prints one row per plugin or theme; json prints the full report (same structure as the JSON export); csv prints one row per finding.
--upcoming	flag	Count upcoming changes (React 19, real-time collaboration) towards each verdict.
--fail-on	broken, check	Exit with code 1 when any plugin or theme has this status or worse. check fails on both Check and Likely broken.

Examples#

# Quick overview
wp editor-readiness scan

# Save a full report
wp editor-readiness scan --format=json > report.json

# One row per finding, with upcoming changes counted
wp editor-readiness scan --format=csv --upcoming

# In a deployment script: stop if anything is likely broken
wp editor-readiness scan --fail-on=broken || exit 1

The table output ends with a line such as Likely broken: 1. Check: 2. Ready: 14. Scan #7; see Tools > Editor Readiness for details. The scan is saved to the history exactly like an admin scan, so you can open it in wp-admin afterwards.

Limitation: no editor simulation#

WP-CLI is not an admin request, so the command cannot simulate the post editor. Meta boxes and editor assets come from what was recorded when an administrator last opened the editor, and from the last successful simulation of an admin scan. The table format prints a warning saying which data it used.

Without any admin scan or editor visit, the scanner has to guess which files are editor scripts and lowers the confidence of iframe findings, which can turn a Likely broken into a Check. For full results, run one scan from Tools → Editor Readiness first, then use WP-CLI for repeat runs.