Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
This came out of a discussion with @catch, @lauriii, @gabor hojtsy, @pameeela, @xjm, @wim leers, @phenaproxima, @timplunkett, @pdureau, @ckrina at DrupalCon Vienna.
Drupal CMS is taking over the 'default UI install' experience from Drupal core.
#3591027: [META] Remove use case specific elements from Standard and Node module. Always install with Standard. Keep Minimal for CLI use only. is open to slim down the Standard profile so that it doesn't include content types. Part of this is to not ship with a theme but let users pick a theme and frontend solution, based on their technical needs. Drupal core being a platform for highly custom needs people will not use Olivero almost ever for sites. The target audience of Olivero will now use Drupal CMS and get a theme (different from Olivero, or Olivero as part of a site template) from there in a selection of a dozen site templates already.
Umami as a demo is already hidden away from users, they should install Drupal CMS with site templates. Those templates have purpose built, purpose designed themes for their use cases. Olivero does not have such a use case, neither sample content. Much configuration will not be left in Standard following the above. The starter guidance functionality of Olivero will be taken over by the system in #3572350: Disable the default /node listing view and add a better default front page for new installs (displayed in the admin theme at the start).
Steps to reproduce
Proposed resolution
Deprecate Olivero in Drupal 11, remove in Drupal 12 and move to contrib. (There is already a contrib repo, so the code of that needs to be updated).
Comments
Comment #2
deviantintegral commentedThe most common use case we have for Olivero is developer testing, as way to find out if a bug can be replicated against a simple install. Stark is pretty rough to use for that use case. Would the idea be that the front-end defaults to the admin theme instead?
Comment #3
gábor hojtsyYes, the frontend will default to the admin theme and display a page telling you to pick a frontend solution (decoupled, Canvas, Display Suite, Layout Builder, Paragraphs with a theme that operates well with it). #3572350: Disable the default /node listing view and add a better default front page for new installs already moves the instruction/welcome page from Olivero to the base system which will be updated to suggest picking a frontend theme / solution to start using Drupal. I think it will need a more broader rewrite following the lack of frontend theme, since that is a strong signal that Drupal core is not for starter personas.
Comment #4
gábor hojtsyI opened #3590882: Don't enable the Olivero theme by default in the Standard profile/recipe as a related issue which we can already do / experiment with without even deprecating Olivero or removing it. We can assemble the Standard profile however we see fit.
Comment #5
mherchelThis is like an end of an era for me. I learned so much creating Olivero. Very bittersweet, but I do like the direction Drupal is going. Count me in as a contrib project maintainer.
Comment #6
nicxvan commentedI rarely use it, but do we really want to ship without a front end theme?
Comment #7
gábor hojtsy@nicxvan: yeah all the steps in #3159848: [Policy] Merge the minimal and standard install profiles into a starting point recipe are about removing "product" assumptions about Drupal core's default experience: that you would post nodes in time order on your front page and have articles and comments on it. All of these assumptions belong in site templates now and Drupal core as per the current strategy is for highly custom needs, where the assumptions will be far from the same assumed for a simple blog-like site. These days people building with Drupal core as a base will either want a decoupled setup (not Olivero) or a component based setup (Canvas, Display Builder, Paragraphs, Layout Builder) with a custom look (not Olivero).
The target persona that would use Olivero and the blog-like default setup is now at the site templates, not a persona for core.
I think this issue is what makes the strategy real to people building with Drupal core visually and is a strong statement indeed.
See https://www.drupal.org/about/core/policies/drupal-core-strategy
Comment #8
gábor hojtsyAdjust parent to implementation issue from policy issue.
Comment #9
gábor hojtsy@catch already opened #3555047: Core should ship with only an admin theme in last October which is as of now titled "Core should ship with only an admin theme" but was more focused on what happens if we remove block UI, so will now repurpose to that. However there was this approval list of those that discussed moving away from Olivero, so saving here for posterity as co-signees of what is being discussed here:
Also updating the issue summary with this.
Comment #10
gábor hojtsyAdded credit for those mentioned from the meeting.
Comment #11
quietone commentedRemoving a module from core needs sign off from all the committer roles and the subsystem maintainer. The product managers, lauriii and gabor hojtsy, have approved this as stated in the issue summary, This still needs input from the frontend framework managers, the release managers (2 of 5 have been involved) and the subsystem managers (1 of 4 have spoken here).
Comment #12
justafish+1
Comment #13
godotislate+1
Comment #14
longwave+1
Comment #15
kostyashupenko+1
Comment #16
quietone commentedI checked with the release managers and we all agree to remove Olivero.
Concern was expressed that this would mean that there would no longer have a user facing theme to test feature. However, Start or Admin could be used. A plus was that core could drop some default CSS which in turn would allow CMS and contrib to innovate better.
Comment #17
quietone commentedIn a Slack thread @gábor hojtsy mentioned a discussion in core-maintainers where Olivero subsystem maintainers andy-blum and kostyashupenko did not object to this change. I have read that thread and confirm this is true, so I am removing that tag.
I tagged this for frontend framework manager review but I am no longer sure about that. I have asked the other committers.
In the meantime, I will proceed with creating the various deprecate and remove issues.
Comment #18
quietone commentedYes, confirmed with nod_ that I should not have added "Needs frontend framework manager review". So with that removed this has all the sign-off required.