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)
Strong disagree - yoast, while super popular, is a horrible, bloated mess and loves to dirty up your front end code. It’s also a regular target for vulnerabilities, due to its popularity.
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.
I wouldn't recommend it, I've seen it abused as a database a few times and it was never good. It really is barebones and mostly for content and the UI/features show that.
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)
Payload has an e-commerce template, but it definitely pales in comparison to WooCommerce. I can't speak to specifics, but if I were looking to migrate away from WooCommerce, I'd look at MedusaJS (http://medusajs.com)
I feel like everyone runs into this in WP dev eventually, but not everyone is honest with themselves about it. It can get messy, fast — I’ve certainly been there!
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.
Hi, thanks! Currently I've created a small plugin that replaces the download URL of products with a post meta `use_external_url`, appends the `order_id`, and signs it using HMAC. Then I have a CF worker that reads that, validates the signature and stamps the PDF file with the order number, on the fly, after the user clicks to download the file. (I tried some of available plugins but they sucked).
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.
NextJS instead of templates. Full-featured admin area. I'd say Payload is more akin to Wagtail than Django itself. It feels ridiculously modern compared to other CMSes I've touched, Wagtail included. Payload doesn't prescribe i18n like Django.
When you need to, you can step down into NextJS and write custom endpoints and the like.
> 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.
"Prescribe" perhaps wasn't the right word. "Bundle" is probably better. Payload has no official i18n package/module/plugin/whatever.
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.
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)