WordPress is not a
Imagine three web projects that use WordPress.The first is a corporate website built with a…
Imagine three web projects that use WordPress.
The first is a corporate website built with a commercial template, a visual editor and several plugins. Its team can update content without programming knowledge. The second uses a bespoke theme and custom-developed functionality to meet specific needs. In the third, WordPress works solely as a content management system: the visible website is developed separately, perhaps with React, and retrieves information through an API.
All three projects share the same CMS. However, their architecture, their administration experience and their maintenance needs may be very different.
That is why statements such as ‘WordPress is slow’, ‘WordPress is flexible’ or ‘WordPress is difficult to maintain’ are incomplete. They may describe particular projects, but not necessarily the platform in all its forms.
WordPress does not operate in isolation. What we see as a single website is the result of decisions about components, development, infrastructure and services. WordPress is the starting point, not a complete description of what we have built.
To understand its advantages and limitations, we need to look beyond its core.
The core is only one part of what we use
The WordPress core provides the fundamental functions for managing users, content and publishing. But it rarely constitutes everything a project needs on its own.
Around it, we incorporate themes that define the presentation, plugins that extend functionality, hosting providers that manage the infrastructure, integrations with external services and, sometimes, bespoke development. Within the same installation, code maintained by the WordPress community can coexist with commercial products and solutions developed by an agency.
That combination raises a question that is not always visible from the administration panel: not all components move forward at the same pace, nor are they the responsibility of the same people.
The team that maintains the core sets its own priorities. Each plugin or theme vendor decides how and when to update its products. A hosting provider controls part of the technical environment, while an agency may be responsible for customisations. Each part has its own schedule, terms and limits of responsibility.
This does not make WordPress an exception. Modern software is often built from parts from multiple sources. What is distinctive about its ecosystem is how easily those parts can be added and combined, even when the person managing the site barely perceives the relationships created between them.
Using a single management platform does not mean relying on a single provider. And that diversity, although it requires certain precautions, is also one of its greatest strengths.
The great advantage of not having to build everything
Not every organisation needs to develop its own content management system, program a form or create an integration with an e-commerce platform from scratch. One reason for WordPress’s enduring presence is that it allows us to make use of solutions that others have already built.
A small business can launch a professional website without funding a fully bespoke development. A non-profit organisation can manage donations or registrations. And a more complex project can connect its website with marketing tools or business systems without having to develop the entire integration from the outset.
The advantage is not solely financial either. There is a wide availability of professionals, documentation and specialist knowledge. It is possible to find teams with experience in performance, accessibility, e-commerce or editorial management, and to ensure continuity for projects initially developed by others.
Reusing solutions makes it possible to devote more resources to what truly differentiates each project. Not having to invent everything is a significant advantage.
But having a tool for almost every need can also change the way we make decisions. When a requirement arises, it is tempting to look for a plugin and install it before asking ourselves how that functionality should fit into the whole.
The fact that a solution exists and works does not mean it is the most suitable one. It may use data structures that are difficult to migrate, introduce processes that are not very compatible with other tools or constrain future extensions. Developing something bespoke does not guarantee a better outcome either: both options require judgement.
The strength of the ecosystem lies in offering alternatives. The responsibility for choosing them remains ours.
When every solution introduces a new dependency
The complexity of a website cannot always be measured by counting plugins or calculating how much code it contains. What is usually decisive lies in the relationships between its components.
A plugin requires a particular version of PHP. A theme includes a JavaScript library that another extension also uses. A customisation retrieves data stored by an external provider. An integration depends on an API continuing to function.
Everything may work correctly for months. Then an update arrives, an API changes or a library is no longer maintained. No component needs to be poorly developed for the whole to start causing problems: it is enough that their changes are not compatible with one another.
We can call this accumulated complexity: as the relationships between components increase, it becomes harder to anticipate how a change will affect the rest of the system.
That is why ten relatively independent plugins can be easier to maintain than three that are closely interconnected. And a website with few extensions can be fragile if one of them supports essential processes that no other tool can easily replace.
Having many features is not the same as retaining control over them. That control does not require programming everything from scratch or rejecting external dependencies. It means knowing which elements are critical, how they relate to one another, who maintains them and what alternatives we have if we need to modify or replace them.
An architecture with clearly defined responsibilities, sufficient documentation and testing before updates does not eliminate every risk, but it makes them easier to manage. The aim is not to prevent the system from evolving, but to make every change as predictable as possible.
In WordPress, where extending functionality can be as easy as installing an extension, this distinction is especially important: speed of implementation and the sustainability of a technical decision are not the same thing.
An ecosystem is also an economy
Behind WordPress is an industry of hosting companies, plugin and theme vendors, independent developers, agencies and support providers. Part of this activity contributes directly to the open-source project; another part builds products and services around it.
There is no inherent contradiction between free software and commercial activity. Developing, updating and supporting a tool requires resources. Business models make it possible to sustain many solutions that would otherwise be unlikely to exist.
However, the interests of providers and clients do not always align. A company may change the price of a subscription, reorganise its plans or stop maintaining a product for legitimate commercial reasons. For someone using it as a central part of their website, those decisions can have significant consequences.
Imagine an organisation that manages its sales through a particular extension. Even if it has access to its data and some of the code, changing tools may involve migrating information, rebuilding processes and retraining its team. The cost of leaving may be far greater than the licence fee.
Here, a fundamental distinction emerges: having access to the code does not always mean having the practical ability to replace a solution. A free licence offers important rights, but maintaining an abandoned tool independently can also require knowledge and resources that the organisation does not have.
Before adopting a component, it is worth considering who develops it, how it is funded, what support it provides and what would happen if it disappeared. This does not mean distrusting commercial software or assuming that a free tool will be less reliable. It means incorporating provider continuity and the cost of change into the technical assessment.
Agencies must also examine their own decisions. The tool that makes it possible to deliver a website more quickly will not always be the most suitable for the person who will have to maintain it for years.
Choosing technology means, in part, choosing economic relationships. What matters is understanding them before they become dependencies that are difficult to manage.
The community is not a support department
WordPress also has something that cannot be reduced to its commercial products: an international community that contributes to the core, fixes errors, translates, documents, organises gatherings and shares knowledge.
This network makes it easier to find answers, learn from others’ experiences and keep a platform alive that does not depend on a single development team. It is one of the project’s great assets.
But a community that contributes to the development of a technology is not the same as a team hired to maintain our website.
The fact that a plugin has a public repository or a support forum does not mean that its author is obliged to answer every query. The fact that the core receives updates does not guarantee the compatibility of every combination of themes, extensions and custom code. And the fact that a provider offers support for its product does not mean it must resolve every conflict caused by third parties.
Consider an issue following an update. The hosting works correctly; the plugin provider points to an incompatibility with the theme; and the person maintaining the theme attributes the fault to a customisation. Each may be right within their own remit. Yet the website still does not work.
The example reveals an essential difference: the fact that every piece has someone responsible for it does not guarantee that someone is accountable for the whole.
That is where the professional responsibility of those who design, integrate and maintain the project comes in. It does not mean an agency must provide support indefinitely, nor that maintenance is automatically included in the initial development. It means that it is advisable to establish who oversees updates, who investigates incidents and under what agreements these tasks are carried out.
WordPress can be used without paying a licence fee for its core, but that does not make its maintenance free. Time must be devoted to monitoring changes, carrying out tests and resolving problems. The community can provide tools and knowledge; it cannot take on responsibilities that have never been assigned to it.
Recognising that limit is also a way of respecting the work of those who contribute to free software. Their contribution has enormous value precisely because we should not confuse it with an obligation to provide ongoing support.
Conclusion
Let us return to the three projects from the beginning. They share WordPress, but their architectural decisions, dependencies and maintenance needs are different. That is why asking whether ‘WordPress is a good solution’ without knowing the project tells us less than it may seem.
Choosing WordPress is not just about selecting a CMS. It also means deciding which components to use, which providers to trust, how to organise development and who will be responsible for its evolution.
The solution is not to install fewer plugins as a matter of principle, nor to avoid external services. It is to understand what we have incorporated and retain sufficient capacity to intervene when circumstances change.
The quality of a WordPress project depends as much on the platform as on the judgement with which its components have been chosen, integrated and maintained. Perhaps the most useful question is not what we can build with WordPress, but how much we truly understand about what we have built.
But there is more. As this ecosystem grew, the web was also changing profoundly: devices, performance expectations, security, architectures, and the way content is created and consumed.
That leads us to the next article in the series, The web that WordPress helped to build no longer exists, and to a new question: to what extent does WordPress still meet the needs of a web that no longer resembles the one it was created for?
Comments