ADL vs WordPress | ISDG, LLC

TL;DR: WordPress is the most successful “describe it and it runs” system ever shipped. A large share of the entire web is people declaring sites through an admin screen rather than programming them. Its core is even interpretation-shaped: post types, statuses, and field groups are registered descriptions the runtime serves. But WordPress answered every requirement beyond its built-in vocabulary the same way: install a plugin. The result is a platform whose applications are defined by the union of dozens of third-party codebases running with full privileges, plus settings screens, plus functions.php: a definition no one can read end to end. ADL’s answer to the same demand is the opposite bet: when the vocabulary runs out, extend the vocabulary, not the code pile.

The steelman

Respect first, and not the grudging kind. WordPress won the web (by most counts it runs around four in ten sites on it) and it won honestly: it let people who would never write software declare what they wanted. Pick a theme, create pages, set options, publish. Twenty-plus years later it has the largest operator community in software; every agency knows it, every host runs it, and wp-admin is so universal it functions as shared infrastructure — training cost approximately zero, worldwide.

And under the folksy reputation sits an architecture this series should recognize. A WordPress post is a record with a built-in editorial lifecycle (draft, pending, published, private), the familiar hard-coded state machine. Custom post types are registered descriptions the runtime interprets into admin screens, permalinks, and REST endpoints. Advanced Custom Fields (the plugin that quietly turned WordPress into an application platform) lets you declare field groups in a UI and have them served everywhere. Squint, and a WordPress site is a declared content domain interpreted by a PHP runtime. Sixth proof in the series, and by deployment count the biggest one by far.

People noticed. ACF plus custom post types plus a forms plugin plus a membership plugin, wired together with hooks: small organizations everywhere run directories, intranets, application portals, whole businesses on WordPress. WooCommerce is an entire commerce platform delivered as a plugin. That’s the decision path this essay sits on: not WordPress-as-blog, but WordPress-as-the-app-platform-you-already-have.

The plugin economy is the fence, monetized

Every essay in this series finds the same fence: the declaration describes structure, and the first requirement past structure becomes code. What makes WordPress the most instructive case is that it industrialized the far side of the fence. Need a lifecycle beyond draft/publish? Plugin. Role and permission logic? Plugin. Validation? Forms plugin. Computed values, workflows, audit trails? Plugin, plugin, plugin: some sixty thousand of them, an actual economy built on the gap between what WordPress can declare and what its users need.

Part 12 of this series described the failure pattern of declarative platforms: the workaround pile grows beside the platform until the pile is the platform. WordPress is that sentence with a market cap. The remarkable thing isn’t that the pile exists (every platform grows one) but that the pile became the product, and its size is cited as the platform’s chief virtue.

Now read the pile as an engineer responsible for the system. Ask the auditor’s question (what are the rules of this application?) and the honest answer for a real WordPress app is: the core defaults, plus ACF field groups defined in the admin, plus the settings screens of each installed plugin, plus each plugin’s own code, plus whatever accumulated in functions.php. The definition is diaspora at a scale even the SaaS CMS essay didn’t reach, because here every fragment is executable third-party code. WordPress plugins run in-process with full privileges. There is no capability boundary: a form plugin can read every table, a gallery plugin can create admin users. Which is exactly what the security record shows: year after year, the overwhelming majority of reported WordPress vulnerabilities are in plugins and themes, not core. The core team’s engineering is genuinely good; the architecture just makes the perimeter equal to the sum of everything installed. The liability surface doesn’t grow with your domain — it grows with your plugin list, which is worse, because you didn’t write any of it and must update all of it.

Doesn’t Kalos have plugins too?

Yes — and the distinction is the whole point, so it deserves plain statement rather than a footnote. Kalos is a microkernel: transports, stores, and the scripting layer are plugins behind a versioned ABI with an enforced load-time handshake. But those plugins extend the engine: how requests arrive, where data lives, what the sandbox runs. They do not define the domain. No Kalos plugin adds your validation rules or your state machine; those live in the ADL file, governed by the pipeline, reviewable in one read. Even the escape hatch is sandboxed Lua under instruction limits, not full-privilege code in the runtime’s process. WordPress plugins occupy the opposite role: they are where the application’s behavior lives. Same word, opposite architecture (engine extension versus domain definition), and the auditor’s question comes back with a one-file answer in one case and a plugin list in the other.

For completeness, the spectrum runs further: past WordPress sit the fully managed builders (Wix and its kin) which remove the code entirely, and the sovereignty with it; a fine trade for a brochure site and not a candidate for anyone’s system of record, so that’s all this series will say about them.

The honest concessions

WordPress won, and for content sites it deserves to. For a blog, a brochure site, a small newsroom, choosing anything this series discusses over WordPress would be malpractice: the hosting is everywhere and cheap, the themes are endless, and the editorial experience is understood by everyone you will ever hire. Kalos renders nothing and competes for none of that.

The operator ecosystem is a real asset with no ADL equivalent. Every town has WordPress people. An ADL domain requires reading a spec no one grew up with. The declaration being learnable in a sitting is our answer, but “learnable” is not “already known by millions,” and the difference is worth real money to a small organization.

The pile works more often than architects admit. Thousands of ACF-and-plugins applications run for years, doing their jobs. The argument here is about what happens at the edges (security, audit, change), not a claim that the mainstream case collapses. It usually doesn’t. It just can’t be read.

Closer

WordPress proved the world wants to declare its software and met the demand with an economy of code; ADL meets the same demand by refusing to let the vocabulary stop.