Drupal Core strategy: July 2025

I would summarize the remaining feedback from subsystem maintainers into three key areas.

First, the strategy might not go deep enough on front-end, JavaScript, and theming. Many people have questions about the future direction here, and the document does not provide much clarity or concrete decisions. We are undecided whether this level of detail belongs in the strategy document, but it is important to acknowledge.

Second, there is ongoing questions about the roles of Experience Builder, Layout Builder and Paragraphs, and their relation to Core. A clearer stance and concrete plan would help guide the community.

Third, some subsystem maintainers have asked for a stronger focus on end-user value. They feel the document leans too much toward internal improvements, technical debt, and modernization rather than features that solve real problems for end users. They emphasized that users often choose platforms like AEM or WordPress because they solve practical problems and offer key features, not just because they are technically modern. There is a desire for more end-user innovation that helps Drupal win. This highlights the need to define Drupal Core's out-of-the-box experience more clearly, which remains an important next step. It might also mean we need to clarify the relation between Drupal Core, Drupal CMS (formerly Starshot) and other flavors of Drupal.

I suggest we break these areas into separate issues, resolve them, and incorporate changes into the next version of the strategy document. Even if some outcomes do not belong in the strategy itself, it would still be valuable to have clear resolution.

For theming @pdureau opened 🌱 [Meta] Make Drupal the first "design-system native" CMS + Unify & simplify render & theme systems Active this week which consolidates a lot of past and previous conversations, that's definitely the place for theme/render layer discussion to happen at the moment.

The relationship between layout builder and experience builder and core I need to double check if there's an issue open but otherwise will create one and link from here. For me we need to start with a minimal de-duplication strategy for blocks/layout builder/experience builder between core, contrib and Drupal CMS to allow more flexibility later.

For end user features we definitely need to clarify the relationship between Drupal CMS and core more, both for people's expectations and also in terms of feature duplication and mismatches. https://www.drupal.org/about/core/blog/drupal-core-will-adopt-gin-admin-... → in one step for that.

There's also 📌 Deprecate and remove the Umami demonstration profile from core, make it a contributed site template Active and 🌱 Remove support for installing install profiles via the UI installer Active , and issues around how to redo or replace the standard and minimal profiles which will need product manager input.

Opened 🌱 [meta] Experience builder / layout builder / block module reconciliation Active .