In my previous post, I walked through the installation of Drupal CMS 2.0. On the surface, the promise of a "move-in ready" Drupal was incredibly appealing. It looks modern, feels more accessible, and finally positions Drupal as a true "product" rather than just a developer's framework.
However, after spending some quality time with the user interface and exploring the pre-configured templates, I realized that Drupal CMS 2.0 isn't for Me. I’ve decided to make a U-turn and return to Drupal Core 11.
Why Drupal CMS 2.0 Isn't for Me
1. Too Many Div Tags
Just like Drupal Core, Drupal CMS uses nested div tags to ensure its layout is robust and responsive. However, to support the new visual Experience Builder and various "Site Templates," the nesting has become extreme. When I inspect the HTML of the homepage—which is currently nearly empty—I see a deep hierarchy of containers just to display simple elements. Look at this snippet from the navigation area:<div class="navbar--menu fixed inset-0 top-[calc(var(--drupal-displace-offset-top,0px)+var(--gin-toolbar-height,0px)-var(--navbar-scroll-top,0px))] grid shrink-1 grow-1 grid-cols-[1fr] grid-rows-[auto_1fr_auto] flex-col items-stretch justify-start bg-background pb-8 md:static md:flex md:h-auto md:flex-row md:items-center md:bg-transparent md:pb-0">
<div class="navbar--modal-top relative z-[500] col-span-1 col-start-1 row-span-1 row-start-1 container mx-auto flex w-full justify-between p-2 md:hidden">
<div class="navbar--modal-logo flex min-h-[44px] flex-1 flex-col items-start justify-center md:hidden [&>div]:flex [&>div]:flex-col [&>div]:justify-center">
<div id="block-032b3150-7557-468a-ba40-d1c8fdc27f11--2">
<a href="/" class="inline-block" rel="home">
<div class="branding">
<img class="h-full w-full" src="/themes/contrib/mercury/logo-dark.svg" alt="">
</div>
</a>
</div>
...
</div>
</div>
</div>
<nav> and a <div> tag, keeping the code clean, semantic, and easy to maintain.
2. Too Many CSS Classes
In the code above, you can also see the second major issue: the massive string of Tailwind utility classes. Here is another code sample:<div class="[&_h2]:mt-6 [&_h2]:mb-3 [&_h3]:mt-4 [&_h3]:mb-2 [&_h4]:mt-3 [&_h4]:mb-1 [&_h5]:my-2 [&_h6]:my-1 [&_h2]:text-2xl [&_h2]:lg:text-3xl [&_h3]:text-xl [&_h3]:lg:text-2xl [&_h4]:text-lg [&_h4]:lg:text-xl [&_li]:mb-1 [&_ol]:my-4 [&_ol]:list-decimal [&_ul]:my-4 [&>*:first-child]:mt-0 [&>*:last-child]:mb-0 [&_a]:underline [&_a]:underline-offset-2 [&_a]:transition [&_a]:duration-300 [&_table]:my-6 [&_td]:p-3 [&_th]:p-3 [&_tr]:border-b [&_tr]:border-b-border/40 [&_blockquote]:xl:3xl [&_blockquote]:text-xl [&_blockquote]:italic [&_blockquote]:md:text-2xl [&_blockquote]:m-auto [&_blockquote]:max-w-3xl [&_blockquote]:[&>*:last-child]:mb-0 [&_blockquote]:my-8 [&_blockquote]:border-l-4 [&_blockquote]:border-border/40 [&_blockquote]:py-1.5 [&_blockquote]:pl-4 [&_figure]:my-6 [&_figure]:w-fit [&_figcaption]:block [&_figcaption]:pt-2 [&_figcaption]:pb-3 [&_figcaption]:text-sm [&_figcaption]:opacity-80 [&_figcaption]:lg:text-base text-foreground [&_a]:hover:text-foreground/70 text-sm md:text-md xl:text-lg">
<p>Subscribe to our newsletter to be the first to know about our latest updates, exclusive offers, and more.</p>
</div>
<p> tag.
In Drupal CMS, styles are often "hard-coded" into the HTML attributes. A single div can have 20 or 30 classes defining everything from grid columns to specific pixel-based offsets. This makes the HTML nearly unreadable.
If I want to change the look of my blog, I want to do it in a central CSS file or a clean Twig template. I don't want to hunt through a "soup" of utility classes across dozens of different block configurations in the database.
3. Excessive Module Overhead
Drupal CMS comes pre-configured with a massive stack of modules to support its "move-in ready" promise. When I inspected the administration panel, I found that dozens of modules were already installed and enabled. While these are high-quality tools, many of them are simply "dead weight" for a focused, content-centric blog. For instance, my fresh installation had the following modules installed and enabled:- CVA (Class Variance Authority)
- Drupal Canvas
- Drupal CMS Helper
- ECA
- Drupal Symfony Mailer Lite
- Mail System
- Easy Email
- Modeler API
- Checklist API
- Login with Email or Username
- Project Browser
- Scheduler
- Real-time SEO for Drupal
- SEO Checklist
- Klaro Cookie & Consent Manager
- Webform
It's Much Harder to Customize than Drupal Core
This is the most important realization of my trial: Cleaning up a pre-built product is significantly harder than building from a clean framework. One might argue: "Why not just use a custom theme with Drupal CMS to keep the code clean?" Technically, you can. However, because Drupal CMS is a cohesive finished product built around a specific layout logic and module stack, trying to enforce a minimalist custom theme feels like subtractive development. So, in this situation, instead of spending your time building new features, you spend it:- Uninstalling Recipes and disabling modules that insist on injecting their own logic.
- Fighting Wrappers by writing complex CSS overrides to hide deep-layered div tags.
- Managing Dependencies that you don't need but the CMS Product requires to function.
What I Learned from Drupal CMS 2.0
Even though I’ve decided to roll back to Core, my time with Drupal CMS 2.0 was a highly valuable "technical audit." It provided a masterclass in modern Drupal curation and gave me several insights that I will apply to my new Core-based websites:1. A Curated "Best-of" Module List
Finding the right modules in the massive Drupal ecosystem can be overwhelming. Drupal CMS does the hard work for you. From my trial, I’ve identified several "winners"—like Project Browser, Real-time SEO, and the Gin administration theme—that I will definitely be installing manually in my Core setup.2. The Power of "Recipes"
The concept of Recipes is a game-changer. Even if I don't want the pre-packaged recipes, I’ve learned that Drupal is moving towards a much more modular way of handling configuration. I’m now looking into how I can create my own "Lean Recipes" to speed up my future site deployments.3. Modern Tech Stack Validation
Successfully running Drupal CMS on PHP 8.3 and PostgreSQL 16 gave me the confidence that this bleeding-edge stack is ready for production. It proved that the underlying engine is faster and more robust than ever, regardless of which "flavor" of Drupal you put on top of it.4. The "Product" vs. "Framework" Clarity
This experiment helped me define exactly what I want from a CMS. I realized that for my personal brand, I don't want a Product that makes decisions for me; I want a Framework that empowers me to make my own. Understanding this distinction is vital for any developer planning a long-term digital asset.Conclusion: Two Paths for Different Users
Just like what the official Drupal site suggests, these two versions serve different needs. Drupal CMS 2.0 is the future for new users. It is a Product. It’s for those who want to launch a professional site quickly without touching code. Drupal Core remains the gold standard for experienced users and devlopers. It is a Framework. It’s for those of us who want a lean foundation to build something bespoke—whether it's a high-performance minimalist blog or a complex enterprise application with many unique content types. I’ve wiped the database and reinstalled Drupal Core, which is what you are seeing now. Welcome back to the Core.- Log in to post comments