Drupal Core strategy for 2025-2028

I was writing a reply here, but realized that it's more about Drupal CMS than Core, so I created a new issue there instead: 🌱 [policy] Impact on contributed projects and its maintainers Active .

Putting my core subsystem maintainer hat back on, I appreciate the focus and explicit mention of the entity/field API and UI here, which for a long time was living in the shadows a bit (the API especially, the UI has seen quite some focus recently) compared to the official initiatives that were happening on "fancier", more product-y parts of Drupal (core).

I guess one risk is that funding for those fancier parts might move to Drupal CMS instead, as more modules and possibly features get moved to Drupal CMS/contrib. So we'll need to somehow figure out that Drupal CMS doesn't take away too much of the sunlight that Drupal Core needs.

Ssince this is a long term strategy, it is not version specific, so I am changing to the main development branch.

Putting my core subsystem maintainer hat back on, I appreciate the focus and explicit mention of the entity/field API and UI here, which for a long time was living in the shadows a bit (the API especially, the UI has seen quite some focus recently) compared to the official initiatives that were happening on "fancier", more product-y parts of Drupal (core).

Yes for me entity field API could and should be much further on than it currently is, e.g. it took us nearly ten years to do ✨ Implement a generic revision UI Fixed , various core entities re-implement various things provided by the entity API because they haven't been 100% updated to the generic versions, and we still have weird entity-specific things like node submitted template variables and etc. And this has parallels in views like not having generic entity reference filters (although ✨ Continuation Add Views EntityReference filter to be available for all entity reference fields Needs work made some progress in that direction recently). What I think the core strategy should do is recognise these things as key core features to be improved and promoted in their own right, and that has not always been the case as you point out.

I guess one risk is that funding for those fancier parts might move to Drupal CMS instead, as more modules and possibly features get moved to Drupal CMS/contrib. So we'll need to somehow figure out that Drupal CMS doesn't take away too much of the sunlight that Drupal Core needs.

So I would hope that Drupal CMS drives improvements to the following things in core fairly directly:

- recipes
- package_manager / project_browser / automatic_updates
- the installer (to support a project browser/recipes based install process to replace install profiles)
- experience builder (because it can't live in contrib if it's going to replace block UI / layout builder etc.)

But e.g. for experience builder to provide a consistent experience for all content entity types, it will need to tackle some entity API improvements (or at least, specific core entity implementation oddities).

That has not really happened yet except for recipes, obviously XB is making progress but it's not in either CMS or core yet so to early to see all the results of that. But it's early days and hopefully the next six months more of this can happen.

Also if we move e.g. search module to contrib, because Drupal CMS using search_api module, that shouldn't result in less attention on core as such, but just focus attention on one search solution (in contrib) instead of two competing ones (between contrib and core).

In addition to what @berdir and @catch said I think there are some theme specific things that would be great to refresh. Specifically how preprocess, theme_suggestions, and such are discovered and exposed.

This will make Experience build easier to implement and swap out engines and systems most likely so it aligns with CMS as well.

I've got a long list of things I've been uncovering due to Hook work for Installer and Updater bits that could likely use attention.

There's also issues to modernize how render arrays, and form api arrays are generated to make them more discoverable.

Not sure if this is what the feedback is looking for, I can move it elsewhere if it's more suited to another issue.

@nicxvan eventually we'll need to discuss specifics, but for now the focus is really on the overall strategy. First do you agree with the goal? it might not look like it but it's a pretty big change to become a CMS builder (and not "just" a site builder). Did we miss anything in the "where will drupal core play" section? any worries about the realignment of Drupal Core with regard to Drupal CMS, with the CMS market, or even with the broader open-source and commercial world. Does the "how will we win" section make use of all the strengths of Drupal in general, are we missing something to achieve the goal? I think it's more this kind of things we're looking for at this point.

The discussion about the specific APIs, render arrays, theme and hooks is to low level at this time. It'll be easier to discuss once we have a frame of reference we agree on to make decisions. If it's burning your fingers to talk about it right away, a new issue would be best.

Yes agreed with @nod_ technical discussions/specific proposals are probably better for 🌱 [meta] Drupal modernization Active and its child issues or new ones.

But that issue came about from one of the discussions that led to this document. Stuff like how do we make core coherent/consistent; how do we get large changes in more efficiently; how do we follow-through on adding new APIs/features so that they eventually replace older ones, instead of ending up with both the old and new one operating in parallel (or even three+ sometimes) because we moved onto other things instead. And also that much of this work benefits other core features, site builders, contrib, Drupal CMS etc. and is not 'code purity' or simply refactoring even if it's potentially a level or three below what people generally interact with.

So if the reaction is 'great, the core strategy says we should work on the kind of things I think we should work on' then that is very positive feedback, but the specifics of exactly what and how won't end up in here, except as examples of the type of thing.

Make Drupal great for sites with a great number of authenticated users.

That is what Drupal Core is missing. In the market there is a shift towards those kind of sites. Site owners want a more personalized experience for their users and they are switching from anonymous users to authenticated users. It would great if we could use Drupal for kind of sites.
To let Drupal be a great solution for complicated sites with a great number of authenticated users we need to do a couple of things:
1. Start using asynchronous PHP in Drupal Core. At least for retrieving data out of the database. 🌱 [meta] Use Fibers for concurrency in core Active & 📌 Add revoltphp/event-loop dependency to core Active
2. Switch to using MongoDB as the database and store all entity instances in their own JSON object in the database. This will lead to a lot less queries on the database, therefore making Drupal faster. The amount of functionality that Drupal requires from the database for supporting entity instances in JSON object is significant. The only database that can do that is MongoDB. ✨ [meta] Add database driver for MongoDB to Core as experimental Active & 📌 Drupal on MongoDB (the full PR) Active
3. Load the Drupal kernel (and other stuff) in memory before the user request comes in. #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole →

The combination of those 3 solutions combined with a more carefully use of how data is stored in the database and how it is retrieved will make Drupal great for sites with a huge number authenticated users.

The MongoDB community edition has more benefits:
- Support for regular search. We would no longer need a SOLR server next to your Drupal site. It is just stored in MongoDB. The 2 storage's do not need to be kept in sync.
- Support for vector search. Vectors are the way to store the results from an Artificial Intelligence (AI) in a database. With MongoDB those vectors can be indexed and searched. No Vector database needed and no need to keep data in sync between the two.
- Supports horizontal scaling. With this Drupal can support massive numbers of concurrent authenticated users.

The company MongoDB has a 1000 developers working on making the database a better product. The MongoDB has improved enormously over the last 10 years. When you last looked at MongoDB was more then sat 5 years or more. You need to take another look.
The databases we are using now (MySQL & MariaDB) have almost no improvements over the last 10 years. They are what we call lecacy products. MySQL is owned by the Oracle company and they want every user to switch over to their Oracle database. They are doing the minimum amount of support and development on MySQL.
To me, as the subsystem maintainer of the Database API and the database driver modules, MySQL and MariaDB are for the long term not the right database for Drupal.

For more info about Drupal on MongoDB: https://techblog.finalist.nl/blog/drupal-mongodb

Added a link that explains a bit more of the framework https://fs.blog/playing-to-win-how-strategy-really-works/

Thanks for the clarification!

I think if we take my feedback and go a bit higher level, something Drupal needs is an easier way to get a theme that feels customized for a client.

Whether that's a theme ecosystem, or an SDC library that you can easily pull in bits and pieces, or something else entirely, I don't know. But on the medium to low end projects theming is a barrier.

Thanks to @dries and the core committers for getting this discussion going and creating the doc. I really like the change of focus.

Here some thoughts based on the PDF

Drupal Core is a platform that empowers both low-code users and experienced developers to create powerful, user-friendly CMS solutions.

Can we say that certain audiences we don't want to go after? Which ones? Users who aren't comfortable with "low-code"? Meaning you will have to be okay with some code and config? It seems implied in this idoc but not said anywhere the Drupal Core is not really for *everyone* if you have no experience with some web development this is probably not for you. Maybe you start with Drupal CMS? I think this is a good thing to narrow down our audience.

Any organization that already has sites built on Drupal core and are maintaining them long term,

So does this mean Drupal core still has to prioritize these sites even if they don't fall under the current area of where we want to "play"? Does this effectively mean we can’t narrow where we play?

Experienced Drupal developers and site builders who are comfortable hand-picking modules and recipes to build out a site, but are not necessarily going to create their own repeatable CMS for this purpose

(emphasis mine)
Can we narrow the focus to "complex" sites, otherwise it seems to negate the narrowing above to "complex or repeatable"? Drupal core probably isn’t for experienced developers unless they are building a complex site, otherwise there are better solutions.

Where will Drupal Core play?

This is a long list. It would great to hear explicitly where we are not going to play or at least what is the most important in this list. Otherwise it feels like the "playing everywhere" problem mentioned in the video.

Establish channels for faster feedback loops between developers, site builders, and end-users

Which end users? The end users of Drupal core? Or the site builders and the end users of the CMS's built on top of Drupal core?

@daffie - yes, we need to support a lot of authenticated users, but a web application may not behave like a social media site in terms of the kind of data you need to load and show. Still, for our uses we are very much pained by the slowness of loading (and even more) saving entity data en mass. So, entity/field API performance one of our biggest pain points. We also use custom SQL queries at points, so it's not trivial to drop mongoDB in.

More personally in response - it feels ever more intimidating to get involved in core issues and it seems like a lot of good ideas linger with years of discussion. As a (listed) subsystem maintainer I don't feel like I have any special authority or reason to stay involved. Perhaps the core strategy will help define some technical directions that will reduce circular discussions on issues and encourage involvement.

Can we say that certain audiences we don't want to go after? Which ones? Users who aren't comfortable with "low-code"?

? It seems implied in this idoc but not said anywhere the Drupal Core is not really for *everyone* if you have no experience with some web development this is probably not for you.

I think this is very strongly implied if not explicit here:

Experienced Drupal developers and site builders who are comfortable hand-picking
modules and recipes to build out a site, but are not necessarily going to create their own
repeatable CMS for this purpose.

e.g. an experienced no-code site-builder might still want to use Drupal core, because they're familiar with Drupal concepts, contrib modules etc. especially once core ships with project_browser. But if you don't have that experience yet, then Drupal CMS.

So does this mean Drupal core still has to prioritize these sites even if they don't fall under the current area of where we want to "play"? Does this effectively mean we can’t narrow where we play?

I added this bit, and it's intended to communicate that Drupal CMS doesn't provide ongoing upgrade paths for sites built with it, and that means the responsibility falls to core and contrib to provide smooth upgrade paths - partly automatic updates when it's in core, partly having robust and well tested upgrade paths when we add them that don't break people's sites, partly the bc/deprecation/release policies etc.

Can we narrow the focus to "complex" sites,

This makes sense to me.