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 a release only adds to that surface, it cannot break anyone, and we say so. If it removes a hook, deletes a function, drops a template or narrows a signature, we name the exact symbol and say what happens.

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.

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.