WordPress parity analysis

The 100 most-installed WordPress plugins, distilled into ~170 capabilities, scored against what AstroBaaS already ships — and a phased plan for the gaps worth closing.

Grounded against the WordPress.org “Popular” ranking as tracked in August 2026 (top tier: Elementor, Yoast SEO, Contact Form 7 at 10M+ installs; WooCommerce 7M+; All-in-One WP Migration, Site Kit, Wordfence 5M+; WP Mail SMTP 4M+ — sources at the bottom). The 20 most-installed plugins account for roughly a third of every active plugin install in the directory, so parity with the head of the curve covers most of what real sites need.

Related documents: ROADMAP.md (25 strategic proposals — this document is the tactical, feature-level view; overlaps are cross-referenced as R-##), PLUGIN_DEVELOPMENT.md, THEME_DEVELOPMENT.md.

The thesis: capability, not plugin

WordPress needs 59,000 plugins because its core is deliberately small and its extension mechanism is arbitrary PHP. AstroBaaS takes the opposite bet: the top-20 plugin capabilities belong in core, type-checked and tested together, and the plugin surface is for genuinely vertical code (an optical shop, a payment provider), not for taping over core gaps. The scoreboard below reflects that: most of what a WordPress site assembles from 15 plugins is already one npm install here.

Three things WordPress does that we deliberately do not copy:

1. Arbitrary-code plugins from an open marketplace. WP’s #1 security problem is its own plugin directory. AstroBaaS plugins are reviewed TypeScript modules with a capability-scoped context (ctx.store namespaced to the owner, routes confined to /api/plugin/, semver-gated by requiresCore) — never eval, never a “Code Snippets” equivalent (WP #~40, 700k installs, and a top-5 source of white-screen incidents).
2. In-browser drag-and-drop page building (Elementor, WPBakery, Divi). Our answer is the theme-slot contract plus admin-defined content types: structure lives in typed components, content lives in the CMS. A visual builder that serializes to HTML soup is the single biggest cause of WP lock-in and Core-Web-Vitals failure; the market it serves (non-technical site assembly) is real, but our audience — developers pointing a vibe-coded frontend at a fast backend — is exactly who a builder gets in the way of.
3. Cache plugins. WP Rocket / LiteSpeed / W3TC exist because WP renders every request through PHP. Astro SSR + our derivative pipeline makes the entire category structurally unnecessary; performance parity is achieved by architecture, not by a feature we must build.

Legend — Status of each capability in AstroBaaS today:

The top-100 plugins, grouped

Rather than 100 rows of plugin trivia: the top-100 collapses into 17 capability families. Install counts are WordPress.org buckets (Aug 2026). Every plugin named here is in or near the top-100 by active installs.

Vertical long-tail (each a top-100 member, each a plugin in our model, never core): The Events Calendar (700k), WP Job Manager, LearnPress/Tutor LMS, WP Recipe Maker, Smash Balloon Instagram Feed (1M+), Slider Revolution / Smart Slider 3 (900k), Pretty Links (300k), AMP (300k), Web Stories.

The capability scoreboard

~170 capabilities extracted from the families above. Numbering is continuous so phases can reference rows as C-##.

1. SEO (Yoast / Rank Math / AIOSEO / Redirection)

2. Forms (CF7 / WPForms / Fluent Forms)

3. Commerce (WooCommerce)

Everything here exists in core today (products, brands, categories, coupons, shipping methods, orders, customers, payments, checkout) — the strategic decision recorded in GO-PUBLIC.md is whether it stays GPL in core (the Woo move) or extracts to the commercial suite before the repo goes public. This table therefore marks present-tense location, not aspiration.

4. Page building, blocks & editing

5–6. Performance, caching & media

7–8. Security & anti-spam (Wordfence / Solid / Akismet)

9. Backup & migration (UpdraftPlus / Duplicator)

10–11. Analytics, privacy & consent

12. Email & marketing (WP Mail SMTP / MailPoet / Mailchimp)

13. Custom fields & types (ACF / CPT UI / Pods) — the reason this document exists

14. Multilingual (WPML / Polylang / TranslatePress)

15. Users & community

16. Content utilities

17. Ops & admin

Score: 153 ✅ shipped · 0 🟡 partial · 0 ⬜ roadmap · 10 🧩 commercial · 11 🚫 refused. That is 153 of 174 (88%), and every one of the 153 rows that are actually in scope once the refused and the deliberately-commercial are set aside. There are no open rows left.

No in-scope row is open. C-39 was the last one, and it was waiting on an owner decision rather than on work; that decision was taken — ship the non-fiscal receipt in core, keep anything claiming fiscal status commercial — and the receipt is built. Every in-scope row is shipped, tested against all three storage drivers, and documented.

Counted by scripts/docs/regen-parity-artifact.py from the rows themselves, which is also what rebuilds the published artifact — so the number here, the number on the artifact and the rows below cannot disagree again.

C-2 and C-132 moved 🟡/⬜ → ✅ together, because they were one defect with two row numbers: every URL-emitter deriving the locale from a different place.

C-39: the decision, and what shipped

C-39 was the last open row, and it was open for a decision rather than for work. The parts that are usually the hard part are already built and tested: lib/commerce/tax.ts holds rates as data in basis points with net + tax === gross as an invariant, orders carry line totals, and the order-confirmation email already renders an itemised document in two formats.

What is left is a question with three answers, and they are not the same feature.

1. A fiscal invoice is not a PDF. In Greece a retail invoice is not a document you generate — it is a document the tax authority issues you a MARK for, through myDATA. A PDF that looks like an invoice and was never transmitted is not an invoice; it is a liability with a logo on it. That track is already marked commercial on this roadmap and should stay there: it needs per-country logic, credentials, and a maintenance commitment that a GPL core cannot honestly make on an operator’s behalf.

2. A non-fiscal RECEIPT is a different thing, and it is safe. “Here is what you bought, what it cost, and what VAT was inside it” is a commercial document a buyer is entitled to keep, and no authority has to see it. That is a small, honest feature.

3. The PDF question has already been answered once on this roadmap. C-152 refused a server-generated PDF and gave the reason: a headless Chromium is roughly 300 MB on every self-host, for a file every browser already produces from a stylesheet. The same reasoning applies here unchanged — and an HTML receipt view with print rules is something a customer can save as a PDF, email, or hand to their accountant, with zero new dependencies.

The recommendation, accepted by the owner and now built: ship the receipt view in core (a per-order page, print-styled, reachable from the order confirmation), and leave anything that claims to be a fiscal invoice — myDATA, sequential numbering with legal meaning, credit notes — in the commercial track where the obligation can be met properly.

What shipped, and the three things that were not obvious going in.

The buyer is authorised by a signed token, not by an order number and an email in a query string. Those are personal data, and a URL is the one part of a request that lands in an access log, a proxy, a Referer header and a browser history. The token names one order, lives two years — a receipt that expires before the EU conformity window is not a receipt — and travels only in the buyer’s own confirmation email. It is its own signing purpose, so no other link in that inbox can be replayed as one.

An erased order is refused, however valid the token. The token was signed before the erasure and nothing revokes it. receiptIsAvailable refuses it, and the smoke test creates an order, opens its receipt, erases the subject, and re-opens the SAME link expecting a 404 — because a unit test proves the predicate refuses, not that the page asks. A bad token, an unknown order and an erased one return byte-identical 404s, so the page is not the order-number oracle order-lookup.ts exists to prevent.

There is no VAT-analysis-by-rate table, and that is a finding rather than a shortcut. It is the obvious thing to want and the data looks present — line_totals carries tax_rate_bp and tax_cents per line. It is not. tax_cents on the order is goods tax + shipping tax, and shipping_tax_cents is never persisted on the order. A per-rate table would therefore fail to add up to the VAT total printed beneath it on every order with taxed shipping, and a document whose own numbers disagree is worse than one that says less. Per-line RATE is shown instead, with a single reconciling total. Restoring the table means persisting shipping_tax_cents first.

The fourth audit — of the ROADMAP, not the code

The three previous rounds audited every ✅. This one audited every 🟡 and ⬜ — the rows claiming something is missing — because an unfinished row is a claim too, and nobody had ever checked one.

Fourteen readers, one per category, each required to cite file:line or say nothing. Fifteen of the fifty-seven were wrong, in three shapes:

• Six were already done and had been for a while (C-19, C-32, C-34, C-96, C-108, C-110). Every one of them had been fixed as part of some other row’s work and nobody came back to update its own line.
• Five had the right status and a false explanation. C-44 said “embeds work, add a privacy facade” — iframe is not on the sanitizer’s allow-list, so a pasted embed is destroyed on save; the facade has to ship with iframe support, not on top of it. C-62 credited “alt on upload”, and alt_text has one writer and no reader at all. C-113 claimed webhooks already covered most of ESP sync; WEBHOOK_EVENTS carries no subscriber event whatsoever.
• Four understated what exists. C-146 said “prefix+contains today” when field weighting, phrase bonuses and AND semantics were all built and swept.

The lesson is the same one, pointed the other way. An unfinished row rots faster than a finished one, because finishing something makes you re-read its description while leaving it alone never does. A ⬜ that has been sitting for a month is a claim nobody has tested.

scripts/docs/regen-parity-artifact.py now rebuilds the published artifact from this file, so the two cannot disagree about a number again.

The second audit, of the fixes themselves

The thirteen false claims were fixed — and then the fixes were audited the same way, by ten reviewers with an independent skeptic on every finding. Forty-three survived, eight of them blockers, and the pattern was the same one again: a module built and tested and never called, a path fixed for the server-rendered route and not the API one, a promise in an email for a thing with no implementation behind it.

So four rows that had gone back to ✅ have moved to 🟡 or ⬜:

• C-147 — lib/related.ts has 34 passing assertions and zero call sites.
• C-96 — the API path gates on !user, and an API-key caller IS a user, so both live HEADLESS shops count nothing.
• C-108 — the SMTP client writes DATA to the pre-STARTTLS socket, so it fails on port 587, the default.
• C-34 — the confirmation email is real; the bank details it promises have no writer for the built-in bank-transfer method.
• C-110 — double opt-in works; there is no unsubscribe, which the confirmation page promises.

C-2/C-132 was attempted and reverted once, then closed properly. The first attempt failed because the middleware rewrites a prefixed request, so every locale-prefixed URL the sitemap submitted was declared non-canonical by the page it pointed at. The fix was not to make the canonical follow the URL but to make every URL-emitter derive the locale from the same place: the record. buildPageView and the blog post route now canonicalise through recordLocale(post), which is what the sitemap and the feed already did — so a German post served at the unprefixed /blog/<slug> still names /de/blog/<slug> as its address, and the four signals agree by construction rather than by review.

Closing it also exposed the larger gap: nothing on the site LINKED to a prefixed URL. See C-129.

The lesson is not that the fixes were careless. It is that a fix is a claim, and a claim is worth what its audit is worth. These numbers now survive two adversarial passes; the ones before them survived none.

The 🔜 marker is gone: it meant “in a PR that has not merged yet”, and every PR it pointed at (#35 themes, #36 consent i18n, #37 content types) has been on main for some time. A status that means “soon” rots the moment it ships and nobody goes back to it — shipped or not shipped is the only distinction the table can keep honest.

The fifth audit — of a marathon, by five lenses and a skeptic each

The batch above was audited twice: once as it was built (26 findings, all fixed), then again over the whole 102-file diff after those fixes had landed. The second pass ran five lenses — scope, storage drivers, headless, CSS/CSP, and the new pure modules — with an independent reviewer instructed to REFUTE every claim. Sixteen claims, eleven confirmed and five refuted, and the confirmed set included a blocker that three separate lenses found independently:

/admin/posts/:id/edit was a hard 500. Its frontmatter called discourageIndexing() and its template called defaultLocale(), and both imports sat inside the page’s <script> block — a separate module. Every post edit page threw ReferenceError. Three layers were silent: // @ts-nocheck on that script kept astro check quiet, the smoke walk listed /admin/posts and /admin/posts/new and not the screen between them, and the existing scope guards worked off a hand-written list of helper names that neither symbol was on.

That shape — an import in the wrong Astro scope — has now cost seven bugs in one branch. It is the single most expensive thing about .astro files: the frontmatter and every <script> are separate modules, astro check reports the symptom as a tidiness hint, and the failure is either a 500 nobody’s tests reach or a silent ReferenceError in the browser. The answer is two checks that need no list of names:

• an import inside a <script> whose name never appears in that script is in the wrong scope, and so is a frontmatter import used only in a script;
• and any call to a function exported by src/lib or src/core must be imported in the scope that calls it — with the set of names derived from the source tree, so a helper added tomorrow is covered without anyone remembering it.

Both find the blocker when the fix is reverted. Every other fix in this round is mutation-tested the same way.

The other confirmed findings were the same shapes this document keeps recording: a check comparing a hyphenated slug against a spaced phrase, so every multi-word keyphrase failed a check about a URL that was nothing but the keyphrase; a read time returned as a string by one caller and a number by another into the same theme slot, printing “3 min read min”; a link checker that called every locale-prefixed URL broken in the same release that made the site emit them; and a post body that could not be emptied through the API, answering 200 while storing the old text.

The score went DOWN, and that is the point

It was 103 until every ✅ was checked against the code rather than against its own wording. Thirteen claimed a capability that does not exist, each confirmed by a second reviewer whose job was to refute the first. Five more were accused and rescued, so the check was not simply pessimistic.

The failures had one shape: the evidence cited itself. A row said “locale-aware sitemap — sitemap.xml.ts” and that file does not contain the word “locale”. A row said “server-side page-view counting — lib/page-view.ts” and that file renders a page; nothing in the repo has ever incremented post.views. A row said “reliable SMTP delivery” and there is no SMTP client of any kind. Reading the row told you nothing; only opening the file did.

A scoreboard is only worth the audit behind it. These numbers now mean a reviewer opened each file. Any row added later without that check should be assumed false.

Weighted by installs, the shipped set now covers every 4M+-install plugin’s core job. The last two holes — WXR import (C-90) and form building (C-20) — closed in Phase 2. The thinnest remaining areas are custom fields beyond ref/media (C-123, C-127, C-128), community features (C-136..C-143), and content utilities (C-45..C-47) — none of which blocks a migration, which is why they sit behind the adoption and trust waves.

Last reconciled against main after Phase 2 merged (PR #42). When a phase ships, flip the ROWS as well as the phase list below: the two disagreed for the whole of Phase 2, and a table that under-reports finished work is read as a backlog that does not exist.

The phased plan

Ordering principle: adoption blockers first, then trust, then reach, then depth. Each phase is sized to be one PR-train, each item lands with tests and OpenAPI updates per repo discipline (real CI commands; negative tests that fail without the fix).

Phase 1 — small, loud wins (days, not weeks)

Everything here rides existing rails and shows up on every page.

• C-11 + C-12 JSON-LD structured data + breadcrumbs (Article, Product, Breadcrumb, Organization) — the last visible SEO gap vs. Yoast
• C-47 Duplicate post/page — 4M installs say this matters daily
• C-16 “Discourage indexing” toggle — one setting, saves staging sites from Google
• Website: developers + documentation pages already live; link docs/ROADMAP.md and this file from /docs

Phase 2 — the adoption & trust wave (the WordPress-refugee release)

What someone leaving WordPress checks before committing.

• C-90 WordPress WXR import — shipped. Posts, pages, media (through the shared lib/media/ingest.ts, the same code the upload route uses), categories keeping their WordPress nicename, tags, publish dates, and a generated 301 map from old permalinks into the legacy-recovery engine. CLI, POST /api/import/wordpress, and /admin/import, all rehearsing by default and safe to re-run. WooCommerce shops come across through npm run import:woo, which turns the commerce switch on — never off. Authors are REPORTED rather than invited: creating invitations from an uploaded file would turn this endpoint into a way to make the server email thousands of addresses of an attacker’s choosing
• C-20 + C-21 Public-write content types — shipped. writable: 'public' on a content type opens an anonymous POST guarded by a per-address submission limit, a honeypot and the local proof-of-work check; /forms/<type> renders the form itself, so CF7/WPForms parity really is a schema rather than a plugin. Read and write policies are separate axes, both deny-by-default: the pairing a job application needs — anyone may send one, nobody may read the others — is the one the builder makes easy, and the publish-everything pairing is the one it warns about
• C-122 + C-124 Relation & media field kinds — shipped. ref names its target collection and refuses a dangling link on create and on update; media stores the id and resolves a <field>_url on read. Fixing the switch they plugged into also uncovered that slug, email, url and date had been accepted and silently discarded since the builder shipped — all four are implemented, and the validator now fails closed
• C-105 GDPR data-subject export/erase — shipped. /admin/privacy, admin only, both directions audited. Erasure anonymises orders instead of deleting them, because a shop must still be able to produce its accounts and Article 17(3)(b) says so; everything else about the person goes.
• C-104 + C-102 Consent Mode v2 signals · consent audit trail — shipped. All seven signals including the two v2 ones, mapped once and shipped to the browser as data; and a consent trail that proves a decision happened while holding nothing about who made it. The privacy story Complianz charges for is now complete: banner, prior consent, Consent Mode v2, a receipt trail, and data-subject access and erasure
• C-86 S3-compatible off-site backup target — shipped. Any S3-compatible bucket, on the existing scheduler timer, with SigV4 signed by hand rather than by seventy packages and verified against an independent implementation. Archives what the active driver actually stores, and refuses a remote Turso install rather than uploading a stale db.json
• C-60 Replace-media-in-place — shipped. The record keeps its id and every stored reference is rewritten to the new file; old files are removed unless another record shares them. C-59 (derivative rebuild button) dropped: a replacement already regenerates the full set, and rebuilding without a new file only matters after a change to the width list, which is a deploy
• C-133 Translation-status dashboard — shipped. /admin/translations, across both translation models, open to everyone who writes content. Flags the half-translated products that every locale-key check reports as done
• C-155 + C-109 Scheduler admin screen · outbound email log — shipped as one screen, /admin/operations. The scheduler says whether it is running in THIS process, not just enabled; the email log says who, what, how and whether it worked, and never the body. The log holds addresses, so the GDPR tooling covers it
• C-41 Section composition UI (first pass) — shipped. Reorder was already done; configure now works for PLUGIN sections too, with the variant class namespaced to the plugin so a manifest cannot mint a core class and inherit styling it does not own

Phase 3 — reach & polish

• C-13 AI content analysis (readability/SEO hints via existing assistant) · C-134 draft-translation action
• C-146 Weighted search · C-147 related posts · C-46 table of contents · C-45 table sections
• C-142 Comments (moderated) — decide core vs. first-party plugin at spec time
• C-87 + C-162 astrobaas migrate + CLI verbs (content/user/backup) · C-91 CSV import
• C-123 Repeater fields · C-127 admin-defined settings groups · C-128 custom taxonomies
• C-61 media folders · C-62 alt-audit → accessibility report · C-153 author/date archives
• C-103 cookie declaration table · C-107 analytics charts in admin · C-112 editable email templates

Phase 4 — depth & monetization adjacency

• C-32 Stripe adapter in core payments abstraction (IRIS stays commercial per its own track)
• C-35 product reviews · C-39 invoicing/PDF receipts · C-111 newsletter campaigns
• C-22/C-125 conditional logic (forms + fields) · C-23 public upload fields · C-126 flexible layouts
• C-138 custom roles matrix · C-141 user switching · C-150 editorial workflow · C-149 manual ordering
• C-168 npm theme distribution · C-170 child themes · C-114 popups as first-party plugin
• C-79 spam scoring

Phase 5 — the long tail (each needs a champion before it’s scheduled)

AVIF (C-56) · video posters (C-64) · upload AV-scan hook (C-76) · file integrity (C-82) · staging docs (C-89) · RTL (C-135) · print/PDF (C-152) · per-request profiler (C-157) · white-label (C-159)

Explicitly commercial (never free-core)

Subscriptions (C-36) · funnels (C-38) · marketing automation (C-115) · membership (C-140) · paywall (C-144) — plus optical, IRIS, and the suite. Distribution per the established shape: one suite tarball + ASTROBAAS_PLUGINS_ACTIVATE, no licence-key gating in code.

Refused, with reasons on record

Page builder (C-42) · shortcodes (C-43) · cache plugins (C-52) · DB “optimizer” (C-66) · WAF-in-app (C-77) · hidden login (C-78) · IP-intel phone-home (C-81) · forums/social core (C-143) · admin-menu editor (C-158) · multisite (C-166) · arbitrary-code snippets. Each is either structurally unnecessary here, security theater, or a lock-in mechanism.

Sources

• WP.MD — Most Popular WordPress Plugins, daily ranking tracker
• Peligent — 50 Most Popular WordPress Plugins 2026 (ranked by installs)
• Website & Web Hosting School — The Most Popular WordPress Plugins in 2026
• WP.MD — WordPress Plugin Stats
• SmartWP — 30+ Best WordPress Plugins in 2026
• PluginScore — Most Installed WordPress Plugins
• WP Rocket — Best WordPress Plugins in 2026
• Capability descriptions for ACF, CPT UI, Complianz, WP Consent API, Redirection et al. from their WordPress.org listings (knowledge current to 2026).

Status column audited against the working tree on 2026-08-29 (branch main + open PRs #33–#37). When a row says ✅ it names the file that proves it.