[gijsnijholt1980]

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.

[mfer]

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.

[1] https://www.drupal.org/project/usage/drupal

[mvdtnz]

What is symfony, and why did it cause people to drop the platform?

[mfer]

Symfony is a PHP framework. https://symfony.com/

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.

[mvdtnz]

Wow, that's a very major change and a big expectation for Drupal admins.

[ksenzee]

It wasn’t the admins who had to make the change; it was the developers. But yeah, it was a major, major change.

[ceejayoz]

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.

[TylerE]

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.

[ceejayoz]

PHP's still my bread-and-butter via Laravel. Drupal's on my won't-touch list alongside Joomla and Magento.

[TylerE]

Hah, yes. The job before that one involved some Magento. I bailed after 6 months again.

I guess I wouldn’t say quite never on Drupal, but it would need to be like a 2x comp move to even consider.

[SoftTalker]

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.

[MilStdJunkie]

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.

EDIT My God, Drush is still around.

[cholmon]

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.

[ksenzee]

I’m pretty curious why you think Drupal shouldn’t have a command-line interface.

[MilStdJunkie]

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.

[eaton]

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.

[solardev]

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.

[ksenzee]

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.

[eaton]

I see you, and feel seen

[dpedu]

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.

[solardev]

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 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.

[pmarreck]

Had the same experience to a T. Left it with a sense of "never again"

[solardev]

That should be their official motto, IMO.

Drupal: Never again™