Drupal 7 is gonna haunt us forever... I was working on it as late as 2021-22, and even then it kept getting extended: https://www.drupal.org/psa-2023-06-07
> On February 23, 2022, we announced that we would be extending the End-of-Life for Drupal 7 until at least November 1, 2023. Today, we are officially announcing that Drupal 7 will reach its end of life on January 5, 2025.
There's also a whole cottage industry of Drupal 7 vendors/consultants who will provide support past end-of-life, or help you migrate to 9.
I think it's a double-whammy because the kinds of organization drawn to something like Drupal (a powerful all-in-one monolith) are inevitably the same orgs who put everything into it and never want to care about maintaining or upgrading it afterward. They're in for a WORLD of hurt if they want to move to 8+... there's no upgrade path, it's just a rewrite.
My thought as well. Craft is (inexpensively) commercial but it essentially starts where you’re fighting to get with Drupal for medium-sized projects. And authors like it.
As a CMS with web framework features, it’s also built on top of a model/controller-based framework, using Yii instead of Symfony. Craft has thinned their abstractions over time to more directly match Yii’s methods.
His little startup succeeded in getting many millions of dollars of VC money poured into Drupal, and it’s actually a really good way to build a serious website now, for a particular niche. It’s not for SPAs, and it’s not for non-developer hobbyists, but it’s the best way I know of to build a performant content-heavy multilingual website. You have to be willing to a) write code and b) learn an extensive framework. Lots of people only want to do one or the other of those things, so it’s not for them.
I've been away from Drupal for ~10 years, but I recently helped a friend spruce up a Drupal site he's working on and still found it's largely powered in production by heavy caching, and the page load speeds in development are a slog. I didn't know enough about how he built the site to know if that's still the case everywhere in Drupal or just his configuration, but my impression is still that it's absolutely not production ready without heavy caching in front of the site.
Drupal IS slow, but many "modern" sites in JS or Wordpress are pretty heavily cached too. There's just no beating "static HTML file served over CDN, with portions rehydrated".
Whether you generate that HTML in Drupal, Wordpress, or some other system, having to run code to generate it is always going to be slower than caching. Drupal is plenty fast for internal previews (i.e. when the server is not overloaded), but at the end of the day it's still a PHP app, and LAMP/LEMP is generally harder to scale up and across vs plain files.
And for what it's worth, a Drupal site cached behind Acquia/Pantheon/etc and their CDN can -- usually will -- be faster than an uncached JS site served from any single data center.
So it's slow for any dynamic site? Like if I want to use it to serve a site with user generated content recommended by AI, like a reddit or twitter it's bad for that usecase?
Drupal? I think that would be very slow for that use case (if you want it to be real-time, as opposed to write-rarely-read-often, for a large number of users). I haven't tried to optimize it for that particular case, but out-of-the-box, the Acquia/Pantheon setups aren't really meant for something like that.
You could, however, use Drupal (or any other CMS) to manage the relatively infrequently-changing parts of the website (static assets, the layout, introductory text, landing pages, much of the Javascript, etc.). And then use AJAX to dynamically fetch in the dynamic portions (the user content) from some other API.
I doubt that's the best approach though... probably there are better systems for something like that. Not my specialty though, sorry =/
------
edit: It's also very different if you're operating at reddit scale vs "small website with a few dozen comments a month" scale. If you're not expecting heavy, consistent real-time traffic, it'll probably be OK. Not as fast as it could be with better architecture, but fast enough that users will put up with it. Hell, we all did it for years with phpBB, the Drupal forums, etc.
What in this stack allows mass real time writes and cache invalidations?
Bigpipe looks like it chunks data from the server to the client, but it's not clear to me how that helps with real time updates to the database?
Varnish can help to a degree, but if you're on a big provider you're going through their Varnish setup anyway (among other caches) and it's not super configurable.
Drupal 8 introduced an entirely new caching system, with actually good cache invalidation. Right now if I save new content on one of my sites, it queues an invalidation request that gets sent to Varnish (which can be run either as a shutdown function or via a queue runner on cron) and the new content shows up within seconds.
I’m not sure I read the OP the same way you did. If you read it as “can I build a site on the scale of Reddit or Twitter with Drupal” then no, don’t build Reddit or Twitter with Drupal. If you read it as “will Drupal serve a site with user generated content” then yes, it will, but if you’re planning to be a top 10 site on the internet, you’ll need a custom stack.
There's a lot of room between small- to medium-sized and Reddit-sized. Drupal 9/10 scales out well and does just fine at that large (read "enterprise") size. But certainly the more read-heavy a site is, the more suited it is to Drupal.
I have never made that to work. With Akamai we are resorting to lower ttl for cache expiry. The tag based cache architecture in practice is not helping with constraints from CDN providers
Any chance of switching to Fastly? Or at least testing it? There's excellent documentation for a working setup here: https://docs.lagoon.sh/drupal/integrate-drupal-and-fastly/ I don't know how to get invalidation working on Akamai, but the process of getting it working on another provider might get you the insight you need to get Akamai working.
> if you’re planning to be a top 10 site on the internet, you’ll need a custom stack
To be fair, that's the case with pretty much any CMS. Even if they start with a stock system, by the time they actually hit top 100/1000 (let alone 10) there's a lot of custom work to be done.
And realistically, a "top 100/1000 site" is almost always going to have a cloud of other sub-sites and related properties. The corporate site, intranet/HR, jobs and recruiting, press center... The penumbra of "Oh, yeah, we need one of those... but it would be ridiculous to build it from scratch" sites for a large organization can be pretty large indeed.
Right, the caching is how you get the performance. Ideally you’re behind, say, Varnish. (Like I said, it’s not a hobbyist platform anymore IMO.) There’s pretty slick cache invalidation now, so you can set up Varnish with long cache lifetimes, and still get near-instant updates as authors save content.
A few years ago, most of my job was maintaining a Drupal 7 installation for a mid-sized nonprofit. It's the most "built by engineers for engineers" CMS I'd ever used -- I don't mean that as a positive -- and the UX was atrocious. Everything was buried layers deep both in the UI and in the schema, a simple string change would take multiple functions (to go through the various localization and abstraction pathways), the plugin ecosystem was mostly abandonware that made NPM look like a well-manicured garden, etc.. The community was friendly enough, but overall it just felt like I was working with very old technology and ideology. Reminded me of the Perl days.
Eventually I was tasked with upgrading it to Drupal 8/9 (a new generation, with no backward compatibility with 7.x). It was basically a full rewrite. Well, I built a prototype in the new version, but it was still a convoluted mess -- slightly better, but nowhere near "modern". The whole thing is just way more complicated than it needs to be, and reminds me of 90s-style data management, and a web UI reminiscent of cheap wifi router dashboards: ugly, very slow (much of it wasn't ajax yet), and in general just total drudgery to work with.
After I built that prototype, I swore to myself, "This is the last time I'll ever use Drupal. Ugh." As a proof of concept, I also built that same prototype in several other CMSes: Wordpress with Advanced Custom Fields, Ghost, DatoCMS, Strapi, Contentful, GraphCMS (now Hygraph), Storyblok, Grav, etc. ALL of them were way more usable than Drupal, and each one took like 1/10th the time or less to make. It was especially fast with the headless CMSes + Next.js
Wordpress with ACF was probably the closest direct comparison, and that provided a much better editor experience, but still had poor DX (cuz you had to either work in Wordpress/PHP, or else shim ACF with other plugins to make it act headlessly).
It took me a few months to upsell the team, IT, and management to switch to a proper headless CMS instead, completely detaching the editor experience (managed by the CMS) and the DX (we were now free to develop the frontend however we wanted to, fetching content via GraphQL). It made everyone happier in the end, and it's much more maintainable.
Editors never have to care about forced upgrades, web technology changes, etc., anymore, and devs don't have to worry about accidentally breaking the editor experience while working. And a modern Jamstack (or anything else, really) is way way easier to work in than Drupal or Wordpress templates, especially since they don't share the same server as the database & editor and can be independently hosted, developed, tested, deployed, etc.
I still would never touch Drupal again. I've never used a technology I was so annoyed by (and that's coming from someone who grew up writing AT commands for their 14.4k modem, made websites in Perl, had to use Applescript to shim Filemaker into a web CMS... ugh.) Drupal is by far the most traumatic software I've ever had to use.
---------
Side note: Drupal itself aside, companies like Acquia and Pantheon do make the experience much nicer though. They basically manage hosting, forking, dev environments, backups, visual diffing etc. for you, like a bespoke cloud tailor-made for Drupal and Wordpress. I would definitely host at one of those companies (I prefer Pantheon, personally, but both are great compared to non-Drupal-specific hosting).
I thought Drupal 6 and 7 were great, but this was about 5-10 years ago. Haven't looked at it since then. It was the first CMS I worked with professionally, so I may be biased, but once I "got it", it became quick to add features (not "Features", which wasn't very fun). This was before everything went headless and javascript :)
Drupal 6/7 was actually what led me to discover headless and JS :) After I learned it and built a few features & Features, I thought to myself, "Huh, okay, I see what they're getting at here... it's pretty powerful, just hard to use. Wonder if there's an easier way to do this..."
Turns out, absolutely yes! I guess there's a reason why headless and JS exploded. We migrated and never looked back.
You're forgetting the additional eye-poke joys of minor plugin updates causing WSODs, how slow it is without caching, how painful styling certain things can be, how difficult the DB schema is to wrangle with regards to making _any_ changes and dozens of others that are worth forgetting because of various PTSD.
It _is_ flexible for people wanting to be able to create types/taxonomies within the GUI, if you ignore the chaos behind the scenes. It also has good support for returning said content via JSON if you choose to do so, but if you're doing that, just define your own back-end and avoid the suffering.
> You're forgetting the additional eye-poke joys [...]
Oh, no... I didn't "forget" as much as "permanently blocked it out of my memory to maintain some shred of sanity" :)
> It _is_ flexible for people wanting to be able to create types/taxonomies within the GUI, if you ignore the chaos behind the scenes. It also has good support for returning said content via JSON if you choose to do so, but if you're doing that, just define your own back-end and avoid the suffering.
Ultimately this is what convinced us to move to a headless CMS (which I hadn't heard of at the time, and I had to do some research and prototyping to understand it). But through our internal user (editor) studies, we learned that content organization, ease of editing (good WYSIWYGs), relationships, speed, and most of all UI clarity were really important. I built the same prototype in like 20 different CMSes, excluded the ones that didn't meet some baseline criteria, and had the editors and stakeholders try my demos for like 5-8 of the finalists, ranking each one by the ease of several tasks (rich text formatting, linking to related content, restoring a past revision, sharing a preview draft, etc.). Drupal was pretty much dead last in most of the categories (and this was the newer version, 9 I think). I had my own favorites but I let the editors decide, and the headless systems won by a large margin.
Any good CMS these days will have rich taxonomies -- that's arguably the defining characteristic of a proper CMS (as opposed to a blog engine, say). Where they differentiate is in the editor experience (ease of use, ease of drafts, ease of previews, ease of admin, ease of relationships, etc.) and/or the developer experience (response shapes, GraphQL mutability or not, API and SDK documentation and support). But for teams that have a mix of devs and editors, any of those would typically be better for both sides than a bespoke database.
For the editors, a vendor-supported (or polished open-source) CMS means a nicer editing experience than fighting with some tiny team's internal WYSIWYG field tied to a Postgres/MySQL field, with the corresponding bugs and quirks that's never prioritized by the (typically) backend developers and DB admins who care more about schema purity and such.
And for the developers, well, it frees them from having to worry about that and focus on the frontends, mobile apps, whatever, and also gives them the freedom to use whatever stack they want (be it Jamstack, .NET, HTMX, whatever). The content just come in as JSON and the rest is entirely up to them.
I feel like Drupal tries to occupy that space where it tries to do all of the above (and it CAN, to be fair), but it's not great (or even GOOD) at any of it. It's just a mishmash of sub-par experiences where nobody is happy, except maybe management (because they can worry about just one piece of software at one vendor like Acquia/Pantheon).
Even if your constraints are PHP and self-hosting/commodity virtual hosting, I think Wordpress + ACF is a way cleaner experience for the majority of sites...
Full disclosure: I now do some paid work for one of those CMS companies, so I don't want to give a biased answer :) I'm also not authorized to speak for them. What I can offer, though, is what I remember of our finalists of the Drupal migration project (what the parent post was about) -- that happened long before I joined the CMS company. Also keep in mind this info is from circa 2021-22; I haven't reevaluated since then and the players might've changed. That said:
* Contentful was by far the market leader. They were one of the first in the space, and probably the reason it got so big. Their UI was pretty decent, SDK and docs were good, support was good, good plugin ecosystem... but it was really expensive. When they started they were really affordable, but eventually I think they pivoted towards enterprise and wanted to wind down their more affordable plans. At the org I worked for, they wouldn't quote us an enterprise plan until we signed a NDA, and provided very limited developer sales/devrel time. My boss wasn't willing to continue with the sales process after that.
* DatoCMS was the most editor-friendly one, with a really nice UI, powerful field types, and a good admin interface with good roles & permissions & workflows that enabled complex user types to work in different parts of the CMS. Had a good plugin ecosystem, community support, and a small but really friendly and helpful team of staff. The sales process was great, with several of them sitting down with us to discuss all the details we needed. This was the editors' favorite in several ease-of-use categories. The primary concern there was that they're a relatively small Italian company instead of some huge American business (meaning potential time zone issues, etc.), but they'd been in business a few years already by that point and we were impressed by how supportive and welcoming they were.
* GraphCMS, now Hygraph, was what I considered the most technically powerful of the bunch. It had a really clean API, and was the only one (at least at the time) which allowed GraphQL mutations, meaning you could actually write to the GraphQL API. The others all needed REST APIs for updates, and provided GraphQL for reads. Its UI was pretty good, though a bit developer-centric compared to the others (like fields at the time didn't have editor-friendly labels, just their developer-facing names). The sales process was also great, and they were very accommodating of our questions.
* Prismic offered a really clean editor interface and stood out to me as the one that lets you jump right into editing the quickest. However, at the time, it didn't have some of the more advanced relationships / field types that we needed (don't recall the details, sorry). But I do remember it as "a CMS to revisit if I ever needed a simpler, cleaner one for a less complex schema" just cuz it felt so polished and easy.
* Wordpress with Advanced Custom Fields (a plugin), to my surprise, offered some of the most powerful AND easy to use schema, both in terms of the cleanliness of how it comes out in the API and in terms of how easy it was to compose/define in the editor and admin GUI. If data modeling were our chief concern, this would've been one of the top choice. ACF was really good, but we didn't want the baggage of Wordpress itself (i.e. having to host a LEMP & WP stack on Acquia or Pantheon just to run ACF headlessly; that'd be a waste of resources and dollars).
* There's a bunch of other commercial ones (Sanity, Storyblok, ButterCMS, Agility... see here for a list: https://jamstack.org/headless-cms/). In general they were all "good enough" and passed most of our criteria, but just didn't really stand out against our finalists. But that was just us, with our particular evaluation criteria and our specific individual editors' preferen...
My sentiments and experience completely. Could mostly put up with the DX with the right mix of modules in place, but never got over the UI. Next. Level. Terrible.
Drupal is a great CMS framework. With Drupal and a capable development team, you can use Drupal to build an awesome CMS, and if you want to, also an awesome website on top of the CMS.
Drupal is not a great piece of software to try to use out of the box as both a CMS and a website front-end. Drupal doesn't have the same kind of ecosystem as WordPress. Many of the best themes and modules are really there to assist your development of your own features, as opposed to being plug-and-play solutions.
I'm not sure I understand the question. Drupal is a headless CMS if you want it to be. Do you mean what would be a reason for using Drupal's front-end over developing your own? I came to Drupal from managing community sites with lots of different user roles that each need complex permission sets, and I'd say it really excels over other CMS front-ends for that. Drupal.org is itself an example of this kind of site: thousands of different users (including untrusted users) logging in and creating and editing and moderating content in real-time. Sure, you could rebuild all of this functionality with the exposed APIs, but that'd be a ton of work.
You can easily use Drupal to create the backend for a headless CMS. It's about as simple as turning on the JSON API module that comes out of the box, and then start creating content types.
But then you're having to maintain the CMS, which isn't as appealing as using something like Contentful. It really depends on your use case (like all technologies, of course).
Drupal 8+ is an improvement over 7/6, especially for developers. It's more aligned with Symfony, which makes it much easier to write maintainable modules. You can also use it as a headless CMS if you have your own frontend (eg: mobile apps)
For editors, you have a slightly better default UX (Claro/Olivero), views builder, workflows, etc.
Cut my teeth with drupal back in the day. I walked away after 5 years feeling like I stifled my growth as a programmer because all I ended up doing was hacking away at this behemoth of a framework to try and overcome all of it’s idiosyncrasies.
There must be something good about Drupal, but I was unable to discover it during the 6 months I had to work with it in 2008. The code was messy and the UI unnecessarily complicated. The most unsettling observation though, was that all the people who seemed to believe in it had no idea what they were talking about. I learnt Python, Django and PostgreSQL and never looked back.
It was a very early instance of "WebCMS with a package manager / plugin architecture that's usable by Normal People".
Then, of course, once adopted - like most CMS - it's very hard to migrate out, and it snowballs.
People largely went for Drupal over WP or Plone or Django because they had zero leverage about 1) what comes in to the content system, 2) how they can build a content system, and 3) what comes out of the system. Also, in the aughts, don't forget that WP was extremely primitive compared to today. Lots of enterprise leadership said, "oh, you can't have Python, that's for engineers" combined with "you have to read and write all articles to this arcane XML schema only parseable to five academics in France". Thus the Drupal extensions ecosystem ended up with a TON of low level plugins . . like Drush, which probably shouldn't have existed.
Drush (drupal shell) is just a command line interface to any given Drupal site, similar to Laravel's Artisan console, or Django's django-admin & manage.py, or Wordpress's wp-cli. Managing a Drupal site is much simpler when you can do certain things from the cli: run cron tasks, cache rebuild, import/export config, enable/disable modules, use the built-in REPL to troubleshoot stuff, not to mention the various commands that modules expose.
My feelings are probably dated. Back when Drush was first a thing, it needed su for some of its tricks, which was . . well, back in the pre-containerization days . . insane. There were a LOT of emergency updates we had to do purely to keep Drush running and safe.
Speaking more broadly, Drupal was also seen less as a "framework" and more of a straight "CMS", so the idea of a CMS needing a CLI was, then, a bit of a "Huh?". CMSs were regarded, at the time, as the thing you set up so the secretaries and executive assistants could update the website. Of course, in the decade and a half since then, we've seen how CMSs inevitably grow into pseudo-frameworks.
We also have a better grasp, today, on just how complicated the functionality of a CMS actually is, laying as it does across the intersection of natural and formal languages. A linguistics specialist could have predicted this, or even a dedicated data scientist, but the content world is shockingly bereft of linguistic specialists among its spec writers and practitioners. DITA - to abuse one single example - arose almost entirely from pedagogical academics, with no input from linguistics, computational or otherwise. And DITA is actually kinda-sorta planned. The various MIL-STD content specifications - 48 and counting, not including the bespoke USN things - don't arise from anything, they're just eternal flypaper for whatever contract items get thrown at them, plus golden gimmes from the blessed vendors.
FWIW, the "Drupal should be a framework" vs "Drupal should be a web page management tool" issue wasn't a matter of ignorance in the community as much it was a point of contention — there were fairly high-profile talks at Drupalcon as early as 2011 hitting on that very issue, and some of the linguistics stuff you mention was coming up in core conversations not much later than that. (Source: Was the crazy guy ranting about content-as-a-languagelike-system-of-communication in many of those conversations. Whew, DITA. Memories.)
The challenge, I think, is that by that point in time Drupal had gone through its first big popularity explosion, and was starting to grapple with the competing interests of many different audiences. Acquia ended up being instrumental in steering it towards "enterprise sites with complicated UGC requirements," but for quite some time the open source ideal of "the project reflects the priorities of the people who contribute time to it" meant it lacked a strong, opinionated take on many of the things you mention.
For many years Drupal's strength was (IMO) that enough of _those folks_ existed in the community to ensure you could build complex, highly adaptable structured content systems with it... and enough of _those other folks_ existed in the community to ensure that there were click-together content display and delivery tools that worked with the complex content. If you approached it with a clear understanding of where some of those boundaries were, you could build really amazing things — but if you came in looking for a well-paved path to build a simple site or architect a complex one, well... ¯\_(ツ)_/¯
edit -- clicked on your profile and read some of your posts in other threads, and I feel like I should just get a beer and commiserate with you about doomed CCS initiatives for a few hours. I salute you.
Back in the Drupal... 6, I think? days it was a really, really nice way to do a rapid prototype of a CRUD app. CCK, Views, etc. would let even a minimally technical person whip together what they wanted for something like an in-house ticketing system or knowledgebase or whatnot. We put some neat stuff together for the newspaper I worked at using it.
All that flexibility resulted in pages with 1k+ queries on them, and nasty upgrade paths. I hear D8 is Symfony-based now, and a lot got cleaned up, but after one project upgrading a Drupal app from one major version to another I won't touch it again. After a month's worth of work we refunded the client and canceled the job.
Yes, upgrades between major verions (especially to v8) were painful to the point where you seriously considered whether it would be faster to just start over from scratch.
Last time I looked at Drupal (a few years ago) the majority of Drupal 7 modules had not yet been ported to v8 which had been released for some time at that point.
I also spent a number of years doing Drupal work at a newspaper. A bit ealier..99.9% sure it was on D v5. I ended up actually re-writing large bits of the core content logic to make it not blow chunks. This is 2009-2015 time frame.
Wrote something called the "page module" that let them build out the various landing pages using extremely flexible criteria ... everything from tags to specofic articles to category - and probably more that I'm forgetting. I built specically because views just wasn't good enough. It was able to do a couple of very important things... It had what was essentially a materialized view that was maintained by the import scripts (All actual content editing was done in the propritary publishing software they used, then sent as XML to the web importer which ran constantly looking for new xml files in a directory).
The big upshot of this was that is that getting, saying, the articles for a given "page" (Which wasn't necessarily actually a page - there were also presentations like sidebar lists) was a SINGLE query with no joins. Very performant. We did millions of page views daily on one web server and one db server... both low end commodity boxes.
It was kinda fun, but when I left I made a promise to myself to never, ever, work with Drupal or PHP every again professionally, and I've been quite happy to stick to that.
IMHO only: I think it's one of those enterprise-y software that tries to do everything, like Salesforce or Peoplesoft. It doesn't do any of it quite WELL, but it's a single source of truth, and a single product to support/pay a subscription for/admin. It lends itself to environments that are IT admin heavy, don't care about DX or editor experience, and/or want to outsource some of that work (there are a lot of Drupal contracting shops around). These are often the management-dominant companies that shop for solutions not based on user/staff satisfaction but because it checks enough boxes for them.
As someone forced to use it and learn it for 2 years, I did what they asked me to, cleaned it up, and then convinced everyone to move away to a different system (detailed here: https://news.ycombinator.com/item?id=38489357).
We ended up with a system that was much much faster, much easier to edit, easier to maintain/develop, and thousands of dollars cheaper (compared to Acquia). It's the kind of thing that management would never have bothered to investigate without internal pressure (because, again, Drupal checked all the boxes). It's just an implementation detail that bigger businesses are happy to spend resources on, but it sucks for the day to day users.
It falls squarely in "never EVER again" territory for me too, like others here.
IME this happens when site developers do not bother to pare down user permissions, at least for users with privilege to edit the site. Which seems to be extremely common, at least back when I worked with drupal - 6.x and 7.x. When you can see every bell and whistle it does get quite messy. But it is possible tighten up permissions and when you do so the controls you don't need are hidden.
IMO this is a failure of Drupal's UX and IA, not just permissions. The software is organized from a DB admin's viewpoint, it's laid out like schema, and has nested layers of configs more complex than my IDE.
The whole thing has that "made by developers, for developers" feel, and editors are a complete afterthought. Maybe that was the norm in the 90s and 2000s, but these days there are much more user-friendly, editor-forward options that give them a nice experience out of the box. Drupal never entered that era, and culturally it's still way more focused on the underlying technology than the end-user UX.
It's a CMS that serves admins & management first, developers second, viewers third, and editors last.
I used Drupal for several years across several major versions. Even co-wrote a book on one of those major versions.
Drupal is a web CMS that empowers people without extensive coding experience to do some pretty amazing things. A front end developer at a small consulting company can build a useful experience pretty easily.
And if you are a developer you can extend it extensively.
It hit its peak before some of the extensibility features hit WordPress.
When it moved to being symfony based with Drupal 8 the shift was so great for this audience that Drupal hit its peak usage [1]. It's been in decline since then. Drupal 7 is still the mostly widely used single version and BackdropCMS came long to support that crowd (a Drupal 7 fork).
I look at this as an exercise in knowing your target audiences.
It caused much of the internal of Drupal to be re-written. This included how it was extended. With previous major versions you learned about new features and APIs. They followed mostly existing design patterns so it was easy to learn and updates your extensions for. With Symfony you had to learn whole new systems and ways of doing things. It was like learning something entirely new. And, porting extensions to it was far more work and time.
Also, the updates made Drupal slower while consuming far more system resources for the same thing. This increased costs to operate.
Six months is nowhere near enough time to learn the framework well enough to do anything worthwhile. It’s just enough time to get incredibly frustrated and leave for a tool that’s more appropriate for your current needs. It takes years to get your head around the entire thing. Those of us who (for whatever cursed reason) were able to stick with it that long can in fact do great work with it. I wouldn’t build a corporate website any other way, for example. But I 100% understand people who don’t think that’s a good investment of their time.
When I first moved to New Zealand, I started a diary (before the term blog existed!) using PHP-Nuke. After a while, PHP-Nuke imploded and so I migrated to PostNuke. After a while it imploded so I migrated to Drupal. I had a choice at that stage between Drupal (version 4 it was) and Wordpress. Wordpress still had that "holes, billions of holes" stigma, so I went with Drupal.
Long story short, that's why my online diary (not linked anywhere) runs Drupal 10 to this day. It's now WAY overkill, but it still works well.
I've looked at moving it to Wordpress, or to some static generator but I've got over 3000 entries now and the migration never works very well.
I still find Drupal very easy to work with - my biggest gripe with it was when they just quietly started changing to not downloading .tar.gz but to using composer. And just assuming everyone knew what composer was and how it worked. In the end the friction it was causing me made me learn how to use it.
Anyway my point of this rambling post is that as a USER of Drupal - it's great. I don't write any code, but I can shuffle my website around as I please very easily, adding widgets, changing what's exposed both in the UI and RSS etc.
I didn't quite realise how uncool it was to still use Drupal until I read all these comments! :)
Yeah I don't think they ever stopped, it's just the PostNuke fork had a better community behind it with a deeper focus on security. Then they stopped developing it and instead released a think called Xaria or a similar name, but it never had a strong community.
PHp-Nuke when I installed it I couldn't believe. My own Slashdot!! With comments! It was amazing.
As a user, have you tried any similar CMS offerings at all? Either a totally WYSIWYG page builder like Wix/Squarespace, modern Wordpress with the block editor, a headless CMS, etc.?
Just wondering what your experience is... like is Drupal just "good enough" so you never wanted to switch, or did you investigate several options and choose Drupal because it's better in some way?
Yeah I've got a WordPress blog I self host as well. Having seen how well it's matured I wish I'd picked it back in 2003-4 when I switched.
I've also had a good play with Hugo which I absolutely love. I tried to export my Drupal site to it, but all my old shortlinks broke and it doesn't support making some posts private and available to only some people etc.
So in the end I've stuck with Drupal, I know most of its warts. The key thing is not to use many 3rd party modules, because often they will hold you back from upgrading to the next release until they are upgraded, if they ever are. Now I stick with mostly core modules except for a few I need for other features I require (mostly making some posts needing you to be logged in to view)
You might want to also check out memos. Nothing like Drupal or WP, but for saving notes/entries/memos and having a very simple system to make some posts public, some only shared with a small group, and some completely private, it's a very elegant system. https://github.com/usememos/memos
Any comments from folks who actually kinda like Drupal? I can cop to it almost driving me to tears until I got over the quite considerable learning curve, and once past that I could most any CRUD app with minimal, if any, new code. Once I got over that hump it was actually quite amazing for prototyping CRUD apps or selling small apps to clients that they never would have otherwise ordered given the cost and time of rolling your own.
Honestly Drupal is solid for a number of things, and in terms of getting a CRUD type app/site up it's probably still one of the fastest ways to do it for the non-technical. Actually pretty cool that you can get APIs straight out of the box this way.
That being said, Drupal was initially a forum/blog and it definitely seems somewhat out of place in the modern web landscape. One of its Achilles Heels is that its rendering layer is notoriously slow and overall it's heavy. It's module system also doesn't mesh well with PHP's typical request/response execution model from a performance perspective (anyone who's spent time tuning PHP opcode caching for this knows what I mean).
That being said, the content type and field system is still great and it would be great to see a more generalized version of this concept. This is another area where the implementation is pretty heavy on the Drupal side. Things like this have ultimately limited adoption and not having a clear migration path from D7 to D8 didn't help either.
I’ve been writing Drupal code as my day job since 2009, and honestly I think it’s fabulous. It serves a narrow niche very well. People try to use it outside that niche, and they suffer. I feel for them. It’s not the right tool for everyone. You really have to be willing (and have the time and resources) to learn the entire framework, and figure out the Drupal way to do whatever it is you’re trying to do. The learning curve is indeed quite considerable. But it is a formidable toolkit, once you’ve learned it, and you can do really great work with it, really quickly.
This reminds me of the time I used Drupal for a hobby project of mine (10+ years ago).
I wanted to upgrade it to a new Drupal version, and one of the first steps was "Backup your database".
It'll be fine I thought.
After the upgrade I was presented with a brand new, empty system.
One of the final steps was: now get your backup and load the system with it.
Fun times. Also my last adventure with Drupal.
I used Drupal to build my first real CRUD app. I was a beginner programmer and needed the hand-holding that the framework provided. As my knowledge grew, I found myself relying more on custom modules that I wrote rather than those in the framework. Eventually, I was fighting against the framework more than it was helping. When Drupal 8 rolled around, it was not worth the effort to make the switch. I don't ever see myself using Drupal again but I will always say thanks for providing the training wheels when I needed it most.
I miss Drupal a lot. I sure wish it had won out in the CMS battle with Wordpress. I remember making little custom CRUD apps with almost no code all the way back when Drupal 5 was the thing.
Like a lot of other ppl it seems I left off when they switched to composer. That didn't fit too well into the workflow I had at the time using cheap web hosting services where I didn't get a shell as dev environments.
Also the upgrade treadmill was brutal. A few nice little web apps I made got totally left behind by security updates and such and were also too hard to upgrade to newer versions of Drupal. I remember that also being a major motivator to make the big jump to Python and other things. More code but also easier to manage over long periods of time.
Lots of good lessons in Drupal for other frameworks. I haven't tried it in a while, but it's still in my mind one of the best low-code custom fields, forms, and views systems out there.
In my opinion, Drupal is a much better platform than WP, except that it has always had a much higher geek factor, and I think that's what has stunted it.
I feel that the engineering behind Drupal has always been top-notch. I wrote a couple of Drupal plugins and themes, BitD (Back in the Day), but that was a long time ago. I'm sure that big changes have come, since then.
What I liked, was being able to completely customize both the frontend and the backend of a Drupal site. WP doesn't really give you much, in the way of making its backend much simpler.
During that time, WP has improved its engineering and architecture significantly, so it's still a tough call.
Very true I have been working with a webdev company that only makes sites in Drupal and it was very nice how fast they could implement things but the updates were lengthy and often took way more hours than any small version jump upgrade should take.
And because of the release cycles it's hard (or expensive) to keep a site running for 10+ years. In the end we opted for a plugin called "tome" that would just render the page as a static site and we'd just push the HTML files
The Drupal community made a pivotable decision that ensured it would never "win" a CMS battle with WP.
Wordpress has always been a more product-focused blog/site-builder that works out of the box and simplifies code concepts for an average user who doesn't need to know much PHP to get everything they want to be done. It has always focused on open-source PHP CMS as a product.
Drupal has always been an engineer-first CMS; D8 doubled down on that: focus on long-term maintainability with OOP/Symphony/Composer/etc. That decision caused the casual site-builder who knew little PHP code to say "no thanks". It has always focused on open-source PHP CMS as a framework.
Backdrop happened for those who wanted a good off-ramp for those who were happy to keep the current Drupalisms of D7 and didn't need more PHP-web-dev tools. Unsurprisingly, it became more WP-like as it tilted more toward PHP CMS as a product.
The current community of the Drupal world has kept focusing on improving the UX of the site builder/maintainer role with its current initiatives (auto-updates, project browser) to self-correct.
Ultimately, Drupal focused more on its core strength. That's not a bad thing, that's just product differentiation. It turns out the average website doesn't need to maintain a lot of custom CMS code/workflow/logic they just need to track a handful of blobs of text/image content.
Thanks HN for bringing this up again. I never fully understood what Acquia does and might never will. But it seems to go well, which is hopefully good for Dries. I respect when the open source project and the business behind it are clearly separated.
I've was a Drupal developer for about 15 years, then moved into management, eventually changed to a company that works with a 'modern' stack. I really miss Drupal.
When I started out my career I basically was a one man web design agency, tailoring to small local businesses. When looking for a CMS I quickly found that Drupal allowed me the ease and flexibility to configure and customize websites for my customers. It was a perfect fit for me because I had enough skills to install and host sites, and to customize those things with code that I couldn't find a ready made module for.
Over time Drupal changed a lot, and my skills grew. My focus shifted more and more to the technical side. As Drupal became more professional, so did I, and with it, the customers became a lot bigger too.
I started to manage a team of developers, and then multiple. Finally I made a move to a big Corp in which Drupal was not used. I like the people that I work with a lot, all extremely capable and talented people. But I feel we're constantly reinventing the wheel. Things that I feel have long been solved in Drupal are somewhat half-assed due to the chosen tech stack and the time constraints. Drupal may not be perfect, but it did have an evolution of more than 20 years, and that shows. A very strong entity system, fields, taxonomy, user management, roles/permissions, i18n, asset handling (media), slugs, redirects, breadcrumbs, workflows, revisions, and perhaps the cherry on top: JsonApi (a porcelain if you ask me). A strong community and reasonable documentation means that it's possible to switch vendors, as everybody works with the same API's (mileage may vary a bit).
The situation now with where I'm at couldn't be further from that. Everything JavaScript and microservices based, build on a (imho) dreadful SaaS 'CMS' (Contentful). The so called 'enterprise' CMS is severely lacking, it's a usability a nightmare, I can't stress how bad it is. It's basically a glorified database, which means that everything else needed is being built completely from scratch. That simply doesn't compete with the 20+ years of evolution Drupal has had.
I think that's a great point: that Drupal gave you a whole car, while today's JS gives you five incompatible wheels, thirteen colors of duct tape, and three fragile shells to put over them. Drupal had a lot of really strong (as in idiomatic and enforced) patterns that didn't let you take dirty shortcuts. As much as I hated it, it was solid engineering. (I'd consider it overengineered, but that's only cuz I'm coming from the opposite extreme... Frontpage and Dreamweaver).
That was probably also its downfall. It had a huge learning curve (same as Angular's downfall). And it didn't make for easy division of labor, and there was no quick and dirty way to do anything. The reason why there are so many Drupal consultants is because it takes so much manpower and brainspace to understand how Drupal is architected. With a headless CMS, the schema admin, the content editors, and frontend devs could each do their jobs independently without stepping on everyone else's toes. It's not as complete as a majestic monolith but each person's job was a lot easier, and way more isolated and safe.
Drupal tried to be everything for everyone, and in the end it was just too much for any one normal person. It's what happens when engineers design products for people who aren't like them.
97 comments
[ 2.8 ms ] story [ 161 ms ] thread> On February 23, 2022, we announced that we would be extending the End-of-Life for Drupal 7 until at least November 1, 2023. Today, we are officially announcing that Drupal 7 will reach its end of life on January 5, 2025.
There's also a whole cottage industry of Drupal 7 vendors/consultants who will provide support past end-of-life, or help you migrate to 9.
I think it's a double-whammy because the kinds of organization drawn to something like Drupal (a powerful all-in-one monolith) are inevitably the same orgs who put everything into it and never want to care about maintaining or upgrading it afterward. They're in for a WORLD of hurt if they want to move to 8+... there's no upgrade path, it's just a rewrite.
As a CMS with web framework features, it’s also built on top of a model/controller-based framework, using Yii instead of Symfony. Craft has thinned their abstractions over time to more directly match Yii’s methods.
I've been away from Drupal for ~10 years, but I recently helped a friend spruce up a Drupal site he's working on and still found it's largely powered in production by heavy caching, and the page load speeds in development are a slog. I didn't know enough about how he built the site to know if that's still the case everywhere in Drupal or just his configuration, but my impression is still that it's absolutely not production ready without heavy caching in front of the site.
Whether you generate that HTML in Drupal, Wordpress, or some other system, having to run code to generate it is always going to be slower than caching. Drupal is plenty fast for internal previews (i.e. when the server is not overloaded), but at the end of the day it's still a PHP app, and LAMP/LEMP is generally harder to scale up and across vs plain files.
And for what it's worth, a Drupal site cached behind Acquia/Pantheon/etc and their CDN can -- usually will -- be faster than an uncached JS site served from any single data center.
You could, however, use Drupal (or any other CMS) to manage the relatively infrequently-changing parts of the website (static assets, the layout, introductory text, landing pages, much of the Javascript, etc.). And then use AJAX to dynamically fetch in the dynamic portions (the user content) from some other API.
I doubt that's the best approach though... probably there are better systems for something like that. Not my specialty though, sorry =/
------
edit: It's also very different if you're operating at reddit scale vs "small website with a few dozen comments a month" scale. If you're not expecting heavy, consistent real-time traffic, it'll probably be OK. Not as fast as it could be with better architecture, but fast enough that users will put up with it. Hell, we all did it for years with phpBB, the Drupal forums, etc.
- you host at one of the Drupal-optimized services (Amazee, Pantheon, Acquia)
- you put a Varnish service like Fastly in front of the site
- you use BigPipe to serve the dynamic content
- you have experienced Drupal engineers available for your project
If you’re missing one of those pieces, I’d recommend pretty strongly that you find a different platform.
Bigpipe looks like it chunks data from the server to the client, but it's not clear to me how that helps with real time updates to the database?
Varnish can help to a degree, but if you're on a big provider you're going through their Varnish setup anyway (among other caches) and it's not super configurable.
I’m not sure I read the OP the same way you did. If you read it as “can I build a site on the scale of Reddit or Twitter with Drupal” then no, don’t build Reddit or Twitter with Drupal. If you read it as “will Drupal serve a site with user generated content” then yes, it will, but if you’re planning to be a top 10 site on the internet, you’ll need a custom stack.
> if you’re planning to be a top 10 site on the internet, you’ll need a custom stack.
And yeah, that's what I thought the OP was hinting at (or at least hoping to become).
It'll handle small-medium scale forums just fine. Probably any stack would.
To be fair, that's the case with pretty much any CMS. Even if they start with a stock system, by the time they actually hit top 100/1000 (let alone 10) there's a lot of custom work to be done.
And realistically, a "top 100/1000 site" is almost always going to have a cloud of other sub-sites and related properties. The corporate site, intranet/HR, jobs and recruiting, press center... The penumbra of "Oh, yeah, we need one of those... but it would be ridiculous to build it from scratch" sites for a large organization can be pretty large indeed.
Eventually I was tasked with upgrading it to Drupal 8/9 (a new generation, with no backward compatibility with 7.x). It was basically a full rewrite. Well, I built a prototype in the new version, but it was still a convoluted mess -- slightly better, but nowhere near "modern". The whole thing is just way more complicated than it needs to be, and reminds me of 90s-style data management, and a web UI reminiscent of cheap wifi router dashboards: ugly, very slow (much of it wasn't ajax yet), and in general just total drudgery to work with.
After I built that prototype, I swore to myself, "This is the last time I'll ever use Drupal. Ugh." As a proof of concept, I also built that same prototype in several other CMSes: Wordpress with Advanced Custom Fields, Ghost, DatoCMS, Strapi, Contentful, GraphCMS (now Hygraph), Storyblok, Grav, etc. ALL of them were way more usable than Drupal, and each one took like 1/10th the time or less to make. It was especially fast with the headless CMSes + Next.js
Wordpress with ACF was probably the closest direct comparison, and that provided a much better editor experience, but still had poor DX (cuz you had to either work in Wordpress/PHP, or else shim ACF with other plugins to make it act headlessly).
It took me a few months to upsell the team, IT, and management to switch to a proper headless CMS instead, completely detaching the editor experience (managed by the CMS) and the DX (we were now free to develop the frontend however we wanted to, fetching content via GraphQL). It made everyone happier in the end, and it's much more maintainable.
Editors never have to care about forced upgrades, web technology changes, etc., anymore, and devs don't have to worry about accidentally breaking the editor experience while working. And a modern Jamstack (or anything else, really) is way way easier to work in than Drupal or Wordpress templates, especially since they don't share the same server as the database & editor and can be independently hosted, developed, tested, deployed, etc.
I still would never touch Drupal again. I've never used a technology I was so annoyed by (and that's coming from someone who grew up writing AT commands for their 14.4k modem, made websites in Perl, had to use Applescript to shim Filemaker into a web CMS... ugh.) Drupal is by far the most traumatic software I've ever had to use.
---------
Side note: Drupal itself aside, companies like Acquia and Pantheon do make the experience much nicer though. They basically manage hosting, forking, dev environments, backups, visual diffing etc. for you, like a bespoke cloud tailor-made for Drupal and Wordpress. I would definitely host at one of those companies (I prefer Pantheon, personally, but both are great compared to non-Drupal-specific hosting).
Turns out, absolutely yes! I guess there's a reason why headless and JS exploded. We migrated and never looked back.
It _is_ flexible for people wanting to be able to create types/taxonomies within the GUI, if you ignore the chaos behind the scenes. It also has good support for returning said content via JSON if you choose to do so, but if you're doing that, just define your own back-end and avoid the suffering.
Oh, no... I didn't "forget" as much as "permanently blocked it out of my memory to maintain some shred of sanity" :)
> It _is_ flexible for people wanting to be able to create types/taxonomies within the GUI, if you ignore the chaos behind the scenes. It also has good support for returning said content via JSON if you choose to do so, but if you're doing that, just define your own back-end and avoid the suffering.
Ultimately this is what convinced us to move to a headless CMS (which I hadn't heard of at the time, and I had to do some research and prototyping to understand it). But through our internal user (editor) studies, we learned that content organization, ease of editing (good WYSIWYGs), relationships, speed, and most of all UI clarity were really important. I built the same prototype in like 20 different CMSes, excluded the ones that didn't meet some baseline criteria, and had the editors and stakeholders try my demos for like 5-8 of the finalists, ranking each one by the ease of several tasks (rich text formatting, linking to related content, restoring a past revision, sharing a preview draft, etc.). Drupal was pretty much dead last in most of the categories (and this was the newer version, 9 I think). I had my own favorites but I let the editors decide, and the headless systems won by a large margin.
Any good CMS these days will have rich taxonomies -- that's arguably the defining characteristic of a proper CMS (as opposed to a blog engine, say). Where they differentiate is in the editor experience (ease of use, ease of drafts, ease of previews, ease of admin, ease of relationships, etc.) and/or the developer experience (response shapes, GraphQL mutability or not, API and SDK documentation and support). But for teams that have a mix of devs and editors, any of those would typically be better for both sides than a bespoke database.
For the editors, a vendor-supported (or polished open-source) CMS means a nicer editing experience than fighting with some tiny team's internal WYSIWYG field tied to a Postgres/MySQL field, with the corresponding bugs and quirks that's never prioritized by the (typically) backend developers and DB admins who care more about schema purity and such.
And for the developers, well, it frees them from having to worry about that and focus on the frontends, mobile apps, whatever, and also gives them the freedom to use whatever stack they want (be it Jamstack, .NET, HTMX, whatever). The content just come in as JSON and the rest is entirely up to them.
I feel like Drupal tries to occupy that space where it tries to do all of the above (and it CAN, to be fair), but it's not great (or even GOOD) at any of it. It's just a mishmash of sub-par experiences where nobody is happy, except maybe management (because they can worry about just one piece of software at one vendor like Acquia/Pantheon).
Even if your constraints are PHP and self-hosting/commodity virtual hosting, I think Wordpress + ACF is a way cleaner experience for the majority of sites...
* Contentful was by far the market leader. They were one of the first in the space, and probably the reason it got so big. Their UI was pretty decent, SDK and docs were good, support was good, good plugin ecosystem... but it was really expensive. When they started they were really affordable, but eventually I think they pivoted towards enterprise and wanted to wind down their more affordable plans. At the org I worked for, they wouldn't quote us an enterprise plan until we signed a NDA, and provided very limited developer sales/devrel time. My boss wasn't willing to continue with the sales process after that.
* DatoCMS was the most editor-friendly one, with a really nice UI, powerful field types, and a good admin interface with good roles & permissions & workflows that enabled complex user types to work in different parts of the CMS. Had a good plugin ecosystem, community support, and a small but really friendly and helpful team of staff. The sales process was great, with several of them sitting down with us to discuss all the details we needed. This was the editors' favorite in several ease-of-use categories. The primary concern there was that they're a relatively small Italian company instead of some huge American business (meaning potential time zone issues, etc.), but they'd been in business a few years already by that point and we were impressed by how supportive and welcoming they were.
* GraphCMS, now Hygraph, was what I considered the most technically powerful of the bunch. It had a really clean API, and was the only one (at least at the time) which allowed GraphQL mutations, meaning you could actually write to the GraphQL API. The others all needed REST APIs for updates, and provided GraphQL for reads. Its UI was pretty good, though a bit developer-centric compared to the others (like fields at the time didn't have editor-friendly labels, just their developer-facing names). The sales process was also great, and they were very accommodating of our questions.
* Prismic offered a really clean editor interface and stood out to me as the one that lets you jump right into editing the quickest. However, at the time, it didn't have some of the more advanced relationships / field types that we needed (don't recall the details, sorry). But I do remember it as "a CMS to revisit if I ever needed a simpler, cleaner one for a less complex schema" just cuz it felt so polished and easy.
* Wordpress with Advanced Custom Fields (a plugin), to my surprise, offered some of the most powerful AND easy to use schema, both in terms of the cleanliness of how it comes out in the API and in terms of how easy it was to compose/define in the editor and admin GUI. If data modeling were our chief concern, this would've been one of the top choice. ACF was really good, but we didn't want the baggage of Wordpress itself (i.e. having to host a LEMP & WP stack on Acquia or Pantheon just to run ACF headlessly; that'd be a waste of resources and dollars).
* There's a bunch of other commercial ones (Sanity, Storyblok, ButterCMS, Agility... see here for a list: https://jamstack.org/headless-cms/). In general they were all "good enough" and passed most of our criteria, but just didn't really stand out against our finalists. But that was just us, with our particular evaluation criteria and our specific individual editors' preferen...
I see what you did there ;)
Drupal is not a great piece of software to try to use out of the box as both a CMS and a website front-end. Drupal doesn't have the same kind of ecosystem as WordPress. Many of the best themes and modules are really there to assist your development of your own features, as opposed to being plug-and-play solutions.
"Recapitated"?
But then you're having to maintain the CMS, which isn't as appealing as using something like Contentful. It really depends on your use case (like all technologies, of course).
For editors, you have a slightly better default UX (Claro/Olivero), views builder, workflows, etc.
Then, of course, once adopted - like most CMS - it's very hard to migrate out, and it snowballs.
People largely went for Drupal over WP or Plone or Django because they had zero leverage about 1) what comes in to the content system, 2) how they can build a content system, and 3) what comes out of the system. Also, in the aughts, don't forget that WP was extremely primitive compared to today. Lots of enterprise leadership said, "oh, you can't have Python, that's for engineers" combined with "you have to read and write all articles to this arcane XML schema only parseable to five academics in France". Thus the Drupal extensions ecosystem ended up with a TON of low level plugins . . like Drush, which probably shouldn't have existed.
EDIT My God, Drush is still around.
Speaking more broadly, Drupal was also seen less as a "framework" and more of a straight "CMS", so the idea of a CMS needing a CLI was, then, a bit of a "Huh?". CMSs were regarded, at the time, as the thing you set up so the secretaries and executive assistants could update the website. Of course, in the decade and a half since then, we've seen how CMSs inevitably grow into pseudo-frameworks.
We also have a better grasp, today, on just how complicated the functionality of a CMS actually is, laying as it does across the intersection of natural and formal languages. A linguistics specialist could have predicted this, or even a dedicated data scientist, but the content world is shockingly bereft of linguistic specialists among its spec writers and practitioners. DITA - to abuse one single example - arose almost entirely from pedagogical academics, with no input from linguistics, computational or otherwise. And DITA is actually kinda-sorta planned. The various MIL-STD content specifications - 48 and counting, not including the bespoke USN things - don't arise from anything, they're just eternal flypaper for whatever contract items get thrown at them, plus golden gimmes from the blessed vendors.
The challenge, I think, is that by that point in time Drupal had gone through its first big popularity explosion, and was starting to grapple with the competing interests of many different audiences. Acquia ended up being instrumental in steering it towards "enterprise sites with complicated UGC requirements," but for quite some time the open source ideal of "the project reflects the priorities of the people who contribute time to it" meant it lacked a strong, opinionated take on many of the things you mention.
For many years Drupal's strength was (IMO) that enough of _those folks_ existed in the community to ensure you could build complex, highly adaptable structured content systems with it... and enough of _those other folks_ existed in the community to ensure that there were click-together content display and delivery tools that worked with the complex content. If you approached it with a clear understanding of where some of those boundaries were, you could build really amazing things — but if you came in looking for a well-paved path to build a simple site or architect a complex one, well... ¯\_(ツ)_/¯
edit -- clicked on your profile and read some of your posts in other threads, and I feel like I should just get a beer and commiserate with you about doomed CCS initiatives for a few hours. I salute you.
Drupal: Never again™
All that flexibility resulted in pages with 1k+ queries on them, and nasty upgrade paths. I hear D8 is Symfony-based now, and a lot got cleaned up, but after one project upgrading a Drupal app from one major version to another I won't touch it again. After a month's worth of work we refunded the client and canceled the job.
Last time I looked at Drupal (a few years ago) the majority of Drupal 7 modules had not yet been ported to v8 which had been released for some time at that point.
Wrote something called the "page module" that let them build out the various landing pages using extremely flexible criteria ... everything from tags to specofic articles to category - and probably more that I'm forgetting. I built specically because views just wasn't good enough. It was able to do a couple of very important things... It had what was essentially a materialized view that was maintained by the import scripts (All actual content editing was done in the propritary publishing software they used, then sent as XML to the web importer which ran constantly looking for new xml files in a directory).
The big upshot of this was that is that getting, saying, the articles for a given "page" (Which wasn't necessarily actually a page - there were also presentations like sidebar lists) was a SINGLE query with no joins. Very performant. We did millions of page views daily on one web server and one db server... both low end commodity boxes.
It was kinda fun, but when I left I made a promise to myself to never, ever, work with Drupal or PHP every again professionally, and I've been quite happy to stick to that.
I guess I wouldn’t say quite never on Drupal, but it would need to be like a 2x comp move to even consider.
As someone forced to use it and learn it for 2 years, I did what they asked me to, cleaned it up, and then convinced everyone to move away to a different system (detailed here: https://news.ycombinator.com/item?id=38489357).
We ended up with a system that was much much faster, much easier to edit, easier to maintain/develop, and thousands of dollars cheaper (compared to Acquia). It's the kind of thing that management would never have bothered to investigate without internal pressure (because, again, Drupal checked all the boxes). It's just an implementation detail that bigger businesses are happy to spend resources on, but it sucks for the day to day users.
It falls squarely in "never EVER again" territory for me too, like others here.
The onboarding experience is terrible, too. Compare Wordpress's editing landing page (https://wordpress.com/website-builder/) and editor documentation (https://wordpress.org/documentation/article/wordpress-block-...)
versus Drupal's content editing page (https://www.drupal.org/features/content-authoring), which says nothing at all and just points you to Drupal contractors and sponsors, or its documentation (https://www.drupal.org/docs/user_guide/en/index.html) which is super verbose but has no clear way of getting started.
The whole thing has that "made by developers, for developers" feel, and editors are a complete afterthought. Maybe that was the norm in the 90s and 2000s, but these days there are much more user-friendly, editor-forward options that give them a nice experience out of the box. Drupal never entered that era, and culturally it's still way more focused on the underlying technology than the end-user UX.
It's a CMS that serves admins & management first, developers second, viewers third, and editors last.
Drupal is a web CMS that empowers people without extensive coding experience to do some pretty amazing things. A front end developer at a small consulting company can build a useful experience pretty easily.
And if you are a developer you can extend it extensively.
It hit its peak before some of the extensibility features hit WordPress.
When it moved to being symfony based with Drupal 8 the shift was so great for this audience that Drupal hit its peak usage [1]. It's been in decline since then. Drupal 7 is still the mostly widely used single version and BackdropCMS came long to support that crowd (a Drupal 7 fork).
I look at this as an exercise in knowing your target audiences.
[1] https://www.drupal.org/project/usage/drupal
It caused much of the internal of Drupal to be re-written. This included how it was extended. With previous major versions you learned about new features and APIs. They followed mostly existing design patterns so it was easy to learn and updates your extensions for. With Symfony you had to learn whole new systems and ways of doing things. It was like learning something entirely new. And, porting extensions to it was far more work and time.
Also, the updates made Drupal slower while consuming far more system resources for the same thing. This increased costs to operate.
I still find Drupal very easy to work with - my biggest gripe with it was when they just quietly started changing to not downloading .tar.gz but to using composer. And just assuming everyone knew what composer was and how it worked. In the end the friction it was causing me made me learn how to use it.
Anyway my point of this rambling post is that as a USER of Drupal - it's great. I don't write any code, but I can shuffle my website around as I please very easily, adding widgets, changing what's exposed both in the UI and RSS etc.
I didn't quite realise how uncool it was to still use Drupal until I read all these comments! :)
PHp-Nuke when I installed it I couldn't believe. My own Slashdot!! With comments! It was amazing.
Big fan of e107 for my CS:S clan websites.
0 : https://e107.org
As a user, have you tried any similar CMS offerings at all? Either a totally WYSIWYG page builder like Wix/Squarespace, modern Wordpress with the block editor, a headless CMS, etc.?
Just wondering what your experience is... like is Drupal just "good enough" so you never wanted to switch, or did you investigate several options and choose Drupal because it's better in some way?
That being said, Drupal was initially a forum/blog and it definitely seems somewhat out of place in the modern web landscape. One of its Achilles Heels is that its rendering layer is notoriously slow and overall it's heavy. It's module system also doesn't mesh well with PHP's typical request/response execution model from a performance perspective (anyone who's spent time tuning PHP opcode caching for this knows what I mean).
That being said, the content type and field system is still great and it would be great to see a more generalized version of this concept. This is another area where the implementation is pretty heavy on the Drupal side. Things like this have ultimately limited adoption and not having a clear migration path from D7 to D8 didn't help either.
Luckily eventually I learned how to program properly, but I wonder if eventually the LLM's will make Drupal-esque solutions emerge once again?
Like a lot of other ppl it seems I left off when they switched to composer. That didn't fit too well into the workflow I had at the time using cheap web hosting services where I didn't get a shell as dev environments.
Also the upgrade treadmill was brutal. A few nice little web apps I made got totally left behind by security updates and such and were also too hard to upgrade to newer versions of Drupal. I remember that also being a major motivator to make the big jump to Python and other things. More code but also easier to manage over long periods of time.
Lots of good lessons in Drupal for other frameworks. I haven't tried it in a while, but it's still in my mind one of the best low-code custom fields, forms, and views systems out there.
I feel that the engineering behind Drupal has always been top-notch. I wrote a couple of Drupal plugins and themes, BitD (Back in the Day), but that was a long time ago. I'm sure that big changes have come, since then.
What I liked, was being able to completely customize both the frontend and the backend of a Drupal site. WP doesn't really give you much, in the way of making its backend much simpler.
During that time, WP has improved its engineering and architecture significantly, so it's still a tough call.
And because of the release cycles it's hard (or expensive) to keep a site running for 10+ years. In the end we opted for a plugin called "tome" that would just render the page as a static site and we'd just push the HTML files
Wordpress has always been a more product-focused blog/site-builder that works out of the box and simplifies code concepts for an average user who doesn't need to know much PHP to get everything they want to be done. It has always focused on open-source PHP CMS as a product.
Drupal has always been an engineer-first CMS; D8 doubled down on that: focus on long-term maintainability with OOP/Symphony/Composer/etc. That decision caused the casual site-builder who knew little PHP code to say "no thanks". It has always focused on open-source PHP CMS as a framework.
Backdrop happened for those who wanted a good off-ramp for those who were happy to keep the current Drupalisms of D7 and didn't need more PHP-web-dev tools. Unsurprisingly, it became more WP-like as it tilted more toward PHP CMS as a product.
The current community of the Drupal world has kept focusing on improving the UX of the site builder/maintainer role with its current initiatives (auto-updates, project browser) to self-correct.
Ultimately, Drupal focused more on its core strength. That's not a bad thing, that's just product differentiation. It turns out the average website doesn't need to maintain a lot of custom CMS code/workflow/logic they just need to track a handful of blobs of text/image content.
When I started out my career I basically was a one man web design agency, tailoring to small local businesses. When looking for a CMS I quickly found that Drupal allowed me the ease and flexibility to configure and customize websites for my customers. It was a perfect fit for me because I had enough skills to install and host sites, and to customize those things with code that I couldn't find a ready made module for.
Over time Drupal changed a lot, and my skills grew. My focus shifted more and more to the technical side. As Drupal became more professional, so did I, and with it, the customers became a lot bigger too.
I started to manage a team of developers, and then multiple. Finally I made a move to a big Corp in which Drupal was not used. I like the people that I work with a lot, all extremely capable and talented people. But I feel we're constantly reinventing the wheel. Things that I feel have long been solved in Drupal are somewhat half-assed due to the chosen tech stack and the time constraints. Drupal may not be perfect, but it did have an evolution of more than 20 years, and that shows. A very strong entity system, fields, taxonomy, user management, roles/permissions, i18n, asset handling (media), slugs, redirects, breadcrumbs, workflows, revisions, and perhaps the cherry on top: JsonApi (a porcelain if you ask me). A strong community and reasonable documentation means that it's possible to switch vendors, as everybody works with the same API's (mileage may vary a bit).
The situation now with where I'm at couldn't be further from that. Everything JavaScript and microservices based, build on a (imho) dreadful SaaS 'CMS' (Contentful). The so called 'enterprise' CMS is severely lacking, it's a usability a nightmare, I can't stress how bad it is. It's basically a glorified database, which means that everything else needed is being built completely from scratch. That simply doesn't compete with the 20+ years of evolution Drupal has had.
So yeah, I miss Drupal.
That was probably also its downfall. It had a huge learning curve (same as Angular's downfall). And it didn't make for easy division of labor, and there was no quick and dirty way to do anything. The reason why there are so many Drupal consultants is because it takes so much manpower and brainspace to understand how Drupal is architected. With a headless CMS, the schema admin, the content editors, and frontend devs could each do their jobs independently without stepping on everyone else's toes. It's not as complete as a majestic monolith but each person's job was a lot easier, and way more isolated and safe.
Drupal tried to be everything for everyone, and in the end it was just too much for any one normal person. It's what happens when engineers design products for people who aren't like them.
Drupal 8, 9, 10 and beyond is quite different than what came before it.