06 Jul 2026

feedDrupal.org aggregator

The Drop Times: ECA Crosses 20,000 Reported Drupal Site Installations

ECA's reported growth shows how far configuration-based automation has moved into Drupal site-building practice. The milestone also raises the stakes for a project that many sites now rely on for workflow decisions, integrations, and operational logic.

06 Jul 2026 2:19pm GMT

Drupal Starshot blog: Drupal CMS product strategy: version 2.0

We've published an updated product strategy for Drupal CMS. Version 2.0 replaces the original Drupal Starshot strategy from August 2024, and it reflects where we are after nearly two years of building.

The updated strategy largely documents what we're already doing, and why, and makes some important clarifications.

Developers delivering for marketers

The initial strategy framed content creators and marketers as the primary target audience. That made sense as a signal about our ambitions: Drupal already has a reputation for being developer-friendly, so we wanted to emphasize the focus on end users.

In practice, though, it created some confusion. Marketers are the end users of the sites built with Drupal CMS, but they're not the ones installing it, configuring it, or (in most cases) choosing it. That decision usually belongs to agencies and professional developers.

So the updated strategy is clearer: Content creators and marketers remain the target person for the product as end users, and the primary audience for the builder experience is agencies and professional developers. We can only reach marketers if developers can succeed with Drupal.

Rather than representing a change in what we're focused on, this now more accurately captures it.

What's actually changed

The strategic frame has shifted to "making agencies and developers successful faster." The end goal of delivering great experiences for content teams is still central to the strategy, but we are explicit about doing that through agencies and developers.

A few other notable updates:

AI is now framed as infrastructure, rather than a feature. The original strategy positioned AI as one of several ways to win. Version 2.0 is more direct: every workflow in Drupal CMS should be operable by an AI agent. The goal is to be able to ship new AI-enabled workflows in days, not months.

Integrated hosting providers are now explicitly part of the strategy. These platforms are becoming real distribution channels for Drupal CMS, and the strategy names them as a priority. Making Drupal CMS excellent to provision and host is a prerequisite for those partnerships.

Vibe coding platforms are now named as a positioning opportunity. We're not competing with tools like Lovable or Bolt for prototyping. But we are positioning Drupal CMS as where those projects land when they need real content governance, multi-contributor workflows, and long-term maintainability.

The timeline has changed. Version 1.0 set a target of June 2027. Version 2.0 extends that to June 2028, acknowledging that the scope has grown and the strategy is more comprehensive.

What hasn't changed

We're still aiming to expand in the mid-market, with projects with total budgets in the $30,000-$120,000 USD range, and we're still explicitly not competing with entry-level website builders. We are also calling out that we will continue to maintain our leadership in the enterprise market.

And, of course, the differentiators against proprietary CMS solutions are the same: open source, no vendor lock-in, digital sovereignty.

Read the full strategy

The updated strategy is published on Drupal.org.

If you have questions or feedback on the direction, find us in #drupal-cms-development on Drupal Slack.

06 Jul 2026 1:33pm GMT

Skynet Technologies USA LLC Blogs: What's New in Drupal 11.4.0: Features, Improvements, and Upgrade Highlights!

Drupal 11.4.0 is the latest feature release in the Drupal 11 branch, bringing developer-focused enhancements, performance improvements, and a smoother upgrade experience. As a minor release, it introduces new capabilities while maintaining backward compatibility for public APIs, making it a recommended upgrade for production websites. Drupal 11.4.x will receive security support until June 2027…

06 Jul 2026 1:01pm GMT

The Drop Times: Drupal Camp Asheville Sessions Highlight Accessibility, AI, Canvas, and Local Tooling

Drupal work now extends beyond implementation alone. Four Asheville sessions show where accessibility, AI, components, and local tooling shape delivery.

06 Jul 2026 11:53am GMT

Smartbees: Apator Group

Learn more about our comprehensive implementation for one of the energy sector leaders - Apator Group.

06 Jul 2026 11:38am GMT

The Drop Times: Drupal 11.4.0, AI Workflows, and Orchestration

Recent Drupal developments point to a clearer direction for the project's AI and developer-experience work. The immediate story is not only that Drupal is adding AI features.

Core performance, upgrade tooling, workflow orchestration, and AI governance are beginning to converge around a more controlled operating layer for modern web teams. That makes maintainability, auditability, and human review central to Drupal's AI direction, not secondary safeguards.

Drupal 11.4.0, published on 1 July 2026, gives that direction a stronger core foundation. The release reduces database queries compared with Drupal 11.3, speeds up recipe-based site installation, improves translation file handling, and adds Brotli compression for aggregated CSS and JavaScript when ext-brotli is available. It also introduces an experimental extensible native command-line interface through ./vendor/bin/dr, improves password hashing with support for argon2id, and adds display-management changes intended to support tools such as Drupal Canvas.

The AI layer is moving in the same direction. Drupal AI 1.4.0 adds developer-focused drush generate commands for providers, automators, guardrails, operation types, API explorers, function calls, and related extension points. The release also introduces chat normalisation, Views Bulk Operations integration for AI Automators, failover foundations, and streaming guardrails.

Those additions support AI workflows that need clearer execution paths, safer handling, and extension points that contributed modules can build on. They also match the distinction now forming around Drupal's Inside AI and Outside AI work. Inside AI covers cases where a person uses Drupal and Drupal uses AI to assist, while Outside AI covers cases where a person uses an external agent and the agent uses Drupal.

In that model, Drupal's value is not just page rendering. It is the governed system of record for content structure, permissions, validation, moderation, revisions, and publishing workflows. Dries Buytaert's recent writing on agentic workflows frames the same challenge around setup, connection, context, governed action, validation, recovery, and launch.

The same question appears in Drupal's orchestration work. Recent discussions around ECA, FlowDrop, Maestro, and Drupal core focus on whether automation tools can share vocabulary and data-handoff contracts while keeping their different execution models. Randy Kolenko's recent Nextide post adds the durable-state side of that discussion, positioning Maestro around long-running workflows, human approval steps, and audit trails that persist beyond a single request or cache cycle.

Upgrade tooling is also becoming part of the maintainability story. As of Rector 2.5, Composer-based sets support Drupal, allowing Rector to inspect composer.json, detect installed Drupal and dependency versions, and apply relevant refactoring sets without manually listing each Drupal version in rector.php. For site owners and maintainers, that reduces configuration work as Drupal 11.4, Drupal 12, and later releases move through the upgrade path.

The broader open-source context came through at UN Open Source Week 2026, held from 22 to 26 June 2026 at United Nations Headquarters in New York. The official programme focused on open source, artificial intelligence, Digital Public Infrastructure, Open Source Program Offices, sustainable public infrastructure, and digital cooperation. Matthew Saunders' Drupal.org reflection connected those discussions to AI harnesses, orchestration, constraints, auditability, verification, and human-in-the-loop workflows.

For Drupal, the practical implication is clear. AI adoption depends less on isolated prompts and more on trusted systems that can govern what agents do, record what happened, and keep human responsibility visible.

Readers can follow The Drop Times on LinkedIn, Twitter, Bluesky, and Facebook, or join the publication's Drupal Slack channel at #thedroptimes.

(Allen Jason, junior sub-editor at The DropTimes, writes and curates this week's Editor's Pick.)

06 Jul 2026 5:30am GMT

DDEV Blog: DDEV v1.25.3: Faster Start and Stop, Built-in Docker Compose, Stable Podman, MariaDB 12.3 LTS

DDEV v1.25.3 Release Banner

We're announcing DDEV v1.25.3: faster ddev start and ddev stop, built-in Docker Compose, stable Podman and Docker Rootless support, MariaDB 12.3 LTS support, Node.js improvements, XDG_CONFIG_HOME changes, and more.

This release represents 131 PRs from the entire DDEV community: your suggestions, bug reports, code, and financial support made it possible.

Table of Contents

Faster ddev start, ddev stop, and ddev restart

ddev start in v1.25.3 (bottom) is faster than in v1.25.2 (top), including a faster warm start:

ddev start v1.25.2 (top) vs v1.25.3 (bottom)

ddev stop in v1.25.3 (bottom) is significantly faster than in v1.25.2 (top), and the same improvement also applies to ddev poweroff and ddev delete, since all three share the same code path:

ddev stop v1.25.2 (top) vs v1.25.3 (bottom)

ddev restart in v1.25.3 (bottom) is significantly faster than in v1.25.2 (top), since it stops and starts a project and benefits from both improvements:

ddev restart v1.25.2 (top) vs v1.25.3 (bottom)

Post-healthcheck tasks now run concurrently instead of one after another, reducing overall ddev start time, thanks to @jonesrussell.

A bug in the web server startup script also added a ~10-second delay to ddev stop. That delay is now gone.

We benchmarked ddev start from a stopped state on both macOS and Linux, and v1.25.3 is faster on both. Numbers vary by machine, but you can reproduce it with scripts/compare-start-perf.sh:

git clone https://github.com/ddev/ddev ddev-upstream
cd ddev-upstream
bash scripts/compare-start-perf.sh v1.25.2 v1.25.3

On macOS, v1.25.3 is about 28% faster than v1.25.2 (benchmarked by @rfay):

Summary (ddev start from stopped state)
-------------------------------------------------------------------
  A (v1.25.2): median=11.03s  trimmed-mean=10.49s
  B (v1.25.3): median=7.91s   trimmed-mean=7.84s
  B is FASTER than A by 3.12s (-28.3%) on median

On Linux, it's about 21% faster (benchmarked by @stasadev):

Summary (ddev start from stopped state)
-------------------------------------------------------------------
  A (v1.25.2): median=18.03s  trimmed-mean=18.25s
  B (v1.25.3): median=14.18s  trimmed-mean=14.96s
  B is FASTER than A by 3.85s (-21.4%) on median

New Docker Compose Library

DDEV now uses the Docker Compose SDK directly instead of shelling out to a separate docker-compose binary. The $HOME/.ddev/bin/docker-compose binary DDEV used to download and manage can be removed. This switch was made possible by the Docker Compose maintainers, who exposed the SDK as a reusable library in Compose v5.0.0. Thank you very much!

Driving Compose through the SDK is also what gives you the cleaner output and live per-step timer in the GIFs above: DDEV now controls how progress is displayed instead of passing through whatever the external binary printed.

This is the same underlying change that added the optional ddev config global --docker-buildx-version setting in this release. See Docker Buildx Requirement in DDEV for the full background on Buildx and the Compose SDK switch.

MariaDB 12.3 LTS Support

DDEV now supports MariaDB 12.3, the latest LTS release. For new projects, set it with:

ddev config --database=mariadb:12.3

To migrate an existing project's database, use:

ddev utility migrate-database mariadb:12.3

Podman and Docker Rootless Are No Longer Experimental

Both Podman rootless and Docker rootless are now stable. We introduced this support as experimental in v1.25.0. See Podman and Docker Rootless in DDEV for the background, trade-offs, and the work behind it. Setup instructions:

Node.js Changes

XDG_CONFIG_HOME Is No Longer Respected, but DDEV_XDG_CONFIG_HOME Is Available

We received several reports of DDEV recreating $HOME/.ddev repeatedly:

Warning: multiple global DDEV configurations found, /home/stas/.config/ddev is used, /home/stas/.ddev is not used, delete one of them to avoid confusion

IDEs such as PhpStorm don't always see XDG_CONFIG_HOME from the terminal, so DDEV fell back to and recreated $HOME/.ddev repeatedly. See the upstream issue IJPL-1055 for details.

To avoid this problem, DDEV now reads its own environment variable, DDEV_XDG_CONFIG_HOME, and no longer respects XDG_CONFIG_HOME. If you had set XDG_CONFIG_HOME to something other than its default of $HOME/.config, set DDEV_XDG_CONFIG_HOME to that same value instead.

Support for using $HOME/.config/ddev as the global configuration directory on Linux is unchanged.

Everything Else

This release includes many more features and bugfixes. See the full release notes for the complete list.

From the entire team, thanks for using, promoting, contributing, and supporting DDEV!

If you have questions, reach out in any of the support channels.

Follow our blog, Bluesky, LinkedIn, Mastodon, and join us on Discord. Sign up for the monthly newsletter.


This article was edited and refined with assistance from Claude Code.

06 Jul 2026 12:00am GMT

05 Jul 2026

feedDrupal.org aggregator

Joachim's blog: No data, no problem: computed fields made simple

No data, no problem: computed fields made simple

It's often useful to let the machines do the work, and output something that's dynamically computed on an entity. By that I mean something that can't be hardcoded as a fixed value for all entities of a particular type, but that varies for each entity, in a way that allows it to be generated in code rather than laboriously entered into each entity form by humans.

For example, you might want a backlink for an entity reference, or a link to a view that has an argument for the entity's ID, or something that depends on field values on the entity.

There are several ways in Drupal of putting something dynamic on the entity's display output. You can of course add something to the build array yourself, in either the entity's view handler or hook_entity_view(). The extra fields system lets you then declare your additional build array item with hook_entity_extra_field_info() which allows it to be rearranged among normal fields in the field admin UI.

This is okay, but the extra fields system is Drupal 5-era stuff. Your piece of build array is just that, some render stuff; it can't participate in any data structures and nothing else will recognise it and work with it.

A better approach is a computed field. This involves a little more boilerplate code than the extra fields technique, but there are several benefits.

The first is that you are defining a field value, not a render array, and you get access to all the field formatters that apply to your type of data. So for example, if your computed data is a URL, you get all of the link field formatters at your disposal, in core and contrib.

The second is that anything that works with fields will be aware of your computed field. So you can add it to a view as a field (though not a sort or filter of course, since it has nothing in the database). You can add it to a SearchAPI index (and there, you actually can filter on it, because SearchAPI will index the computed value into its backend).

The code

Here's what you need to do. You need two things:

  1. A FieldItemList class.
  2. A declaration of your field in an entity class or field info hook.

Unlike declaring code fields, you don't need to declare a field storage: that's because a computed field doesn't store anything!

1. The FieldItemList class

Create a subclass of \Drupal\Core\Field\FieldItemList that uses \Drupal\Core\TypedData\ComputedItemListTrait. In this class, all you need to do is implement computeValue() to return your data.

<?php

// The namespace doesn't matter, but I like to put it under \Field.
namespace Drupal\my_module\Field;

use Drupal\Core\Field\FieldItemList;
use Drupal\Core\TypedData\ComputedItemListTrait;
use Drupal\Core\Url;

/**
 * Field item list class for my computed field.
 */
class MyFieldFieldItemList extends FieldItemList {

  use ComputedItemListTrait;

  /**
   * {@inheritdoc}
   */
  protected function computeValue() {
    // You have access to the complete entity, so you can use other field
    // values.
    $entity = $this->parent->getValue();

    // Create a field item for your data. You can create more than one for a
    // multi-valued field.
    $this->list[] = $this->createItem(0, [
      'value' => 'cake',
    ]);
  }
}
?>

For most field types, the key to use in the item array is 'value', but some more specialised fields use something else. You can find this by looking in the field item class for the field type. For example, in \Drupal\link\Plugin\Field\FieldType\LinkItem::propertyDefinitions() you can see that for a link field, you need these array keys:

    $this->list[] = $this->createItem(0, [
      'title' => $this->t('My link title'),
      'uri' => $some_url_that_we-compute->toUriString(),
    ]);

2. Define the field

For the field definition, there are two things to consider:

  • Is it on an entity type you control, or somebody else's?
  • Do you want a base field or a bundle field?

If it's your own entity type, you define the field in the entity class, in either the baseFieldDefinitions() or bundleFieldDefinitions() method. If it's an existing entity type, you need to use hook_entity_base_field_info() or hook_entity_bundle_field_info().

In all cases, the code is broadly similar. For a base field, it looks like this:

/**
 * Implements hook_entity_base_field_info().
 */
#[Hook('entity_base_field_info')]
function entityBaseFieldInfo(EntityTypeInterface $entity_type) {
  if ($entity_type->id() == 'node') {
    $fields = [];
    $fields['my_computed_field'] = BaseFieldDefinition::create('link')
      ->setLabel($this->t('My computed field'))
      ->setDescription($this->t('My field is amazing.'))
      // This declares it as a computed field.
      ->setComputed(TRUE)
      // This is the class you created earlier, which provides the values.
      ->setClass(MyFieldFieldItemList::class)
      // Optional default view display options, which can be overriden in the admin UI.
      ->setDisplayOptions('view', [
        'label' => 'above',
        'type' => 'link',
        'weight' => '0',
      ]);

    return $fields;
  }
}

For a bundle field, you need the Drupal\entity\BundleFieldDefinition class from Entity module, and a few extra things need to be explicitly set on the definition because the field system doesn't handle them for you:

    $fields['my_computed_field'] = BundleFieldDefinition::create('link')
      ->setName('my_computed_field')
      ->setTargetEntityTypeId($entity_type_id)
      ->setTargetBundle($bundle)
      // Rest of the definition as above.

See my earlier blog post on bundle fields for more about their uses and their quirks.

The contrib module

If you want to do it all with less boilerplate, or your computed field is something that's reusable across different entity types, consider the Computed Field module as an alternative to the code examples above. Instead of a Field class, the computational code does in a plugin, which the module then makes available in an admin UI where you can create and edit computed fields alongside the usual stored fields.

And if your computed field is purely a render array rather than data, the Computed Field module also provides a computed_render_array field type for that, with an accompanying field formatter.

Do you need help with data structures, and their integration with Views or SearchAPI? I'm available for hire - contact me!

joachim

05 Jul 2026 4:02pm GMT

04 Jul 2026

feedDrupal.org aggregator

Penyaskito: Canvas Internals - JSON data types in differentes databases: It works on my machine!

Canvas Internals - JSON data types in differentes databases: It works on my machine!

Image
The same JSON, stored and read back from different database engines

Drupal has been working to add a JSON data type since 2023, but that has not landed yet. Drupal Canvas jumps ahead of that in its inputs for a component tree item with

'inputs' => [
  'description' => 'The input for this component instance in the component tree.',
  'type' => 'json',
  'pgsql_type' => 'jsonb',
  'mysql_type' => 'json',
  'sqlite_type' => 'json',
  'not null' => FALSE,
],

Recently some of our tests started failing for MySQL and Postgres on CI, but passed in SQLite and MariaDB, which is what most of us use locally.

The problem was that the sorting of the keys of that field was not deterministic, and we used assertSame in our tests to see if operations added/removed the inputs as expected when components evolved.

How does that translate to different engines?

For MySQL, there's a native data type. Quoting their docs:

To make lookups more efficient, MySQL also sorts the keys of a JSON object. You should be aware that the result of this ordering is subject to change and not guaranteed to be consistent across releases.

For PostgreSQL, the engine offers two different data types: json and jsonb, with the second being the option we (and core) opted for because of its efficiency. But that's key, as the docs explain:

In general, most applications should prefer to store JSON data as jsonb, unless there are quite specialized needs, such as legacy assumptions about ordering of object keys.

That's exactly what our problem was.

For MariaDB, the JSON type is just an alias. See their docs:

JSON is an alias for LONGTEXT COLLATE utf8mb4_bin introduced for compatibility reasons with MySQL's JSON data type. MariaDB implements this as a LONGTEXT rather, as the JSON data type contradicts the SQL:2016 standard, and MariaDB's benchmarks indicate that performance is at least equivalent.

And the last one, SQLite, has support for a jsonb format since 3.45, but the work in progress for introducing this in Core uses json, which, like MariaDB, is ordinary text and sorting of the keys is respected.

How did we fix this?

The actual sorting of the inputs in the database is, as of today, irrelevant to us. So we ended up with:

  • Our own assertSameInputs, which sorts the keys before comparison. assertEqualsCanonicalizing is not an option, as that sorts by value.
  • Our own PHPStan rule, which is not 100% accurate but detects most usages of assertSame with these inputs, and suggests using assertSameInputs instead.

Translating Drupal Canvas

This is just one of the many show-stoppers that we faced while working on the much-anticipated symmetric translation support for Drupal Canvas. If you want to test this experimental feature, check the release notes in Canvas 1.7.0, but please only on test sites for now!

penyaskito

04 Jul 2026 4:24pm GMT

03 Jul 2026

feedDrupal.org aggregator

The Drop Times: Shibin Das on Making Drupal Workflows Legible

Shibin Das explains why visual workflow tools need visible execution, audit trails, runtime ownership, and clear boundaries between deterministic workflows and AI-assisted decision-making.

03 Jul 2026 3:39pm GMT

Undpaul.de: Drupal Tip: How to change field length with existing data

Every Drupal developer eventually hits this wall: a client or editor requests that a standard text field (like a headline or subheadline) be expanded from 255 to 512 characters. You change the value in the field configuration YAML or try to update it programmatically via the Entity API, only to be hit with a fatal exception.

03 Jul 2026 7:27am GMT

02 Jul 2026

feedDrupal.org aggregator

Nextide Blog: Someone Has to Hold the State: Maestro's Place in Drupal's Orchestration Stack

Randy Kolenko, partner and senior architect at Nextide, recently joined the Drupal Orchestration Initiative with Jurgen Haas, Shibin Das and Dries Buytaert. The Orchestration Initiative is still in its infancy, however, the discussions and (dis)agreements will continue until the vision of what Orchestration means to Drupal is sharpened.

02 Jul 2026 3:30pm GMT

Drupal Core News: Use Rector on your Drupal site easier than ever with new Composer-based sets

As of Rector 2.5, Composer-based sets now support Drupal! This allows you to automate version-specific custom code upgrades seamlessly.

Instead of manually adding dozens of configuration sets and keeping your list up to date as you upgrade to new Drupal releases, you can enable the new feature in your rector.php file. Rector will automatically inspect your composer.json, detect your exact installed versions of Drupal and its dependencies, and run the relevant refactoring sets. This means as you upgrade to newer versions of Drupal in the future, Rector will dynamically adapt and apply the correct upgrade rules without any manual config updates.

Add it to your site

Install Drupal Rector with Composer:

composer require --dev palantirnet/drupal-rector:^1.0

That pulls in Rector 2.5 or newer, which is where the interesting part lives. Then create a rector.php in your project root:

<?php

declare(strict_types=1);

use DrupalRector\Set\DrupalSetProvider;
use Rector\Config\RectorConfig;

return RectorConfig::configure()
  ->withPaths([
    __DIR__ . '/web/modules/custom',
    __DIR__ . '/web/themes/custom',
  ])
  ->withSetProviders(DrupalSetProvider::class)
  ->withComposerBased(twig: TRUE, phpunit: TRUE, symfony: TRUE, drupal: TRUE);

And run it:

vendor/bin/rector process

Two lines of configuration does the work: withSetProviders registers the Drupal rules, and withComposerBased(drupal: true) tells Rector to select them based on what's actually installed. No version numbers need to be in your config.

The feature is backed by recent Drupal Rector 1.0.0 beta releases. Although we are still running a beta for Drupal Rector, the composer-based sets landed in Rector 2.5.0. Run it on your custom code, read the diff, and tell us where it's wrong.

How does it work?

Rector reads the installed drupal/core version and loads every set up to and including that minor. A site on 11.4 loads the 11.0 → 11.4 rules. A site on 11.2 loads 11.0 → 11.2. When you upgrade core, the set selection moves with you. You don't need to change rector.php again.

That's the same mechanism Rector already uses for Symfony, Doctrine, Twig, and PHPUnit. Drupal is now a first-class citizen.

But the config was never the hardest part. The hard part was coverage. Automatic version selection is only worth anything if the rules behind it are good and preferably complete. That changed a lot when the Project Update Bot was refreshed for Drupal 12 readiness, pushing automated deprecation coverage past 80%. The bot and drupal-rector draw from the same well. Better coverage there is what made shipping this as the default setup defensible. The fact we also run all these rules against almost 10.000 contrib modules makes for some very good testing.

Even less work maintaing your Drupal site

Drupal rules will also appear on getrector.com/find-rule at a later date. That's the searchable catalogue of every rule Rector ships. Having Drupal in it means a maintainer can look up exactly which transformation handles a given deprecation, the same way they can for any other framework today.

Drupal 12 readiness isn't a one-time push, every new minor brings deprecations, and we will keep on adding any missing coverage. Because your setup selects rules by installed version, the rules you get tomorrow are the rules for the core you're running tomorrow. No migration step. You upgrade core, you run Rector, you're up-to-date.

Add it to a project this week. Point it at your custom modules, run vendor/bin/rector process, and open an issue when something doesn't transform the way it should. It's a beta because we want exactly that. Two lines of config, the correct rules for your version, automatically.

Also posted on Rector's blog, big thanks to the author of Rector, Tomas Votruba for the collaboration on making this happen.

02 Jul 2026 9:35am GMT

DrupalCon News & Updates: Digital Sovereignty Starts with Technical Choices

Digital sovereignty often sounds abstract but, in practice, it comes down to technical decisions: where data is stored, who controls the platform, how systems are maintained over time, and how much privacy, transparency, and independence is built in from the start.

These choices directly affect how digital services are designed and delivered. That is why digital sovereignty is a key theme at DrupalCon Rotterdam 2026. The event's Digital Sovereignty & Open Web track connects platform strategy with architecture, governance, accessibility, regulation, and the long-term future of open digital ecosystems.

Image
Photo by Matthew Saunders

Photo by Matthew Saunders

This is not only a policy discussion, it is also a practical one. Privacy-first architecture, public code, digital identity, accessibility, open-source infrastructure, and responsible AI all shape how organisations think about control and trust today. In that context, digital sovereignty is no longer a side topic, it's becoming part of how teams approach procurement, hosting, compliance, and long-term platform resilience.

That is what makes this conversation especially relevant in Rotterdam. Developers can connect values to implementation, digital leaders can look at governance and long-term control and public sector teams, accessibility advocates, and open-source contributors can all bring important perspectives to the same discussion.

Drupal has long been part of the open web story. At DrupalCon Rotterdam, digital sovereignty becomes a practical question: how do we build systems that remain open, secure, adaptable, and worthy of trust.

- Article by Daniela Moreira.


🎟️ Join Us at DrupalCon Rotterdam 2026

Continue the conversation at DrupalCon Rotterdam 2026, where the Digital Sovereignty & Open Web track explores the technologies, strategies, and decisions shaping open digital ecosystems.

👉 Register for DrupalCon Rotterdam 2026

02 Jul 2026 8:44am GMT

The Drop Times: Drupal 11.4.0 Delay Shows Dependency Patch Pressure on Core Releases

Release timing is often treated as calendar work, but the 11.4.0 delay exposed a dependency problem beneath the schedule. The fix changes how selected Composer dependencies can move when security updates land.

02 Jul 2026 6:41am GMT

Webpro Company blog: Why does Drupal get slower over time?

Many Drupal sites are fast when launched, but become heavier over the years. The cause is usually not Drupal itself, but how the platform is maintained, extended and filled with content over time. Slowness rarely comes from one change A Drupal site does not usually become slow overnight. It is usually a gradual process: more content is added; more images and files are uploaded; new modules are installed; small custom features are built; analytics, marketing and chat scripts are added; cache or server configuration falls behind; old solutions remain in place next to new ones. Each individual change may seem small. Together, they can make the site slower, harder to manage and more expensive to develop further. Content growth has a bigger impact than expected A large organisation's Drupal…

02 Jul 2026 6:00am GMT