3 ms·

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

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

jh3 3y ago
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 :)
- solardev 3y ago
  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.
vgeek 3y ago
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.
- solardev 3y ago
  > 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...

jh3 3y ago

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 :)

solardev 3y ago
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.

vgeek 3y ago

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.

solardev 3y ago
> 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...