About
A second opinion on WordPress code, from something that has read all of it.
FledgePress takes a plugin, theme, or block library, reads every line of it inside a throwaway container, and returns a score out of 100 across five categories. Every point it takes off has a finding, a file, and a line attached.
It is built first for the developer writing the addon, around a loop that should be boring: scan, read the findings, fix, scan again, watch the score climb. Agencies and site owners checking an addon before it goes near a live site are the second audience, and the same report serves them. When those two pull in different directions, the developer wins, because a report a developer can act on is the only kind worth anyone else reading.
The addon is never trusted
We treat submitted code as hostile until proven otherwise. It's never executed, and never analysed on the machine serving this page. Every scan gets its own container with CPU, memory, and filesystem limits the kernel enforces, and no network unless the job has to clone a repo. If a feature would weaken that boundary, we redesign the feature.
Scans stay cheap and fast
Analysis is static. The code is read, not run, so a scan finishes in seconds and costs us almost nothing. That's what lets free scans stay properly free instead of turning into a trial that runs out.
Scores are explainable
Every point deducted maps to a named finding you can act on, with the file and line it came from. No black-box number and no weighting you can't see. If you disagree with a deduction, you can go and look at exactly what triggered it.
What's built, and what's next
The scanner reads a PHP syntax tree and runs every check across the five categories, so commented-out code and strings never produce a finding. Heavier engines are next in line: PHPCS with the WordPress standard, PHPStan, Plugin Check, and a vulnerability feed lookup. They'll add findings to the same report and the same scoring model rather than introducing a second one.