How this works

Every week, WordPress plugins ship releases whose changelogs say "bug fixes and improvements". That tells you nothing about whether the update is safe to apply.

What we actually do

For every release of every plugin we track, we download the new version and the one before it, and compare the code. Not the changelog — the code. We extract the plugin's public surface: the hooks it fires, the functions and classes it declares, the shortcodes, blocks, post types, REST routes and template files it registers. Anything another plugin or a theme can legitimately depend on.

Then we look at what disappeared. If we detect no removal from that public surface, we report no public-surface impact detected. If a release removes a hook, deletes a function, drops a template or narrows a signature, we name the exact symbol and explain what can happen on sites that depend on it.

Where each part comes from

Being precise about this matters more than sounding impressive. Every verdict in the feed — what broke, and the symbol it broke — comes from the code comparison described above. We never read the changelog. We do not even request it from WordPress.org.

Two things are not code. The maintainer signal uses WordPress.org's committer list, because a plugin changing hands is not visible in a diff. And the context sections under the feed — which plugins have gone quiet, which are behind on WordPress compatibility — come from directory metadata: the last release date, and the "Tested up to" line a developer writes in the plugin's readme. That line is a claim by its author, not something we verified, and it lives in the same file as the changelog even though we never parse the changelog itself.

So: the feed is evidence. The context sections are the directory's own record, organised. Both are useful; they are not the same kind of claim, and we would rather say which is which than blur them.

What we will not do

We do not guess. Where a hook name is built dynamically at runtime, we cannot resolve it, so we say nothing about it rather than inventing a verdict. Bundled dependencies, build output and test fixtures are excluded — a regenerated Composer autoloader is not a breaking change, and reporting it as one would teach you to ignore us.

We never say an update is "safe". We say no impact detected, and we tell you how many changes we checked to arrive at that.

Common questions

What does Plugin Radar analyze?

It compares consecutive WordPress.org plugin release packages and records changes to hooks, functions, classes, methods, shortcodes, blocks, post types, taxonomies, REST routes, assets, templates, compatibility requirements, ownership, and new network or code-execution capabilities.

Does a “no risk detected” result guarantee an update is safe?

No. It means the analyzer found no supported public-surface change in that release. Runtime behavior, dynamically constructed symbols, premium code, environment differences, and interactions outside the measured surface can still matter.

How often is Plugin Radar updated?

The release pipeline runs daily and the public report rolls up the latest findings into a weekly issue.

Why ownership changes get their own section

In 2026 an attacker bought around thirty WordPress plugins through Flippa and put a backdoor in the first commit after taking over. It sat dormant for eight months before activating, and over 400,000 sites were exposed. WordPress.org does not review ownership transfers and does not sign updates. So we watch the committer list, and when a plugin changes hands and ships new network or code-execution capability in the same release, we say so loudly.