Compatibility
Technical dependency
A feature requires specific versions of WordPress, PHP, a theme, a builder or other extensions. Changing one layer can create errors elsewhere.
Guides
The real cost of WordPress is not the plugins: it is dependency
A CMS can do almost anything. The decisive question arrives when something breaks: who can fix it immediately, and how many vendors, versions, licences and release schedules does your website depend on?
Direct answer
WordPress is not a problem because it uses plugins: modularity is one of its strengths. Risk appears when a business function depends on a chain that nobody governs end to end. An update may be necessary for security yet incompatible with a theme, builder or add-on; editing vendor files exposes the patch to overwriting; waiting for a fix hands priorities and timing to someone else. A bespoke website does not eliminate every dependency: it reduces them, makes them explicit and concentrates responsibility on the project’s code.
Gian Luca Partengo
Web developer since 1995 · bespoke websites · Updated:
Can WordPress do the same things as a bespoke website?
Often yes at the level of the visible feature. Not necessarily at the level of control, responsibility and ability to intervene.
- 01A ready-made feature reduces initial time but introduces another vendor’s lifecycle
- 02Theme, builder and plugins must remain compatible with each other, WordPress and the server
- 03A local fix may be overwritten or turn the website into a fork that you must maintain
- 04The real cost appears during updates, incidents, renewals, migrations and supplier changes
A WordPress website is a chain, not one product
The interface may look unified, but the output depends on different software, organisations and release calendars.
-
01
WordPress core
It manages content, users, routing and base APIs. Its evolution and requirements can change how extensions behave.
-
02
Theme
It controls presentation and often functionality. If abandoned or heavily customised, every update becomes a delicate decision.
-
03
Page builder
It adds an editor, components, CSS, JavaScript and its own data models. It may require a specific core or Pro version.
-
04
Functional plugins
SEO, forms, caching, security, languages, ecommerce and cookies introduce code and independent update cycles.
-
05
Plugin add-ons
An extension can depend on another extension, not just WordPress. Compatibility becomes a matrix rather than a line.
-
06
PHP, database and server
Versions, memory, modules, caching and server configuration can make previously working code incompatible.
-
07
Licences, APIs and support
Updates and premium services may depend on renewals, accounts, external infrastructure and support priorities.
-
08
Business process
The technical problem becomes commercial when it interrupts leads, sales, bookings, indexing or staff activity.
The dependency that matters
Risk is not measured by counting plugins. It is measured by asking which features are critical, who controls their code, how long recovery takes and what happens if a vendor stops cooperating.
Dependency is not one thing: it is technical, security, operational and commercial
Two websites with the same number of plugins can carry completely different risks.
Risk window
Security dependency
A vulnerability requires a vendor fix. Until it arrives, you must mitigate, disable, replace or accept the risk.
Intervention time
Operational dependency
The person supporting the website may diagnose the problem without controlling the roadmap of the component that caused it.
Contracts and continuity
Commercial dependency
Expired licences, changed plans, usage limits, tiered support or discontinued products alter the cost and availability of a feature.
Composite vendor lock-in
Open source does not mean operational independence
WordPress and many plugin codebases are available. In theory they can be studied, changed or forked. In practice, maintaining a secure fork requires skills, tests and continuous updates.
Licence freedom reduces some legal and technical constraints; it does not remove the cost of taking over the work previously done by the vendor.
The update paradox: you must update, but not blindly
Delaying updates increases exposure; applying them without inventory, staging and recovery can interrupt the website.
WordPress recommends keeping plugins and themes updated. That is sensible: new versions fix vulnerabilities, incompatibilities and defects.
The same ecosystem also requires backups and rollback capability because an update can fail or conflict with other components. Automation does not remove that responsibility.
Correct maintenance is therefore a process: know the dependencies, read relevant changes, test in a controlled environment, verify critical paths and be able to return to a working version.
“Update everything” is not an operating plan. It is an action that requires testing, observation and recovery.
Inventory and tested backup
Versions, licences, declared compatibility, data, files and the recovery procedure must be known.
Staging and critical features
Login, editor, forms, checkout, caching, SEO, languages and integrations must be tested beyond the homepage.
Logs, browsers and monitoring
PHP and JavaScript errors, HTTP status, performance and conversions must confirm the website is more than merely visible.
WordPress documentation recommends backups and recovery because automatic updates can go wrong: read the official procedure.
Why editing a theme or plugin directly is not a stable solution
An urgent patch can bring the website back. The question is who will maintain that deviation at the next release.
| Intervention | Initial speed | Update effect | Later debt |
|---|---|---|---|
| Edit vendor files | May be immediate | May be overwritten | The patch must be remembered and reapplied or abandoned |
| Official hook, filter or API | Requires a suitable extension point | More resilient, not guaranteed forever | Must be tested against supported versions |
| Child theme | Suitable for expected customisation | Protects separated files | Does not repair defects inside a theme, builder or plugin |
| Independently maintained fork | Slow to establish correctly | Full control, manual updates | Security, compatibility and merging become your responsibility |
Documented case: when Elementor Core and Pro do not advance together
This is not a client story or an invented scenario: it is an error and recovery path described by Elementor’s official support.
Version dependency
One visible feature, at least two packages to keep compatible
Elementor documents a specific fatal error that can appear when Elementor Core is updated but Elementor Pro is not. The website may go down and the administration area may be unavailable.
The stated solution is to remove or disable Elementor Pro through FTP, regain access and install an updated compatible version. For other post-update issues, Elementor also documents rollback.
-
01
The update starts
One component changes version while the other remains behind.
-
02
The internal contract no longer matches
The Pro component calls a method that the installed combination does not expose as expected.
-
03
The error becomes fatal
This is not a visual detail: it can prevent both the website and WP Admin from loading.
-
04
Access outside the CMS is required
The official procedure requires FTP or a file manager to disable the component blocking administration.
-
05
Versions are realigned
A compatible release is installed, or the system returns to an earlier version after a backup has been prepared.
-
06
Then the entire website is tested
Restoring WP Admin does not prove that forms, templates, checkout, caching and the frontend are all correct.
Case reconstructed from the official procedure, updated on 18 May 2026: fatal error after installation or update.
My experience with Yoast: diagnosing does not mean being able to fix
On more than one occasion I found JavaScript errors, prepared a diagnosis and urgently contacted the vendor. The operational answer was to wait for a later release.
The point is not to blame Yoast: all software contains bugs and every vendor must assess impact, priority, compatibility and release timing. Support can acknowledge a problem without being able to deliver an immediate fix.
From the company’s perspective, however, the outcome is unchanged: the person managing the website knows the cause but does not control the fix calendar. A patch to plugin files may solve the urgency while creating a change destined to be overwritten.
That is the difference between diagnostic expertise and operational control. You can know exactly what is wrong and still depend on another team’s decision.
Diagnosis
Error reproduced, console and conditions identified: the problem is no longer generic.
Report
The vendor receives useful information and can confirm that the defect belongs to the component.
Wait
The fix enters the vendor’s roadmap, not that of the business suffering the problem.
During an emergency, the task is not to find blame: it is to restore service
A serious plan separates containment, recovery and the permanent correction.
Collect evidence
Time, latest change, logs, stack trace, console, HTTP status, affected pages and users.
Protect data and access
If compromise is possible, preserve logs, restrict access and do not confuse recovery with destroying evidence.
Contain the component
Disable, isolate or restrict only what causes harm, while assessing the effect on business functions.
Restore a known version
File and data rollback must return the system to a verified state, not simply to a screen that opens.
Decide who can correct it
Vendor, integrator or internal team need explicit responsibilities and timings; “we opened a ticket” is not recovery.
Test critical journeys
Leads, sales, login, editor, payments, email, indexing and caching must be verified according to the website’s role.
Real recovery time
The value of technology is not visible only when it works. It appears in how quickly an accountable person can understand the failure, intervene without side effects and prove that service integrity has been restored.
A bespoke website is not dependency-free: it is designed to govern dependencies
PHP, servers, browsers, web standards, selected libraries and external services still exist. The difference lies in scope and responsibility.
Control, not isolation
Reduce the dependency surface and own the application code
In my method every layer must justify its presence. Common features enter the GLP CORE as versioned components; specific features are integrated into the project without turning every requirement into an independent plugin.
- Project code that is readable, versioned and directly changeable
- External dependencies limited to what creates concrete value
- Semantic HTML and server-side content not trapped in a visual editor
- Builds, tests, commits and selective deployments that trace every change
- Rollback and diagnosis based on the project rather than accidental component combinations
- One person responsible for the complete output, not merely their own module
CMS and bespoke websites: the difference emerges over the lifecycle
This table does not declare a universal winner. It shows where responsibility sits when the website must change or recover from a problem.
| Situation | CMS ecosystem | Controlled bespoke | Business question |
|---|---|---|---|
| New feature | Ready-made plugin or extension combination | Feature designed within the existing scope | Do you need initial speed or long-term coherence? |
| Urgent error | Diagnosis distributed across several vendors | Responsibility concentrated on the project | Who can release the fix today? |
| Update | Matrix across core, theme, plugins and runtime | Declared dependencies and tests of affected code | Do tested staging and rollback exist? |
| External vulnerability | Wait for patch, mitigate or replace | Direct fix when owned code is affected | How long is the exposure window? |
| Licence or service discontinued | Feature, updates or support may change | Application code remains in the project | What stops working without renewal? |
| Technology change | Content may export; the system often needs rebuilding | Portability depends on documentation and standards used | Do you own data, files, accounts and the URL map? |
To choose the technology, also read WordPress or a bespoke website ; for attack surface, see the website security guide.
The hidden cost is not the plugin price
The total includes what you pay, what you must maintain and what you lose when the website does not do its job.
Visible costs
Hosting, theme, licences, renewals, premium support, backups, security, staging and supporting tools.
Maintenance time
Updates, tests, incompatibilities, logs, tickets, renewals and coordination among supplier, host and vendors.
Incident cost
Urgent diagnosis, downtime, recovery, data restoration, lost orders and out-of-hours work.
Opportunity cost
Delayed features, slowed campaigns, insufficient performance and business decisions adapted to platform constraints.
TCO, not entry price
An inexpensive plugin can be an excellent purchase. It becomes costly when the feature is critical and the business has neither control over the code nor a practical exit path.
To estimate licences, maintenance and time over five years, use the WordPress total-cost calculator.
When WordPress or another CMS can remain the right choice
Recognising suitable cases makes the opposite choice more credible.
Frequent distributed publishing
A large editorial team needs roles, reviews, scheduling and day-to-day publishing autonomy.
A mature vertical feature
An established extension can provide more value than a rewrite when requirements and compromises genuinely match.
Short or experimental project
To validate a temporary idea, speed and initial cost may matter more than long-term system ownership.
An internal team capable of governing it
Inventory, staging, updates, security, backups and incident response turn the CMS from a shortcut into managed infrastructure.
When direct control is worth more than a ready-made ecosystem
Bespoke development gains value when the website is an operational asset intended to last and differentiate the business.
The website generates work or sales
Leads, bookings, catalogue or checkout make downtime and regressions a concrete business risk.
Performance and SEO are strategic
Structure, rendering and weight should follow real content rather than compensate for a general-purpose stack.
Specific integrations exist
APIs, flows, data and permissions should enter a coherent architecture instead of crossing several bridge plugins.
Security and privacy require minimisation
Reducing logins, exposed databases, scripts, endpoints and third parties may be more effective than adding corrective layers.
The project must evolve for years
Features and content should change without chasing a theme, builder or commercial plan.
Clear responsibility is needed
The business wants to know who owns the full output and can intervene, not which vendor will open the next ticket.
The decision in one sentence
I do not sell the impossible absence of dependencies
I design a deliberate reduction of the dependency surface and take direct responsibility for the code governing the website.
The difference is not being able to add a feature. It is being able to understand, correct and verify it without waiting for a chain of vendor roadmaps.
Checklist: who actually controls your website?
If many answers are unknown, the problem is not necessarily WordPress: it is the absence of technical governance.
-
01
Do you have a complete component list?
Core, theme, child theme, builder, plugins, add-ons, snippets, APIs, licences and server versions.
-
02
Do you know which features are critical?
Components do not have equal impact on sales, leads, data, SEO and internal activity.
-
03
Do you know owners and expiry dates?
Domain, hosting, licences, email accounts and services should belong to the business or be transferable.
-
04
Does trustworthy staging exist?
The test copy must represent enough configuration, data and journeys to expose real regressions.
-
05
Has the backup ever been restored?
An automatically generated file is not a strategy until you know it can restore website and data.
-
06
Do customisations survive updates?
Every change should live in extension points, child themes or controlled documented components.
-
07
Who decides during an incident?
Contacts, responsibilities, access, priorities and authority to disable a feature should be established in advance.
-
08
How long can you wait for a vendor?
A non-critical feature may wait; checkout, forms and vulnerabilities may need an immediate alternative path.
-
09
Can you export data and URLs?
Content, media, orders, users, metadata and the address map are required to change systems without losing the digital asset.
-
10
Do you know the three- or five-year cost?
Add licences, hosting, maintenance, incidents, internal hours, rebuilds and lost opportunities—not only the initial quotation.
How I turn dependency into a verifiable migration plan
I do not patch the old stack forever: I record what matters and rebuild the outcome without carrying over the technical debt.
GLP method
Recover the value, not the chain trapping it
A WordPress migration starts with an audit and separates useful content, URLs, data and features from the theme, plugins and configurations that created fragility.
- Inventory of pages, media, URLs, plugins, integrations, licences and critical issues
- Map of features to retain, simplify, replace or remove
- Baseline for SEO, performance, security, accessibility and conversions
- Bespoke rebuild with fewer dependencies and controlled shared components
- Redirects, canonicals, sitemap, structured data and tests before launch
- Traceable deployment, live verification and maintenance proportionate to the project
| Path | Scope | Price before tax |
|---|---|---|
| Migration audit | Analysis of the current WordPress website, dependencies, content, URLs, risks and action plan | €175 |
| Essential | Compact rebuild with up to four independent pages | €1,000 |
| Pro | Architecture, pages and features for a more substantial business website | from €2,500 |
| Essential e-commerce | Focused catalogue, product pages, basket and checkout without WooCommerce | from €4,500 |
For process, conditions and frequently asked questions, see the dedicated WordPress migration page. The final quotation depends on the content, integrations and actual approved scope.
Verified primary sources
Vendor and WordPress project documentation. The Elementor case is an official procedure; the Yoast episode is explicitly identified as personal professional experience.
-
WordPress — Plugin management and compatibilityOpen source
Declared or untested compatibility, updates and the varied nature of available extensions.
-
WordPress — Automatic plugin and theme updatesOpen source
Update configuration, backups and recovery capability when a release causes problems.
-
WordPress — Troubleshooting FAQOpen source
Disabling plugins through FTP and overwriting direct changes during updates.
-
WordPress Developer — Plugin dependenciesOpen source
Core class that reads requirements, dependants, unmet dependencies and circular dependencies.
-
WordPress Developer — Child themesOpen source
The intended method for separating theme customisation and reducing the risk of losing it during updates.
-
Elementor — Fatal error after installation or updateOpen source
Website unavailable, Core and Pro incompatibility, recovery through FTP and version realignment.
-
Elementor — Roll back to an earlier versionOpen source
Restoring an earlier release when an update causes problems and the need for a prior backup.
-
Yoast SEO 27.3 — Official changelogOpen source
A recent example of console, integration and security issues corrected through a later release.
-
WordPress — Updating WordPressOpen source
Backups, core files involved in an upgrade and the manual procedure when automatic updating fails.
Sources checked on 7 August 2026. Versions, procedures and commercial terms change: always verify the current documentation for the component actually installed before acting.
Frequently asked questions about WordPress, plugins and dependency
Direct answers about updates, patches, security, ownership, migration and bespoke websites.
Is WordPress always the wrong choice?
No. It can suit frequent editorial work, standard projects and organisations able to govern updates, compatibility, backups and security. It becomes risky when treated as a system that maintains itself.
Is a website with few plugins automatically secure?
No. Quality, exposure, configuration, maintenance and the value of affected features matter. Reducing components helps, but does not replace correct development and management.
Why is automatically updating everything not enough?
Updates reduce known risks but can introduce incompatibilities or regressions. Restorable backups, proportionate staging, tests of critical journeys and post-release monitoring are required.
Can I fix a plugin’s code myself?
Technically, often yes. If you edit vendor-distributed files, the next update may overwrite the patch. Official hooks and APIs are preferable; a fork means taking on future maintenance and security.
Does a child theme solve every dependency problem?
No. It protects correctly placed theme customisation, but does not automatically fix defects inside plugins, builders, WordPress or external services.
Does open source mean there is no vendor lock-in?
Code availability provides important freedom, but operational independence requires the skills and budget to maintain changes. Data, editors, shortcodes, builders and licences can still create exit costs.
Why can Elementor updates require FTP?
Elementor documents cases in which a fatal error prevents access to WP Admin. Recovery involves disabling or removing the component through FTP and realigning versions.
Does a bespoke website use no dependencies?
No. It depends at least on its language, server, browsers, standards and selected services. The professional objective is to reduce avoidable dependencies, document necessary ones and directly control application code.
How do I know whether my WordPress website is too dependent?
If you do not know the components, licences, account owners, compatibility, recovery procedure, incident owner and ability to export data and URLs, technical governance is missing regardless of plugin count.
Does leaving WordPress mean losing content and SEO?
No, when the migration inventories content and URLs, preserves what creates value, sets correct redirects and verifies canonicals, sitemaps, metadata, structured data and performance before and after launch.
How much does a migration assessment cost?
The migration audit costs €175 before tax and analyses the website, dependencies, content, URLs, risks and rebuild path. The new website quotation is defined against the approved scope.
How much does rebuilding without WordPress cost?
Current packages start with Essential at €1,000, Pro from €2,500 and Essential e-commerce from €4,500, before tax. Size, content, features, languages and integrations determine the final cost.
Next step
Does your website depend on too many components to remain governable?
The migration audit identifies features, content, URLs, risks and costs in the current chain. You can then decide with concrete evidence whether to keep it or rebuild the website to measure.