The Biggest CMS Headaches That Exist Today

[RATIU5]

Why do we still struggle with CMS solutions in 2024/25?

I'm asking the general public about their biggest pain points when setting up and/or using a CMS for their projects. Let me start by sharing my own frustrations after working with various CMS solutions over the past few years:

Setup complexity has been my biggest hurdle. Last time I used it, I spent hours trying to get Sanity's server and client running properly. While I appreciate GROQ's power, learning an entirely new query language feels excessive for what should be straightforward content management. And with Strapi, I've found myself wishing I could just edit schemas directly in my code instead of always needing a development server running.

Environment management is another pain point I've hit repeatedly. Switching between production and development datasets is more complicated than it should be - you either need to spin up a separate database instance or pay extra for the privilege of having a development environment.

The preview experience has been consistently frustrating. When building web projects, I often know I need components like a hero section for example, but there's no easy way to preview different variants before implementing them. A simple component gallery with live previews would save me and my clients so much time!

Documentation has been hit or miss in my experience. I've found Sanity's docs scattered across different places, while Payload's documentation sometimes lacks the depth needed for more complex implementations. It seems like most CMS docs do well at basic tutorials but fall short when you need to leverage more powerful features.

The technology lock-in is particularly frustrating. I want to choose my tech stack first and then find a CMS that fits, not the other way around. For instance, I love using Astro, but finding a CMS that integrates smoothly with it has been a real challenge.

Working on a Solution

These experiences have motivated me to start developing Luxe, aiming to address these common pain points. While it's still in early development and not ready for production use, I'm focused on building a clear roadmap that tackles these issues head-on. You can check out the current plans and details in the project's README.

How has your experience been like? As a developer, above are the issues I've encountered, but I'm really interested in hearing from both developers and content creators. What challenges have you faced?

And hey, let's hear some positive stories too, if you've had good experiences with any CMS solutions, I'd love to know what worked well for you!

[MelihDarcanxyz]

Hi, wanted to give a feedback about what I live with Payload CMS. It's great, like really great. I like having both Globals and Collections, I love being able to declare fields and reuse them, I love hooks, I love access control (read, create, edit permissions), I love PostgreSQL, I love it being truly free and open source for self hosting options.

But,

• It's hard to integrate with Astro, because it's opinionated towards NextJS. You can't really mix them together in the same project. Rather, you have to keep them in different folders. There are two direct results of this. I can't use collection types created by Payload in Astro. And it's harder and slower to get the data from Payload to Astro.
• Things get blurred when it comes to Rich Text Editor feature of Payload. I like to define my components in Astro. But in Payload, you have to define "Blocks" to use in Rich Text Editor which are React components. I wish there was an Astro way of using components in Payload RTE. In result, you have less control about how that rich text is converted to HTML or Markdown. Maybe all I need is user friendly WYSIWYG .md(x) editor in Payload, using Astro components. Because, in its current form it tries to handle some stuff that is already handled by Astro.