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