3 ms·

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,

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