ProcessWire: The CMS of Choice When Facts Matter More Than Marketing

What is ProcessWire, in a few lines

ProcessWire is an open-source CMS written in PHP, distributed under the Mozilla Public License 2.0. But calling it just a "CMS" is reductive: it is also a content management framework and a web application framework, that is, an infrastructure on which to build complete web applications, not just editorial pages.

It was born in 2003 (then called Dictator CMS), took its current name in 2006, and became an open-source project in 2010. Version 3.0, in 2016, introduced PHP namespaces and front-end editing; the latest major release, 3.0.255, was released in January 2026. In between, over twenty years of continuous and consistent development. Few things in web software have this kind of continuity.

Two architectural traits define it. The first: content lives in a hierarchical page tree, without limits of depth, which scales from showcase sites to installations with millions of records without changing paradigm. The second: every field is a custom field. There are no "system fields" to work around—you define the structure of your data exactly, and nothing else.

"Designed, not assembled": the difference that matters

WordPress was born as a blogging engine. That's its history, and also its strength in that niche: quickly putting a site online based on an existing theme, often without writing a single line of code. ProcessWire starts from the opposite premise. It doesn't give you A blog, a menu, categories, and a ready-made media library. It gives you fields, templates, and pages—neutral building blocks with which to exactly shape the structure you need.

This difference can be summarized in two mental models. On the one hand, the assembly logic: take a theme, graft a dozen plugins onto it (one for custom fields, one for SEO, one for forms, one for the cache, etc.), and you get a functional but composite mosaic. On the other, the design logic: build the application starting from the project's actual data, controlling every single portion of markup that ends up in output.

This is precisely the technical point most cited by developers migrating. In WordPress, custom fields are an afterthought: common practice requires plugins like Advanced Custom Fields, and the data ends up in a table (wp_postmeta), which, on complex structures, becomes a bottleneck at query time. In ProcessWire, custom fields are a native, first-class feature. There's no level of adaptation between what you think and what the system does: the data structure is the system.

The API that developers respect

If there's one reason ProcessWire is beloved among developers, it's its API. It's modeled after jQuery conventions—the stated goal is to give a site's pages the same fluid control that jQuery gave over the DOM. The result is that every piece of content on the site is just one line of code away, no matter how large your site.

At its core is an expressive selector engine. Retrieving data doesn't require writing SQL or navigating fragmented APIs: you describe what you want, in a readable syntax.

php

// All buildings taller than 100 meters, sorted from tallest
$skyscrapers = $pages->find("template=building, height>100, sort=-height");
echo $grattacieli->each("<li>{title} — {height} m</li>");

No imposed template engine, no obscure abstractions: the template files are pure PHP, and you control the markup 100%. Those who have been using WordPress for years often describe the same moment of surprise—the feeling that operations that previously required plugins and workarounds are simply already there, clean and consistent. This is a weighty aspect, and one that is rarely considered: a consistent API is not only pleasant to write, it is maintainable over time. Code written today can be read and extended in three years without any archaeology.

Security: a track record, not a slogan

Here the facts are particularly eloquent, and it is This is the point we call for independent verification. In nearly fifteen years of open source project, ProcessWire's core has not had any significant security incidents, nor has it ever required the issuance of a security advisory. This isn't a coincidence, it's architecture.

The technical reason is clear: the only input from the front end to the CMS is the URL. This places a structural limit on the attack surface. Any other input is optional, at the developer's discretion, and is accompanied by a full suite of sanitization tools. In admin, the system offers configurable password requirements and opt-in two-factor authentication. And every line of code that enters the core goes through the lead developer's security review—a pipeline that no open plugin ecosystem can guarantee in the same way.

There's a practical implication that technical customers really like: you can install a version of ProcessWire, publish the site, and leave it for years without forced updates, without it becoming a target. When you update, you do it because you want a new feature, not because you're chasing a patch.

This needs to be said honestly—and it's the kind of fairness that's needed. This makes a credible comparison—that WordPress is also a target because of its scale: its enormous reach makes it a cost-effective target for attackers. And often the problem isn't the WordPress core itself, but the jungle of third-party plugins and themes that most installations depend on, which aren't subjected to the same review. The difference, therefore, isn't "WordPress is insecure." It's that ProcessWire concentrates value in the controlled core, while WordPress distributes it across components that no one centrally manages.

Flexibility and integrations: what ProcessWire "talks" to

One of the most common misconceptions is thinking of ProcessWire as a "closed" CMS around its pages. The opposite is true, and that's perhaps why it's so suitable for attackers. well for modern projects.

Modular architecture taken to the extreme. In ProcessWire, modules aren't an afterthought: they are the system. The "CMS" part itself is a set of modules built on top of the framework. This makes extensions simpler and faster than elsewhere. The directory has over 600 modules—a deliberately smaller number than other platforms, because much of what requires a plugin elsewhere is already in the core here.

Front-end agnostic and headless. Since you control every piece of output and have a powerful API, nothing forces you to serve HTML from the CMS. You can use it as a headless backend that exposes JSON to a React, Vue, or vanilla front-end; you can build custom endpoints; You can combine it with Node/Express microservices for the application parts. This is the approach we follow when a project requires a custom front end and separate application logic.

Integration with external services. The PHP API and the hook system (which allows you to intercept and modify almost any system behavior) make it natural to connect ProcessWire to any third-party service: payment gateways, transactional email providers, PDF generation, and—increasingly—artificial intelligence APIs like those from Anthropic and OpenAI. This is precisely where we base our vertical assistants: the CMS manages content and a structured knowledge base, while an application layer communicates with the models.

Native multilingual. Multilingual support is not a plugin: it's in the core, with integrated fields, URLs, and translation tools. Anyone who has managed international sites on other platforms knows how life-changing this is.

ProcessWire and AI: Built for This Moment

This is the most current chapter, and it's worth telling because it's unusually candid. In April 2026, Ryan Cramer, the creator of ProcessWire, published a long post about his first, belated encounter with AI-assisted development. He tells you how he started using Claude Code as a daily "colleague," became about twice as productive in a month, and became convinced that ProcessWire is on the path to becoming the most suitable open source CMS for AI agents.

The technical reason is illuminating and touches on all the topics discussed so far. A consistent API, without "magic boxes" where it's unclear how an input becomes an output, is essential. ideal terrain for a pattern-based agent. The same post announced Agent Tools, a module—born from a collaboration between Cramer and Claude Code himself—that allows AI agents to operate within ProcessWire, along with an initiative to document the API in a machine-readable format.

The most critical voice also deserves space. A key point emerged in the discussion, because it's exactly the kind of balance this topic requires. One community developer noted that what makes ProcessWire "AI-friendly" is, more precisely, "pattern-friendly": a predictable code base with clear conventions is the perfect input for systems that recognize and reproduce patterns. It's not magic—it's a good fit between tool and task. This is a reading we share: ProcessWire's robustness with AI isn't a special effect, it's the consequence of twenty years of architectural rigor.

The honest comparison: when WordPress makes sense

An article claiming that ProcessWire always wins wouldn't be credible—and it wouldn't be true. There are scenarios where WordPress is the right choice, and it's worth listing them, because they are the same ones indicated in the official ProcessWire documentation:

• If the need doesn't go beyond a blog and an existing theme is fine, WordPress is an excellent solution.
• If the project is small and neither original design nor development is needed, assembling plugins may suffice.
• If you have no web development skills and your needs are simple, WordPress is a good entry point.
• If a high-quality plugin already exists that solves your specific problem exactly, it often makes more sense to use it than rebuild it.

The dividing line is clear. WordPress excels when the goal is to: Get something online quickly, starting from what already exists. ProcessWire excels when the goal is to build something original—a custom website, an application, a system designed to last and be maintained by professionals. Developers tend to adopt ProcessWire after they have outgrown WordPress, when the pre-packaged features start to weigh more than they help.

Why Livedata builds on ProcessWire

At this point, our choice is self-explanatory, but it's worth making it explicit, because it's not an aesthetic preference: it's consistent with the way we work.

We build original projects, not mosaics of themes and plugins. ProcessWire gives us Complete control over markup and a data structure modeled after the actual project, not a template to adapt. We deliver their own code, with no lock-in: no hidden subscriptions, no dependency on an ecosystem that could change the rules. We aim for longevity—a site that, if needed, can remain secure for years. And we work with technically demanding clients who verify the claims: the core security history, API consistency, and architectural transparency are exactly what withstands that kind of scrutiny.

In other words: ProcessWire is designed to do the work we do. It's The silent partner that starts with "Designed. Not Assembled."

The facts speak for themselves

We didn't ask you to believe that ProcessWire is the best tool because we say so. We've put the facts in front of you: twenty years of consistent development, an architecture where every field is yours and every line of markup is under your control, an API that developers describe as a pleasure to use, a security track record almost unique in the open source landscape, a natural openness to modern front ends, external services, and AI agents—and a respected community that chooses this tool after trying others.

If what you need is a quick blog on a ready-made theme, WordPress is fine. If what you need is something built, secure, and built to last, the facts point in a pretty clear direction. We've been following it for a long time.

---

Want to understand if ProcessWire is the right tool for your project? Let's talk about it.