We are back from Rotterdam, and we are still blown away. Three weeks later we are still processing what happened. We brought a whole bouquet of topics: structured concurrency for PHP, Translation Bliss, our page builder session and CrowdPower.Digital. Some days felt a bit like a movie. One conversation led to the next, and suddenly we were at a table with people whose names we have read in the issue queue for years.
The scene we keep replaying is about structured concurrency, so we start there.
Four days before DrupalCon, Merlin published his series "PHP Structured Concurrency and Beyond": history and vision, ownership, structured state and call for backers. It is the fruit of years of experimenting, learning and trying.
Our first conversation was with catch (Nathaniel Catchpole). He listened, gave us hints for the path into core, and then passed us on. That is how we spent contribution day at a table where, over the course of the day, justafish (Sally Young), webchick (Angie Byron), kingdutch (Alexander Varwijk), who opened the Revolt issue in 2024, bircher (Fabian Bircher), alexpott (Alex Pott) and others sat down with us. Each conversation took its own turn, into ownership, state, the core patches it would take, or how to bring something this size into Drupal at all. That is the Drupal community: one person hears you out and introduces you to the next. Nobody owed us that.
We also arrived with an unusual message: we have built something, we will keep building it, and it has a price tag. Everyone we talked to knows the problem of how to fund open source. Everyone welcomed the attempt, and some backed it with their own personal commitment.
The open question we took home is who pays for what. Structured concurrency makes the PHP concurrency ecosystem easier to maintain. That is a big gain, but nobody pays for it on its own. Structured state fixes bugs that hurt today, but they do not hurt enough for anyone to pay for the fix either. What companies pay for is a faster website. So the offer we are working on has two sides. The foundations belong in core, where every Drupal site gains from them. Companies that want the full performance gain pay for the system that delivers it, and with that for the maintenance of the whole.
That is why Merlin is building out the prototype: several site scenarios on FrankenPHP that stand to gain most from structured concurrency and structured state. On each one he hunts for further state bugs and measures what the approach saves against the same site as it runs today. Those numbers are the first thing a company will ask for, and most of our bench time goes there right now. What structured concurrency means for Drupal and how the work goes on will follow in a workshop report from Merlin's bench.
On Tuesday Merlin hosted a BoF, Drupal on persistent servers: Connecting the dots. Drupal 11.4 boots through symfony/runtime, which brings FrankenPHP worker mode, RoadRunner and Swoole within reach. The BoF gathered what still stands in the way when one process serves many requests: sessions, static caches, services that keep request state, globals set at boot, exit and output buffering, and database connections that live for hours.
Translation Bliss started as our answer to some really nasty multilingual bugs in core. Merlin wrote a new suite of modules for a more streamlined way to translate a site. Translation Bliss keeps config in one copy in its source language and translates it on read through interface translation, adds a language selector to every config form, and exports and imports every translation as .po files with Drush, so translations live in git and go through review like code. Along the way it fixes a whole range of other multilingual bugs: config translations that go stale after an edit, shipped config that core relabels into the site language, config written in German that used to block a later English translation, and config that ends up in an unexpected language, which is what crashes the Canvas editor today (#3591850); one Drush command finds that config, another relabels it. It is at 1.0.0-alpha17 and already runs on our production sites; eight sites report using it on drupal.org.
We wanted to know what a path into core would look like, so we talked to alexpott and Gábor Hojtsy. Improving a long-standing system is always hard when people have learned to live with its bugs, and sites have built workarounds around these ones since Drupal 8. Their advice was to let Translation Bliss mature in contrib and to study how agencies run translation in their daily workflows. Later Gábor Hojtsy came over to us and thanked us for pushing things forward: "We need people like you." That one stayed with us.
We still think it is time to fix multilingual, not least because it was the first of six demos in the Driesnote, with a language selector in the Drupal CMS 2.2 installer and full translation support in Canvas. Our page builder research ran into one of the core bugs Canvas is affected by: Canvas rebuilds its config copy of a component in the language of the request, so a cache clear on a German page writes German labels and a new version hash into config (#3555538). Translation Bliss keeps config in one source language and translates on read, so a cache clear in any language writes the same config.
Full house on Wednesday afternoon for Page Builder Deathmatch: Canvas vs Display Builder in a Real World Project. Almost half of the room had already worked with one of the two builders. We built the same site in both: the website of a housing cooperative that finances its homes through member shares and direct loans from supporters. The checklist from the abstract is our last slide, six questions to ask about your own project before you pick a builder. We hope everybody took something home. The recording is on YouTube, and the slides are here.
You attended our session? We are keen to get your feedback.
The housing cooperative in our session is a real pattern, and it is the reason we have a second venture. Housing cooperatives, community energy groups, farms and village shops finance themselves through their own members and supporters: member shares, direct loans, subordinated loans. Raising that money is a campaign with the website at its hub. The subscription form on the Mitmachen page of our demo site was real: it comes from CrowdPower.Digital, our SaaS for exactly this kind of campaign. Then comes the part that keeps a community project busy for decades: contracts, regulatory requirements, interest and payouts, communication with hundreds of small investors. CrowdPower.Digital covers that too, with software and consulting for both ends, the campaign and the years after it. Of course we talked about it a lot in Rotterdam. Many people encouraged us to keep pushing this vision forward, and for a team of two that means a lot.
If you are interested in any of these topics, write to merlin [at] hook-dev-alter.com or andi [at] hook-dev-alter.com. Thank you, Rotterdam, and thank you to everyone who sat down with us.
Andi has a passion to make tech work for people. When he isn't building or debugging websites, he often finds himself digesting and prioritizing customer requirements, writing documentation and designing interfaces. He has a strong drive bringing teams and projects on track quickly and checking in with everybody before things go wrong.
