Black Friday: 79% off every plugin Shop the sale →

Introduction

What Editor Readiness Scanner does#

From WordPress 7.1 the post editor always loads its content inside an iframe, list tables use new row markup, and several editor component props no longer do anything. React 19 and real-time collaboration are on the way. Most of the breakage this causes comes from plugins and themes that were written for the old editor, and the site owner usually finds out only after the update.

Editor Readiness Scanner looks at every installed plugin, the active theme and its parent theme, and tells you what is likely to break before you update. It gives each one a single verdict, Ready, Check or Likely broken, and backs every finding with the file and line, a severity, a confidence level, an explanation of why it matters, how to fix it, and a link to the official WordPress developer note.

Who it is for#

The plugin is built for agencies and site owners who need a go/no-go decision before a major WordPress update. It is not a developer linting tool, although developers will find the file-and-line pointers useful when they report problems to plugin authors.

What it is best at#

  • Finding iframe breakage. Editor scripts that reach into the editor canvas through the global document or jQuery, and editor stylesheets that only reach the canvas through a deprecated compatibility copy (or never reach it at all).
  • Checking against real editor data. The scan opens the post editor for every post type in a simulated, unsaved state, records exactly which scripts, styles and meta boxes load, and only runs editor rules on files that really load in the editor. That keeps false positives down.
  • Spotting list table and component changes. CSS and JavaScript that target the old list table markup, blocks registered with apiVersion below 3, and component props that changed in 7.1.
  • Looking ahead. Bundled copies of React 18’s jsx-runtime, string refs and defaultProps (React 19), and classic meta boxes that will turn off real-time collaboration. These “upcoming” findings are listed separately so they do not change a verdict unless you want them to.
  • Reporting to clients. A print-friendly report with the site name and date, CSV and JSON exports, a history of the last 10 scans, and a white-label option that removes the plugin’s name from reports.

Privacy and safety#

The scanner is read-only. It never changes other plugins’ files, posts or settings; it stores only its own scan results and settings. Scan data never leaves your site. The only outbound requests are the license check and update check to technoleet.dev, which send the license key, the site URL and the plugin version. Only administrators (users with manage_options) can run scans or see results.

The runtime check runs other plugins’ enqueue_block_editor_assets and add_meta_boxes callbacks, exactly as opening the editor would. If you do not trust a plugin’s editor code, run the first scan on a staging copy of the site.

Next steps#

  1. Check the Requirements.
  2. Follow Installation and License.
  3. Run your first scan with the Quick Start.
Was this article helpful?