The changelog says "bug fixes and improvements"
So you click "update all" on sixty sites and find out what actually changed when a
client rings. The tools that exist don't close this gap: security scanners tell you
whether a version is hackable, and screenshot tools tell you something broke
after it broke, and only if the breakage was visible.
None of them tell you what is in the update.
So we read the code instead
For every release, we download it and the version before it and compare them. We
pull out everything outside code can depend on — the hooks it fires, the functions and
classes it declares, its shortcodes, blocks, post types, REST routes and templates —
and look at what disappeared.
If a release only adds to that surface, we say we detected no impact and how many
changes we checked to get there. If it removes something, we name the exact symbol and
say what happens when it's gone — for the sites that use it.
Who it's for
Agencies and freelancers running ten or more WordPress sites, where "update all" is a weekly gamble and one bad release costs an afternoon and a client's trust.
What you get, every Monday
- The high-risk list. Releases that removed something, with the exact symbol.
- The clear list. Releases that removed no hook, function, class, shortcode or template that outside code can depend on.
- Maintainer changes. Plugins that quietly changed hands.
- Plugins going quiet. Dependencies that stopped being maintained.
What we won't do
We don't guess. Where a hook name is built at runtime we can't resolve it, so we say nothing rather than invent a verdict. We never say an update is "safe" — we say no impact detected, and how many changes we checked to get there. And we never read the changelog. The method, and its limits →