The DrupalCon program is always more than any one person can take in, so ahead of Rotterdam I want to lay out where Tag1 will be and how to connect with us. We have seven talks across Tuesday the 29th and Wednesday the 30th.
If you are coming, treat this as a map to where we will be and what we will be talking about. If you are not, the lineup is a fair read on where our heads are this year. A good deal of it is AI a team can put to work in a Drupal project today. More of it is the unglamorous work inside Drupal core, the parts nobody demos but everything else leans on. And one talk is the client story that keeps the rest honest. The full DrupalCon schedule covers everything beyond our own sessions; the times below are all local CEST.
First Stop, Afloat: The Enterprise Drupal AI SummitThe week opens on Monday the 28th, before any of the DrupalCon sessions, with a full day at the Enterprise Drupal AI Summit aboard the SS Rotterdam, the former ocean liner. It's a strategy day rather than a code day, built for senior decision-makers in government, higher education, and large enterprises, with a program on data sovereignty and running AI on enterprise platforms. Tag1 is there as both a summit sponsor and a Certified Gold Partner and Maker in the Drupal AI Initiative. The certification marks demonstrated Drupal AI expertise and a commitment to the Drupal code and community, and it fits a longer pattern. Data sovereignty is also where my own session picks up the next day, so if that is the thread you care about, the summit is the place to start.
Next Stop, Ashore: The DrupalCon Sessions Tuesday, September 29 From Shadow AI to Sovereign AI InfrastructureOften, AI use inside a company was never approved by IT. It arrives through a browser extension, a personal account, a tool someone tried because it saved them an afternoon, and it stays out of the security review until something goes wrong. That is shadow AI. Thomas and I walk through an alternative: a private AI gateway that gives an organization visibility into how AI is being used without pushing teams off the tools they like or slowing them down. My part is how Scolta uses amazee.ai's private AI infrastructure to add secure AI capabilities across Drupal, Laravel, and WordPress, so the AI a site needs does not come with the governance gaps shadow AI opens. If this is a challenge your organization is facing, come find me after and we can compare notes.
Wednesday, September 30 Rebuilding the LMS Mid-Flight: A Drupal Success Story with AFT and AFL-CIORebuilding a live LMS is risky. Rebuilding it while it powers mission-critical training for organizations like the American Federation of Teachers and the AFL-CIO is even harder. This session takes you through that journey—from growing pains and technical debt to a fully reimagined Drupal-native solution—sharing the lessons learned along the way.
Inside the Pyramid - A path to faster, clearer Drupal testingThe test pyramid has been a cornerstone of software quality for decades, yet Drupal core has no formal guidelines instructing contributors how to write automated tests. This session will cover both the current state – discussing techniques to write faster tests – and how to change Drupal to make these improvements structural.
A joyful tour through the CLI now in Drupal CoreIt finally happened! A CLI in Drupal core. With the help and blessing of the Drush maintainers, Drupal core has gained its own extensible CLI. Learn how to use it, and develop and test commands for it.
Client Spotlight Scolta: Drop-in AI Search Without a Search ServerWhat if you could replace Solr with something that runs in the browser, costs almost nothing, and delivers better results out of the box? Scolta is an open source search toolkit that does exactly that: client-side search powered by Pagefind, with an AI layer for query expansion and summaries.
How we made the biggest performance gains in a decade in Drupal coreDrupal 11.4 reduced database queries and cache I/O by around 50% compared to Drupal 11.0, as well as various front end performance improvements. This session will explain how we got there and give you tips for applying these techniques to your own site.
AI-Powered Site Building in Drupal: From Blank Site to Styled Pages in a Conversation Francesco Pesenti Francesco QuagliatiBuilding a complete Drupal site demands expertise across content types, taxonomy, menus, block configuration, and styling. What if a non-technical user could describe what they need in plain language and get back fully structured, styled pages, then refine everything through conversation?
Come Find UsA lot of the work in these talks usually sits out of sight, in performance, testing, and the plumbing of AI workflows, so a week like this is one of the few times it surfaces all at once. If any of it is close to what you're working on, catch me or any of the team between sessions and let's talk. We would love to hear about the hard problems you're working to solve.
Any long-lived Drupal site, whether it stores files in a local folder or a remote bucket like Amazon S3, holds hundreds of files, and there is no easy way to see which ones Drupal still tracks and which it has lost sight of. The files come from four places: live content, leftovers from nodes deleted years ago, migration and backup residue, and direct uploads, such as a PDF dropped onto the server because it was faster.
This is a common problem in the sector, and it does not depend on the technology in use. Every content system faces it sooner or later. The root cause is two stores that must agree: the bytes in storage versus the database that is supposed to keep track of them. The moment both stores exist, they drift. It happens in three ways: records get deleted but the files stay, files get uploaded but never registered, and jobs fail halfway.
These accumulated unreferenced files are untracked files, a kind of dark data: information an organisation keeps but no longer uses.
The cost of untracked files…On an editorial site, it is often useful to give articles, documents and other content types their own administration listings. Editors can then work with one type of content at a time, with an "Add Article" or "Add Document" button alongside the relevant list.
Maintaining a separate button definition for every listing means keeping the same relationship in two places. Whenever we add a listing or change which content type it shows, we need to remember to update its creation action too. This article shows how to avoid that duplication with a local action deriver.
When those listings are built with Views, their content-type filters already tell us which creation form belongs on each page. We can use that information to generate the buttons, keeping their definitions in step with the listings they belong to.
Illustrative mockups with example content. Each listing offers its own creation action.
A creation button for each listingDrupal provides these buttons through local actions. To add one, we specify its label, where it links to and which page should display it. For an article listing, that could take a short YAML definition in listing_actions.links.action.yml, assuming the custom module's machine name is listing_actions:
listing_actions.add_article: title: 'Add Article' route_name: node.add route_parameters: node_type: article appears_on: - view.content.page_articlesHere, appears_on places the button on the article listing. The route name view.content.page_articles assumes that the View's ID is content and its page display's ID is page_articles, following the pattern view.{view_id}.{display_id}. Clicking it opens the node.add route, where the node_type parameter selects the article creation form.
We could add another entry for documents and continue in the same way for other listings. That is a good fit when each action needs its own wording or destination. If all the listings follow the same convention, though, we can get those values from existing configuration: the View identifies the display and content type, and the content type supplies its label.
A plugin deriver lets us build those entries from the existing configuration. It returns several plugin definitions that share one implementation—the same approach I described in my 2014 post about block derivatives. The early Drupal 8 code in that post is outdated, but the idea applies to local actions too.
Which displays qualify?For this example, we will use a View named content, with a page display for each listing. To choose the right creation form, the deriver needs to know that a display lists exactly one content type. The configuration therefore needs to follow a few conventions:
The key type_1 identifies a particular filter in the View's configuration; the content type it selects has its own machine name, such as article. Your View may use a different filter key, for example type. To find it, export the View and look under display → your_display_id → display_options → filters in views.view.content.yml. Find the entry with entity_type: node and field: type, then use its key in place of type_1 in the PHP example. As written, the deriver expects that same key on every eligible display.
These constraints let the deriver read the filter straight from each display's stored configuration. It skips displays that inherit their filters; to support those as well, we would need to read their effective options through the Views display API.
The example also relies on a cache rebuild after configuration changes, so it fits a deployment workflow that imports configuration and then rebuilds caches. We will look at that requirement after the implementation.
Register the deriverWith those conventions in place, we can replace the individual action entries with one definition that points to the deriver. In an enabled custom module named listing_actions, put this in listing_actions.links.action.yml:
listing_actions.content_add: class: Drupal\Core\Menu\LocalActionDefault deriver: Drupal\listing_actions\Plugin\Derivative\ContentLocalActionsLocal actions use YAML discovery, so this entry is how Drupal finds the deriver. The class property keeps core's LocalActionDefault as the implementation for every generated action. All we need to supply is the code that works out their labels and routes.
Read the displays and build the definitionsTo load the View and its referenced content types, the deriver needs the entity type manager. The complete class uses ContainerDeriverInterface to receive that service from Drupal. Save it as src/Plugin/Derivative/ContentLocalActions.php inside the module so it matches the class named in the YAML entry.
Most of the work happens in getDerivativeDefinitions(). It loads the content View, skips displays that do not meet the conditions above and builds an action for each remaining display:
public function getDerivativeDefinitions($base_plugin_definition): array { $this->derivatives = []; $view = $this->entityTypeManager->getStorage('view')->load('content'); if (!$view || !$view->status()) { return $this->derivatives; } foreach ($view->get('display') as $display_id => $display) { if ($display['display_plugin'] !== 'page') { continue; } $options = $display['display_options']; if (($options['enabled'] ?? TRUE) === FALSE) { continue; } // Only use filters explicitly overridden for this display. if ($options['defaults']['filters'] ?? TRUE) { continue; } $filter = $options['filters']['type_1'] ?? []; $types = $filter['value'] ?? []; if (($filter['entity_type'] ?? NULL) !== 'node' || ($filter['field'] ?? NULL) !== 'type') { continue; } if (($filter['operator'] ?? NULL) !== 'in' || !empty($filter['exposed']) || count($types) !== 1) { continue; } $node_type = $this->entityTypeManager->getStorage('node_type')->load(reset($types)); if (!$node_type) { continue; } $this->derivatives[$display_id] = [ 'title' => $this->t('Add @label', [ '@label' => $node_type->label(), ]), 'route_name' => 'node.add', 'route_parameters' => [ 'node_type' => $node_type->id(), ], 'appears_on' => ['view.content.' . $display_id], ] + $base_plugin_definition; } return $this->derivatives; }The array near the end of the method contains the same values as our first YAML example. The content type supplies the label and creation-form parameter, while the display ID determines where the action appears. Adding $base_plugin_definition carries over shared properties, including the action class we registered earlier.
Using the display ID as the array key also gives each action a distinct derivative ID. Drupal combines it with the base plugin ID, so the action for page_articles becomes:
listing_actions.content_add:page_articlesThat ID identifies the action itself. Its appears_on route is still view.content.page_articles, and its destination is still node.add with the article type as a parameter—just as in the static definition.
Who can see the button?Once Drupal has these definitions, it can decide which actions to show on a page. It does this by checking access to each destination route with its parameters. For the article action, that means checking whether the current user may open node.add for the article content type, separately from whether they may view the listing.
This is why the deriver contains no current-user permission checks. Drupal caches its definitions, so making discovery depend on the user who triggered it could leave other users with the wrong set of actions. Access belongs in the later step, when Drupal builds the buttons for the current page.
When the configuration changesCaching also means that the deriver does not reread the View on every request. If a display's filter or ID changes, or a content type gets a new label, the stored action definitions need to be regenerated.
For this example, a full cache rebuild is the point at which those changes take effect. Rebuild after installing the files and after importing changed configuration, using Drupal's "Clear all caches" action at Configuration → Development → Performance or your environment's Drush cache-rebuild command. This refreshes both the definitions and the rendered output.
The same applies when editing the configuration through the UI. If those edits need to take effect automatically, the integration must respond to the relevant configuration changes, call clearCachedDefinitions() on plugin.manager.menu.local_action and invalidate the affected rendered output. Those handlers are not included in the accompanying class.
With this in place, adding another listing that follows the same filter convention also gives it the appropriate creation action after the next cache rebuild. There is no separate button definition to maintain.
berliner Thu, 09/24/2026 - 00:05 TagsSharing Drupal code across country sites does not sync product specifications, documents, or company claims.
Drupal multisite vs multilingual teams must decide where authoritative facts live before AI assistants encounter contradictory pages. Maciej Lukianski compares multisite, one multilingual Drupal, and Domain Access for market-aware publishing.
In Post 8 I described my monthly billing run. One client never gets an invoice: the Drupal community, which has had almost all of my working time since July 2025. This post is that invoice. The eight posts before it showed the fun part: the Modeler API, the Workflow Modeler, test and replay, the ECA Guide, orchestration. This one shows the ledger underneath: 87 actively maintained drupal.org projects, the Gin admin theme, the Admin theme subsystem in core, 293 public projects on the LakeDrops GitLab, a calendar of weekly and monthly community meetings, two DrupalCons a year. Innovation gets applause; maintenance gets a green badge. Every funding conversation so far was about a feature. Nobody has offered to sponsor a security release. Since July 2025 the revenue has been zero, paid for by earlier years. Dries' cost-allocation posts explain why. The menu at the end has prices: sponsor maintenance through Open Collective, a service agreement, hiring for ECA work, funding the next innovation. Total: roughly €10,000 a month.
The Enterprise AI Summit takes place in one week, on 28 September aboard the SS Rotterdam, and the countdown is a good moment to properly introduce a session that's been on the agenda for a while: sovereign AI with Julien Blanchez.
Digital sovereignty has moved from a policy discussion into a boardroom question. Regulators, procurement teams and public sector organisations are asking the same thing in different ways: can we use world-class AI technology while keeping control over where our data lives, who can access it, and under what conditions?
With over a decade at Google working on data protection, security and digital sovereignty for large, highly regulated organisations, Julien will walk us through what's driving rising sovereignty expectations and how to keep access to leading AI technology on your own terms.
He joins a day full of similar questions answered with real numbers. The European Personnel Selection Office deployed a RAG-powered instant answer engine inside Drupal in under eight weeks, running in all 24 EU official languages, with 90% fewer repeat support questions and zero hallucinations on manual review. The American Diabetes Association will share what happened when editorial teams got real AI tools in their hands, including the honest lessons that came with it. And Moritz Arendt takes on a question that sits right next to Julien's: can AI strengthen digital communities, or does it risk hollowing them out?
With just days left, there’s still time to check the full agenda and save your seat. Tickets and details are available on the Enterprise AI Summit page.
Choosing a CMS for a multilingual product catalogue is a content-operations decision, not a plugin shootout.
Drupal vs WordPress enterprise teams must compare field-level translation, moderation, entity APIs, and AI-ready outputs before assistants read conflicting specs. Maciej Lukianski explains when WordPress still wins, when Drupal fits connected complexity, and how to pilot migration without guessing.
A few years ago I said Drupal needed infrastructure innovation, and I finally took the time to do something about it. While I really like DDEV, I'm really not a fan of having to use Docker for everything so I'm trying to do something about it.
theodore September 22, 2026European Digital Identity Wallets are moving from technical framework and pilot programmes towards services that people will be able to use across the European Union. The European Commission says Member States must make wallets available to citizens, residents, and businesses by the end of 2026. For Drupal teams, that makes digital identity less a future policy topic and more an application-architecture question.
The wallet model changes what an online service can ask a user to prove. Instead of treating identity as one complete profile, users can present particular identity data or attestations and disclose only the information required for a transaction. Commission figures say more than 550 companies and public authorities across 26 Member States, Norway, Iceland, and Ukraine are participating in large-scale pilots covering government services, banking, education, health, transport, telecommunications, and other uses.
The relevant role for a Drupal application is the relying party. Under the European framework, organisations that use wallets for digital services must register their intended use and indicate the data they plan to request. That puts the request itself inside a defined trust and registration model rather than leaving every application to decide independently what identity information it wants to collect.
The technical exchange is also more specific than adding another login provider. For remote presentation flows, the EUDI architecture uses OpenID for Verifiable Presentations to carry requests and wallet responses between wallets and relying parties. A Drupal service could potentially use a validated result from that layer for authentication, account linking, permissions, eligibility checks, or workflow decisions, but the material reviewed for this issue does not establish a production-ready Drupal integration that provides those functions today.
Data handling may prove more consequential than authentication itself. A wallet may be able to prove that a person has a particular attribute without requiring the service to collect a larger identity record, and the European framework is designed around data minimisation and selective disclosure. The application still has to decide what happens next: whether the verified attribute becomes persistent Drupal user data, whether only a derived result is retained, or whether the information can disappear once the transaction has been completed.
Those decisions sit above the wallet protocol. Drupal already provides accounts, permissions, fields, workflows, access rules, logging, and application-specific data models, but none of those automatically determine which verified identity attributes an organisation should retain. Connecting a verifier to Drupal therefore solves only part of the problem; the rest belongs to application design, data governance, and the legal requirements of the service being built.
The EUDI technical framework is still developing as deployment approaches. Version 3.0.0 of the EUDI Wallet Architecture and Reference Framework, published in July 2026, updates Wallet-Relying Party registration and introduces the concept of Relying Party Services alongside other changes. For Drupal projects in European government, education, and other identity-sensitive environments, the question is not simply how Drupal accepts a wallet, but which verified facts the application actually needs after the wallet has done its job.
Follow The DropTimes on LinkedIn, X, Bluesky, and Facebook, or join #thedroptimes on Drupal Slack.
Kazima Abbas wrote and curated this issue of Editor’s Pick.
