I've been using Payload for 18 months. They're only recently (with the upcoming v3 release) really piggy-backing on Next.js' server and routing. Before that, it was "just" a really nice headless CMS built on Node/TypeScript.
This was obviously posted in the wake of the WordPress drama, but I landed on Payload while feeling stagnant after 10+ years building on WordPress. Everything else I was doing was 100% TypeScript, my entire professional career had been working with metadata driven data structure, I felt right at home with Payload.
It's just enough structure (full admin area, API, GraphQL) to make scaffolding a basic site (with authentication) quite easy. I had built an app using Next 13 before Payload began integrating directly and using the local API (versus making HTTP calls to a server endpoint) is very clean. It feels like WordPress (i.e. you're editing "client" code on the "server") but with a LOT less cruft.
Because it's headless, anything goes on the front end. One big reason that WP got so big was because of the theming capabilities. Payload has extensibility by way of plugins, but it's (obviously...) not as robust as what's available in the WP plugin repo. It'll be interesting to see how these alternatives fare against the more prescriptive tools like Ghost (which does support theming, but does not support custom fields in any way, shape, or form).
That being said, I'm all in on Payload moving forward. If you're curious, go straight to the v3 beta -- it's very close to release and plenty stable, in my opinion. Happy to answer questions.
(Not affiliated with Payload, just a big admirer of their work)
How easy/hard would you consider the amount of work needed to create a ecommerce for digital products using Payload? I'm currently using WP + Woo but the plugins that I'm using aren't flexible enough and I'm re-inventing some of them, so might as well re-invent some more and learn Next.
The pitch alone on PayloadCMS shows that this is still a developer-focused CMS. Just look at the difference between the github page, the Payload website, and wordpress.org's landing. This is not purely a marketing difference but a strategic conversation.
I'm all about transitioning CMSes and yet WordPress has got the turnkey part of their open-source platform clear and easy to understand. You can self-host or choose a provider. Payload doesn't make that clear, it's either too dev-centric for running or wants you to "Schedule a Demo" (which is a way to capture enterprise dollars).
What about more consumer-friendly pitches and deployments? Any recommendations on that?
I worry about the criticisms I see about Payload not marketing to marketers and site builders, because as a dev I’m a huge fan and would love to see it thrive.
It’s a fair point, especially given that in so many cases the marketers are the ones procuring the CMS. And people who don’t code at all are a big portion of WP’s market.
My main concern is I’m not sure it’s easy for non-devs to see how much of the PHPish ecosystems are filling gaps in the CMS core. I don’t know how many previous CMSes the Payload folks had used before going about building it, but I’ve built tons of features and templates on most of the big ones, and IMO they did a phenomenal job of boiling it down to exactly what a developer needs to build any feature any customer or employer could ever want.
There’s no need for, say, a heavy SEO plugin. You can just define the fields you want your people to fill out and attach those fields to whatever content types you’d like. Then use those fields in the head when presenting the content out front in whatever frontend you want to use.
On top of that, you have all of the JS ecosystem you can plug right in. Dataviz for custom dashboards, data crunching, video and image processing, all of it. And because you’re not starting with a huge, opinionated plugin/module/contrib, it’s not the clunky and unfun when you need a feature that wasn’t there before. It’s so much easier to build exactly what you need if you’re comfortable with code.
SO much of a serious CMS is just content CRUD, and Payload makes it so simple to define your content types in code, where they objectively should be defined for the sake disaster recovery and reliable builds across all environments.
You can deploy Payload anywhere you can deploy any Nextjs app, and as of v3, you'll be able to deploy it to serverless environments too like Vercel and Netlify. We'll work on adding more deployment guides directly into our docs for various platforms as well to help with this.
Again, we read everyone's feedback about Payload itself and our website so it's very much appreciated and we'll be addressing this gap in how we present ourselves!
edit: I may have misunderstood your initial point, oops
Yeah we're not consumer facing in the way Wordpress is. It's quite a huge gap to fill
If Payload is a framework or not is debatable. I think it's more like a data layer around a database for a any js app and an Admin Panel (that uses Next.js now). It might be called a framework for your own Headless CMS, because it is code first. So you basically code the panel and the data structure yourself.
"Framework" isn't really the best term for them to actually use to describe Payload. Its basically a tool for NextJS developers to quickly build a custom CMS. I'd think of it more like CMS-in-code than a framework.
PayloadCMS is looking really nice for us. However, for us a as a small non-profit organization with ~100 people having access to our systems the missing SSO feature (enterprise only) is really a blocker.
I understand what the idea is to make SSO an enterprise feature but I really think this hurts security for small and medium sized organizations as well (not only with this project, as this is a common pattern in my experience).
Hey there - small to medium orgs can use one of the available community, open source SSO plugins, with the only caveat that they are not officially supported by Payload. Or you could build your own!
Question - does the word "enterprise" make you think that the amount we charge would make it unfeasible for your org to pay to use Payload?
I don't think it's ideal that we hide all our "premium" features behind the word "enterprise" and have been thinking of alternative words / messaging to describe that.
In june evaluated PayloadCMS (v3 beta), Strapi and Sanity for powering an app with (30+ content types) and a website.
In the end i chose PayloadCMS.
- I can programatically define content types in typescript
- selfhosting
- localization support.
Sanity:
_Pros_: great DX, easy to start
_Cons_: i was afraid of exploding bills, it felt a bit slow/sluggish
STRAPI:
_Pros_: open source, selfhostable, managed solution available,
_Cons_: too much clicking in the UX, and having to write middleware to get related data.
I tried to switch to this from keystonejs. Keystone’s documentation is painfully inconsistent with its library. I have lost entire days over it. but “it works.”
Was expecting more with payload but seems to be another buggy experience but with better UI.
Eagerly waiting for a player in this space that isn’t just developer-first but also developer-friendly.
Hey! I'm CEO of Payload and want to make sure we resolve any bugs you found. Pretty much the whole team is focused on closing issues right now as we work toward 3.0 stable so depending on when you were trying out Payload, I'd imagine you might see lots of the bugs you faced as already resolved.
Keystone would be my other vote though, if I were looking for a CMS and Payload didn't exist. I think that is a solid crew.
Not flexible enough, performance problems, doesn't provide much ootb.
You're better off just writing a service from scratch, the time you are saving is minimal (this applies to most products before we get to django or wordpress imho)
Performance problems are usually something related to maybe missing indexes in your database for fields that you query on often, or similar. Payload itself is super thin. Can you give me an example of where you're seeing slowdowns? Maybe I can point you in the right direction.
Also I would love to hear about where Payload is not flexible enough. Extensibility is one of our priorities so if there is something you'd like to accomplish, but can't, I will see what I can do about it!
We are using this at work. Generally I'm pretty happy with the configuration driven approach. You have config objects for all your collections where you define the types of the fields and everything else happens automatically.
With this comes a few gotchas. It's easy for an unassuming developer to change the name of a field (e.g., upper to lower case) and suddenly all data is gone in production since this affects the database. What you should do instead is write a migration.
I'm also not a fan of Lexical. It's very focused on being a good rich text editor but not on being a good document format for your clients. For example the way they render lists is, in my opinion, simply wrong (see https://github.com/facebook/lexical/issues/2951). Or this https://github.com/facebook/lexical/issues/6269. You also have the added complication of using the Payload flavor of Lexical, which can add its own complexities.
I haven't had time to look into its GraphQL API yet.
Documentation wise I'd compare it to working with NixOS. For some simple tasks the documentation is useful but for anything more complicated you want to look at the Payload source code. Especially when you start customizing the UI. Which generally works pretty well.
I wish they had thought about versioning the Rich Text somehow, so a client knows which version of your documents they get.
I don't know why, but it very much reminds me of Pimcore [1] back when they started. Not the functionality, but the feeling when I look at the code.
Pimcore was awesome, it was clean, considering the alternatives - it was a basically a dynamic objects store which would load dynamic blocks to generate content and theming on the frontend - and editable blocks in the admin panel. It was so relatable from a webdev standpoint, and very "hackable" - I loved it.
The idea at that time was so appealing (mind you, afaik that was before React or even Angular. Jquery was a thing at that time and ExtJS, Pepperide Farm remembers...). Now it gotten much much bigger of course, but in the beginning, it kinda reminds me of this: sleek, extensible also very relateable. Definitely not made for the size of a multi billion dollar franchise, but fun to hack around while still maintaining relatively clean code.
They do mention WP (Word Press)... I am confused. What exactly this does?
I get it takes care of content and they mention Stripe, so that is good. But is this WP compatible layer or this is accidental use of shorthand for something else?
It is more like those templates that people use to jumpstart sites, I think this can be very useful.
I don't want to sound too complainy over the free code you can get and examine yourself, maybe adding thumbnails of 3 templates would be fantastic.
Overall some clarity would be great, maybe developer should talk to someone outside his little circle and explain and see what they should include.
No, it's a Headless CMS, so no frontend themes and templates. They have an official demo page including a frontend, that you can base your work on: https://github.com/payloadcms/public-demo
If you are looking for a Wordpress-clickety click solution with templates, Payload is not a candidate.
This CMS appears to be a breath of fresh air amid the toxicity in the WordPress world.
Considering devs are looking at complaints/features in this thread, I will post one:
In WordPress, I can copy a plugin folder from one old project into a new one and enable it in the ui without touching code or cli. I see the benefit of defining plugins through a cli tool, but I also like the copy-paste folder structure of early 00's software.
It looks like a top choice for me. But a big part of why I'm probably still going to use WordPress is because of the Gravity Forms plugin.
A place where it's easy to drag and drop forms, do conditional stuff, edit thank you messages, connect inputs to other stuff like spreadsheets, zapier etc.
If any CMS / plugin could fix that for Payload. Please let me know!
[+] [-] marpstar|1 year ago|reply
This was obviously posted in the wake of the WordPress drama, but I landed on Payload while feeling stagnant after 10+ years building on WordPress. Everything else I was doing was 100% TypeScript, my entire professional career had been working with metadata driven data structure, I felt right at home with Payload.
It's just enough structure (full admin area, API, GraphQL) to make scaffolding a basic site (with authentication) quite easy. I had built an app using Next 13 before Payload began integrating directly and using the local API (versus making HTTP calls to a server endpoint) is very clean. It feels like WordPress (i.e. you're editing "client" code on the "server") but with a LOT less cruft.
Because it's headless, anything goes on the front end. One big reason that WP got so big was because of the theming capabilities. Payload has extensibility by way of plugins, but it's (obviously...) not as robust as what's available in the WP plugin repo. It'll be interesting to see how these alternatives fare against the more prescriptive tools like Ghost (which does support theming, but does not support custom fields in any way, shape, or form).
That being said, I'm all in on Payload moving forward. If you're curious, go straight to the v3 beta -- it's very close to release and plenty stable, in my opinion. Happy to answer questions.
(Not affiliated with Payload, just a big admirer of their work)
[+] [-] icemelt8|1 year ago|reply
[+] [-] slig|1 year ago|reply
[+] [-] synergy20|1 year ago|reply
[+] [-] nerveband|1 year ago|reply
I'm all about transitioning CMSes and yet WordPress has got the turnkey part of their open-source platform clear and easy to understand. You can self-host or choose a provider. Payload doesn't make that clear, it's either too dev-centric for running or wants you to "Schedule a Demo" (which is a way to capture enterprise dollars).
What about more consumer-friendly pitches and deployments? Any recommendations on that?
[+] [-] obvi8|1 year ago|reply
It’s a fair point, especially given that in so many cases the marketers are the ones procuring the CMS. And people who don’t code at all are a big portion of WP’s market.
My main concern is I’m not sure it’s easy for non-devs to see how much of the PHPish ecosystems are filling gaps in the CMS core. I don’t know how many previous CMSes the Payload folks had used before going about building it, but I’ve built tons of features and templates on most of the big ones, and IMO they did a phenomenal job of boiling it down to exactly what a developer needs to build any feature any customer or employer could ever want.
There’s no need for, say, a heavy SEO plugin. You can just define the fields you want your people to fill out and attach those fields to whatever content types you’d like. Then use those fields in the head when presenting the content out front in whatever frontend you want to use.
On top of that, you have all of the JS ecosystem you can plug right in. Dataviz for custom dashboards, data crunching, video and image processing, all of it. And because you’re not starting with a huge, opinionated plugin/module/contrib, it’s not the clunky and unfun when you need a feature that wasn’t there before. It’s so much easier to build exactly what you need if you’re comfortable with code.
SO much of a serious CMS is just content CRUD, and Payload makes it so simple to define your content types in code, where they objectively should be defined for the sake disaster recovery and reliable builds across all environments.
[+] [-] paulpopus|1 year ago|reply
You can deploy Payload anywhere you can deploy any Nextjs app, and as of v3, you'll be able to deploy it to serverless environments too like Vercel and Netlify. We'll work on adding more deployment guides directly into our docs for various platforms as well to help with this.
Again, we read everyone's feedback about Payload itself and our website so it's very much appreciated and we'll be addressing this gap in how we present ourselves!
edit: I may have misunderstood your initial point, oops
Yeah we're not consumer facing in the way Wordpress is. It's quite a huge gap to fill
[+] [-] attah_|1 year ago|reply
Yo dawg, i heard you like frameworks!
[+] [-] mzronek|1 year ago|reply
These are examples for React frameworks: https://react.dev/learn/start-a-new-react-project#production...
Next.js is a React framework.
If Payload is a framework or not is debatable. I think it's more like a data layer around a database for a any js app and an Admin Panel (that uses Next.js now). It might be called a framework for your own Headless CMS, because it is code first. So you basically code the panel and the data structure yourself.
[+] [-] _heimdall|1 year ago|reply
[+] [-] cle|1 year ago|reply
[+] [-] mrexroad|1 year ago|reply
With that said, yep, I do like robust/stable and purposeful abstractions.
[+] [-] lmarschk|1 year ago|reply
I understand what the idea is to make SSO an enterprise feature but I really think this hurts security for small and medium sized organizations as well (not only with this project, as this is a common pattern in my experience).
[+] [-] sneek_|1 year ago|reply
Question - does the word "enterprise" make you think that the amount we charge would make it unfeasible for your org to pay to use Payload?
I don't think it's ideal that we hide all our "premium" features behind the word "enterprise" and have been thinking of alternative words / messaging to describe that.
[+] [-] arnejenssen|1 year ago|reply
In the end i chose PayloadCMS. - I can programatically define content types in typescript - selfhosting - localization support.
Sanity: _Pros_: great DX, easy to start _Cons_: i was afraid of exploding bills, it felt a bit slow/sluggish
STRAPI: _Pros_: open source, selfhostable, managed solution available, _Cons_: too much clicking in the UX, and having to write middleware to get related data.
So far I am pretty happy with PayloadCMS.
[+] [-] sneek_|1 year ago|reply
[+] [-] dirtbag__dad|1 year ago|reply
Was expecting more with payload but seems to be another buggy experience but with better UI.
Eagerly waiting for a player in this space that isn’t just developer-first but also developer-friendly.
[+] [-] sneek_|1 year ago|reply
Keystone would be my other vote though, if I were looking for a CMS and Payload didn't exist. I think that is a solid crew.
[+] [-] jobsdone|1 year ago|reply
[+] [-] jokethrowaway|1 year ago|reply
Not flexible enough, performance problems, doesn't provide much ootb.
You're better off just writing a service from scratch, the time you are saving is minimal (this applies to most products before we get to django or wordpress imho)
We tried and abandoned keystone too.
[+] [-] sneek_|1 year ago|reply
Performance problems are usually something related to maybe missing indexes in your database for fields that you query on often, or similar. Payload itself is super thin. Can you give me an example of where you're seeing slowdowns? Maybe I can point you in the right direction.
Also I would love to hear about where Payload is not flexible enough. Extensibility is one of our priorities so if there is something you'd like to accomplish, but can't, I will see what I can do about it!
[+] [-] YuukiRey|1 year ago|reply
With this comes a few gotchas. It's easy for an unassuming developer to change the name of a field (e.g., upper to lower case) and suddenly all data is gone in production since this affects the database. What you should do instead is write a migration.
I'm also not a fan of Lexical. It's very focused on being a good rich text editor but not on being a good document format for your clients. For example the way they render lists is, in my opinion, simply wrong (see https://github.com/facebook/lexical/issues/2951). Or this https://github.com/facebook/lexical/issues/6269. You also have the added complication of using the Payload flavor of Lexical, which can add its own complexities.
I haven't had time to look into its GraphQL API yet.
Documentation wise I'd compare it to working with NixOS. For some simple tasks the documentation is useful but for anything more complicated you want to look at the Payload source code. Especially when you start customizing the UI. Which generally works pretty well.
I wish they had thought about versioning the Rich Text somehow, so a client knows which version of your documents they get.
Overall I like it.
[+] [-] sroussey|1 year ago|reply
[+] [-] thawab|1 year ago|reply
[+] [-] tomw1808|1 year ago|reply
Pimcore was awesome, it was clean, considering the alternatives - it was a basically a dynamic objects store which would load dynamic blocks to generate content and theming on the frontend - and editable blocks in the admin panel. It was so relatable from a webdev standpoint, and very "hackable" - I loved it.
The idea at that time was so appealing (mind you, afaik that was before React or even Angular. Jquery was a thing at that time and ExtJS, Pepperide Farm remembers...). Now it gotten much much bigger of course, but in the beginning, it kinda reminds me of this: sleek, extensible also very relateable. Definitely not made for the size of a multi billion dollar franchise, but fun to hack around while still maintaining relatively clean code.
[1] http://web.archive.org/web/20110606024114/http://www.pimcore...
[+] [-] desireco42|1 year ago|reply
I get it takes care of content and they mention Stripe, so that is good. But is this WP compatible layer or this is accidental use of shorthand for something else?
It is more like those templates that people use to jumpstart sites, I think this can be very useful.
I don't want to sound too complainy over the free code you can get and examine yourself, maybe adding thumbnails of 3 templates would be fantastic.
Overall some clarity would be great, maybe developer should talk to someone outside his little circle and explain and see what they should include.
[+] [-] mzronek|1 year ago|reply
No, it's a Headless CMS, so no frontend themes and templates. They have an official demo page including a frontend, that you can base your work on: https://github.com/payloadcms/public-demo
If you are looking for a Wordpress-clickety click solution with templates, Payload is not a candidate.
[+] [-] MongoTheMad|1 year ago|reply
Considering devs are looking at complaints/features in this thread, I will post one: In WordPress, I can copy a plugin folder from one old project into a new one and enable it in the ui without touching code or cli. I see the benefit of defining plugins through a cli tool, but I also like the copy-paste folder structure of early 00's software.
[+] [-] parsadotsh|1 year ago|reply
[+] [-] RobotToaster|1 year ago|reply
[+] [-] sneek_|1 year ago|reply
In this way, would you consider WordPress to be open-core as well, considering the amount of paid plugins there are available?
[+] [-] bartligthart|1 year ago|reply
A place where it's easy to drag and drop forms, do conditional stuff, edit thank you messages, connect inputs to other stuff like spreadsheets, zapier etc.
If any CMS / plugin could fix that for Payload. Please let me know!
[+] [-] theflyinghorse|1 year ago|reply
[+] [-] seamossfet|1 year ago|reply
[+] [-] kiddjones|1 year ago|reply
[+] [-] paulpopus|1 year ago|reply
[+] [-] adhamsalama|1 year ago|reply