DEV Community: Mecanik Dev

WordPress 7.0 and the AI Client in Core

Norbert E. Boros — Thu, 05 Nov 2026 19:00:00 +0000

WordPress 7.0 shipped on 20 May 2026 under the release name Armstrong, six weeks later than the date on the original 2026 schedule, and it is the most consequential core release for agencies since the block editor. The headline is that core can now talk to generative AI models. The detail that matters more is that core now defines how a plugin is supposed to talk to them, which quietly changes what every plugin on the site is allowed to assume about its own territory.

For an editor, the visible changes are modest. There is a command palette, a tidier dashboard, a font management screen and better revisions. For anyone who maintains sites professionally, the important changes sit underneath the admin: a credential store in the options table, a registry of things the site can do, and a REST surface that lists them. None of it is optional, because it arrives with core rather than with a plugin somebody chose.

This is the practitioner's read. What actually landed, what was pulled twelve days before release and why, what the update will and will not break, and what to say to a client who has just read a headline about AI going into WordPress.

Should you update? Yes, but go to 7.1 rather than stopping at 7.0. WordPress 7.1 shipped on 19 August 2026 and 7.0 has four maintenance releases behind it. The AI features are inert until an administrator saves a provider key under Settings then Connectors, so the update on its own sends none of your content anywhere. The real risk in this update is ordinary plugin and theme compatibility, not the AI.

What Actually Shipped in WordPress 7.0

The release is named after Louis Armstrong, following the project's convention of naming major versions after jazz musicians. The release announcement credits more than 875 contributors and over 420 enhancements and fixes.

The list of what landed is short enough to be useful. Core gained an AI Client, a provider-agnostic PHP interface for sending prompts to generative models. It gained a Connectors screen under Settings, where an administrator stores provider credentials. It gained the JavaScript half of the Abilities API, whose PHP half had already shipped in 6.9.

On the editorial side there is a command palette on Ctrl+K or Cmd+K, a modernised dashboard, a dedicated font management page, visual scrubbing through revisions, and new Heading, Breadcrumbs and Icons blocks alongside a lightbox slideshow for galleries.

What did not land was the feature the whole release had been built around. Real-time collaborative editing was removed twelve days before launch. That absence, and the reason behind it, tell you more about the current state of core than the feature list does.

Why the date moved

The release was originally scheduled for 9 April 2026. It slipped to 20 May because collaborative editing was not ready and the project would not ship it as it stood. The path forward post is explicit that the delay existed "to allow more time to address testing feedback about the implementation of real-time collaboration", and the cycle went back into beta while keeping release candidate version numbers for technical reasons.

That is unusual. A major release returning to beta after reaching RC is a strong signal, and it was the right call.

The AI Client: Core Ships the Abstraction, Not the Model

The single most important architectural fact about WordPress 7.0 is that core does not include an AI model, an API key, or a relationship with any vendor. The AI Client dev note states plainly that "WordPress Core does not bundle any AI providers directly".

What core ships is a consistent PHP interface. A plugin calls wp_ai_client_prompt(), which returns a WP_AI_Client_Prompt_Builder object, chains configuration such as using_temperature() or using_model_preference(), and finishes with generate_text() or generate_image(). Errors come back as WP_Error, requests go through the WordPress HTTP transport, and the whole thing is wired into the hooks system.

The practical effect is that a plugin author no longer writes an HTTP client, a retry loop, a key storage screen and a settings page for every model vendor. They describe what they want and core routes it.

That is a genuine reduction in duplicated code. It is also a centralisation of trust, which is the part worth thinking about before you switch anything on.

What a connector is

A connector is the registered relationship between your site and an external service. In 7.0 the only connector type is AI providers, and there are three flagship provider plugins covering Anthropic, Google and OpenAI, each installed separately.

The Connectors API dev note describes how credentials resolve. A key can come from an environment variable, a PHP constant, or a database setting, checked in that order, with option names following the pattern connectors_ai_{$id}_api_key.

One detail deserves attention from anyone responsible for a site. The dev note says API keys stored in the database "are not encrypted but are masked in the user interface", with encryption tracked as follow-up work. If you set a key through the admin screen, it sits in wp_options in plain text, and every backup of that database now contains a billable credential.

What this means if you do not write code

For a site owner the change is simpler than it sounds. Nothing generates, summarises or rewrites anything until two things are true: a provider plugin is installed, and somebody has pasted a working key into Settings then Connectors.

Until then the AI Client is a dormant library. Updating to WordPress 7.0 does not send your posts to a model, does not create an account anywhere, and does not incur a bill.

What it does do is lower the barrier for the next plugin you install. A plugin that previously had to ask you for a key can now find one already configured on the site and use it. That is convenient, and it is exactly the thing to write a policy about before it happens by accident.

The Abilities API and Why Plugin Design Changes

The Abilities API is the piece that will still matter in three years, and it has nothing inherently to do with AI. It is a registry. A plugin registers a named unit of functionality with wp_register_ability(), in the form namespace/ability-name, with a human-readable description, JSON Schema for its inputs and outputs, an execute callback and an optional permission callback.

The official documentation shows the permission callback as an ordinary capability check, for example returning current_user_can( 'manage_options' ). That is the whole security model, and it is only as good as the plugin author's judgement.

Once abilities exist, other things can enumerate them. A model can be handed a list of what this specific site can do, in schema form, and can call one. So can a client-side command palette, which is why the JavaScript half of the API landed in the same release as the palette.

The design consequence for plugin authors is real. A feature that used to be reachable only through your own admin screen, with your own nonce and your own form, is now something you may be expected to expose as an ability with a machine-readable contract. That is a different threat surface and a different documentation burden.

What changed in 7.1

WordPress 7.1 tightened the registry rather than expanding it. The 7.1 abilities dev note adds validation filters wp_ability_validate_input and wp_ability_validate_output, an action wp_ability_invoked that fires at the start of execution, and a public metadata flag controlling whether an ability is discoverable over REST at /wp-json/wp-abilities/v1/abilities.

That dev note also carries the sentence every logging plugin author should read. The invocation hook receives raw, unnormalised input, and developers "should avoid logging input indiscriminately, because it may contain credentials, personal information, or other sensitive data".

Real-Time Collaboration and the Table It Needed

Collaborative editing is built on Yjs, a conflict-free replicated data type, with a sync provider abstraction. Core ships an HTTP polling provider by default, chosen over WebSockets because it works on any host, and plugins can swap the transport through a filter.

The problem was never the merge algorithm. It was where the sync data lived. The original implementation persisted it in post meta, which is the obvious choice in WordPress and the wrong one for data that changes several times per second.

Post meta writes fire cache invalidation. With an editor open, sync data was being written continuously, so every write cleared cached queries for that post. In practice a single person editing a page could keep the site's persistent object cache flushing for the duration of the session.

That is a good general lesson about post meta. It is a key value store attached to the cache lifecycle of the content it hangs off, and it is fine for attributes that change when the post changes. It is not a scratch space for high-frequency state.

The measured fix, and the decision

Contributors tested storage strategies across eight hosting environments. The performance analysis concluded that a dedicated table backed by transients was around 52% faster than the existing implementation, and a plain dedicated table around 37% faster. With a persistent object cache present, both transient-backed strategies dropped to a single database query per dispatch.

The custom table with transients was chosen. Then, on the same day, the feature was pulled.

The removal notice cites "concerns around surface area, race conditions, server load, memory efficiency, and recurring bugs found through fuzz testing", and says the decision was made "in service of shipping a stable and reliable WordPress 7.0 release for our users".

Where it stands now

It did not ship in 7.1 either. The 7.1 field guide states that real-time collaborative editing "received extensive testing and feedback during the WordPress 7.1 cycle, but it is not enabled in the final release".

Notes, which is the related but separate feature for leaving block-level comments, did ship and was improved in 7.1 with rich text formatting and @ mentions. If a client asks for Google Docs style co-editing in WordPress, the honest answer today is that Notes covers the review workflow and simultaneous typing is still not in core.

The Admin Changes and the Tickets They Generate

Two changes will produce support requests, and neither is a bug.

The command palette on Ctrl+K or Cmd+K is genuinely fast once learned, but Ctrl+K is the keyboard shortcut for inserting a link in many editors, and some users will report that link insertion has broken. It has not; focus context decides which handler wins.

The modernised dashboard is the larger one. Any client whose staff were trained on screenshots now has out of date training material, and any plugin that injected markup into admin screens by assuming particular classes or DOM structure may render oddly. This is cosmetic rather than functional, but it arrives on the day of the update, on every site, for every user, which makes it the most visible part of the release to the people who are not developers.

Budget an hour per client for a short written note with new screenshots before you update anything. It is cheaper than the same explanation given fifteen times by email.

The Compatibility Question That Actually Matters

The version numbering suggests a breaking release. The PHP requirements do not. As the PHP support clarification sets out, the minimum supported PHP version is 7.4 since WordPress 7.0, and the minimum recommended version remains 8.3. Support for PHP 7.2 and 7.3 was dropped in this release.

The clarification also retired the old "beta" label for newer PHP versions, and records full support for PHP 8.5 in WordPress 6.9 and 7.0.

The gap between supported and sensible is the point. PHP 7.4 reached end of life in November 2022, so a site that only just clears the minimum is running an interpreter that has had no security fixes for close to four years. If your hosting is still on 7.4 in 2026, the WordPress version is not your most urgent problem.

Breakage in practice follows a predictable pattern. Abandoned plugins fail first, particularly anything that manipulates the admin DOM or the editor iframe. Custom themes with hard-coded admin styling look wrong. Page builders that ship their own React bundles are the usual source of white screens in the editor, and they are also usually the fastest to patch.

A concrete update procedure

Stage it. Clone production, including the database, to an environment that is not indexable and not sending email. Nothing below is worth doing on a live site.

Record the baseline. Note the PHP version, the plugin and theme list with versions, and the current WordPress version. Take screenshots of the two or three admin screens the client uses daily.

Update WordPress alone first. Leave plugins and themes untouched, then walk the front end, the post editor, the site editor, WooCommerce checkout if present, and any custom admin screens. A failure here belongs to core or to an incompatible extension, and separating that from a plugin update is the whole reason to do it in this order.

Then update plugins in small batches, retesting between batches, so a regression has a short list of suspects.

Check error logs rather than eyeballing pages. PHP notices from a deprecated call do not always render visibly and will fill a log quietly for months.

Leave the Connectors screen empty. Ship the update with no AI provider configured, and treat enabling one as a separate, deliberate change with its own approval. Our WordPress security hardening checklist covers the surrounding controls, and the performance audit guide covers what to measure afterwards.

Governance: What a Connector Is Permitted To Do

Here is the question that the abilities layer creates and that no plugin author can answer for you. A third party plugin can register an ability that reads customer records, exports users, or edits published content, and a model with access to the registry can call it. The permission callback is a capability check, so the model acts with the permissions of whoever is signed in.

If that person is an administrator, the model can do administrator things. That is not a defect in the design; it is the design working as documented. It does mean the decision about which connectors exist on a site is a data protection decision, not an IT preference.

Content in a CMS is rarely just marketing copy. Comments, form submissions, order records and user profiles are personal data, and sending them to an external model is a processing operation you have to be able to justify. The ICO's guidance on AI and data protection sets out the accountability and transparency expectations, including demonstrating data protection by design and keeping governance proportionate to the use.

The practical minimum for a client site is a short written policy: which connectors are permitted, who may add one, which abilities are exposed publicly over REST, and what the retention position is with the provider. Write it before somebody pastes a key in, because afterwards it is an incident report rather than a policy.

What Is Queued Next

WordPress 7.1 arrived on 19 August 2026 with responsive styling controls in Global Styles, a persistent admin bar across editors, a proper media editing modal, Playlist and Tabs blocks, and the Notes improvements already mentioned. It also completed the move to an iframed post editor, including for sites registering legacy meta boxes, which is the change most likely to expose an old plugin.

WordPress 7.2 is planned as the final major release of 2026. The 7.2 release page puts the final release in the window of 8 to 10 December 2026, with betas from late October. That schedule is planned rather than shipped, and this project has already moved one major release date this year.

Collaborative editing remains the obvious candidate for a future release, but it has now missed two, and nobody should promise a client a date for it.

What This Changes Commercially

Three client conversations change, and only one of them is about AI.

The first is the update conversation. WordPress 7.0 and 7.1 are worth charging for as a managed update with a staging pass, because the iframed editor and the admin redesign genuinely surface old extensions. Selling that as a fixed-price package with a written test plan is more honest and more profitable than absorbing it into a retainer and discovering a broken page builder at 6pm.

The second is governance. Connector policy, ability review and credential handling are billable advisory work that did not exist before May 2026, and they suit an agency far better than they suit an in-house marketing team.

The third is build work. The AI Client removes the boring half of building an AI feature into a site, which lowers the price of the plumbing and raises the value of knowing what is worth building. If you are weighing that against a bespoke build, our comparison of WordPress and custom development covers where the line usually falls, and our notes on WordPress developer rates cover what the work should cost.

Mecanik handles core version upgrades, connector governance and AI feature work as part of our WordPress development and AI integration services. The pattern we see is consistent: the update itself is routine, and the expensive surprises come from extensions nobody had reviewed in three years.

Related reading

Frequently Asked Questions

When was WordPress 7.0 released and why was it delayed?
WordPress 7.0 "Armstrong" was released on 20 May 2026, six weeks after the 9 April date on the original schedule. The delay was to address testing feedback on the real-time collaborative editing implementation, and the cycle returned to beta after reaching release candidate. Collaborative editing was ultimately removed from the release on 8 May 2026.

Does WordPress 7.0 send my content to an AI provider?
No. Core ships an AI Client but bundles no AI providers, no models and no API keys. Nothing is sent anywhere until an administrator installs a provider plugin and saves a working credential under Settings then Connectors. Until that happens the AI Client is a dormant library that costs nothing and transmits nothing.

What is the Abilities API for?
It is a registry that lets a plugin declare a named unit of functionality with JSON Schema inputs and outputs, a permission callback and an execute callback. Other software, including AI models and the command palette, can then enumerate what a site can do and call it. The PHP half shipped in WordPress 6.9 and the JavaScript half in 7.0.

What PHP version does WordPress 7.0 require?
The minimum supported version is PHP 7.4 since WordPress 7.0, which dropped support for PHP 7.2 and 7.3. The minimum recommended version remains PHP 8.3. Since PHP 7.4 reached end of life in November 2022, running only the minimum means running an unsupported interpreter, so treat 8.3 or higher as the real requirement.

Is real-time collaborative editing available yet?
Not in core. It was removed from WordPress 7.0 twelve days before release over concerns about race conditions, server load and memory efficiency, and it is not enabled in WordPress 7.1 either. The separate Notes feature, which allows block-level comments with mentions, did ship and covers review workflows rather than simultaneous typing.

CMS Migration Without Losing Your Traffic

Norbert E. Boros — Thu, 05 Nov 2026 07:00:00 +0000

A CMS migration is one of the few projects where the technical work can go perfectly and the outcome still be a disaster. The site launches on time, looks better, loads faster, and traffic falls by half, because a few hundred URLs changed shape and nobody built the map.

The traffic loss is not caused by the new platform. It is caused by discontinuity: addresses that used to resolve now do not, pages that used to be identifiable now look new, and accumulated history attached to old URLs has nowhere to go.

The single decision that determines the outcome: are you keeping the URL structure? If yes, the migration is mostly a content and template exercise and the risk is modest. If no, every changed address needs a redirect to its specific equivalent, and the completeness of that map is what decides whether the migration is invisible or expensive. There is no third option where the URLs change and it works out.

What a CMS Migration Actually Breaks

URLs, which is the big one. Different platforms have different conventions for paths, pagination, categories and dates, and adopting the new platform's defaults silently rewrites every address on the site.

Metadata. Titles and descriptions written over years frequently do not survive an export, and the new platform generates them from templates instead. This is easy to miss because the pages look fine.

Structured data. Markup added by a plugin on the old platform disappears with the plugin, and the new equivalents rarely emit identical output. Our guide to how AI search engines read schema markup covers what needs to survive.

Internal links. Body content full of absolute links to old paths will keep pointing at them, which after a URL change means every one of them travels through a redirect at best.

Images and media. Different storage paths, different file names, and alternative text that lived in the old database and was not in the export.

Anything a plugin was doing. Redirects configured over years, canonical rules, feed formats, and functionality nobody documented because it was a checkbox.

Inventory all of this before the migration, not after. The list of what the old platform quietly does for you is always longer than expected.

The Redirect Map Decides Everything

If URLs change, this is the deliverable that matters, and it needs to be complete rather than nearly complete.

Build the source list from more than one place. A crawl of the live site finds what is linked. Your analytics and Search Console find pages that receive traffic but may be orphaned. Server logs find what is actually requested, including by other sites linking to you. Any single source misses things, and the pages missed are disproportionately the old ones with links attached.

Map each old URL to its specific new equivalent. Not to the homepage, and not to a category page, because a redirect to something that does not answer the original request is treated as a soft error and passes little value. Google's site move documentation sets out the mapping it expects. If genuinely nothing corresponds, returning a not-found response is the honest answer and better than a misleading redirect.

Use permanent redirects, keep chains to a single hop by pointing old addresses directly at final destinations, and remember that redirect rules are evaluated in order, so a broad pattern placed above a specific rule will swallow it.

Then test the map before launch, against the full list rather than a sample.

Before You Switch

Crawl and archive the old site. A complete record of every URL with its title, description, canonical, status code and word count. This is your comparison baseline and you cannot produce it after the fact.

Export and verify the content. Check counts, not just that the export ran. Missing categories, dropped custom fields and truncated posts are all common and all silent.

Stage it on a blocked environment. A staging site that gets indexed creates duplicates of your entire site, which is a worse problem than the one you were solving.

Check the new templates emit what the old ones did. Titles, descriptions, canonicals, structured data, hreflang if you run multiple languages, as covered in our multilingual SEO guide.

Plan the timing. Not before your busiest period, and not on a Friday. You want several working days of attention immediately afterwards.

After You Switch

The first forty-eight hours matter more than the following month, because that is when a fixable error is still cheap.

Watch server logs for not-found responses. This is the fastest way to find the URLs your map missed, and it finds them from real requests rather than from your assumptions. Submit the new sitemap, and check that crawling is actually happening rather than assuming it.

Compare against the baseline crawl. Every URL that was indexable before should now either resolve or redirect somewhere specific. Any that does neither is a hole.

Expect a dip. Some fluctuation for a few weeks is normal even on a well-executed migration, because the new addresses have to be recrawled and reassessed. What is not normal is a sustained fall that does not recover, and that almost always traces back to redirects that were missed or pointed somewhere generic.

Keep the redirects permanently. They are not a transitional measure, they are the only thing connecting years of accumulated links to your current pages, and removing them a year later reproduces the original loss.

Mecanik handles migrations of this kind as part of our website development work. The pattern is consistent: the platform change is routine, and the difference between a good outcome and a bad one is entirely in the completeness of the map.

Related reading

Frequently Asked Questions

Why does traffic drop after a CMS migration?
Almost always because URLs changed and the redirect map was incomplete. Old addresses stop resolving, so years of accumulated links and crawl history have nowhere to go. The platform itself rarely causes the loss; discontinuity between old and new addresses does.

Should I keep my URL structure when changing CMS?
If you can, yes. Keeping the structure reduces the migration to a content and template exercise with modest risk. Changing it means every altered address needs a redirect to its specific equivalent, and the completeness of that mapping determines whether the migration is invisible or expensive.

Where do I get the list of URLs to redirect?
From several sources, because each one misses things. A crawl of the live site finds linked pages, analytics and Search Console find pages receiving traffic that may be orphaned, and server logs find what is actually requested including from external links. Pages missed by a single source tend to be old ones with links attached.

Can I redirect old pages to the homepage?
No. A redirect to something that does not answer the original request is treated as a soft error and passes little value. Map each old URL to its specific equivalent, and where nothing genuinely corresponds, returning a not-found response is more honest and more useful than a misleading redirect.

How long should migration redirects stay in place?
Permanently. They are not a transitional measure but the only connection between years of accumulated inbound links and your current pages, so removing them a year later reproduces exactly the traffic loss the migration was supposed to avoid.

Password Storage: What to Use in 2026

Norbert E. Boros — Wed, 04 Nov 2026 19:00:00 +0000

Password storage is one of the few areas in software with a genuine right answer, published, maintained and free. It is also one of the most consistently got wrong, because the wrong answers were correct at some point and nobody revisited them.

The failure is rarely exotic. It is a system built in 2016 against advice that was current in 2012, still running, still accepting logins, and nobody has looked at that function since the person who wrote it left.

If you take one thing: use Argon2id, and if you cannot, use bcrypt. Everything else in this article is detail. A general-purpose hash such as SHA-256 is not a password hash regardless of how many times you apply it, because its speed is a design goal, and speed is precisely what you are trying to deny an attacker who has your database.

Password Storage Has Exactly One Correct Shape

Store a hash produced by a deliberately slow, memory-hard function, with a unique random salt per password, using parameters tuned to your hardware.

The OWASP password storage guidance states the current recommendations precisely, and they are worth quoting as numbers rather than as principles.

Algorithm	Recommended parameters	When to use
Argon2id	19 MiB memory, 2 iterations, 1 degree of parallelism	First choice
scrypt	N=2^17 (128 MiB), r=8, p=1	If Argon2id is unavailable
bcrypt	Work factor 10 or more, 72 byte password limit	Legacy systems
PBKDF2-HMAC-SHA256	600,000 iterations	Where FIPS-140 compliance is required

Two notes on that table. The Argon2id figure is a minimum, and higher memory with fewer iterations is an equivalent trade, so a configuration of 47 MiB with 1 iteration provides comparable security to the baseline. And bcrypt's 72 byte limit is a real truncation, not a validation rule: anything past 72 bytes is silently ignored, which matters if you accept long passphrases or pre-hash the input.

These parameters are revised as hardware improves. Read the source rather than this table when you implement.

A Salt Is Not Optional and Not Sufficient

A salt is a unique random value stored alongside each hash. Its purpose is narrow and important: it ensures two users with the same password produce different hashes, which defeats precomputed rainbow tables and stops an attacker cracking one password and getting every account that shared it.

What a salt does not do is slow anybody down. An attacker with your database has the salts too, because they must be readable to verify a login. Salting alone against a fast hash means an attacker attacks each password individually at enormous speed, which is exactly the situation you were trying to avoid.

The slowness has to come from the algorithm. That is the whole point of a memory-hard function: it deliberately consumes resources so that an attacker with specialised hardware gains far less advantage than they would against a fast hash.

A pepper, a secret value applied to every password and stored outside the database, adds a real layer, because a database dump alone becomes insufficient. It also adds an operational burden, since rotating it requires rehashing on next login, and losing it locks out every account. Worth it for high-value systems and skippable for most.

The Mistakes That Survive for Years

A fast hash with a salt. SHA-256 with a salt looks responsible and is not. Speed is the vulnerability.

Encryption instead of hashing. Encryption is reversible by design, which means a key exists, and anybody who obtains it obtains every password in plaintext. Passwords should never be recoverable, only verifiable.

Work factors set once and never raised. A bcrypt cost chosen in 2015 is substantially weaker against 2026 hardware. Raise it on next successful login, when you have the plaintext momentarily and can rehash.

Truncation or character restrictions. A maximum length below about 64 characters, or a ban on particular characters, usually signals that the password is being stored in a way that cares what it contains. It should not; you are hashing it.

Comparison that leaks timing. Verification must use a constant-time comparison. Standard library functions do this and hand-rolled equality checks do not.

Logging the password. It reaches an error log, a request trace or a monitoring system, and then it is in three places with weaker access controls than the database.

Migrating an Existing System

You cannot rehash what you do not have, because you only hold hashes. The workable approach is to upgrade at login.

When a user authenticates successfully, you have their plaintext password in memory for a moment. Verify against the old hash, then immediately compute a new one with the current algorithm and replace the stored value. Over a few months most active accounts migrate with no user-visible change.

Track the algorithm per record so both can coexist, and set a date after which remaining old hashes are invalidated and those users must reset. Dormant accounts with weak hashes are exactly the ones an attacker wants.

Do not wrap the old hash in the new algorithm as a shortcut. It works, and it leaves the weak hash as the effective security boundary while looking modern.

What Matters More Than the Algorithm

Correct hashing protects you when the database leaks. It does nothing about the more common attack, which is somebody logging in with a real password obtained elsewhere.

Rate limiting on authentication, multi-factor availability, checking new passwords against known-breached lists, and alerting on credential stuffing patterns all address that, and all matter more day to day than the choice between Argon2id and bcrypt. The API security controls are the same family of problem.

Both are worth doing, and the order is worth being honest about: get the hashing right once because it is cheap and permanent, then spend the ongoing effort on the login path, which is where the attacks actually arrive. Mecanik reviews both as part of our application security work.

Related reading

Frequently Asked Questions

What is the best password hashing algorithm in 2026?
Argon2id, at a minimum of 19 MiB of memory, 2 iterations and 1 degree of parallelism. If it is unavailable, scrypt at N=2^17, r=8, p=1 is an alternative, bcrypt with a work factor of 10 or more suits legacy systems, and PBKDF2-HMAC-SHA256 at 600,000 iterations covers FIPS-140 requirements.

Is salting passwords enough?
No. A salt ensures identical passwords produce different hashes, defeating rainbow tables and stopping one cracked password unlocking every account that shared it. It does not slow an attacker down, because salts must be readable to verify logins. The slowness has to come from a deliberately memory-hard algorithm.

Why not use SHA-256 for passwords?
Because its speed is a design goal, and speed is exactly what you are trying to deny an attacker holding your database. A general-purpose hash is not a password hash regardless of how many times it is applied or whether it is salted.

Does bcrypt have a password length limit?
Yes, 72 bytes, and anything beyond that is silently truncated rather than rejected. This matters if you accept long passphrases or pre-hash input before passing it to bcrypt, since the truncation happens without any error to indicate it.

How do I upgrade password hashes without user passwords?
At login. When a user authenticates you hold their plaintext momentarily, so verify against the old hash and immediately rehash with the current algorithm. Track the algorithm per record so both coexist, and set a date after which remaining old hashes are invalidated and those users must reset.

Disaster Recovery for Small Software Teams

Norbert E. Boros — Wed, 04 Nov 2026 07:00:00 +0000

Disaster recovery in a small team is usually one line in a document nobody has opened: backups are enabled. That statement is true and it is not an answer, because it says nothing about how old the data would be, how long the restore takes, or whether anyone has ever performed one.

The gap between having backups and being able to recover is where most outages become incidents. A backup that exists, is current, and has never been restored is a hypothesis, and the moment you test it is a bad moment to discover it was wrong.

Two numbers turn this from an opinion into a plan. How much data can you afford to lose, and how long can you afford to be down? Those are your recovery point and recovery time objectives. Until somebody in the business states them, every technical argument about backup frequency is unresolvable, because there is no criterion to argue against.

RPO and RTO in Plain Terms

Recovery point objective is how much data you can lose. Nightly backups mean an RPO of twenty-four hours: a failure at 5pm loses everything since the previous night. If that is unacceptable, the backup schedule is wrong, and no amount of care elsewhere compensates.

Recovery time objective is how long you can be down. This includes everything: noticing, deciding, provisioning, restoring, verifying and switching traffic back. Teams estimate the restore step and forget the other five, which is why real recoveries take several times longer than expected.

Both are business decisions rather than technical ones, and both cost money as they tighten. An RPO of five minutes needs continuous replication. An RTO of one hour needs infrastructure that can be rebuilt automatically, because nobody is going to configure a server by hand inside an hour under pressure.

The productive conversation is the trade. Tell the business what each level costs and let it choose, rather than picking a number in engineering and hoping it matches expectations that were never stated.

An Untested Backup Is Not a Backup

The failures that hurt are rarely the absence of backups. They are backups that turned out to be unusable.

Common causes, all of which are only visible on restore: the job has been failing silently for weeks because nobody watches success as well as failure; the dump captured the schema but not the data, or a subset of tables somebody added to an exclusion list; the file is encrypted with a key stored on the machine that died; the backup lives in the same account or region as the thing it protects.

That last one matters more than it used to. A backup in the same environment as production is protected against hardware failure and against nothing else. It does not survive an account compromise, an accidental deletion at the account level, or ransomware that reaches everything the same credentials can reach.

The only way to know a backup works is to restore it. Schedule it, do it quarterly at minimum, and time it. That timing is your real RTO, as opposed to the one in the document.

What Disaster Recovery Has to Cover

Data is the obvious part and rarely the slow part. The things that extend recoveries are usually the ones nobody listed.

The database, which everybody remembers. Uploaded files, which live somewhere separate and often have no backup at all. Configuration and secrets, which frequently exist only on the running machine. DNS and certificates, which cannot be recreated quickly if the account holding them is the thing you lost. The infrastructure itself, meaning the servers, networks and rules, which is fast to rebuild if it is defined as code and slow if it was clicked into existence.

And the knowledge of how it all fits together, which is the single largest determinant of recovery time in a small team. A system one person can rebuild from memory has a recovery time equal to that person's availability, which is not a plan.

Write the inventory before the plan. Most teams discover at least one component with no backup at all while making the list, and finding it that way is considerably cheaper than the alternative.

A Plan That Fits on One Page

Long documents do not get read during an incident. Aim for something a tired person can follow at three in the morning.

It needs: who decides that recovery has begun, because hesitating over whether this counts as a disaster is a common source of delay. Where the backups are and how to reach them, including credentials that do not depend on the failed system. The restore steps in order, specific enough to follow without improvisation. How to verify it worked, which means a concrete check rather than the site appearing to load. And who to tell, internally and externally.

Keep it somewhere that survives the failure. A recovery plan stored only in the system it recovers is a recurring and entirely avoidable mistake.

The same reasoning applies to access. If one person holds the credentials for the hosting account, your recovery time is bounded by whether they answer the phone. Our Linux server hardening guide covers the access controls this depends on.

Proportionate, Not Perfect

A small team does not need a hot standby in a second region. The cost is real and the complexity introduces its own failure modes.

What most small teams need is considerably cheaper: backups in a separate account with credentials that production cannot use, a restore tested and timed on a schedule, infrastructure defined as code so it can be recreated without archaeology, and a one-page plan somebody has read.

That set covers hardware failure, accidental deletion, account compromise and ransomware, which is most of what actually happens. Everything beyond it is a decision about how much a further reduction in downtime is worth, and that is a question for the business rather than for engineering.

Mecanik reviews and builds this as part of our server security work. The first question is always the same, and it is not about technology: how long can you be down, and who decided that?

Related reading

Frequently Asked Questions

What do RPO and RTO mean?
Recovery point objective is how much data you can afford to lose, so nightly backups imply an RPO of twenty-four hours. Recovery time objective is how long you can afford to be down, including noticing, deciding, provisioning, restoring, verifying and switching traffic back. Both are business decisions, and both cost more as they tighten.

Why is an untested backup not a backup?
Because the failure modes are only visible on restore. Jobs fail silently for weeks when nobody monitors success as well as failure, dumps capture schema without data or omit excluded tables, encryption keys sit on the machine that died, and copies live in the same account as the thing they protect. Restore quarterly and time it.

Where should backups be stored?
In a separate account or region, with credentials production cannot use. A backup in the same environment protects against hardware failure and nothing else: it does not survive an account compromise, an account-level deletion, or ransomware that reaches everything the same credentials can reach.

What do people forget to include in disaster recovery?
Uploaded files stored separately from the database, configuration and secrets that exist only on the running machine, DNS and certificates held in an account that may itself be lost, infrastructure that was clicked into existence rather than defined as code, and the knowledge of how it fits together when only one person has it.

Does a small team need a hot standby?
Usually not. The cost is real and the added complexity brings its own failure modes. Backups in a separate account, a tested and timed restore, infrastructure defined as code, and a one-page plan somebody has read will cover hardware failure, accidental deletion, account compromise and ransomware, which is most of what happens.

Uptime SLAs That Mean Something

Norbert E. Boros — Tue, 03 Nov 2026 19:00:00 +0000

An uptime SLA looks like a promise and behaves like a refund policy. Suppliers know this. Customers frequently do not, and sign a service level agreement believing they have bought availability when what they have bought is a small discount in the event they do not get it.

That is not necessarily a bad deal. It is a different deal from the one most people think they are making, and the difference matters when the system is down and somebody asks what the contract says.

Three nines sounds close to perfect and allows 43 minutes of downtime a month. Four nines allows four. If your business can absorb a 43 minute outage during a working afternoon, 99.9% is fine and you should not pay for more. If it cannot, no number of nines helps, because the agreement pays you a credit rather than preventing the outage.

What an Uptime SLA Promises in Minutes

The percentages compress a large range into a small-looking difference. Written as time, the differences are obvious.

Availability	Downtime per year	Downtime per month
99%	3.65 days	7.2 hours
99.9%	8.76 hours	43.2 minutes
99.95%	4.38 hours	21.6 minutes
99.99%	52.6 minutes	4.32 minutes
99.999%	5.26 minutes	26 seconds

Two things follow. The step from 99.9% to 99.99% is a tenfold reduction in permitted downtime and typically a much larger increase in cost, because it requires redundancy that removes every single point of failure including the deployment process. And anything at or beyond five nines is below the time it takes a human to notice and respond, so it can only be met by systems that fail over without anybody involved.

Decide the figure from what an outage actually costs you per hour, not from what sounds impressive. Most business systems are honestly served by 99.9%.

Service Credits Are Not Compensation

The remedy in nearly every uptime SLA is a credit against future fees, usually a percentage of the monthly charge, and often capped at that month's total. Google Cloud's compute SLA is a representative example: credits only, claimed by the customer, capped.

That means the maximum you can recover is roughly what you paid for the period, which for most services is far less than an outage costs. A platform charged at a few hundred pounds a month cannot compensate a day of lost trading, and no supplier will agree to terms where it could.

Credits are also frequently claim-based rather than automatic. You must notice the breach, calculate it, and submit a claim inside a window, sometimes as short as thirty days. Suppliers are not obliged to volunteer that they missed the target, and most do not.

The practical conclusion is to stop treating the credit as protection. It is a signal of how seriously the supplier takes their own number. What protects you is architecture, and the recovery planning covered in our disaster recovery guide.

The Clauses That Decide Everything

What counts as downtime. Total unavailability, or degraded performance too? A service responding in thirty seconds is unusable and, under most definitions, available. Get a latency threshold into the definition if response time matters.

How it is measured, and by whom. Almost always by the supplier, using their own monitoring, from their own network. That is measurement of their infrastructure rather than of your experience. Agree the measurement point, and run independent monitoring regardless, because you cannot dispute a number you did not observe.

Exclusions. Planned maintenance is usually excluded entirely, which means a supplier can be unavailable for hours a month without breaching anything. Check how much notice is required and whether there is a cap. Also excluded: anything attributed to your configuration, to a third party, or to force majeure, and those categories can absorb a lot.

The measurement window. Monthly is standard and favours you. Annual measurement lets a supplier take a long outage and still meet the target, because a full day down is inside the yearly allowance at 99.9%.

Response versus resolution. Many agreements commit to responding within a period and say nothing about fixing. A one hour response and an unbounded fix is a common shape and is much weaker than it reads.

What to Ask For Instead

Push on the things that change behaviour rather than on the headline number.

A cap on planned maintenance, with notice and a window outside your peak hours. This often affects real availability more than the percentage does.

Status transparency, meaning a public status page and a commitment to post incidents promptly. A supplier who reports their own outages is telling you something about how they operate.

A defined escalation path with names or roles and times, so an incident does not begin with finding out who to contact.

Incident reports after significant outages, describing what happened and what changed as a result. This is the single most informative document a supplier can give you, and a reluctance to provide one is itself informative.

Termination rights on repeated failure. Chronic underperformance should let you leave without penalty. That right is worth more than any credit, because it is the only remedy proportionate to the harm.

If You Are the One Offering an SLA

Offer a number you can meet on your worst month, not your average one, and measure it yourself before you commit to it. Suppliers who commit to a figure they have never verified discover the gap in public.

Define planned maintenance honestly and keep to the window. Publish a status page. Write the incident report even when nobody asks, because the customers who stay are the ones who believe you know what happened.

And price the tiers by what they actually cost you to deliver. Four nines is not a marketing decision, it is redundant infrastructure, automated failover and a deployment process that cannot take the system down, and all of that has a bill attached. The operational groundwork in our CI/CD pipeline guide is where most of it starts.

Mecanik builds and operates systems under availability commitments as part of our server security work. The commitment worth making is nearly always the one you can hold during a bad week.

Related reading

Frequently Asked Questions

How much downtime does 99.9% uptime allow?
8.76 hours a year, or 43.2 minutes a month. The step to 99.99% cuts that to 52.6 minutes a year and 4.32 minutes a month, a tenfold reduction that typically costs far more than ten times as much to deliver because it requires removing every single point of failure including the deployment process.

Are service credits real compensation for downtime?
No. Credits are usually a percentage of the monthly fee and capped at that month's charge, so the most you can recover is roughly what you paid, which is far less than an outage typically costs. They are also often claim-based with a short window, and suppliers rarely volunteer that they missed the target.

What should I check in an uptime SLA?
What counts as downtime and whether degraded performance is included, who measures it and from where, what the exclusions cover, whether planned maintenance is capped and noticed, whether the window is monthly or annual, and whether the commitment is to respond or to resolve.

Why does the measurement window matter?
Monthly measurement favours the customer. Annual measurement lets a supplier take one long outage and still meet the target, because a full day of downtime sits inside the yearly allowance at 99.9%. The same failure would breach a monthly agreement outright.

What is worth negotiating instead of a higher number?
A cap on planned maintenance with notice outside peak hours, a public status page with prompt incident posting, a named escalation path with times, written incident reports after significant outages, and termination rights on repeated failure. The last is the only remedy proportionate to the harm.

Vibe Coding Technical Debt: Repair or Rebuild Your App?

Norbert E. Boros — Tue, 03 Nov 2026 07:00:00 +0000

Vibe coding technical debt becomes visible when a useful prototype turns into software that other people depend on. The app still looks convincing, but a small change breaks a different screen, nobody can explain which database is authoritative, and the person buying maintenance cannot tell whether the next proposal is a repair or a fresh start.

Repair a vibe-coded application when its important workflows can be understood, reproduced and improved without unacceptable disruption. Consider a staged replacement when structural problems prevent that progress, and include data migration and operational continuity in the comparison. Decide from evidence about the application, rather than from how its code was originally written.

Interest in building apps this way is real. In its vibe coding curriculum announcement, Google reports increased US search interest and describes planning, testing and debugging as part of the learning path. That is evidence of attention to the approach, not proof that your particular application is defective or that a rebuild will pay for itself.

This guide is for founders and operations teams with a working app and an uncertain next step. It offers a way to commission an assessment, compare proposals and preserve what the prototype has already taught you. The intake application below is hypothetical; it is not a customer case study or a measured return on investment.

Recognise vibe coding technical debt by its consequences

Technical debt is useful shorthand for design and implementation choices that make later changes more expensive or risky. Some choices are deliberate: a prototype may use a simple manual process while the team learns whether customers want the service. The problem is continuing to depend on that choice after its limits become material.

Look for observable consequences. Can a developer reproduce a reported failure? Can your team release a change without editing the live database by hand? Do records have stable identifiers, or do different screens interpret the same customer differently? These questions turn an emotional argument about code quality into a reviewable maintenance problem.

Separate symptoms from an explanation

A hypothetical customer-intake app sometimes creates duplicate enquiries. The symptom is a repeated record. Possible causes include repeated form submissions, duplicated integration events or inconsistent record matching. Asking an assistant to remove the visible duplicates might improve the screen while leaving the underlying operation unchanged.

Record what happened, which path produced it and how the team detected it. Then ask for a reproducible explanation. The fact that AI wrote some code is not enough to identify the cause, and a large number of generated files is not by itself a reason to discard them.

Establish what you actually own and can reproduce

Before comparing repair and replacement, inventory the repository, hosting, database, domain, third-party integrations and administrative accounts. Confirm who controls each item and whether another developer can obtain the necessary access through an agreed process. Keep credentials out of the assessment document.

Ask the assessor to build and run the application from the recorded source and documented configuration. If the live service depends on changes that exist only inside a hosting dashboard, identify them explicitly. A repository that looks complete may still fail to describe what customers are using.

The Twelve-Factor guidance on configuration separates deploy-specific configuration from application code. Use that distinction to request a configuration inventory without putting secrets into the repository or review brief. Record who controls each setting and how a replacement team obtains access.

Evidence	What it tells the buyer	What its absence means
Reproducible build and configuration inventory	Another team can work from the source	The handover has unresolved dependencies
Workflow and integration map	Records and business effects have an owner	Repair scope cannot yet be trusted
Representative defect reproduction	A proposed fix addresses an observed cause	Estimates rely on assumptions
Restore and release evidence	Changes can be introduced and recovered deliberately	Operational continuity needs investigation

The Twelve-Factor guidance on development and production parity explains why differences between environments create deployment problems. Apply the principle to the app's actual services and backing systems. A local demonstration using different storage or configuration is weak evidence that a production repair will behave the same way.

Make one valuable workflow understandable

Choose a path the business already relies on. In the intake example, a visitor submits an enquiry, a colleague reviews it and an approved record reaches the CRM. Map the inputs, record identifiers, transformations and external effects along that path. Include rejected submissions and manual intervention.

Trace the whole path

The app's success message might appear before the CRM accepts the record. If the business treats that message as proof of a completed handoff, the defect is partly an outcome-design problem. Repair should establish what success means and what the user sees when the destination has not confirmed it.

Agree how uncertain cases are detected and who owns them. A record that might have reached the destination needs inspection before replay. This kind of clarification can be more valuable than a cosmetic rewrite of the interface because it changes how the team handles real work.

Trace a business outcome across every boundary, including the point where the destination acknowledges the work. View full-size diagram

Turn the path into acceptance evidence

Use realistic examples that cover permitted, rejected and uncertain outcomes. An acceptance test should demonstrate the business rule, such as retaining the original enquiry reference when the same submission is received again. Avoid tests that simply repeat the implementation's current behaviour without deciding whether that behaviour is right.

Preserve useful product learning. The wording that customers understand, the fields staff actually use and the exception routes already discovered may be worth keeping even when a component needs replacement. A rebuild that discards this knowledge can reproduce old mistakes in a cleaner repository.

Compare targeted repair with staged replacement

Ask the assessor to explain alternatives against the same acceptance requirements. Repair may be appropriate when a problematic boundary is isolated and the surrounding workflow is understandable. Replacement may be justified when the required change repeatedly crosses inconsistent data models or inaccessible platform constraints.

Finding	Repair can be reasonable when	Replacement deserves consideration when
Duplicate records	A bounded matching or retry defect is reproducible	Several incompatible record models prevent consistent identity
Unreliable releases	Configuration and deployment can be documented and tested	Essential behaviour cannot be reproduced in a supported environment
Difficult changes	Responsibilities can be separated incrementally	Every change crosses unresolved structural dependencies
Missing permissions	Access checks can be enforced at the right boundary	The underlying data model cannot support the required isolation
Platform limitations	A supported export or integration meets the need	Required ownership or operating controls are unavailable

These are assessment criteria, not an automatic scoring system. A serious defect in a critical workflow can outweigh several minor improvements elsewhere. The decision also depends on how much interruption the business can tolerate and whether the application is still proving its market.

Be wary of a proposal that announces a rebuild before inspecting the data and release process. Be equally wary of a repair promise that avoids explaining how the next developer will verify the changes. Both approaches need a credible path from the current application to an accepted operational state.

Treat security review as a separate workstream

Maintainability and security overlap, but they answer different questions. Code that is easy to change can still expose another customer's records. A permission fix can reduce a security risk without making deployment or maintenance predictable. Specify both scopes when the app needs them.

OWASP's Application Security Verification Standard provides a basis for verifying application security controls and defining requirements. It can help structure the security part of an assessment. A completed checklist does not by itself demonstrate that the app's business workflow is maintainable or that every risk has been removed.

Our vibe coding security audit guide explains that review in more detail. For the repair decision here, request findings that distinguish urgent containment, targeted remediation and longer-term design changes. A report that calls every finding a reason to rewrite the whole application makes priorities harder to assess.

Preserve investigation evidence if there are signs of an actual incident. Routine maintenance planning should not overwrite logs or reset environments that the incident owner needs to examine. Establish the current situation before treating every unexplained behaviour as ordinary technical debt.

Plan migration before approving replacement

A replacement estimate is incomplete without a data and cutover plan. Identify authoritative records, attachments, customer accounts, external identifiers and the state of work in progress. Decide which history must move and how the team will verify its meaning after migration.

GitHub's repository backup guidance distinguishes a mirror clone from additional work needed for Git LFS objects and wikis. A source backup is therefore only part of the inventory. Separately account for the application's live database, uploaded files and external services before treating a code export as a recovery plan.

Prove the destination can preserve the workflow

Run a rehearsal using controlled data and compare source and destination records. Check relationships and operational states as well as totals. An enquiry linked to the wrong organisation is wrong even if the record count matches. Document intentional transformations so they are not mistaken for lost information.

Avoid running competing writers against the same business process without an explicit coordination plan. During a staged replacement, define which system owns each operation and how changes cross the boundary. Otherwise the migration can create the duplicate work the project was intended to remove.

Repair and replacement should meet the same business acceptance requirements. Replacement also needs a tested migration and cutover path. View full-size diagram

Define a stopping condition

Agree what evidence permits the cutover and what would stop it. Consider missing records, incorrect access, unacknowledged integrations and unacceptable manual work. Define who makes the decision and how work continues if the release is delayed.

Rollback is not simply redeploying yesterday's interface. Once the new system has changed records or triggered external operations, the previous application may not understand the resulting state. Ask the supplier to explain recovery after real business activity, including any changes that cannot be automatically reversed.

Compare costs across the whole change

Request a scoped GBP proposal separating assessment, repair, testing, migration and handover. Include assumptions about access to the source and the ability to export data. A fixed price based on an unexplored repository can conceal uncertainty rather than remove it.

Cost area	Targeted repair	Staged replacement
Investigation	Reproduce the failure and locate its boundary	Establish current behaviour and replacement requirements
Implementation	Correct or isolate the affected component	Build the required destination behaviour
Verification	Demonstrate the repair and nearby regressions	Demonstrate equivalence and intentional changes
Transition	Release safely into the existing service	Rehearse migration, coordinate cutover and reconcile data
Ownership	Document the improved system and remaining debt	Transfer the replacement and retire dependencies deliberately

Include the business's own work: reviewing examples, preparing data, training colleagues and managing exceptions during transition. Those activities consume capacity even if they do not appear in a developer's estimate. Describe them explicitly instead of inventing a universal rebuild price or a promised productivity gain.

The cheapest credible option is the one that meets the agreed outcome with acceptable ongoing ownership. Sometimes that is a focused repair. Sometimes a platform constraint makes replacement the practical choice. The assessment should give you enough evidence to understand why.

Commission a maintainable next step

Prepare the application URL, a redacted example of the failing workflow, repository ownership details and the business consequence of the problem. Explain which changes you need next and which parts of the current product already work well. This gives an assessor something concrete to investigate.

Ask for an initial deliverable that includes a reproducible finding, repair and replacement alternatives, assumptions, acceptance criteria and an account of remaining uncertainty. That is a better buying decision than commissioning an open-ended cleanup whose end state nobody can describe.

Our software development service is the starting point for discussing application repair, integration changes or a staged replacement. Where access, code and operational knowledge are being transferred between teams, our software project takeover guide also explains what to request in the handover.

To discuss your app, send us the workflow that is becoming difficult to operate or change. We can use that brief to scope an assessment and the evidence needed for a repair-or-rebuild decision. The objective is software your team can own and operate, with its remaining limitations understood.

Related reading

Frequently Asked Questions

What is vibe coding technical debt?
Vibe coding technical debt describes implementation and design choices in an AI-assisted application that make later changes harder or riskier. Assess it through reproducibility, workflow behaviour, data integrity and ownership rather than assuming all generated code needs replacement.

Does a vibe-coded app always need rebuilding?
No. Targeted repair can be appropriate when the important workflows are understandable and the defects can be isolated and verified. A replacement recommendation should explain the structural limitations, alternatives, migration work and operational consequences.

What should we check before hiring a developer to repair the app?
Confirm control of the source, hosting, data and integrations, then provide a reproducible example of the problem. Ask for acceptance criteria, a safe release approach and a handover that another developer can use.

How do we compare repair and rebuild costs?
Compare scoped GBP proposals against the same business outcome. Include investigation, implementation, verification, migration where needed, internal staff time and ongoing ownership. A replacement price that omits data transition is not a complete comparison.

Is a security audit enough to establish maintainability?
No. A security audit evaluates controls within an agreed scope. Maintainability also requires evidence that the application can be reproduced, changed, released, recovered and handed over, with its important business workflows understood.

Should we stop using the app while it is assessed?
Not automatically. Agree containment or restrictions when a specific risk warrants them. The assessment should explain which operations can continue and who owns exceptions.

Can we keep the existing design when replacing the backend?
Often that is a useful option to investigate. Keep the interface decisions that customers understand, then test whether the replacement preserves their meaning. A familiar screen can still behave differently when validation, record ownership or integration timing changes. Include those behaviours in acceptance tests rather than treating visual similarity as proof of equivalence.

What if the original platform cannot export everything?
Establish the missing records, files and relationships before agreeing a replacement scope. Ask for an evidence-based export rehearsal and document what remains manual or inaccessible. The business may need a staged transition, temporary access to the old system or a narrower replacement. Do not schedule a final cutover on the assumption that an untested export will become available. Any unresolved limitation should appear in the proposal and acceptance conditions.

What should the first assessment deliver?
A reproducible finding, repair and replacement options, explicit assumptions, acceptance criteria and a scoped next step. It should explain what remains unknown and what evidence would change the recommendation.

Postmortems That Actually Change Something

Norbert E. Boros — Mon, 02 Nov 2026 19:00:00 +0000

A postmortem is easy to hold and hard to make useful. The meeting happens, a document is written, four action items are recorded, and six months later the same failure occurs and somebody finds the old document while searching for something else.

The word "blameless" gets most of the attention in discussions of this, and it is genuinely important, but it is not where the failure is. Plenty of organisations run scrupulously blameless reviews that change nothing, because the review was treated as the deliverable rather than as the thing that produces one.

The test of whether yours are working is embarrassingly simple: what proportion of action items from the last six months are done? If the answer is most of them, the process is working whatever it looks like. If it is under half, you are holding meetings rather than running a process, and adding better templates will not fix it. Fewer items, owned and scheduled, beats a thorough list nobody has time for.

What a Postmortem Is Actually For

Not to explain what happened. The people in the room usually know that by the end of the incident.

It exists to find the conditions that allowed a small problem to become a large one, and to change some of them. That is a different question from what broke, and the distinction shows up immediately in the write-up. "The database ran out of connections" is what broke. "Nothing alerted on connection pool saturation, and the dashboard that would have shown it is not on the on-call runbook" is a condition, and it is actionable.

The second thing it produces, which is undervalued, is a shared account of the event. Without one, everybody keeps their own version, and those versions diverge in the direction of whatever each person already believed about the system.

Blameless Means Something Specific

It does not mean nobody made a mistake. It means the analysis assumes that a person acting reasonably on the information available took an action that turned out to be wrong, and asks why that action looked correct at the time. Google's SRE book sets out the practice and the failure modes that come with it.

The reason this is not merely kindness is that blame destroys information. In an organisation where incidents attach to individuals, people describe events carefully, omit the detail that looks bad, and delay reporting until they understand it well enough to present it safely. The review then works from an account that has been edited for self-protection, which is the worst possible input.

Practically, blameless is a property of language. "Why did you restart the service?" invites defence. "What did the dashboard show when you decided to restart?" invites information. The second question is also the more useful one, because the answer is a fact about your monitoring rather than about a colleague.

If a genuine performance problem exists, address it separately and directly. Doing it inside the incident review corrupts the review and is, in any case, a poor way to have that conversation.

Building a Timeline That Teaches

The timeline is the most valuable part of the document and the part most often written badly, as a sequence of technical events with the humans removed.

Include what people knew and when. Not just "the service was restarted at 14:32", but what the person could see at 14:32 and what they believed was happening. That is where the actionable material is, because a fifteen-minute delay caused by an ambiguous dashboard is a fixable problem and a fifteen-minute delay recorded as a gap is not.

Mark the moments that mattered: when it started, when anybody first noticed, when the right person was involved, when the cause was understood, when it was mitigated, when it was resolved. The gaps between those are where the improvement lives, and detection time is very often the largest one.

Write it while it is fresh, ideally within a day or two. Memory of what somebody believed at a particular moment decays much faster than memory of what happened.

There Is Rarely One Root Cause

The phrase encourages stopping at the first plausible explanation, and incidents of any size are chains where several things had to hold simultaneously.

A useful review lists contributing factors instead: the change that triggered it, the test that would have caught it and did not exist, the alert that fired to a channel nobody watches, the runbook that was accurate for a previous architecture. Each is a separate opportunity, and you can choose to fix the cheapest two rather than the one that happened to be first in the chain.

This also reduces a common distortion. When a review names one root cause, that cause is very often "human error", which is a description rather than an explanation and closes the investigation exactly where it should have started.

Making the Follow-Up Happen

This is where postmortems live or die, and the fixes are unglamorous.

Fewer items. Two that get done beat eight that do not. Rank them by whether they reduce detection time, blast radius or likelihood, and cut the rest.

A named owner and a date, in your normal work tracker rather than in the document. Items that live only in the postmortem are invisible during planning, which is when work actually gets scheduled.

Review the open items at the next postmortem. This single habit does more than any template. It makes incompletion visible and it turns the sequence of reviews into a process rather than a series of unrelated meetings.

Accept some items honestly. A team that consistently completes half of what it commits to should commit to half as much. Recording an intention nobody will fund is worse than recording a decision not to act, because the second is at least true.

The improvements that come out of this are usually the same family covered in our disaster recovery guide and in software testing strategies: faster detection, smaller blast radius, and a system somebody other than the original author can operate.

Mecanik runs incident reviews on systems we maintain as part of our server security work. The pattern across most of them is that the technical cause was understood quickly and the detection gap was the expensive part.

Related reading

Frequently Asked Questions

What is the point of a postmortem?
To find the conditions that let a small problem become a large one and change some of them, which is a different question from what broke. It also produces a shared account of the event, without which everyone keeps a private version that drifts toward what they already believed about the system.

What does blameless actually mean?
That the analysis assumes a person acting reasonably on the information available took an action that turned out wrong, and asks why it looked correct at the time. It matters because blame destroys information: people edit their accounts for self-protection and the review then works from a corrupted input.

Should a postmortem identify a single root cause?
No. Incidents of any size are chains where several conditions had to hold at once, so listing contributing factors is more useful. It lets you fix the cheapest two rather than whichever came first in the chain, and it avoids concluding with "human error", which is a description rather than an explanation.

What should an incident timeline include?
What people knew and when, not only what the systems did. Record when it started, when anybody first noticed, when the right person was involved, when the cause was understood, when it was mitigated and when it resolved. The gaps between those are where improvement lives, and detection time is usually the largest.

Why do postmortem action items never get done?
Because they live in the document rather than in the work tracker, so they are invisible when work is scheduled. Fix it with fewer items, a named owner and a date in the normal tracker, and a review of open items at the start of the next postmortem, which makes incompletion visible.

Drupal Hosting: What Actually Runs Drupal Well

Norbert E. Boros — Mon, 02 Nov 2026 07:00:00 +0000

Drupal hosting is where most of the "Drupal is slow" reputation comes from, and it is almost always a purchasing decision rather than a software problem. A site gets built properly, then goes live on a plan priced for a brochure site with a handful of PHP files. The result is a content management system with a serious render pipeline running inside a memory limit it cannot change, on an opcode cache it does not control, with no shell to run its own tooling.

The comparison people make in their heads is with WordPress, and it is the wrong one. WordPress runs acceptably on almost anything because its market share forced hosts to make it run acceptably on almost anything. Drupal assumes a current PHP, a recent database, a real cache backend, a command line, and a deployment process that treats the codebase as a build artefact rather than a folder you edit.

What does Drupal actually need from a host? A PHP version at or above the floor for your release, a current MySQL, MariaDB or PostgreSQL, 256MB of PHP memory in practice, OPcache, shell access for Composer and Drush, a real cron entry, and an external object cache once you have logged-in users. Cheap shared hosting fails three or four of those at once.

What Drupal Actually Requires From a Server

The published requirements are short, specific and public, and almost nobody reads them before buying. They are also version-specific in a way that matters right now, because two of the floors move in December 2026.

The PHP version floor is not negotiable

Drupal 11 requires PHP 8.3 as a minimum and supports 8.3, 8.4 and 8.5. Drupal 10 requires 8.1 and supports up to 8.4, and Drupal 12 raises the floor again to PHP 8.5. Those numbers come from Drupal's own PHP requirements documentation, which is the only version of the list worth trusting.

This matters more than it looks, because the PHP branches themselves expire. php.net's supported versions page puts the end of security support for PHP 8.2 at 31 December 2026, with 8.3 running to 31 December 2027 and 8.4 to 31 December 2028. PHP 8.1 is already past it. A host advertising "PHP 8.1 and 8.2 available" is offering a stack that is unpatched now or unpatched within months.

The two dates collide. Drupal 10 reaches end of life on 9 December 2026 and Drupal 12 ships the same week, according to the core release schedule. If your host cannot serve PHP 8.3 or newer, you cannot run a supported Drupal after that. Our guide to Drupal migration costs, options and deadlines covers what that means if you are still on 10.

Database engines and their real minimums

Drupal 11 wants MariaDB 10.6 or later, MySQL 8.0 or later, PostgreSQL 16 or later, or SQLite 3.45 or later, per the database server requirements. Drupal 10 is more forgiving at MariaDB 10.3.7, MySQL 5.7.8, PostgreSQL 12 and SQLite 3.26, which is exactly why an upgrade sometimes forces a database upgrade the client was not expecting.

Two details get skipped. InnoDB must be the storage engine on MySQL and MariaDB, because Drupal relies on transactions and row-level locking. On PostgreSQL, the pg_trgm extension has to be created on the Drupal database before installation, and a managed database service that does not let you run CREATE EXTENSION is not usable.

SQLite is genuinely supported and fine for local development, but it is not a production answer once several editors are saving content, because write concurrency becomes the ceiling first.

Memory, extensions and the web server

Drupal's documented minimum is 64MB of PHP memory, and it shows warnings below that. The same page notes that 128MB or 256MB is typical on production and that media-heavy installations need more. In practice, treat 256MB as the working figure and expect to raise it for the command line, because Composer and large migrations are the memory-hungry operations, not page serving.

The extension list is unremarkable and worth checking anyway: PDO with a database driver, XML, JSON, mbstring, cURL, OpenSSL for outbound HTTPS, and either GD or ImageMagick for image derivatives. Drupal 12 adds Argon2 for password hashing, which is one more thing a very old PHP build will not have.

On the web server, Drupal supports Apache 2.4.7 or later and Nginx 1.1 or later, and does not support Microsoft IIS as of Drupal 11.0.0. Apache needs mod_rewrite for clean URLs and AllowOverride All so the shipped .htaccess applies. That last point catches people: some of Drupal's protective rules exist only in .htaccess, so an Nginx deployment has to reproduce them in the server configuration by hand. It is a routine step that is routinely skipped, and it is one of the first things we look for in a server security audit.

Why Shared Hosting Fails Drupal

Shared hosting is not bad hosting. It is hosting optimised for a different application shape, and Drupal breaks against its constraints in four predictable places.

No shell means no Composer and no Drush

Modern Drupal is a Composer project. Core, contributed modules and their PHP dependencies are all resolved by Composer, and once Composer manages one module it has to manage core as well. Mixing Composer with manual file updates is how a site ends up unable to update at all.

A control panel with a file manager cannot do that. Neither can an FTP client. Without SSH you also lose Drush, which is how cache rebuilds, configuration imports, database updates and user password resets are actually performed. A site you cannot run drush cr against is a site where every recovery step becomes a support ticket.

The limits you cannot see, let alone change

A shared account gives you a memory_limit set by someone else, usually 128MB and sometimes lower, with no route to raise it for the one migration that needs 512MB.

OPcache is the bigger problem. It stores precompiled script bytecode in shared memory so PHP does not reparse files on every request, and on a shared host that memory pool is shared across hundreds of accounts. Drupal has thousands of PHP files, so it is a heavy tenant of a pool it is competing for, and it gets evicted. The symptom is a site that is quick for a minute after a visit and slow again an hour later.

Then there is what is missing entirely: no Redis, no Memcached, no control over the PHP process manager, and no way to run a long queue worker.

Cron that never really runs

Drupal's Automated Cron module runs every three hours by default and is triggered by end users visiting the site. On a busy site that means a visitor occasionally pays for search indexing with their page load. On a quiet site it means cron effectively does not run, so the search index goes stale, log tables never get trimmed and available security updates are never checked.

The documentation recommends triggering cron externally instead, because it always runs on schedule and uses fewer resources. That needs a real crontab entry, which the cheapest tier does not provide.

The Caching Layers and Which One Your Visitor Hits

Drupal has more caching than most people realise, and the layers are not alternatives. They stack, and each one catches what the layer above it could not.

OPcache sits below Drupal entirely

OPcache is not a Drupal feature. It caches compiled PHP bytecode at the interpreter level, so it applies to every request whether or not any Drupal cache hits. Get this wrong and nothing above it can compensate, because every request pays to recompile the framework before it reaches the router. Size the shared memory generously and disable timestamp validation in production, where the file set only changes on deployment.

Internal Page Cache and Dynamic Page Cache

Internal Page Cache is a core module, enabled by default, and it serves anonymous users only. It assumes every anonymous visitor sees the same page, stores the whole response on first request, and reuses it. For a marketing site with no personalisation, this is the layer that does almost all the work.

Dynamic Page Cache is also core and also enabled by default, and it caches for anyone, including authenticated users. It works by having the render system turn the genuinely personal parts of a page into placeholders, caching everything around them. That is why a logged-in Drupal page can still be mostly cached: only the user menu and a few blocks are actually dynamic.

BigPipe and the render cache

Below both sits the render cache, which caches individual blocks, fields, views results and entity renders. A page that misses the page cache is usually assembled largely from render cache hits rather than rebuilt from the database.

BigPipe handles what is left. It has been in core since Drupal 8.1, stable since 8.3, and in the standard install profile since 8.5. Instead of waiting for every placeholder to resolve, it flushes the cacheable page immediately and streams the personalised fragments in afterwards. It needs no configuration, and it helps authenticated users far more than anonymous ones.

So the anonymous visitor on a well-configured site hits Internal Page Cache, or the CDN in front of it, and never touches most of this. The logged-in editor hits Dynamic Page Cache, the render cache and BigPipe on every request, which is why authenticated traffic costs so much more.

The external object cache

Every layer above needs somewhere to store its entries. By default that is the database, in cache tables, which means your cache reads compete with your content queries on the same server.

The Redis module moves cache, lock, flood and queue backends onto Redis or a compatible store such as Valkey, using either the PhpRedis extension, the Relay extension or the pure-PHP Predis library. Memcached is the equivalent alternative. For a small anonymous site this changes little. For a site with logged-in users it is usually the single largest available improvement, because it removes the noisiest write load from the database and makes locking cheap.

Reverse Proxy and CDN in Front of Drupal

A reverse proxy such as Varnish or Nginx, or a CDN, answers requests before PHP is involved at all. For anonymous traffic this is the difference between serving a page in single-digit milliseconds and serving it in a few hundred. It is also the layer people are most afraid of, because a stale cache on a news site or a shop is a visible failure.

Cache tags are what make a CDN safe

Drupal's answer is cache tags. Cache tags describe data dependencies, written as strings like node:5, user:3 or node_list. Every cached item records which tags it depends on, so editing node 5 invalidates every cached fragment, page and view that referenced it, wherever it appeared.

The important part is that Drupal can publish those tags outward. Contributed modules emit them as a Surrogate-Key header for Fastly or a Cache-Tag header for Cloudflare, and the CDN then purges by tag when Drupal says so. That converts a CDN from a time-based gamble into an event-driven cache: you can set a long time to live, because an edit purges exactly the affected URLs within seconds.

Watch the header budget. Cloudflare's purge by cache tag documentation caps the aggregate Cache-Tag header at 16KB after the field name, roughly 1,000 unique tags, with a maximum of 1,024 characters per tag in an API call and 100 tags per dashboard purge. A Drupal view listing many entities can generate far more tags than that, so a page that lists everything will silently overflow the header unless the module is configured to trim or hash them.

Choosing Drupal Hosting: Four Tiers, Honestly

There are four real options, and the correct one is decided by whether you have authenticated traffic and whether you have anyone to operate the server. The bands below are what UK clients typically pay in our experience, exclusive of VAT, and are indicative rather than quoted from any vendor.

Tier	Typical monthly cost	What it buys
Shared	GBP 3 to GBP 15	Nothing Drupal needs
Unmanaged VPS or cloud	GBP 20 to GBP 120	Full control, no operator
Managed Drupal platform	GBP 40 to GBP 800 and up	Opinionated stack and workflow
Custom infrastructure	GBP 400 upwards	Everything, plus the obligation

Shared hosting

Suits nobody running Drupal in production. It fails on shell access, memory, opcode caching, object caching and cron simultaneously. If budget genuinely caps here, a small unmanaged instance at a similar price is a better use of the money.

Unmanaged VPS or cloud instance

Roughly GBP 20 to GBP 120 a month buys a machine with full root, which suits the large majority of Drupal sites. You choose the PHP version, size OPcache, install Redis, set a crontab and configure Nginx properly. What you do not get is anyone to do it, patch it, monitor it or restore it at 2am. This tier is correct when you have a developer or agency on retainer, and the retainer is the real cost, not the instance.

Managed Drupal specialist platforms

Managed Drupal hosting starts around GBP 40 a month for a small site and rises quickly with traffic, environments and support tier. What you buy is an opinionated stack that is already correct, plus Git-based deployment, staging environments, backups and someone who understands Drupal answering the phone. It is good value when the alternative is nobody, and poor value when you pay platform prices for a brochure site that gets 4,000 visits a month.

Full custom infrastructure

Separate database, dedicated cache nodes, application servers behind a load balancer, object storage for files. This starts to make sense above roughly GBP 400 a month, and only when authenticated traffic, integrations or compliance requirements make the managed tiers awkward. It is the most capable tier and the most demanding, because you now own patching, monitoring and disaster recovery. Our Drupal web development guide covers where that complexity comes from on the application side.

Deployment: You Do Not Edit Files on the Server

Because Composer resolves the entire dependency tree, the server's codebase is an output, not a workspace. Editing a module file in place means the next composer update overwrites it, and it means your production code no longer matches anything in Git.

A sane release process builds the artefact somewhere else. Run composer install from the committed composer.lock in CI, so the build is reproducible and the production host never needs Composer, PHP memory for dependency resolution, or write access to vendor. Ship the result, run database updates, import configuration, rebuild caches. Roll back by pointing at the previous artefact.

That also settles the hosting question quietly. A host that expects you to edit files over FTP is incompatible with the way Drupal is maintained, whatever its specification sheet says.

Where configuration synchronisation fits

Drupal keeps active configuration in the database and exports it to YAML files, which is how content types, fields, views and settings move between environments. The configuration management documentation explains that the site UUID has to match between source and destination, which is the usual reason a first import fails.

Practically, this means configuration is code. It is committed, reviewed and deployed with the rest, and the import step runs as part of the release rather than being clicked through in the admin interface afterwards. Hosting has to support that: you need a place to run the import, and an environment where a failed import can be rolled back rather than half-applied to production.

Files, Media and Backups

Drupal has two file systems and the difference is load-bearing. The public one lives under the web root and is served directly by the web server. The private one lives outside the web root, and every request for a private file passes through Drupal so that access can be checked.

Private files are therefore far more expensive than public ones, because each download bootstraps PHP, so a site serving large private documents needs headroom a static file server would not.

Offloading media to object storage

Once files live on the application server, horizontal scaling and rebuilds become painful, and every backup carries the whole media library. Moving the public file system to S3-compatible object storage separates the two, lets the CDN serve media directly, and makes an application server genuinely disposable.

A restore test proves what a backup cannot

A backup proves a file exists. A restore test proves the file is complete, that the database and the files are from the same moment, that your credentials still work, and that you know how long it takes. Those are four separate failure modes and none of them are visible from a green tick in a control panel.

Test it against a real timer at least twice a year and write the number down. If the restore takes six hours and your tolerance is one, the architecture is the problem, not the backup. Recovery time is a hosting requirement, and it belongs in the specification rather than in an incident.

Sizing a Drupal Host Properly

Pageviews are the wrong unit. A site with 200,000 anonymous monthly pageviews behind a CDN can be comfortable on a small instance, while a site with 8,000 pageviews can struggle if most of them are logged in.

Authenticated traffic is the real driver

Anonymous requests can be answered by the page cache or the CDN without touching PHP. Authenticated requests cannot. Every one of them runs the render pipeline, checks access on each entity, resolves placeholders and writes session data. The practical question is not how many visits you get, it is how many concurrent logged-in users you have, and what those users are allowed to see.

Editors are the extreme case. Content administration screens are among the heaviest pages in Drupal, and they are uncacheable by definition, so a site with twelve editors working simultaneously has a genuine concurrency requirement that its public traffic never suggests.

Views, taxonomy and queue work

Beyond authenticated traffic, the reliable cost centres are large views with many filters and relationships, which generate expensive joins; deep taxonomy trees, where term hierarchies are traversed on every render; and cron or queue work such as search indexing, feed imports and media derivative generation.

Queue workers should not share the web server's resources with visitors if you can avoid it. On a larger site they belong on a separate process or instance, so an import backlog cannot make the front end slow. That is an architecture decision made at buying time, and it is the point at which the managed tiers stop fitting and custom infrastructure starts to.

Getting the Decision Right

The pattern is consistent. The hosting is not undersized, it is the wrong shape: no shell, no object cache, an opcode cache someone else controls, and a PHP version about to fall out of support. Moving the same site onto a correctly specified instance at a similar price usually beats any amount of front-end optimisation.

Mecanik specifies, builds and maintains Drupal infrastructure as part of our website development work, and reviews existing stacks through a server security audit when the concern is exposure rather than speed. If you need people rather than a platform, our guide to hiring a Drupal developer covers what to look for.

Related reading

Frequently Asked Questions

What are the minimum server requirements for Drupal 11?
PHP 8.3 or newer, and MariaDB 10.6, MySQL 8.0, PostgreSQL 16 or SQLite 3.45 as the database. Apache 2.4.7 or Nginx 1.1 and later on the web server side, with Microsoft IIS unsupported from Drupal 11.0.0 onwards. Drupal warns below 64MB of PHP memory, but 256MB is the realistic production figure.

Can Drupal run on shared hosting?
It will install and it will serve pages, but shared hosting usually fails three or four requirements at once: no shell access for Composer or Drush, a PHP memory limit you cannot raise, no Redis or Memcached, and cron that only fires when a visitor happens to load a page. Those conditions are what produce the reputation for Drupal being slow.

How much should Drupal hosting cost?
A small Drupal site on a properly configured unmanaged instance typically sits around GBP 20 to GBP 120 a month before anyone manages it. Managed Drupal platforms commonly start near GBP 40 and rise into the hundreds with traffic and environments. Custom infrastructure starts to make sense above roughly GBP 400. The cheapest tier is rarely the cheapest outcome.

Does Drupal need Redis?
Not for a small anonymous site, where the internal page cache and the database are adequate. Once you have logged-in users, editors or a members area, an external object cache such as Redis or Memcached moves cache reads, locks and queues off the database, and it is usually the single largest improvement available for the money.

Is a CDN safe in front of a dynamic Drupal site?
Yes, provided you invalidate by cache tag rather than by time. Drupal records tags such as node:5 for everything a response depends on, and modules translate those into Cache-Tag or Surrogate-Key headers so the CDN purges exactly the pages an edit affected. Without tag invalidation you are choosing between stale pages and a cache that never helps.

Drupal 12: What Changes and When to Move

Norbert E. Boros — Sun, 01 Nov 2026 19:00:00 +0000

Drupal 12 is scheduled for the week of 7 December 2026, and Drupal 10 reaches end of life on 9 December 2026. Both dates sit on the same page of the Drupal core release schedule, two lines apart, and most people running a Drupal 10 site have noticed neither. The first alpha of the new major was tagged on 2 September 2026, so the shape of the release is now a matter of record rather than speculation.

That collision is the whole story. A major version arriving is not usually urgent for a site owner, because you can sit on the previous major for a year or two while the ecosystem catches up. This time the previous major stops receiving security advisories in the same week the new one ships, which converts a technical event into a deadline with a compliance edge on it.

What follows is the calendar as drupal.org publishes it, what actually changes in the code, what the new platform floors force on your hosting, the three realistic upgrade paths with cost bands, and a plan working backwards from December. The reassuring part arrives early: most of a Drupal major version bump is deletion, not reinvention.

When does Drupal 12 come out, and do I have to move? Drupal 12.0.0 is scheduled for the week of 7 December 2026, released alongside Drupal 11.5.0. Drupal 10 reaches end of life two days later on 9 December 2026, after which no further security advisories are issued for it. A Drupal 11 site faces a small upgrade. A Drupal 10 site has to pass through Drupal 11.4 or later first, so the work is two hops rather than one.

The Two Dates That Decide Your Next Six Months

The release managers publish the whole cycle in advance, and the current one is unusually tidy. Drupal 11.4.0 landed in the week of 29 June 2026, and that release ended security support for both Drupal 11.2.x and Drupal 10.5.x. The 12.0.0-alpha1 tag went out on 2 September 2026. Beta requirements had to be complete by 11 September 2026, with 12.0.0-beta1 and 11.5.0-beta1 in the week of 14 September and release candidates in the week of 9 November.

Then the week of 7 December does three things at once. Drupal 12.0.0 ships, Drupal 11.5.0 ships alongside it, and security support ends for both Drupal 11.3.x and Drupal 10.6.x. Two days later, on 9 December 2026, Drupal 10 as a whole reaches end of life and no further releases of it will be made at all.

Date	What happens
Week of 29 June 2026	Drupal 11.4.0 released, security support ends for 11.2.x and 10.5.x
2 September 2026	Drupal 12.0.0-alpha1 tagged
Week of 14 September 2026	Drupal 12.0.0-beta1 and 11.5.0-beta1
Week of 9 November 2026	Drupal 12.0.0-rc1 and 11.5.0-rc1
Week of 7 December 2026	Drupal 12.0.0 and 11.5.0 released, security support ends for 11.3.x and 10.6.x
9 December 2026	Drupal 10 end of life

Why Drupal 10 and Drupal 12 Land in the Same Week

This is policy, not coincidence. The release process overview states that major versions arrive every two years in even years, and that each major is supported for a minimum of four years, until two further majors have been released. Drupal 10.0.0 came out on 15 December 2022. Drupal 11 arrived in August 2024 and Drupal 12 arrives in December 2026, which is the second further major, and four years have passed. The clock ran out exactly on schedule.

The same policy governs minors. Each minor version is supported for one year, with bug fixes and security fixes for the first six months and security fixes only for the last six. That is why only 10.6.x still receives advisories today, and why 11.3.x loses its coverage the moment 11.5.0 ships.

Drupal 11 does not stop when Drupal 12 starts. Releasing 11.5.0 in the same week begins what the policy calls the Long Term Support phase, in which the previous major keeps an API-matched minor, moves onto an LTS release of Symfony, and receives a maintenance minor every six months with a shrinking scope. Drupal.org does not publish a firm Drupal 11 end of life date, though its own deprecated extensions documentation says Drupal 11 will be supported until mid to late 2028.

How Many Sites Are Still Sitting on Drupal 10

The numbers are public and they are not comfortable. Drupal.org's core usage statistics for the week beginning 23 August 2026 record 468,877 sites reporting a core version. Of those, 205,568 are on some branch of Drupal 10 and 168,857 are on Drupal 11. Roughly 44 per cent of the reporting installed base is on the version that stops receiving advisories in December.

The sharper number is inside that figure. Only 10.6.x still has security coverage, and 10.6.x accounts for 139,911 of those sites. The remaining 65,657 are on 10.0 through 10.5, which means they are running an unsupported minor today, in September, without waiting for December to arrive.

These counts come from sites that voluntarily report through the Update Status module, so the real population is larger and skews the same way. The practical reading is that a very large number of organisations are going to try to book the same upgrade work in the same quarter, and agency capacity in October and November will be the constraint rather than the code.

What End of Life Actually Means for a Drupal Site

End of life is not a switch that breaks the site. Your Drupal 10 install will keep serving pages on 10 December exactly as it did on 8 December. What changes is that the Drupal Security Team stops publishing advisories and patches for that code, so from that date every newly discovered vulnerability in Drupal 10 core is permanent.

The second effect is slower and does more damage. Contributed module security coverage depends on the module having a stable release on a supported core branch, so as maintainers drop Drupal 10 compatibility, the modules on your site quietly leave the advisory process too. You do not get a notification when this happens. The module simply stops appearing in security releases, and the available updates report on your own site keeps looking green.

The third effect is that the exit gets more expensive the longer you wait. A Drupal 10 site upgraded in November is upgraded against a maintained core branch with a working update path. The same site upgraded in the following June is a recovery project, because the contributed modules it depends on have had six more months to move on without it.

Cyber Essentials, Insurance and Contract Clauses

This is where an unsupported CMS stops being an engineering concern. The NCSC's Cyber Essentials requirements for IT infrastructure v3.3, dated April 2026, states that all software on in-scope devices must be licensed and supported, and must be removed from devices when it becomes unsupported, or removed from scope by using a defined subset that prevents all traffic to or from the internet. The control applies to servers, IaaS, PaaS and SaaS, so a Drupal install on a server in scope is squarely covered.

A public-facing Drupal 10 site cannot be firewalled off the internet, so after 9 December 2026 the two available answers are to upgrade it or to accept that it fails that control. If your organisation holds Cyber Essentials or Cyber Essentials Plus and renews it annually, that is a question you will be asked in writing on your next assessment.

Be careful about what you claim beyond that. Whether a specific cyber insurance policy or client contract is affected depends entirely on its wording, and the clauses that matter are usually the ones requiring supported software or vendor-supported versions rather than anything naming Drupal. Read your own policy and your own master services agreements before December rather than after an incident, because that is the cheap time to find out.

What Is Actually Different in Drupal 12

Very little, and that is the honest and useful answer. The 12.0.0-alpha1 release notes put it plainly: 12.0.x will be nearly identical to 11.5.x except that deprecated code is removed including entire deprecated modules, dependencies are updated to new major versions, and system requirements are raised. For every other change, the notes tell you to read the 11.5.x branch.

There are a handful of genuine behaviour changes worth knowing. The default password hashing algorithm switches to argon2id, with bcrypt available through kernel parameters where argon2 is unavailable. The core robots.txt now blocks search result pages carrying query parameters, which stops search engines crawling infinite faceted combinations, and sites with a customised robots.txt need to add those disallow rules by hand. HTMX, which core already ships, moves from version 2 to version 4 for beta1.

One more is easy to miss. Hosting Drupal directly on Windows in a production environment is deprecated in Drupal 12, on the grounds that there is no automated Windows test environment and few developers testing on it. Windows remains supported for local development. If you run production on Windows, that is a hosting decision to make in the next few months rather than a code change.

The Extensions That Leave Core

Drupal has spent years moving narrow modules out of core into contributed projects, and Drupal 12 continues that. The alpha1 notes list Ban, Contact, Field Layout, History, Settings Tray, Shortcut and Telephone as removed, along with the Stable 9 theme. The Text with Summary field plugin has also moved to its own contributed module. Ban was deprecated back in 11.3, Contact, Field Layout, History and Telephone in 11.4, and Settings Tray, Shortcut and Text with Summary in 11.5.

Two of those will surprise people. Shortcut and Settings Tray are administrative features that a great many editorial teams use daily without ever thinking of them as optional, and Settings Tray in particular underpins the in-place block configuration that content editors rely on.

The mechanics of handling this matter more than the list. The correct move is to add the contributed version to your Composer requirements before you upgrade, not to uninstall the module. Uninstalling destroys the extension's configuration, and Drupal's module discovery looks in core last, so once the contributed project is present Drupal simply uses it. Note also that Drush can bypass the warnings on update.php about missing extensions, so the failure surfaces afterwards as errors on the status report.

Losing Migrate Drupal Is the Change That Bites Hardest

The Migrate Drupal and Migrate Drupal UI modules are removed in Drupal 12 and, unlike the rest, they are not being moved to a contributed project. Drupal 12 keeps the Migrate API and the destination plugins for modern Drupal, but it does not keep the source plugins for Drupal 6 and Drupal 7.

Read that again if you own a Drupal 7 site. The tooling that reads a legacy Drupal database and writes it into a modern one exists in Drupal 11 and does not exist in Drupal 12. Drupal.org's guidance is explicit: sites on Drupal 6 or Drupal 7 that intend to use the migration API should continue to migrate to Drupal 11, and then use the ordinary update process to move from Drupal 11 to Drupal 12.

That turns a vague intention into a hard sequencing constraint. A Drupal 7 rebuild that lands after Drupal 11 goes out of support has to either build its own source plugins, restore an older core to run the migration in a throwaway environment, or export and re-import the content by other means. All three are more expensive than doing the migration into Drupal 11 while Drupal 11 is a current, maintained target. Our guide to Drupal migration costs, options and deadlines covers the shape of that work in detail.

The New Dependency Floors

A major version is where Drupal is allowed to raise its platform requirements, and Drupal 12 uses that allowance across the board. These floors are the part of the upgrade you cannot negotiate with, because they are enforced at install time.

PHP 8.5, and nothing older

Drupal 12 requires PHP 8.5. The PHP requirements table shows Drupal 12.0 supporting PHP 8.5 and refusing everything below it, while Drupal 11.3 and 11.4 accept 8.3, 8.4 and 8.5. That overlap is your migration route: move the site to PHP 8.5 while still on Drupal 11.4, confirm it behaves, then change Drupal.

The floor is generous rather than punishing. PHP 8.5 was released on 20 November 2025, and php.net's supported versions page puts its active support to 31 December 2027 and security support to 31 December 2029. Landing on it buys three years before this conversation happens again.

Databases and Symfony

The database server requirements for Drupal 12 are MySQL 8.0 or later, MariaDB 10.11 or later, PostgreSQL 18 or later, and SQLite 3.45 with the json1 extension. PostgreSQL sites should treat that floor as the one to verify carefully, because the alpha1 release notes say PostgreSQL 19 while the requirements page and the installer code both say 18. Check it again at beta1 before you book database work.

Underneath, Symfony moves from 7.4 to 8.1 and Guzzle from 7 to 8. Support is dropped for several older library majors including doctrine/lexer 2, egulias/email-validator 3 and guzzlehttp/psr7 2. Custom code that type hints Symfony classes directly is where this shows up.

What the floors force on your hosting

The MariaDB jump is the one that catches shared and managed hosts. Drupal 11 accepts MariaDB 10.6, whose community maintenance ended on 6 July 2026 according to the MariaDB maintenance policy, so a Drupal 11 site can currently sit on an unsupported database engine quite legitimately. Drupal 12 lifts the floor to 10.11, which is maintained until 16 February 2028. If your host cannot offer PHP 8.5 and MariaDB 10.11 today, the hosting move has to happen before the Drupal move, and that reordering is what turns a two-week job into a two-month one. Our note on what actually runs Drupal well covers the platform side.

Why the Deprecation Model Makes Drupal 12 Tractable

Here is the mechanism most site owners have never had explained, and it is the reason Drupal majors are no longer frightening. The continuous upgrades policy commits core to a simple promise: the next major release has the same public API as the last minor release of the previous major. New APIs are added in minors, old ones are marked deprecated in minors, and the deletion happens only at the major boundary.

The practical consequence is worth stating in plain terms. If your custom code and your contributed modules run on Drupal 11.5 with no deprecation warnings, they run on Drupal 12. The upgrade stops being a rewrite and becomes a dependency bump plus a database update, because everything that would have broken was already reported to you months earlier as a warning you could have fixed at leisure.

This is also why the release notes tell you to update to 11.4 or later first, and strongly recommend 11.5. The database update path from releases prior to 11.4.0 has been removed from Drupal 12 outright, so a site on 11.3 or earlier has no route into 12 until it moves up the 11 branch first. That is not advice, it is a missing code path.

The Tools That Report Deprecations

Two projects do the work, and both are currently maintained. Upgrade Status is the site-wide scanner. You install it on the site you are upgrading from, not the one you are upgrading to, because the deprecated APIs have to exist for it to find calls to them. It checks whether your environment meets the next major's system requirements, cross-references your contributed projects against available updates, runs PHPStan for deprecated PHP API use, and reads Twig templates, info.yml files, composer.json and deprecated configuration keys. Release 5.0.0-alpha3, from 2 July 2026, declares compatibility with Drupal 10.4, 11 and 12.

It also categorises what it finds, which is the part that saves money. Problems are sorted into those a machine can fix and those a person has to, so you can cost the manual half before committing to a date. It runs under Drush as upgrade_status:analyze, and its Code Climate JSON output plugs into GitLab CI.

Drupal Rector is the other half. It rewrites the mechanically fixable deprecations in your custom modules and themes, with a --dry-run flag to preview the diff first. Version 1.1.2 was released on 7 August 2026. Between the two, a competent developer can produce a defensible readiness report for a mid-sized site in two to three days.

Path One: Drupal 11 to Drupal 12

If you are on Drupal 11.4 or 11.5 with current contributed modules, this is a small piece of work. The official upgrade guide is mostly Composer commands: require the version 12 metapackages with --no-update, drop any explicit drupal/core requirement, run composer update --dry-run, then run it for real and apply database updates with drush updatedb.

The real work sits either side of that. Beforehand, run Upgrade Status, add contributed replacements for any removed core extension you actually use, and confirm your host offers PHP 8.5. Afterwards, expect every core scaffold file to have changed, including .htaccess, so any customisation you made to those has to be reapplied deliberately rather than merged blindly.

When a dependency refuses to resolve, composer why-not drupal/core ^12 names the blocker. Allowing two majors of a module in composer.json, for instance "^6.1 || ^7.0", is the standard way to bridge a project mid-transition. If you need a module that has a working patch but no tagged release, the Drupal Lenient Composer endpoint exists for exactly that and is still maintained.

Path Two: Drupal 10 to Drupal 12 Is Two Hops

There is no direct Drupal 10 to Drupal 12 upgrade. The Upgrade Status documentation says so explicitly, and the removal of the pre-11.4 database update path is what enforces it. You go from Drupal 10.6 to Drupal 11.4 or 11.5, verify the site, and then go from there to Drupal 12.

Planned properly, that is not twice the work. The Drupal 10 to Drupal 11 hop carries almost all of the risk, because that is where the contributed module compatibility problems live and where custom code meets removed APIs. The second hop is the small one described above. Teams that try to compress both into a single change window usually end up unable to tell which of the two broke something.

The sequencing that works is to do the Drupal 11 hop now, run the site on 11.4 or 11.5 for several weeks so real editorial and traffic behaviour surfaces anything odd, and take Drupal 12 in the new year once contributed modules have tagged stable releases against it. Doing the first hop before December is what matters, because it is the hop that takes you off unsupported code.

Path Three: Drupal 7 or 8 Is a Rebuild, Not an Upgrade

Anything older than Drupal 9 is a different exercise. Drupal 7 reached end of life on 5 January 2025 and Drupal 6 in February 2016. Neither upgrades in place at all, because they predate the modern architecture entirely. They are migrated, which means a new site is built on current Drupal and the content is moved into it with the Migrate API. A Drupal 8 site technically does have an in-place route, but it runs through four consecutive majors and every contributed module has to survive each one, so it is normally cheaper to treat it as a rebuild too.

The cost is dominated by everything that is not content. The theme is rebuilt, custom modules are rewritten against an entirely different API, and integrations are reconnected. In our experience the content migration itself is usually the smaller half of the budget, which is the opposite of what most owners expect when they ask for a quote, and it is the reason we scope these as website development projects rather than upgrades.

For these sites the December deadline works differently but still bites, because of the Migrate Drupal removal. Your target has to be Drupal 11, not Drupal 12, and Drupal 11 is supported until mid to late 2028 according to drupal.org's own documentation. That gives a Drupal 7 owner a genuine window, but it is a window with a hard end, and starting a six-month rebuild in 2028 to hit a 2028 target is not a plan.

What Each Path Costs in the UK

These are house estimates from our own delivery, not published rates, and the spread inside each band is driven almost entirely by contributed module health rather than by site size. UK agencies bill roughly £600 to £900 a day for this work. A Drupal 11 to 12 upgrade on a maintained site is three to eight days including testing, which lands around £2,000 to £6,000. Where the same site has stale contributed modules, allow two to four weeks and £6,000 to £12,000.

A Drupal 10 site costs both hops. Well maintained, the Drupal 10 to 11 hop is £6,000 to £15,000 and the Drupal 12 hop adds £2,000 to £6,000, so £8,000 to £21,000 in total across four to eight weeks. Neglected, the first hop alone runs £15,000 to £35,000 and the total lands between £17,000 and £41,000. A Drupal 7 rebuild is three to six months and commonly £40,000 to £120,000, higher for large or heavily customised sites.

Starting point	Realistic effort	House band
Drupal 11.4 or 11.5, maintained	3 to 8 days	£2,000 to £6,000
Drupal 11.x, stale contributed modules	2 to 4 weeks	£6,000 to £12,000
Drupal 10, well maintained	4 to 8 weeks, two hops	£8,000 to £21,000
Drupal 10, neglected	8 to 14 weeks, two hops	£17,000 to £41,000
Drupal 7 or 8	3 to 6 months	£40,000 to £120,000

The Contributed Module Audit That Sets Your Date

Upgrade projects rarely die on core. They die on the fourteenth module in the list, the one nobody remembers installing, which has no release compatible with the next major and a maintainer who last commented in 2023. Do this audit before you commit to a date, because it is the audit that produces the date.

Run Upgrade Status and export the report, then sort your modules into four buckets. The first is projects with a stable release supporting the target major, which cost nothing. The second is projects with a patch or a development release in the issue queue, which cost a small amount of integration work and carry the risk that the patch never lands. The third is projects with an open issue and no patch, which need somebody to write one. The fourth is projects with no activity at all.

The fourth bucket sets your timeline, and its size is knowable today rather than in November. A site with thirty contributed modules and nothing in bucket four is a straightforward job. The same site with four modules in bucket four is a different engagement with a different budget, and the difference between those two quotes is a day of scanning.

What to Do About an Abandoned Module

There are four honest options and the right one depends on what the module does. Remove it, if the feature it provides is no longer used, which is more often true than teams expect after several years of editorial drift. Replace it with a maintained project that does the same job, accepting the configuration migration that comes with that.

Take over maintenance, which is a real option in Drupal and less daunting than it sounds. Drupal.org has a documented process for becoming the maintainer of an unsupported project, and for a small module that your business depends on, adopting it can be cheaper than replacing it. The cost is ongoing rather than one-off, so account for it honestly.

Or reimplement the behaviour in a custom module scoped to what you actually use. A contributed module solves the general case for everybody, while you usually need one narrow slice of it. Reimplementing that slice against current APIs is frequently a two-day job against a two-week port, and it removes the dependency permanently. Our guidance on hiring a Drupal developer covers how to vet somebody for exactly this kind of judgement.

A Timeline Working Backwards From 9 December 2026

Start from the end date and the plan writes itself. By late September, run Upgrade Status against Drupal 12 on a copy of production and get the four buckets on paper. That is a two to three day exercise and it is the only artefact that lets you cost anything else honestly.

By mid October, confirm your hosting can deliver PHP 8.5 and the database floors, and start the move if it cannot. Also decide the contributed module questions, because every one of them has a lead time attached. By early November, have the Drupal 11.4 or 11.5 upgrade complete on a Drupal 10 site, with the site running on the new branch in production.

By early December you are watching the 12.0.0 release rather than reacting to it. If you are on Drupal 11 at that point, take Drupal 12 in January or February 2027, once contributed projects have tagged stable releases against it. There is no prize for upgrading in release week, and Drupal 11.5 will still be supported. The prize is for not being on Drupal 10 when the advisories stop.

What It Costs to Do Nothing

The direct cost is that every Drupal core vulnerability disclosed after 9 December 2026 stays open on your site permanently. Drupal's advisory history includes remote code execution issues serious enough to be exploited within hours of publication, and an unpatched CMS on a public IP is found by automated scanning, not by a targeted attacker who chose you.

The indirect costs arrive sooner and are usually larger. Failing the supported-software control on a Cyber Essentials assessment can affect eligibility for contracts that require the certification, which in UK public sector procurement is common. Contributed modules stop shipping fixes for your branch. And the upgrade itself gets more expensive every month, because the gap between your codebase and the maintained ecosystem widens without anybody touching anything.

There is a quieter cost too. A site nobody is allowed to upgrade tends to become a site nobody is allowed to change, and feature work stops because every change has to be built against an API that is going away. That is how a five-year-old Drupal site turns into a rebuild rather than an upgrade. If you are weighing that decision, our Drupal development guide is a better starting point than a quote.

Two Legitimate Reasons to Wait

Waiting is defensible in two situations, and only if you wait deliberately. The first is that you are already on Drupal 11.4 or 11.5. Those branches are supported, they are the designated launchpad for Drupal 12, and there is no advantage in taking a brand new major in its first weeks while contributed projects are still tagging releases. Waiting until the first quarter of 2027 is the professional choice, not the lazy one.

The second is a Drupal 7 site with a funded rebuild already scheduled. Migrating Drupal 7 into Drupal 11 and then immediately into Drupal 12 is wasted motion. Land on Drupal 11, run it, and take Drupal 12 as ordinary maintenance later.

What is not defensible is sitting on Drupal 10 without a booked plan. If that is you, the minimum acceptable position by the end of September is a scan report, a named target branch, and a date in a calendar. Everything else can move. If you want that assessment done by somebody who has run it before, our software development team does version audits as a fixed-scope piece of work.

Where to Start

Run the scan first. Nearly every bad Drupal upgrade quote in existence was produced without one, which is why so many of them are wrong in both directions. Two to three days of Upgrade Status and Drupal Rector output tells you which of the five cost bands above you are actually in, and that single number changes the conversation with your board more than any amount of general advice about major versions.

Mecanik runs those audits and the upgrades that follow, on Drupal 10 sites facing December and on Drupal 11 sites planning a calmer move in 2027. Custom module work, integrations and the deprecation clean-up sit with our software development practice, while a rebuild or a hosting move belongs with website development. If security posture is the reason this landed on your desk, start with our note on Drupal security advisories and real risk, and if organic traffic is the worry during a version move, the Drupal SEO setup piece covers what to protect.

Related reading

Frequently Asked Questions

When is Drupal 12 released and when does Drupal 10 reach end of life?
Drupal 12.0.0 is scheduled for the week of 7 December 2026, released alongside Drupal 11.5.0, and Drupal 10 reaches end of life on 9 December 2026. Both dates are published on the Drupal core release schedule. In the same week, security support ends for the 11.3.x and 10.6.x minor branches. Drupal 12.0.0-alpha1 was tagged on 2 September 2026.

Can I upgrade directly from Drupal 10 to Drupal 12?
No. The database update path from releases prior to Drupal 11.4.0 has been removed from Drupal 12, so a Drupal 10 site has to move to Drupal 11.4 or later first and then to Drupal 12. Drupal.org recommends 11.5.0 or higher before the major move. Plan it as two hops, with the Drupal 10 to 11 hop carrying nearly all the risk and cost.

What are the Drupal 12 system requirements?
Drupal 12 requires PHP 8.5 and drops support for PHP 8.4 and earlier. The database floors are MySQL 8.0, MariaDB 10.11, PostgreSQL 18 and SQLite 3.45 with the json1 extension. Symfony moves to 8.1 and Guzzle to 8.0. Hosting Drupal directly on Windows in production is deprecated, though Windows remains supported for local development.

What is actually new in Drupal 12 compared to Drupal 11.5?
Almost nothing, by design. The alpha1 release notes state that 12.0.x is nearly identical to 11.5.x apart from removed deprecated code, updated dependency majors and raised system requirements. The behaviour changes worth noting are argon2id as the default password hashing algorithm, HTMX moving to version 4, and a core robots.txt that blocks search result pages with query parameters.

How much does a Drupal 12 upgrade cost in the UK?
On a maintained Drupal 11 site, three to eight days of work at typical UK agency rates of £600 to £900 a day, so roughly £2,000 to £6,000. A Drupal 10 site pays for both hops, landing between £8,000 and £21,000 when well maintained and £17,000 to £41,000 when neglected. A Drupal 7 rebuild is three to six months and commonly £40,000 to £120,000. These are house estimates, not published rates.

WordPress Plugin Development That Survives Core Updates

Norbert E. Boros — Sun, 01 Nov 2026 07:00:00 +0000

Most WordPress plugin development follows the same arc. Somebody needs a booking form, a feed importer or an extra field at checkout, a developer writes it, it works, everyone moves on. Two years later the site is stuck on an old version of WordPress because nobody is confident that plugin will survive an update, and whoever wrote it has gone.

The cause is rarely that core moves too fast. WordPress is conservative about breaking things, and plenty of well written plugins from five years ago still run unchanged on WordPress 7.1. Plugins break because of decisions taken in the first week: functionality put in the theme, core files edited instead of hooked, data stored in whichever structure was nearest, and nobody ever testing against a release candidate.

What makes a custom WordPress plugin survive core updates? Four things. The code lives in a plugin rather than the theme. It extends WordPress through actions and filters instead of editing core files. It stores each piece of data in the structure that matches that data's shape. And somebody tests it against every release candidate before that release ships.

Why WordPress Plugin Development Belongs in a Plugin, Not the Theme

The default home for custom code is the theme's functions.php, because it is already there and it already runs. It is also the file that disappears at the next redesign.

A theme is presentation. Change themes and everything the old theme was doing stops. Custom post types stop being registered, so the content sits in the database with no admin screen and no permalink. Shortcodes render as raw text mid page. The analytics snippet, the schema markup and the nightly call to the CRM all go, and nothing raises an error.

The rule is simple enough to put in a brief. Anything that must still be true after a redesign belongs in a plugin: custom post types and taxonomies, integrations with anything external, shortcodes and blocks, business rules, scheduled jobs, and anything that writes to the database. The theme keeps templates, styles and template parts.

The price arrives late. At the next redesign you either pay again to rebuild what already existed, or copy the old functions.php forward. On a site with years of accumulated snippets that is several thousand pounds of avoidable work, and it is why a redesign quote comes back at twice what the client expected. A child theme is still a theme.

The Extension Model, and the One Rule That Matters

WordPress is built to be changed from the outside. The mechanism is hooks, and the hooks documentation describes them as the predefined spots where one piece of code can interact with or modify another. An action fires at a defined moment and lets you do something: send a notification after a post publishes, or register a post type. A filter hands you a value, expects you to change it or leave it alone, and expects you to hand it back.

The rule that follows is absolute. If you are editing a file inside wp-admin, wp-includes or another plugin's directory, you have already lost. Those edits are erased by the next update, with no warning, no error and usually no discovery until a client reports that something stopped working. Ask a developer this directly before hiring them.

When the hook you need does not exist, wrap the behaviour rather than replacing it, move up to a broader hook, fork the third party plugin under version control with the divergence documented, or ask upstream for the hook, which is how most of them got added.

Naming, Prefixes and One Very Crowded Namespace

PHP in WordPress runs in a single global namespace shared with core, the active theme and every other active plugin. Two plugins that both declare a function called get_settings() do not compete politely: the second is a fatal error and the site is white.

Prefixes are longer than you think

The handbook's plugin best practices page asks for a unique prefix on everything globally accessible, at least four characters and preferably five, avoiding common English words and never wp_, _ or WordPress itself. With tens of thousands of plugins in circulation, three letters from the client's initials is a coin toss.

Namespaces and autoloading

Modern practice solves half of the problem. Declare a PHP namespace, put one class in one file, and let a PSR-4 autoloader find them, so there are no manual require statements and no chance of a class name colliding with another plugin's. It also makes the code testable, because classes with constructor dependencies can be instantiated without WordPress being loaded.

Autoloading does not fix two plugins shipping different versions of the same library. Whichever loads first wins. Prefix vendor namespaces at build time for anything distributed.

The strings namespaces cannot help with

A namespace covers PHP symbols. Much of what a plugin registers is not a PHP symbol but a string in a shared registry, and those still need the old prefix convention: hook names, option and transient keys, post meta keys, post type and taxonomy names, shortcode tags, cron event names, REST namespaces and custom table names. They live in a flat space where the last registration wins or two plugins silently share state.

Two limits are worth knowing before naming anything. A post type key must not exceed 20 characters and a taxonomy key must not exceed 32, both lowercase alphanumeric with dashes and underscores. A five character prefix leaves 15 characters for a post type name, which is less room than it sounds.

Choosing Where the Data Lives

This is the decision with the longest tail. Get it wrong and the plugin works fine at launch, gets slower every month as the data grows, and by the time anybody notices the fix is a migration rather than an edit.

Options and transients

Options are for site wide settings: a handful of keys, small values, read on most requests. The trap is autoloading, because every autoloaded option is fetched on every single request, including admin-ajax and REST calls, whether or not anything uses it.

WordPress 6.6 changed the mechanics, as set out in the Make WordPress Core post on disabling autoload for large options. The stored value is now on, off or auto, and an option larger than 150,000 bytes is not autoloaded by default, with the threshold adjustable through the wp_max_autoloaded_option_size filter. Treat that as a ceiling, not a target. Transients are options with an expiry, and are the right home for anything fetched from elsewhere.

Post meta is not a key value store

Post meta is for attributes of one post: a subtitle, a price, a supplier reference. It is not a general purpose key value store, and the reason is visible in the table definition. The wp_postmeta table has four columns and three keys. Only post_id and the first 191 characters of meta_key are indexed. The meta_value column is a longtext with no index on it at all.

A query filtering on a meta value therefore cannot use an index. Every clause in a meta query adds another join, and on a site with 50,000 posts carrying 20 meta rows each the table holds a million rows. Three clauses mean three joins against a million rows on every page load. It is one of the commonest reasons a site that was quick in year one is unusable in year three, and it turns up constantly in WooCommerce performance work.

Custom post types and taxonomies

A custom post type is right when the thing is content. It needs its own list screen, permalinks, revisions and an editorial workflow, and it makes sense as a page somebody could visit. A custom taxonomy is right when you need a shared vocabulary that groups those things and deserves archive pages of its own.

Both bring free machinery: admin screens, capabilities, search, the block editor and the REST API. Set show_in_rest to true or the block editor will not handle the type, and register both on the init hook, never before it.

When you actually need your own table

Your own table is right when the data is not content: high volume append only records such as event logs, import queues, price history or audit trails, or anything you will filter and sort by a field that is not a post column. Past a few hundred thousand rows queried by their own fields, a table with the right indexes outperforms post meta by orders of magnitude and stays predictable as it grows.

The cost is that you own everything: table creation and versioned migrations, cleanup in uninstall.php, your own admin screens, REST endpoints and caching. That is why the honest answer for most plugins is still a custom post type.

Security Is Four Habits, and Three of Them Get Skipped

The WordPress security handbook states the principle plainly: do not trust user input, third party APIs, or data already sitting in your database. Four habits carry almost all of the risk, and in the plugins we audit they are skipped in a consistent order. Capability checks first, nonces second, output escaping third. Prepared statements come last, because a missing one gets caught in review.

Capability checks

Every handler that changes something must ask whether this user is allowed to, which means current_user_can() with the specific capability, checked inside the handler rather than only around the button that calls it.

is_admin() is not a permission check. It reports which side of the site the request is on, and returns true for any logged in subscriber hitting an admin-ajax endpoint. An admin_post_ or wp_ajax_ action with no capability check is reachable by every registered user, which on a shop means every customer who ever ordered. Our WordPress security hardening checklist covers the site level controls around this.

Nonces

A nonce protects a form or a URL against a request the user did not intend to make. Use wp_nonce_field() in the form and check_admin_referer() in the handler, or check_ajax_referer() for AJAX. Despite the name they are not single use: they are hashes valid for a window, one day by default under a two tick scheme that puts the real lifetime between twelve and twenty four hours.

The nonces documentation is explicit that they must never be relied on for authentication, authorisation or access control. A nonce establishes that the request came from your form. It says nothing about whether that person should be allowed to do the thing.

Sanitise on the way in, escape on the way out

Validate where you can, because validation is specific: a postcode either matches the pattern or it does not. Sanitise where you cannot, with sanitize_text_field(), sanitize_email(), sanitize_key(), absint() or wp_kses_post() depending on the field.

Then escape at the point of output, every time, with esc_html(), esc_attr(), esc_url() or wp_kses_post(). The escaping documentation asks for this as late as possible, so a reviewer sees escaping and output on the same line. Escaping gets skipped more than anything else because nothing looks wrong when you skip it. The page renders perfectly until somebody puts a script tag in a field.

Prepared statements

Any query you write yourself goes through $wpdb->prepare(), which takes %d for integers, %f for floats, %s for strings and %i for identifiers such as table and column names. Placeholders are left unquoted, a literal percent sign is written twice, and a LIKE wildcard is passed inside the substitution argument rather than typed into the query. Concatenating a variable into SQL is not a style disagreement, it is the vulnerability.

The REST API and the Block Editor

A plugin written this year should expose its data through the REST API and its settings through the editor, not through a hand rolled options page.

Routes are registered with register_rest_route() on the rest_api_init hook. Since WordPress 5.5 a permission_callback argument is required, and omitting it triggers a _doing_it_wrong() notice naming the route. A genuinely public endpoint uses __return_true, which is the point of the design: making a route public becomes a deliberate line of code instead of an omission. The custom endpoints documentation also covers the argument schema, where sanitisation and validation callbacks belong so bad input never reaches your handler.

Settings are registered with register_setting() and show_in_rest set to true. That puts them on the core settings endpoint, so the block editor or an external script can read and write them through an interface that already handles authentication, permissions and validation. It removes an options page, its nonce, its form handler and the bugs living in them.

Blocks are registered from a block.json file, the recommended canonical method since WordPress 5.8. The block metadata documentation sets out the benefit: assets declared there load only on pages where the block appears, instead of site wide because a plugin is active.

Performance Discipline Inside a Plugin

Four things account for most of the plugin caused slowness we find in audits, and all four are cheap to avoid and expensive to retrofit. The first is autoloaded options, because they cost something on every request forever.

The second is uncached remote requests during a page load. A wp_remote_get() to a supplier's API with no caching means every visitor waits for that supplier. When the supplier is slow your site is slow, and when it is down your site hangs until the timeout expires. Cache the response in a transient, set an explicit timeout, and decide in advance what the page renders when the call fails.

The third is queries inside a loop. Calling get_post_meta() for each of 200 rows is 200 round trips unless the meta cache has been primed, and WP_Query primes it for you if you let it. The fix is usually to stop disabling something, which is true of most findings in a Core Web Vitals audit.

The fourth is work done inside somebody's page request. WP-Cron is not system cron: it is triggered on page load, so a scheduled job runs inside a visitor's request, and on a quiet site the two o'clock job does not run until somebody visits at five. Define DISABLE_WP_CRON, drive wp-cron.php from a real system scheduler, and keep jobs short and idempotent.

Surviving Core Updates: The Part Nobody Budgets For

Core rarely deletes anything outright. Functions get deprecated, keep working and emit a notice, which is why running staging with WP_DEBUG enabled is the cheapest early warning system available. A deprecation notice is a dated invitation to fix something while it is still cheap.

The process that prevents surprises costs about an hour a quarter. Follow the core development blog so you know when a beta and then a release candidate exist. Read the Field Guide, published during the release candidate phase, which lists that release's developer facing features and breaking changes. Then put the release candidate on a staging copy and run a written smoke test of the plugin's real functions.

Version support matters as much as the code. WordPress requires PHP 7.4 as an absolute floor and recommends 8.3 or newer, alongside MariaDB 10.11 or MySQL 8.0. Declare Requires PHP and Requires at least in the plugin header honestly, then test on the lowest version you declared rather than on whatever the developer's laptop runs.

Version your own plugin semantically and mean it. A patch fixes something, a minor adds behaviour without breaking anything, and a major may break provided it says what it broke. Clients on automatic updates rely on that promise.

Distribution, Licensing and How Updates Reach the Site

WordPress is released under the GPL version 2 or later, and the wordpress.org licence page sets out the project's position that plugins and themes are derivative works which inherit the licence, while acknowledging a legal grey area over what counts as derivative.

You get the source, always, and you can hire anybody else to modify it. What the GPL does not do is force you to publish it, so a plugin built for one business can stay private. It also does not stop the developer selling the same work to somebody else. If exclusivity matters, that is a contract term rather than a licence term.

If the plugin goes into the public directory it has to satisfy the plugin directory guidelines, eighteen of them. The first requires GPL compatible licensing for everything in the package, images included. Others rule out trialware, meaning functionality locked behind a payment or upgrade, ban obfuscated code, prohibit tracking users without consent, and forbid links or credits added to the public site without permission.

If it stays private, updates become your problem. Set the Update URI header, which exists to stop a private plugin being overwritten by a similarly named one from the directory, and serve updates from your own endpoint. Leaving this to the end is how a client ends up updating by FTP.

What a Custom WordPress Plugin Costs

The bands below are UK agency prices in GBP, for work delivered to the standard described here: with tests, documentation and a named person responsible after launch. A capable WordPress and PHP developer bills roughly £400 to £600 a day, so these are statements about scope rather than rate.

A small utility plugin runs £1,500 to £3,000. One job, a few hooks, perhaps a settings toggle: redirect handling, an extra field on an order, a nightly export to a supplier.

A mid sized integration runs £3,000 to £15,000. A third party API with authentication, retries and error handling, a custom post type, admin screens and background processing. This is the most commonly commissioned size and the most frequently underestimated, because the integration is a week and the failure handling is a fortnight.

A substantial product plugin runs £20,000 to £75,000 and upwards. Its own tables, block editor interfaces, licensing and update infrastructure, multisite support, and a support burden that begins the day it ships.

Paying at the low end is not automatically wrong. It is wrong when the price came from a scope that quietly excluded the deliverables below. Our guide to WordPress developer rates and what to ask covers how to read a quote, and our WordPress development page sets out how we scope this work.

What should be in the deliverable

Ask for all of these in writing before work starts, because every one is cheap to include and expensive to add afterwards. The source, in a repository you own, with its history intact, rather than a zip file emailed on the last day. Unit tests for the business rules and an integration test for anything that writes to the database or calls an external service, which is what makes it safe to change in two years by somebody who was not there.

A readme saying what the plugin does, what it hooks, what it stores and where, what external services it calls and what happens when each of those fails. Two pages is plenty, and its absence is why plugins get replaced rather than maintained. An uninstall.php that removes options, tables, cron events and meta. And a named support arrangement covering testing against each core release and fixing what that testing finds.

Getting It Built

Mecanik builds plugins at all three sizes above, and takes over plugins written by somebody else, often the more useful engagement. Our WordPress developer and software development pages explain how we scope and deliver. If you already have a plugin nobody wants to touch, an audit against the practices above takes about a day and tells you whether it is repairable or replaceable.

Related reading

Frequently Asked Questions

Should custom functionality go in a plugin or in the theme?
In a plugin, unless it is purely presentational. A theme gets swapped at the next redesign and everything it was doing stops: custom post types lose their admin screens, shortcodes render as raw text, and integrations silently stop running. Anything that must still be true after a redesign belongs in a plugin.

How much does a custom WordPress plugin cost in the UK?
A small utility plugin typically costs £1,500 to £3,000, a mid sized integration with a third party API and admin screens costs £3,000 to £15,000, and a substantial product plugin with its own tables and update infrastructure costs £20,000 to £75,000 or more. Developers capable of this work bill roughly £400 to £600 a day.

Is it ever acceptable to edit WordPress core or another plugin's files?
No. Those edits are erased by the next update, with no error and usually no discovery until something stops working. Use actions and filters instead. If the hook you need does not exist, wrap the behaviour, fork the plugin under version control, or ask upstream for the hook.

Do I own a plugin I paid somebody to build?
You own your copy and whatever the contract says. The GPL gives you the source, the right to modify it and the right to hire anyone else to maintain it, and it does not require you to publish it, so a plugin built for one business can stay private. It does not stop the developer reselling the same work, so put exclusivity in the contract if it matters.

How do you stop a plugin breaking when WordPress updates?
Test it against every release candidate on a staging copy before that version ships, run staging with WP_DEBUG enabled so deprecation notices surface early, and declare the PHP and WordPress versions the plugin supports in its header. WordPress requires PHP 7.4 as a floor and recommends 8.3 or newer.

Software Supply Chain Security for Small Teams

Norbert E. Boros — Sat, 31 Oct 2026 19:00:00 +0000

Supply chain security sounds like a problem for organisations with a security function, and the framing is misleading. A small team running a handful of services typically depends on hundreds of packages it has never read, pulled at build time from registries it does not control, executing installation scripts on machines that hold its deployment credentials.

The exposure is not proportional to company size. It is proportional to dependency count and build automation, and small teams often have more of the first and less scrutiny of the second than the organisations that worry about this publicly.

The uncomfortable arithmetic: your application has perhaps a dozen direct dependencies and several hundred transitive ones. You chose the dozen. You did not choose the rest, you have not read any of them, and any one of them running an install script has the same access as your build process. That is the actual attack surface, and it is not visible from the dependency list you wrote.

Supply Chain Security Starts at Install Time

The dangerous moment is usually not running the code. It is installing it.

Package managers permit scripts to execute during installation, which means a compromised or malicious package runs with the privileges of whoever ran the install. On a developer machine that is their credentials. In a build pipeline it is the deployment keys, which is worse.

Three attack shapes account for most real incidents.

Typosquatting. A package with a name one character from a popular one, published and waiting for a mistyped install command. Cheap to execute and effective at scale.

Account compromise of a legitimate package. A widely used package whose maintainer's credentials were stolen, updated with something harmful. This is the hardest to defend against because nothing about the name or the download count looks wrong.

Dependency confusion. A public package published under the name of one of your internal ones, where a misconfigured resolver prefers the public registry. Entirely a configuration problem and entirely preventable.

None of these require anyone to target you specifically, which is the point. They are opportunistic and they scale.

Controls That Repay the Effort at Small Scale

Commit the lockfile and install from it. A lockfile pins exact versions and their hashes. Installing from the manifest instead resolves fresh versions at build time, which means your build is not reproducible and an upstream change reaches production without review. Use the install command that fails when the lockfile disagrees rather than the one that updates it.

Disable install scripts where you can. Many ecosystems support this, and most packages do not need them. It is the single largest reduction in exposure available, and the packages that break are worth knowing about.

Automate vulnerability alerts, then triage. Scanners produce more findings than a small team can act on, and the failure mode is not missing alerts, it is ignoring all of them because most are irrelevant. Filter to what is reachable from your code and act on that. A queue nobody reads is worse than no queue.

Pin your build tooling too. The container image, the runtime version and the action or plugin your pipeline calls are all dependencies, and referencing a mutable tag means your build changes without you.

Separate build credentials from everything else. A pipeline that can deploy should not hold credentials that can do anything more, and a compromised build should not be able to reach production data.

What an SBOM Does and Does Not Tell You

A software bill of materials lists what is in your application, and its value is answering one question fast: are we affected by this?

That question used to take days. When a widely used component turns out to be vulnerable, an organisation with a current inventory answers in minutes and one without it spends a week searching. That difference is the whole argument, and it is why SBOM adoption is being pushed as baseline practice rather than as an advanced control.

What it does not do is make you secure. An inventory is a list, not a defence. It does not tell you whether a listed vulnerability is reachable in your code, whether it matters in your configuration, or whether anything has been compromised. Teams that generate one and file it have added a document rather than a control.

Generate it from the build, so it describes what was actually shipped rather than what the manifest claimed. Keep the one matching each release. And accept that its value is entirely in the speed of answering a question you will be asked under pressure.

Where Small Teams Actually Get Hurt

Not usually by an exotic package compromise. By ordinary things.

Secrets in the repository, which remain in history after deletion and are found by automated scanners within minutes of a push. A dependency three years out of date with a published exploit and no upgrade path, because upgrading was deferred until it became a project. Build pipelines with excessive permissions, where a pull request from a fork can run with access it should not have. Nobody watching, so a compromise persists because no alert reaches a person.

The unglamorous conclusion is that keeping dependencies current is most of supply chain security in practice. The software maintenance cost that teams treat as optional is the same work, and deferring it converts a routine upgrade into an emergency with an exploit attached.

A Proportionate Starting Point

For a small team, in order: get secrets out of the repository and rotate anything exposed. Commit lockfiles and install from them strictly. Turn on dependency alerts and triage weekly rather than continuously. Pin build tooling to immutable references. Reduce pipeline permissions to the minimum. Generate an SBOM per release once the rest is in place.

That sequence covers the realistic threats without a security function, and each step is hours rather than weeks. The controls beyond it, provenance attestation, reproducible builds, signed artefacts, are genuinely valuable and belong to a stage where the basics are already stable.

Mecanik reviews and hardens build pipelines as part of our application security work. The finding is almost never a sophisticated compromise. It is a token in a repository and a dependency nobody has updated since it was chosen.

Related reading

Frequently Asked Questions

Why is installing packages the risky moment?
Because package managers allow scripts to run during installation, with the privileges of whoever ran the install. On a developer machine that means their credentials; in a build pipeline it means deployment keys. The code does not have to be executed by your application to do damage.

What is dependency confusion?
An attack where a public package is published under the name of one of your internal packages, and a misconfigured resolver prefers the public registry over your private one. It requires nobody to target you specifically and is entirely preventable through resolver configuration.

What does an SBOM actually give you?
A fast answer to one question: are we affected by this? With a current inventory that takes minutes; without one it takes a week of searching. It does not tell you whether a listed vulnerability is reachable in your code or whether anything has been compromised, so an SBOM that is generated and filed is a document rather than a control.

Should I commit my lockfile?
Yes, and install from it strictly using the command that fails when the lockfile disagrees rather than the one that updates it. Installing from the manifest resolves fresh versions at build time, which makes builds unreproducible and lets an upstream change reach production without any review.

Where should a small team start?
Remove secrets from the repository and rotate anything exposed, commit lockfiles and install strictly, enable dependency alerts and triage them weekly, pin build tooling to immutable references, reduce pipeline permissions, then generate an SBOM per release. Each step is hours rather than weeks.

Drupal AI: What the AI Modules Actually Do

Norbert E. Boros — Sat, 31 Oct 2026 07:00:00 +0000

Drupal AI has stopped being a scatter of provider-specific contributed modules that whoever needed them bolted on separately. It is now one coordinated project with an abstraction layer underneath it, a security-team-covered release cycle, and a packaged product in Drupal CMS that offers to switch parts of it on during installation. The question worth asking has moved on from whether Drupal can do AI to which parts of it are worth turning on, and what each one costs once four editors use it every working day.

Most write-ups stop at the demo. Somebody types a prompt, a page appears, a chatbot creates a content type while you watch. The demo is real. What it does not tell you is what leaves your infrastructure when an editor clicks that button, which of the modules on the list have never shipped a stable release, and which budget line actually grows.

What does Drupal AI give a business? A provider abstraction in the AI module that routes chat, embeddings, translation and image calls to any configured vendor or to a model on your own hardware, plus submodules for alt text, translation, editorial assistance, semantic search and site-building agents. The narrow features are production ready and cost very little to run. Semantic search and agents are still alpha or immature and need real engineering built around them.

What Drupal AI Actually Is in 2026

The spine of it is a single contributed project. The AI (Artificial Intelligence) module reports 17,818 sites in use, works with Drupal 10.5 and above or 11.2 and above, and carries stable releases at 1.4.7 and 1.3.12 with a 1.5.0 release candidate published on 27 August 2026. Stable branches are covered by the Drupal Security Team, which matters more than the feature list when you are deciding whether to run something on a client site. A 2.0.x branch is in active development.

For context on the platform underneath it, the current recommended Drupal core release is 11.4.5, published on 6 August 2026, with 10.6.15 kept available for sites that have not upgraded yet. If you are still deciding whether Drupal is the right platform at all, our 2026 guide to Drupal web development covers that question separately.

The provider abstraction is the part that matters

The developer documentation states the design plainly: AI providers are services Drupal can call, and those calls have been abstracted into operation types. The named types include chat in basic and streaming forms, text to image, text to speech, speech to text, embeddings, moderation, audio to audio, speech to speech, image classification, translate text and image to image.

The consequence is commercial rather than technical. A module written against the chat operation works with whichever provider is configured, so changing vendor is a configuration change rather than a rewrite. Drupal's own providers page lists 48 integrations, including OpenAI, Anthropic, Google Gemini and Vertex, AWS Bedrock, Azure, Mistral, Groq, Hugging Face, DeepL, Deepgram, ElevenLabs, LiteLLM, LM Studio, Ollama and amazee.ai.

That portability has a limit worth stating early. The interface is portable; the prompts are not. A prompt tuned against one model frequently produces worse output against another, so a provider switch is cheap in code and costs a round of prompt testing.

What ships in the box

The AI project bundles a core layer plus submodules for automators, an API explorer used for debugging, observability and logging, a chatbot, CKEditor integration, and an assistants and agents API. Several capabilities that started inside it have since moved out to their own contributed projects, which is why the ecosystem looks scattered when you first search for it. AI Search, AI Content Suggestions, AI Translate, AI Validations, AI ECA and Field Widget Actions now have separate release cycles and very different maturity levels.

How Drupal CMS Packages It

Drupal CMS is a separate product rather than a version of core, aimed at marketers and content teams rather than developers. Drupal CMS 2.0 shipped on 28 January 2026, built on Drupal core 11.3, and the release line has kept moving since: 2.1.4 was published on 1 September 2026.

The AI capability it packages is deliberately narrow. It generates complete pages from text prompts using the available Canvas components, runs an admin chatbot for site-building tasks such as creating content types, defining taxonomy terms and adding fields, generates alt text with human review in the loop, and provides a dashboard showing which features are on and which providers are configured. The setup flow offers amazee.ai, OpenAI and Anthropic.

The word in the release announcement that should shape your risk assessment is "optional". Nothing in a Drupal CMS install calls a model until somebody configures a provider and supplies credentials, so a fresh install is not by itself a data protection question. It becomes one the moment an administrator pastes an API key into the provider form, which is usually done by whoever is fastest rather than whoever is accountable.

The Applications That Earn Their Keep

Alt text and media metadata

The AI Image Alt Text module reports 10,467 sites and released 1.0.2 on 5 December 2025 for Drupal 10.2 and 11. It puts a Generate button on every image field widget, supports multilingual content and custom prompts, and ships a bulk submodule for regenerating alt text across images already on the site.

This is the clearest win in the whole set, because it targets work that never gets done otherwise. A library of six thousand images represents weeks of manual writing that no organisation funds, so the alt attributes stay empty and the accessibility audit keeps failing on the same line every year. Generation plus review turns that into a few days, provided the review actually happens.

Translation across a multilingual site

AI Translate reached stable 1.4.0 on 27 August 2026, reports 886 sites and works with Drupal 10.4 and above or 11. It adds one-click translation to Drupal's own content translation system, working from the Translate tab, handling multiple field types and referenced entities.

The important design point is that it fills Drupal's existing translation workflow rather than replacing it. Revisions, moderation states and permissions stay exactly where they were, and a human can edit the result through the normal interface. That is the difference between a translation feature you can put in front of a regulated client and a bolt-on that bypasses your editorial controls.

Editorial assistance and taxonomy

The AI project ships CKEditor integration, and the AI Content Suggestions module moved out to contrib to cover summarisation, readability scoring, moderation, tone adjustment, title generation and taxonomy tag suggestion inside the authoring experience. This is the busiest and least settled corner of the ecosystem, and the modules here change shape between releases more than the rest.

Before planning around any of them, read the reported install count on the project page. Alt text sits above ten thousand sites; several of the editorial modules sit in the hundreds. That is not a judgement on the code, it is a measure of how much production shaking-out it has had, and it should decide how much testing time you budget.

Semantic Search Is the Feature Most Likely to Disappoint

AI Search is the module people ask for by name and the one least ready to be switched on. As of 2 September 2026 it has no supported stable release: the 1.x branch sits at 1.3.0-alpha4 from 12 July 2026 and the 2.x branch at 2.0.0-alpha2 from 24 June 2026, with 703 reported installs.

It also brings infrastructure with it. It runs as a backend for the Search API module and requires a vector database, with support for Milvus, Pinecone, Qdrant, PostgreSQL, MariaDB, OpenSearch, Azure and SQLite. The honest description is alpha software plus a datastore your team now operates, monitors and backs up. That is a project, not a checkbox.

The deeper problem is upstream of the module. Semantic retrieval is only as good as the chunks you feed it, and a content set written as long pages covering six loosely related topics embeds into vectors that mean nothing in particular. Sites that get good results from vector search almost always restructured their content first, and that restructuring is the actual work.

Agent-Style Site Building

The AI Agents module is a framework for text-to-action agents, at stable 1.3.4 since 13 August 2026, with 9,677 reported installs and support for Drupal 10.3 and 11 or higher. It ships three agents out of the box, covering fields, content types and taxonomy, and integrates with the chatbot and the AI Assistants API.

Used well, this is genuinely useful for the tedious middle of a build. Creating thirty fields across six content types by hand is an afternoon of clicking that produces no design value, and an agent does it in minutes from a description. What it does not do is decide what those content types should be, which is the part that determines whether the site still works in two years.

One operational rule separates a time saver from an incident. Run configuration agents against a development environment with configuration export enabled, never against production, so every change arrives as a reviewable diff in version control. Our guide to AI agents in business, their costs and failure modes covers why unreviewed agent actions are the most expensive category of AI failure.

Hosted API or a Model You Run Yourself

The abstraction gives you three shapes, and the choice moves cost, latency and data handling in different directions.

A hosted vendor API is the default. It is cheapest to start, needs no infrastructure and gives access to the strongest models. It also means content leaves your network on every call, and your running cost is a variable bill you do not control.

A private or managed endpoint from a provider that contracts on data residency sits in the middle. You still pay per token, but you can point at a region and get contractual terms about processing. It is what most UK and EU clients end up choosing.

A model on your own hardware, served through Ollama or LM Studio and configured as a provider, is the only version where content never leaves your infrastructure. The cost shape inverts: instead of a per-token bill with no floor, you pay a fixed monthly cost for the machine whether you make ten calls or ten million.

Latency matters less than people expect for editorial work, because an editor waiting a few seconds for generated alt text does not care where the model runs. It matters when a model sits in the request path of a public search or chatbot, which is exactly the case where self-hosting is hardest to size.

Quality is the honest trade. Open-weight models have closed most of the gap on constrained tasks such as alt text and translation, where the instruction is simple and the output is short. They remain behind on long-context summarisation and on the multi-step instruction following that agentic configuration changes require.

What Drupal AI Costs to Run

Token pricing is published per million tokens and quoted in US dollars. OpenAI's pricing page currently lists gpt-5.6-luna at $0.20 input and $1.20 output, gpt-5.6-terra at $2.00 and $12.00, and gpt-5.6-sol at $4.00 and $20.00 on short context. Cached input is roughly ten times cheaper than fresh input on each tier, which matters a great deal for retrieval workloads that resend the same context.

A worked estimate for editorial features

These are estimates, and they are built from assumptions you should replace with your own measurements. Take a 900-word page. Source text plus a system prompt lands near 1,500 input tokens, and a translation of it near 1,600 output tokens, because most target languages expand.

On the mid tier, that is about $0.003 of input and $0.019 of output, so roughly $0.022 per page per language. Translating a back catalogue of 500 pages into eight languages is 4,000 calls and about $88, once. Keeping up with 40 new pages a month across the same eight languages is about $7 a month.

That number usually surprises people in the wrong direction. They have budgeted for a large AI bill and the editorial features cost less than the coffee. Alt text and taxonomy suggestion are smaller still, because the outputs are a few dozen tokens each.

The number that does bite

Retrieval is different, because every query resends the retrieved passages to the model as input. Ten passages of 500 tokens is 5,000 input tokens plus a question, with maybe 300 tokens of answer.

On the cheapest tier that is about $0.0014 per query, so 50,000 queries a month costs about $70. On the mid tier the same traffic costs about $680. Model choice moves that bill by a factor of ten, and prompt caching moves it again.

This is also the one feature whose cost tracks visitor traffic rather than editorial volume. Everything else scales with how much your team publishes, which is predictable. A public AI search or chatbot scales with how many people visit, which is not, and it is the feature that produces the alarming invoice.

What the estimates leave out

Vector database hosting is a separate line, whether that is a managed service or a server your team runs. Embedding the corpus once is cheap; re-embedding on every content save is not, and nobody models it. Failed and retried calls are billed. And the review step is labour rather than tokens, which is why it is almost always the largest number on the page.

Data Protection Is Where UK and EU Projects Stall

When an editor clicks Generate, the field content and your prompt go to the configured provider. Under a hosted API that is a transfer of data to a third party, and it happens on every call, silently, from an interface that looks like the rest of the CMS.

The specific risk in a content management system is that people underestimate what it holds. Articles are the safe part. Comments, user profiles, webform submissions, editorial notes and unpublished drafts about named individuals are all personal data sitting in the same database, and an automator configured a little too broadly will happily send them.

Controller and processor

You do not transfer responsibility by using a vendor. The ICO's guidance on accountability and governance in AI is explicit that overall accountability for data protection compliance lies with the controller, meaning your organisation, and that identifying controller and processor relationships is part of the exercise rather than a formality.

The same guidance sets a clear expectation on impact assessments. It states that in the vast majority of cases, the use of AI will involve processing likely to result in a high risk to individuals' rights and freedoms and will therefore trigger the legal requirement to undertake a DPIA. Where you assess that a particular use is not high risk, you still have to document how you reached that conclusion. Note that the guidance is currently under review following the Data (Use and Access) Act, so recheck it before relying on the detail.

The EU AI Act transparency obligations

If you serve EU users, Article 50 of Regulation (EU) 2024/1689 applies. Article 113 sets the general application date as 2 August 2026, which has passed, so these are live obligations rather than future ones.

Three parts touch a CMS directly. Article 50(1) requires that systems intended to interact directly with people are built so those people are informed they are dealing with an AI system, unless it is obvious. That is your site chatbot. Article 50(2) puts a marking obligation on providers of systems generating synthetic content, with an exemption where the system performs an assistive function for standard editing or does not substantially alter the input.

Article 50(4) is the one that changes how you staff a project. Deployers who generate or manipulate text published to inform the public on matters of public interest must disclose that it was artificially generated, and the obligation does not apply where the content has undergone human review or editorial control and a natural or legal person holds editorial responsibility for it. The review step you were tempted to cut is the same step that discharges the disclosure duty.

Where It Fails

Metadata nobody reads

Alt text generated in bulk and published unread is the most common failure, because the feature makes it so easy. A vision model describes what is in the frame, not what the image is doing on the page, so a product photograph becomes "a person holding a bottle" rather than the product name. For a screen reader user that is worse than an empty attribute, because the page now looks remediated and nobody will revisit it.

The same applies to generated summaries and meta descriptions. They read fluently, which is precisely why reviewers skim them, and a fluent wrong summary survives review far longer than an awkward right one.

Search that is worse than the search it replaced

Two failure modes stack. The first is structural: badly chunked content produces retrieval that returns approximately relevant passages instead of the right one. The second is a regression nobody anticipates, which is the loss of exact matching. A user typing a part number, an invoice reference or a surname wants that exact string, and pure vector search returns documents that are semantically about part numbers.

The fix is hybrid retrieval, running keyword and vector search together and merging the results. That is standard practice, and with AI Search sitting at alpha it is usually something you build rather than configure.

Translation that drifts from the source

Machine translation of a page is fine. Machine translation of a page that later changes in English, with the translations left untouched, is a site that quietly contradicts itself in seven languages. Nothing in the module tracks source staleness for you, so somebody has to own re-translation as a process.

Numbers deserve their own check. A translated page that renders a price in the wrong currency symbol, or converts a figure the English never converted, creates a commercial dispute rather than a typo.

The review step nobody budgeted

Every feature here moves work rather than removing it. Generation takes seconds and review takes minutes, so at 500 pages the review is the project. Teams that budget only for implementation discover this in week three and quietly stop using the feature, which is how AI pilots die.

What You Still Have to Build

Governance comes first, because the modules give you capability without policy. You need to decide which roles can use which feature, on which content types and fields, against which provider, and then enforce it in configuration rather than in a wiki page.

Prompts belong in version-controlled configuration, reviewed and deployed like any other change. Prompts typed into a production form by whoever was on shift are untested code with direct cost implications.

Spend control is not included. The observability submodule logs calls, which tells you what happened after it happened. A misconfigured automator looping over a large content set needs a hard cap at the provider, plus an alert.

You also need fallbacks. A provider outage should degrade the authoring experience gracefully, not prevent an editor saving a node. This is ordinary integration engineering, and it is the part that separates a demo from a deployment. If you are also weighing up front-end architecture at the same time, our comparison of headless and traditional CMS approaches is the companion decision.

What an Implementation Costs

Rates first, since everything else derives from them. UK Drupal contract rates run roughly £400 to £550 a day for mid-level and £550 to £750 for senior work, as set out in our guide to hiring a Drupal developer.

A narrow deployment, meaning the AI module, one configured provider, alt text and translation, role-level governance and support for your DPIA, typically lands at £4,000 to £9,000. A full editorial suite adding taxonomy suggestion, CKEditor assistance, prompts held in code and spend monitoring runs £10,000 to £25,000.

Semantic search or a public chatbot over a substantial content set is a different order of work. Hybrid retrieval, a chunking strategy, vector infrastructure and an evaluation harness that tells you whether the new search beats the old one puts that at £25,000 to £60,000. Token spend sits on top of all three and is usually the smallest line in the first year.

Two costs sit outside the development budget. The DPIA and the provider contract review are legal and data protection work, and editorial review capacity is a staffing decision rather than a project line. Scoping both is part of our AI integration services engagement, because a project that ships without them ships a liability.

Getting It Deployed

Mecanik builds these integrations on Drupal as part of our software development work, and the pattern is consistent across clients. The modules install in an afternoon. What takes the time is deciding which features justify their review burden, keeping content out of a third party's logs where it should not go, and building the governance and monitoring the contributed modules deliberately leave to you. If you want that scoped against your own content set and your own regulatory position, our AI integration services page is the place to start.

Related reading

Frequently Asked Questions

What does the Drupal AI module actually do?
It provides an abstraction layer that turns AI calls into operation types such as chat, embeddings, text to image and translate text, then routes them to whichever provider you configure. Submodules build on that layer to deliver specific features including alt text generation, content translation, taxonomy suggestion, semantic search and site-building agents. The base module does nothing visible on its own until you install a provider, supply credentials and enable the submodules you want.

Is Drupal AI free to use?
The modules are free and open source under the same licence as Drupal core, but the model calls are not. Every generation, embedding and retrieval sends tokens to whichever provider you configured, and that provider bills you per million tokens in its own currency. Running a model on your own hardware removes the per-token bill and replaces it with a fixed monthly cost for the machine that serves it, which is cheaper only above a certain volume.

Does Drupal AI send my content to a third party?
Under a hosted provider, yes. The field content and your prompt leave your infrastructure on every call, and a content management system holds personal data in comments, user profiles and webform submissions as well as in articles. You remain the controller under UK GDPR, the ICO expects a DPIA in the vast majority of AI deployments, and a self-hosted model is the only configuration where nothing leaves your own servers.

Is Drupal AI Search production ready?
Not on its own. The AI Search module had no supported stable release as of 2 September 2026, only alpha builds on both branches, and it requires the Search API module plus a vector database that your team then has to operate. Sites getting good results from it have built hybrid retrieval and a chunking strategy around it, so treat it as one component of a search project rather than a module you switch on.

How much does a Drupal AI implementation cost?
A narrow deployment covering the AI module, one provider, alt text and translation, role-level governance and DPIA support usually runs £4,000 to £9,000. A full editorial suite with prompts held in code and spend monitoring runs £10,000 to £25,000. Semantic search or a public chatbot over a large content set, with hybrid retrieval, chunking and evaluation, runs £25,000 to £60,000, and token spend sits on top as the smallest line.