WordCamp Europe 2026 ran June 4 to 6 at the ICE Kraków Congress Centre, with 2,458 ticket holders from 81 countries and 49 talks across the tracks. The official recap on WordPress.org covers the whole program, so I’ll skip the pierogi and get to the two things I keep thinking about: home.cern now runs on WordPress, and WordPress 7.0 shipped an AI layer into core. The first is a blueprint, and the second changes what I’d build for clients this year.
I think the CERN keynote was the most useful session of the event for people who build sites for a living, even though the AI sessions got more of the room’s attention. An institution that has published the web’s first website for three decades rebuilt its entire web presence on a shared WordPress platform, then stood in front of 2,400 builders and described how. That’s a reference architecture, freely explained, and most agencies I know are quietly trying to build some version of the same thing.
CERN built the platform agencies keep promising
Joachim Valdemar Yde and Francisco Borges Aurindo Barros described a setup with four moving parts. There’s a self-service portal where anyone at CERN can request a site, and behind it a shared distribution: one common theme plus a curated set of approved, security-hardened plugins. An in-house provisioning tool puts each new site on Kubernetes in about a minute, and it has already set up hundreds of sites in its first year. On the migration side, a single command lifts a site’s pages, headings, and images and rebuilds them as Gutenberg blocks, with no downtime. They plan to open source that tool.
“As of today, our main flagship website, home.cern, is now served on WordPress. It’s been automatically migrated, and it’s live.” (Joachim Valdemar Yde, CERN web manager)
This matters for client work more than the hosting glamour does. The curated plugin list shrinks the surface you support, because every plugin on the allow list is one you have vetted and can patch across the fleet in one place. The self-service portal removes the agency as a bottleneck for routine work, which is where small retainers bleed out. And the automated block migration attacks the part every legacy project stalls on: content conversion. I have spent a lot of hours explaining to clients why a 400-page site cannot just be “moved into blocks,” and CERN answered that with a command.
Kubernetes and a dedicated platform team are out of reach for most shops, and you don’t need either for a dozen client sites. The part worth copying is the distribution: a versioned starter theme and an allow list of plugins, maintained as a product, where anything outside the list goes through review before it touches a live site. A two-person shop can do that. What I’d skip is the orchestration, until the site count makes it pay for itself.
The WordPress 7.0 AI layer is plumbing
WordPress 7.0 put three pieces into core: a native AI client, an Abilities API that lets plugins declare what they can do in a way other tools can discover, and a Connectors screen under Settings > Connectors for wiring up OpenAI, Anthropic, or Google Gemini. The 7.0 field guide has the details, and one fact matters more than the feature list: keys live in that one screen, core handles request routing, and the layer stays inert until an administrator connects a provider. Treat it like the REST API, as an interface you build on rather than a feature to sell.
So my advice is to stop writing bespoke provider integrations. If a client feature needs a model, call the client and let core route it, and guard against the feature shipping on a site that hasn’t updated yet:
if ( function_exists( 'wp_ai_client_prompt' ) ) {
$builder = wp_ai_client_prompt();
// Chain prompt config, then request the result.
}The Abilities API is the piece with legs for stores. Register what your plugin can do (“search products”, “look up an order”) as structured abilities, and anything agent-shaped on the site can find and call them without knowing your code. The 7.0 cycle was already the story at WordCamp Asia’s contributor day earlier this year, and the closing chat in Kraków pushed the same line. Matias Ventura pointed out that models already use WP-CLI fluently, and Studio Code is the project’s own open source, agent-based coding tool. Your code is about to be read by machines as often as by people, and that only works if what the code does is machine-readable.
What I’d take from WordCamp Europe 2026
The smaller sessions had the usual share of things worth stealing. Two Plugins team reviewers, who have between them reviewed more than 25,000 plugins, named the avoidable issues that keep good plugins stuck in the review queue, which for a first-time author is the difference between an afternoon and a month of waiting. Jessica Lyschik made the case that accessibility-ready requirements are easier to meet than most theme developers assume. Peter Wilson walked through the caching work that made WP_Query faster at scale. None of it is glamorous, but all of it shows up in invoices.
If you maintain client sites, this is my short list after the event:
- Read the field guide before your next estimate touches anything AI-shaped.
- After updating a client site, check Settings > Connectors and decide deliberately whether it stays empty.
- Audit anything you ship that talks to a model provider directly, and plan the move to the core client.
- Watch for CERN’s migration tool when it’s open sourced, and test it on your ugliest legacy page first.
The open question I left Kraków with is whether that migration tool survives contact with real client content. Clean academic markup is one thing; page builder soup, dead shortcodes, and a decade of inline styling is another. If it copes, the CERN model stops being a laboratory story and becomes the sane default for anyone holding a pile of legacy sites, which is why I’ll watch the release closely. If it doesn’t, we’re back to hand-migrating one site at a time. If you’re facing a pile like that and want this route scoped for your sites, that’s work I do, and I’m glad to look at what you’ve got.
