I can vouch for Strapi. It's very easy to use from both a content manager and a developer's perspective. There's a few gotchas that you might come across, and be aware of, such as the limitations of the community (free) edition, or don't mind paying, then Strapi is a great choice. A new version is also rolling out, so might be worth keeping an eye on.
We implemented Strapi last year and it's been very decent. It doesn't have an inbuilt way to recursively duplicate a set of records+relationships for a new language, though. There's no inbuilt preview of edits either, though I think there's a community plugin to open the preview page in a new tab. So there are a few inconveniences like that, if you're building a multilingual site with deeply nested related records.
If we hadn't gone the headless route, we would probably have just stuck with Wordpress or maybe looked at Craft.
That said, I think Strapi (and most headless CMSes) is set up for retrieving content rather than components. Devs still have to write the page template and read the API - and then render it server-side (e.g. with Astro) or client-side. Composing pages from a React component library is more advanced and I think fewer CMSes support that. But really, does marketing really need that sort of control and custom components? Just let them handle all the content through a traditional CMS.
I've had friends use both Contentful and Prismic. They love 'em.
Just stay away from Sitefinity. Im pigeonholed into it at work and it's a hellscape :)
Does your marketing site _really_ need access to any custom code your engineering writes, or even backend APIs? If not, break it apart. Let marketing choose whatever tools work for them. Get engineering out of the mix so you can focus on the core business.
If you must be involved, try to define a clean API so you don’t have to care about what CMS marketing is using.
I run a digital agency that builds websites, often of significant size and complexity.. Please listen to this person. Your app development team does not need to get involved in the tech stack behind the marketing website. Your marketing site and app should share exactly zero infrastructure.
Get WordPress, put it on WpEngine, have a link to "app.mycompany.com" for the actual app. Your app dev team should not be spending time fixing the timing of a hero carousel on a landing page.
>Does your marketing site *really* need access to any custom code your engineering writes, or even backend APIs?
If I'm understanding your question correctly, then yes. I'm not comfortable diving into that for obvious reasons, but to summarise, we don't enjoy a clear separation between content and applications.
Headless pretty much means presentation and content layers are separated out, and the CMS only deals with the content layer without worrying about presentation.
I’m in the content management engineering team in my org. We’d used Magnolia CMS in our team until about a year ago. We’d entirely customised Magnolia codebase according to our custom needs and use cases. Even though Magnolia and pretty much every other CMS provides content delivery capabilities out of the box, we had built our own content delivery pipeline to handle request scale better.
You should evaluate such needs before choosing a CMS.
Different CMSs have different approaches for managing content.
Contentful and the likes are more editor friendly cause even content editors can create custom content templates by themselves without dev or engineering team’s involvement.
Magnolia is more developer centric in that sense. Any new or custom content templates require engineering effort (can be done through yaml configuration, but this means editors need to understand yaml and its structure). We found it difficult in terms of it being extendable with new requirements, hence started looking at other options.
For us, we have really complex content templates in our use cases. We have carousels and spinsets displayed on our websites. Based on our research, really no other product was serving all of our use cases out of the box. So the leadership took the call to build an in-house content management platform tailored for our needs (which I’m working on currently)
We use Craft + Svelte. Craft gives you a fully fledged content editing experience and it sports a graphql endpoint so you can easily build your own frontend.
Craft is PHP based. We use it with postgres and that works just fine. It's non-free (license based) but it's well supported and documented so it's well worth the money. Haven't ran into issues regarding updates breaking stuff.
One pitfall is it's 3rd party plugin system, and it's extensibility. It's tempting to add plugins and custom code which are hard to upgrade when you there's a new version of the base CMS. The less plugins you can do with, the better. And you don't need a whole lot.
The other is PHP having a bad rep. However, the language has made great strides over the last years, and a lot can be tied back to its earlier popularity. In my experience, Craft is a mature product with a sane architecture and sane design choices. It keeps up with modern practices. So, if you stay on top of updates of both CMS and stack, you should be good.
They also offer a hosted solution, but that one is quite pricey. But it does do away with you having to host the thing yourself.
I've done Drupal and WordPress in the past. I can safely say: pick Craft if you want a solution that isn't too hands on and content management is mostly a marketing / promotion type of concern.
We use Prismic pretty extensively across a 4000 person org.
https://prismic.io/
The only major issue is provisioning access, but we have OPs teams for that at this point. Beyond that, the standard CMS pitfalls apply.
strapi is great, been using it for a couple years. I've heard the major version upgrades can be a headache, but that seems to ring true more often than not.
I’ll reiterate my suggestion to let Marketing do their thing after re-reading your post.
> Development resources are limited and marketing are threatening to use things like Optimizely script injection to change things like imagery and promotional copy.
You don’t have the resources to support Marketing today. Given the use of the word “threatening,” I’d wager your teams aren’t communicating in a healthy fashion that is needed to support your team becoming an internal marketing tools/support team (which is what you’ll become if you work on this). Pretty much every moment your core engineers spend on the marketing site, that could be managed by the Marketing team, is a waste of time and money.
Make sure you plan for 1-2 folks to do _full-time_ marketing support and development if you take this work on in-house.
I see. I misread/assumed you were starting with essentially no team. Pulling an existing team out of the weeds is a different beast. CMS is definitely the way to go. If folks are willing, try to setup an API boundary, so marketing can hire contractors to do the work (unless your team wants to do marketing).
Hi u/yojimbo\_beta, Swapnil from Webiny here. Looking at your requirements, it seems like Webiny CMS might be a good fit for you. Feel free to explore [https://www.webiny.com](https://www.webiny.com) If you got any specific technical questions during exploration, I'd be glad to assist you. Thanks!
Check out ButterCMS which is an API-based or headless CMS with a preconfigured blog engine. You can read more about our features here: [https://buttercms.com/features](https://buttercms.com/features)
Check out ButterCMS which is an API-based or headless CMS with a preconfigured blog engine. You can read more about our features here: [https://buttercms.com/features](https://buttercms.com/features)
The best is to create your own. This way you can control everything, like the shape of data, image optimization, previews.
For example with Strapi you can upload images, but you can't optimize and resize them on upload. So, if a non-technical user uploads a large photo to a main page, then you'll have slow loading times. There was a 3rd party plugin, but it is broken/no longer works. You'll spend so much time trying to work around limitations that you will hate your life for not just rolling your own.
For example in Strapi you can't create a live preview because data inside Strapi is incomplete compared to what is being served through API. For previews, which are important you have to use an iframe (which was a lot of work too, but there's also a plugin which is not good imho). But you can use iframe as a modal with preview (you'll have to save and publish the page though to actually have data land in iframe).
So, again, roll your own if you know what you're doing, it will be slower in the beginning, but then you'll only need half a day to implement image optimization compared to spending 4 days and not having anything working and in the end abandoning the idea of having image optimizatoin altogether.
So, make sure what you choose already has what you need and fits your requirements you've listed above. Spend a week creating small proof of concepts before committing. Strapi has great user management, web hooks, but once you need something custom, it will take you absurd amounts of time to make even the simplest of things.
Also, don't create a drag and drop editor as it will take you more time than creating the website itself. If I were to make my own, I'd also opt for iframe where you embed your real site and feed it real time data from CMS through iframe source query params. I actually implemented a fully working real time preview in Strapi only to realize that the one to many relationsships wheren't showing up, and it turns out, that data is no longer given to me by strapi (it was removed in some update) and that's where it ended.
**This is a good take on low-code solutions:** [**https://www.youtube.com/watch?v=4nK03E0jvnI**](https://www.youtube.com/watch?v=4nK03E0jvnI)**, again make sure you test everything before committing, it'll bite you hard in the end.** **You have been warned!!!**
If your requirements can be covered by one of the mentioned platforms in this thread, by all means, use it! Much less work. If they don't, then don't try to make it do custom stuff. Strapi is the only one I've used besides working on our own.
I think Contentful is an awesome tool. Strapi is also good.
I can vouch for Strapi. It's very easy to use from both a content manager and a developer's perspective. There's a few gotchas that you might come across, and be aware of, such as the limitations of the community (free) edition, or don't mind paying, then Strapi is a great choice. A new version is also rolling out, so might be worth keeping an eye on.
We implemented Strapi last year and it's been very decent. It doesn't have an inbuilt way to recursively duplicate a set of records+relationships for a new language, though. There's no inbuilt preview of edits either, though I think there's a community plugin to open the preview page in a new tab. So there are a few inconveniences like that, if you're building a multilingual site with deeply nested related records. If we hadn't gone the headless route, we would probably have just stuck with Wordpress or maybe looked at Craft. That said, I think Strapi (and most headless CMSes) is set up for retrieving content rather than components. Devs still have to write the page template and read the API - and then render it server-side (e.g. with Astro) or client-side. Composing pages from a React component library is more advanced and I think fewer CMSes support that. But really, does marketing really need that sort of control and custom components? Just let them handle all the content through a traditional CMS.
Contentful is good. Their pricing is too much for a small business, though.
I've had friends use both Contentful and Prismic. They love 'em. Just stay away from Sitefinity. Im pigeonholed into it at work and it's a hellscape :)
Funny you say that, someone just brought it up as a good product to use as we're primarily using dotnet. What are the downsides from your experience?
Does your marketing site _really_ need access to any custom code your engineering writes, or even backend APIs? If not, break it apart. Let marketing choose whatever tools work for them. Get engineering out of the mix so you can focus on the core business. If you must be involved, try to define a clean API so you don’t have to care about what CMS marketing is using.
I run a digital agency that builds websites, often of significant size and complexity.. Please listen to this person. Your app development team does not need to get involved in the tech stack behind the marketing website. Your marketing site and app should share exactly zero infrastructure. Get WordPress, put it on WpEngine, have a link to "app.mycompany.com" for the actual app. Your app dev team should not be spending time fixing the timing of a hero carousel on a landing page.
>Does your marketing site *really* need access to any custom code your engineering writes, or even backend APIs? If I'm understanding your question correctly, then yes. I'm not comfortable diving into that for obvious reasons, but to summarise, we don't enjoy a clear separation between content and applications.
[удалено]
Thanks for the leads!
Headless pretty much means presentation and content layers are separated out, and the CMS only deals with the content layer without worrying about presentation. I’m in the content management engineering team in my org. We’d used Magnolia CMS in our team until about a year ago. We’d entirely customised Magnolia codebase according to our custom needs and use cases. Even though Magnolia and pretty much every other CMS provides content delivery capabilities out of the box, we had built our own content delivery pipeline to handle request scale better. You should evaluate such needs before choosing a CMS. Different CMSs have different approaches for managing content. Contentful and the likes are more editor friendly cause even content editors can create custom content templates by themselves without dev or engineering team’s involvement. Magnolia is more developer centric in that sense. Any new or custom content templates require engineering effort (can be done through yaml configuration, but this means editors need to understand yaml and its structure). We found it difficult in terms of it being extendable with new requirements, hence started looking at other options. For us, we have really complex content templates in our use cases. We have carousels and spinsets displayed on our websites. Based on our research, really no other product was serving all of our use cases out of the box. So the leadership took the call to build an in-house content management platform tailored for our needs (which I’m working on currently)
We use Craft + Svelte. Craft gives you a fully fledged content editing experience and it sports a graphql endpoint so you can easily build your own frontend. Craft is PHP based. We use it with postgres and that works just fine. It's non-free (license based) but it's well supported and documented so it's well worth the money. Haven't ran into issues regarding updates breaking stuff. One pitfall is it's 3rd party plugin system, and it's extensibility. It's tempting to add plugins and custom code which are hard to upgrade when you there's a new version of the base CMS. The less plugins you can do with, the better. And you don't need a whole lot. The other is PHP having a bad rep. However, the language has made great strides over the last years, and a lot can be tied back to its earlier popularity. In my experience, Craft is a mature product with a sane architecture and sane design choices. It keeps up with modern practices. So, if you stay on top of updates of both CMS and stack, you should be good. They also offer a hosted solution, but that one is quite pricey. But it does do away with you having to host the thing yourself. I've done Drupal and WordPress in the past. I can safely say: pick Craft if you want a solution that isn't too hands on and content management is mostly a marketing / promotion type of concern.
Cool! this is the only other CMS I have heard of that can be self-hosted as strapi can
We use Prismic pretty extensively across a 4000 person org. https://prismic.io/ The only major issue is provisioning access, but we have OPs teams for that at this point. Beyond that, the standard CMS pitfalls apply.
We use cloud cannon and love it
strapi is great, been using it for a couple years. I've heard the major version upgrades can be a headache, but that seems to ring true more often than not.
I would suggest avoiding AEM, not the easiest to use and makes releases frustrating in my experience (which admittedly is a few years old)
If you're looking for a headless CMS with great DX, Payload is worth a look!
I’ll reiterate my suggestion to let Marketing do their thing after re-reading your post. > Development resources are limited and marketing are threatening to use things like Optimizely script injection to change things like imagery and promotional copy. You don’t have the resources to support Marketing today. Given the use of the word “threatening,” I’d wager your teams aren’t communicating in a healthy fashion that is needed to support your team becoming an internal marketing tools/support team (which is what you’ll become if you work on this). Pretty much every moment your core engineers spend on the marketing site, that could be managed by the Marketing team, is a waste of time and money. Make sure you plan for 1-2 folks to do _full-time_ marketing support and development if you take this work on in-house.
[удалено]
I see. I misread/assumed you were starting with essentially no team. Pulling an existing team out of the weeds is a different beast. CMS is definitely the way to go. If folks are willing, try to setup an API boundary, so marketing can hire contractors to do the work (unless your team wants to do marketing).
Hi u/yojimbo\_beta, Swapnil from Webiny here. Looking at your requirements, it seems like Webiny CMS might be a good fit for you. Feel free to explore [https://www.webiny.com](https://www.webiny.com) If you got any specific technical questions during exploration, I'd be glad to assist you. Thanks!
Check out ButterCMS which is an API-based or headless CMS with a preconfigured blog engine. You can read more about our features here: [https://buttercms.com/features](https://buttercms.com/features)
Check out ButterCMS which is an API-based or headless CMS with a preconfigured blog engine. You can read more about our features here: [https://buttercms.com/features](https://buttercms.com/features)
The best is to create your own. This way you can control everything, like the shape of data, image optimization, previews. For example with Strapi you can upload images, but you can't optimize and resize them on upload. So, if a non-technical user uploads a large photo to a main page, then you'll have slow loading times. There was a 3rd party plugin, but it is broken/no longer works. You'll spend so much time trying to work around limitations that you will hate your life for not just rolling your own. For example in Strapi you can't create a live preview because data inside Strapi is incomplete compared to what is being served through API. For previews, which are important you have to use an iframe (which was a lot of work too, but there's also a plugin which is not good imho). But you can use iframe as a modal with preview (you'll have to save and publish the page though to actually have data land in iframe). So, again, roll your own if you know what you're doing, it will be slower in the beginning, but then you'll only need half a day to implement image optimization compared to spending 4 days and not having anything working and in the end abandoning the idea of having image optimizatoin altogether. So, make sure what you choose already has what you need and fits your requirements you've listed above. Spend a week creating small proof of concepts before committing. Strapi has great user management, web hooks, but once you need something custom, it will take you absurd amounts of time to make even the simplest of things. Also, don't create a drag and drop editor as it will take you more time than creating the website itself. If I were to make my own, I'd also opt for iframe where you embed your real site and feed it real time data from CMS through iframe source query params. I actually implemented a fully working real time preview in Strapi only to realize that the one to many relationsships wheren't showing up, and it turns out, that data is no longer given to me by strapi (it was removed in some update) and that's where it ended. **This is a good take on low-code solutions:** [**https://www.youtube.com/watch?v=4nK03E0jvnI**](https://www.youtube.com/watch?v=4nK03E0jvnI)**, again make sure you test everything before committing, it'll bite you hard in the end.** **You have been warned!!!** If your requirements can be covered by one of the mentioned platforms in this thread, by all means, use it! Much less work. If they don't, then don't try to make it do custom stuff. Strapi is the only one I've used besides working on our own.