PayloadCMS: Open-Source, Fullstack Next.js Framework
github.com
github.com
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)
When you need to, you can step down into NextJS and write custom endpoints and the like.
Not sure what you mean?
> When you need to, you can step down into NextJS and write custom endpoints and the like.
I don't think you were necessarily implying otherwise but one of the Django mantras is "It's just Python" - i.e. you can bypass (nearly) everything Django provides and drop down to doing whatever you want with http requests.
Re: the NextJS custom endpoint thing -- you're right in that I wasn't comparing to Django but referring to my parent comment about Ghost, which I'd say doesn't really "support" custom endpoints even if it's "possible" -- plus the .yaml routing config is kind of a drag.
I’d be interested to know what sort of work your plugins are doing. I think a lot of that ecosystem is there to fill gaps — ACFish custom field functionality, for example, is core functionality in Drupal, Payload and many others.
Just another example — I love Drupal, but the Paragraphs module was always filling a gap in Drupal that Payload’s simple, but quite powerful ‘blocks’ field type makes easy.
Another thing I didn’t realize I love about it until just now: the hooks system is super clear. It’ a lot of the same stuff you use in WP, Drupal and others, where you can hook into functionality. With WP and Drupal, it wasn’t super obvious which hooks fire when. It can take some immersion to really understand it.
I’m such a Payload Stan. I don’t work there, I swear! I’m looking forward to trying out 3.0 embedded in Sveltekit soon here.
Also, I'd like to have more flexible bundles (possibly bundles of bundles), a more flexible transaction e-mail that offers upsells right after the user buys something, for instance: the user bought the Foo Vol. 1, right after I want to send an email offering a coupon so that they can get the discounted Vol 1, 2, and 3 with the amount they just paid discounted. (I can do that with Mailpoet or Omnisend if they buy just one product, or can implement multiple discounts and upsells with a little bit of JS running on my Windmill instance + Resend).
I feel like I'm going to re-invent a lot of stuff, and since I'm using Stripe, it shouldn't be so hard to think of a nice Products/Bundles/Downloadables/Gallery DB design and ship something ultra light that I can actually understand vs the million lines that a default WP + Woo install has, plus themes and plugins.
You're better of using anything else, if you want a UI ontop maybe a tool like Pocketbase is better suited or you go the route of using an actual e-commerce tool like Saleor or Medusa.
Both are good, definitely better than homebrewing your database and that is >>> any open source CMS (I've tried a few dozen since I am building a CMS myself)
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?
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
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.
Yo dawg, i heard you like frameworks!
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.
Can a library have compiler?)
What they've added is wrapping your code in more memoization functions, basically. All stuff that doesn't fundamentally transform the code, aside from inserting more `useMemo` and the like.
The JSX macro - which is itself already optional but everyone uses it - is just that, a handy macro with implementations available in every common bundler and transpiler out there.
React Compiler is just a babel plugin for automatic performance improvement, memoization specifically, for never perfectly memoized React code.
Can library have compiler? Well why can't it? For example stdlib has a compiler, because C does.
As for anything that has patterns of building with, will argue it's a framework.
If you don't use them, then React is quite literally no different to you.
Hooks themselves are just a solution to async code, but the implication was that react was no longer a state-based UI rendering library and became a full blown frontend framework.
Hooks solution to async code? Hooks make React full blown forntend framework? Routing only important for single page applications? Yellow gorilla bread butter? Chickity dickity web frontend back single page I understand much
With that said, yep, I do like robust/stable and purposeful abstractions.
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).
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.
But personally, I think having core security features (which I believe SSO is, e.g. also for small orgs) behind such paywall is not really helping the product.
Using a free plugin developed independently from the core product does incur other issues e.g. during updates etc. Also, it does present an additional hurdle for all non-enterprise users to make use of the, typically, more secure SSO solution they might already use leading to - in my opinion - more unsafe deployments of Payload (or any other product). It is also not helping to overcome the cybersecurity poverty line anytime soon.
When I am deciding whether to buy the enterprise version of a product, for me a main concern is whether I would also be able to use the product with its core features without any subscription (preventing vendor lock-in, in worst case I would be able to run the product on my own for a specified period of time). This wouldn't be the case if no user can login any more ^^
One last aspect: We as an organization also provided and extended SSO implementations in various products in the last years. But we only do this if the SSO code is free software. In our experience SSO implementations are way better if they can be improved by the community.
Might have some updates for you soon.
or it probably won't fly, there are also still many options.
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.
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.
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)
We tried and abandoned keystone too.
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!
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.
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...
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.
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.
In this way, would you consider WordPress to be open-core as well, considering the amount of paid plugins there are available?
I feel like a few people could be convinced that visual editing is part of the open source base product, not the enterprise plugins.
Because several of those are sold by Automattic, the company that owns wordpress, I have made that argument before, yes.
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!
have you seen that?
Both of which can be included in blocks which can then be included in the rich text editor (lexical) so you're still keeping all your content in one place.
Flexibility is the name of the game here but I can give more advice if you've got specific needs or questions around this