11–20 of 50 posts
A Headless CMS is a GUI that simply lets nontechnical people manage content in a database (as opposed to traditional WordPress, which included front-end templating logic). These aren't super new but they are good. They're extra good in a world where you're increasingly likely to have multiple front-ends for a single application.
Keep in mind that many FOSS CMS's can also do headless. Drupal has very robust JSON:API support (as well as GraphQL through a contrib module), and WP has its own Rest API. Drupal also has a distribution specifically geared toward headless/decoupled: https://www.contentacms.org
What this article is really saying is that the web CMS is going away, leaving content CMS's with web API's as the king. What you're saying is that Web CMS's are morphing into content CMS's.
Which is great, but I don't really see the point of the article. None of this is really new.
Earlier quoted context omitted.
My immediate reaction as well. Headless CMS seems like a good idea, but I would not want to outsource the core of my own business if I were in the content biz. And honestly, if it were that advantageous, there’s no good reason there can’t or shouldn’t be open source headless CMSes just as there were headful open source CMSes...
Strapi[0], Cockpit[1], Directus[2], Ghost[3]. Just to name a few open source headless CMSs. There are a lot more where they come from. And you can always add a JSON or Graphql module to your wordpress, drupal, etc. [0] https://strapi.io/ [1] https://getcockpit.com/ [2] https://directus.io/ [3] https://ghost.org/
> And you can always add a JSON or Graphql module to your wordpress, drupal, etc.
That’s a great point, especially for migrating. I’ve worked where we had a huge nearly unmaintainable Drupal instance and it could’ve probably saved us a lot of time to just jam a GraphQL API on-top instead of trying to synchronize everything to another separate database. (Many lessons learned from that experience.)
My biggest gripe with most CMSes is how they handle organization (tags, categories, hierarchies...) as it always seems to come off as too flexible in some ways and not enough in others. Oh, and scaling, but at least you can always cache everything.
Cutting through the deluge of marketing-speak: A Headless CMS is a GUI that simply lets nontechnical people manage content in a database (as opposed to traditional WordPress, which included front-end templating logic). These aren't super new but they are good. They're extra good in a world where you're increasingly likely to have multiple front-ends for a single application.
I can't help but to think back on my experiences, that's going to make a terrible program.
What a poor quality article, it doesn't have any explanation what a headless CMS is.
Cutting through the deluge of marketing-speak: A Headless CMS is a GUI that simply lets nontechnical people manage content in a database (as opposed to traditional WordPress, which included front-end templating logic). These aren't super new but they are good. They're extra good in a world where you're increasingly likely to have multiple front-ends for a single application.
The goal is to use less skilled labor? I can't help but to think back on my experiences, that's going to make a terrible program.
Edit: The original version of my comment which this poster was replying to, said something along the lines of "a GUI that lets nontechnical people manage a database", which was ambiguous.
Earlier quoted context omitted.
Strapi[0], Cockpit[1], Directus[2], Ghost[3]. Just to name a few open source headless CMSs. There are a lot more where they come from. And you can always add a JSON or Graphql module to your wordpress, drupal, etc. [0] https://strapi.io/ [1] https://getcockpit.com/ [2] https://directus.io/ [3] https://ghost.org/
I used Ghost as a non-headless CMS and had no idea it could be used as headless. Neat! > And you can always add a JSON or Graphql module to your wordpress, drupal, etc. That’s a great point, especially for migrating. I’ve worked where we had a huge nearly unmaintainable Drupal instance and it could’ve probably saved us a lot of time to just jam a GraphQL API on-top instead of trying to synchronize everything to anoth…
A part as the usual CMS, but also to drive a portion of a mobile app, and in that case its using essentially the headless part.
Since you have used it, any caveats I should be aware?
Thanks.
What a poor quality article, it doesn't have any explanation what a headless CMS is.
Cutting through the deluge of marketing-speak: A Headless CMS is a GUI that simply lets nontechnical people manage content in a database (as opposed to traditional WordPress, which included front-end templating logic). These aren't super new but they are good. They're extra good in a world where you're increasingly likely to have multiple front-ends for a single application.
But I’m weird like that. :)