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

Turns out, absolutely yes! I guess there's a reason why headless and JS exploded. We migrated and never looked back.

* 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' preferences. Before the eval, I built a prototype in many/most of these systems. I'd really encourage that! It really doesn't take long (it's so much faster and easier than in Drupal) and gives you a much better picture of what it's like to use each one, both as an editor and as a dev. Just define some good-enough schema (something like Northwind Traders, or even simpler https://en.wikiversity.org/wiki/Database_Examples/Northwind) and some basic frontend, then try to implement that schema in each service, fetch its data, and also try to programatically add/edit a record. I had a lot of fun doing that for about 20 different providers in the span of a week or so, and learned a lot along the way.

* There are also a few open-source/self-hostable ones if the cloud isn't your jam: the ones I remember were Strapi, Directus, and Ghost. There are probably more these days.

I see what you did there ;)