DEV Community: Sean Zubrickas

Launch Week Day 5 - Replace Shopify in Your Headless CMS Stack

Sean Zubrickas — Fri, 07 Apr 2023 17:09:37 +0000

To wrap up our second launch week, we're releasing our Ecommerce starter kit. It demonstrates the strength of Payload and how it can be used to power much more than simple website content.

Today, the typical custom ecommerce build workflow is to combine a headless CMS with an ecommerce vendor like Shopify or Medusa. I refuse to discuss Woocommerce so ... you're welcome. We've built projects like that in the past, and while doable, you start to have a kaleidoscope of different vendors / functions / API requests / spaghetti.

One of the big takeaways from this week's launches is that we want to start to see the web get simpler, not more complex. We want to promote efficiency and reduce the time it takes for developers to build products, and from our own experience, building anything custom with ecommerce is quite the nightmare in today's ecosystem.

Let's take Sanity and Shopify for example (a popular combination for custom ecommerce). Is it strange to you that both platforms can manage content, but you still need both platforms regardless, even though there's a lot of overlap?
Let's consider an MVP ecommerce build. If you combine Shopify and Sanity, you're really only leveraging Shopify for a few aspects of your MVP:

Your cart
The checkout experience
Processing payments
Customer authentication

If you leverage these parts of Shopify, and then manage content in Sanity, here's how the workflow will look.

From the engineering perspective

Fetch data from Shopify for pricing, product meta, attributes, etc.
Fetch product landing page content from Sanity
Combine the two into product landing pages / archives
Manage separate environments for dev / stage / prod in both Sanity and Shopify, and then somehow keep them in sync
Create accounts for customers in Shopify, and build the cart from Shopify
In the cart, merge product meta from Shopify with whatever content is necessary from Sanity

That's not too bad really. Halfway to microservices hell, but it's doable. We've done similar many times before. But now let's think about it from the marketing / business perspective.

From the marketing / business perspective

I need to add a new product. What do I do first? Build the product in Shopify, then go build the landing page in Sanity?
Where do I manage product prices again? That's done in Shopify.
Where do I manage the product thumbnail image? That's content, right? So Sanity. Wait, no, that's done in Shopify.
I need to add a new attribute to a product. It needs a description. Content, right? OK - probably sanity. Wait. Nope, that's product meta. Gotta do that in Shopify.
Rage due to confusion

This is harder than it needs to be

When my team built projects like this in the past, frankly they didn't turn out great. We had a hard time ourselves bringing in new devs to the code because it was all a network of inter-connected mysteries. If it's remotely hard for engineers, it's certainly going to be hard for the admin end-users.

But there's a better way. Payload offers so much more than a typical SaaS CMS, which makes this all significantly easier. Let's look at the following examples.

Payload gives you authentication
You own your APIs and your database so you can write hooks to sync product meta automatically
You can integrate a payments provider like Stripe seamlessly
You can use Stripe webhooks thanks to the fact that you can open your own endpoints (on your own server)
You can do literally ALL product management directly in one place (Payload)

Payload can eliminate Shopify from the mix entirely. Replace Shopify with Stripe, and then you have literally zero overlap between the platforms.

When an admin logs in to manage products, everything is directly in Payload. When an engineer goes to build a new feature, everything is directly in Payload.

Announcing our Ecommerce Starter Kit

Today, we're officially announcing our Ecommerce starter kit which gives you everything you need to get an ecommerce store up and running instantly with Payload + NextJS. Oh, and it's completely free and open-source.

No Shopify necessary. No microservices hell. You can even instantly deploy the starter to Payload Cloud, which hooks you up with everything you need to run in production.
With this starter, you get all of the following:

Deep integration with Stripe, including automatic two-way sync via Stripe webhooks
Manage content for your entire ecommerce store in one place
Next.js frontend ready to go with products, attributes, pricing, and more
Customer authentication built with Payload and tied automatically to Stripe customers
Shopping cart out of the box
Lots, lots more

This is specifically cool for agencies

Coming from an agency background, I share many of the struggles that engineers in an agency face.

Each project you take on is subtly different, and you might find yourself scrambling to find the perfect tech stack for each one. You can quickly end up managing a smattering of products, each with entirely different stacks.

Project A needs a simple donation form, so let's go with Contentful and a simple Stripe payment form
Project B needs to sell licenses to a digital product, so let's use Sanity and Shopify for licensing and digital downloads
Project C is just a brochure marketing site, so let's use Webflow
Project D is an enterprise site, so let's use Contentstack
Project E has subscriptions, so let's build a custom backend with Laravel and use Stripe Subscriptions

Each one of these projects will be a learning experience and your engineering efficiency will suffer big time. And then fast forward a year—you have to onboard new engineers into these projects completely separately, and you'll end up with a bunch of engineers that never really understand any of the projects because they're all totally different. Revisit a project a few months later and you'll need to spend 2 days getting back up to speed with the mania that you built.

I think one of Payload's biggest shining points is that we can handle every single project in the list above. The fact that we're half application framework and half CMS is what enables all of this.

In an agency setting, imagine if you could flatten your stack. What if each project could build off the last, seamlessly? What if you could write a feature, and then the next time a client comes asking for a similar feature, you literally just re-use what you already have, but bill them as if you had to build it?\

That's the dream. And that's what we're trying to give you.

This ecommerce kit is the beginning of lots more to come, but it's one that we're very excited about. It'll make you build better products, save money, and be happy with your engineering workflow to top it all off.

Give the new ecommerce kit a shot today.

Launch Week Day 4 - The Future of Headless

Sean Zubrickas — Fri, 07 Apr 2023 17:09:10 +0000

The tech ecosystem, especially frontend, changes at light speed. It gets overwhelming to try and keep up. But I kinda love change and I think it's once again time for change in the CMS world.

Don't wanna read this whole monologue? Then skip right to the good stuff. Spoiler alert, you can now deploy Payload serverlessly on Vercel within an existing NextJS app.

Steven Tey and I dove into the topics covered in this blog post on a livestream yesterday.

Back in ~2015, I was an early advocate for headless CMS because I wanted our agency to be able to use React for the frontends of the sites we built. I had a big pitch I'd give to my clients about the value of "headless" CMS, and they bit. But now we're taking a second to re-evaluate that pitch.

In my pitches, I would fire off the benefits of headless CMS, focusing on ideas like separation of concerns, more maintainable architecture, and the ability to deliver omnichannel content from a single source of truth.

But in retrospect, I had to gloss over the unfortunate side-effects of headless. The simple fact is that I was pushing my technical agenda on our clients simply because I wanted to use React. Granted, we built some killer stuff for our clients and React enabled that.

Lots of the other upsides to headless CMS were true, for sure. A CMS should obviously be API-first nowadays. That's a given that doesn't even need to be stated anymore. But I can count on one hand the amount of times we used a headless CMS for OmNiChAnNeL content. Most all of our headless CMS builds were just used to power a single website. Actually reading about how some of the big headless CMS position themselves as thought leaders around decentralized / omnichannel / content hub / etc. just makes me laugh at this point.

Anyway, our move to headless certainly posed struggles for us along the way, especially early on. Here's a few:

Keeping CMS changes in sync with the frontend

When we'd update a content model on the CMS side, we'd need to very deliberately think about how to deploy all of our changes to the CMS at the exact same time as our changes to our frontend to minimize downtime and prevent breaking code.

Doesn't matter if we used Contentful, Sanity, Wordpress, whatever—the CMS being separate meant that we had to orchestrate deployments with caution.

Sharing TypeScript types

A good CMS (like Payload 😈) can generate TypeScript interfaces for you which could theoretically be re-used on your frontend. But, with the separation of the CMS and the frontend, you have a few equally bad options to share these types:

Manually copy / paste types from the CMS to the frontend repo
Publish a third-party types package that can be leveraged for both backend and frontend (still need to copy / paste)
Use a monorepo and get wild with scripts to automate your copy/pasting

Rough edges to do with "preview"

Back in the monolithic CMS days you'd log into your CMS and then browse around on your frontend. You'd have a nice little "admin bar" that was purpose-built to give connectivity to your frontend and your backend, but we've lost a lot of that with the move to headless.

There are "headless" CMSs like Storyblok who give you a full frontend visual editor, but... is that still headless? Cool in any way you look at it for sure, but I question if a CMS can call itself "headless" if it literally gives you a preview environment for your website - the "head".

You need to have a strong engineering team

Lots of the pushback I would hear from my clients, and rightfully so, is something like this:

"What happens if you and your team go away? Will we be stuck with a beautiful engineering masterpiece with no one smart enough / cost-effective enough to work on it? If we use WordPress, we can grab a developer off the street that works for cheap."

This always reminded me of Ducatis. Beautiful machines, but RIP if you have to work on one. If you've got a crazy dev environment that has three separate services all combined, sharing code in separate NPM packages, the onboarding for a developer coming into the project is gonna be steep.

Let's take a second to remember that we're doing this to ourselves. All for the sake of a website in most all cases.

It's time for things to get simpler

Over the past quarter, the Payload team has been thinking about all of the above quite a bit. My thesis on the topic is that the whole web dev ecosystem perpetually swings back and forth from complexity to simplicity. Someone comes up with new tech, and it's complex, but worth it. And then people get tired of the complexity and want something simpler. And then someone makes it simpler. Repeat for the rest of our lives.

I think right now we are swinging back toward simplicity. Case in point: I'm personally tired of manually solving for headless CMS "rough edges" if we're just building a simple website.

Many of you already know that one of Payload's core pillars is simplicity. Is there a way that we can solve some of the above complexity issues with Payload?

Where we're going at Payload

We envision a way to make Payload embeddable in just about any environment - be it an Express server, serverless functions, or edge functions. We want it to be portable so that you can install it within your website itself, no matter if your website is running Svelte, Next, Remix, Vue, Gatsby, whatever. If your environment can run Node, it should be able to run Payload.

We want to promote simplicity once again. Building a website? Make it easy on yourselves, not harder. Install Payload in the same repo as your frontend. Share types, simplify dev ops, take some of the rocket science away.

To realize this vision, the Payload team and I have dedicated much of the last few months to simplifying, streamlining, and modularizing our codebase so that it can be run directly in as many different types of projects as possible.

The first steps

We've simplified our code so that the Payload Local API is as barebones as possible. No HTTP overhead, no GraphQL bloat, just Node methods that are strongly typed and hit your database directly. It's almost like an ORM but it gives you an admin panel as well. This allows you to bring Payload into any project, even if it's not Express-based.

Yesterday, we announced that you can now deploy Payload serverlessly, within an existing NextJS app, on Vercel.

This is a first step, but it's a monumental shift from the "headless CMS" paradigm. You can now use Payload directly in Next server components to get strongly typed data, hitting your database directly, without any HTTP overhead. It's kinda like we're giving an optional "head" back to the headless CMS.

// Here's a NextJS server component
const Page = async ({ params: { slug } }) => {
  const payload = await getPayload();

  // Zero HTTP overhead - this doesn't hit a REST API,
  // it goes straight to your database
  const pages = await payload.find({
    collection: "pages",
    where: {
      slug: {
        equals: slug,
      },
    },
  });

  const page = pages.docs[0];

  if (!page) return notFound();

  return (
    <React.Fragment>
      <AdminBar adminBarProps={{ collection: "pages", id: page.id }} />
      <Hero {...page.hero} />
      <Blocks blocks={page.layout} />
    </React.Fragment>
  );
};

Being able to deploy Payload within your app, wherever your app is running, will solve for basically all of the above complexities that I mentioned. It'll be faster, simpler, and require less black magic.

Future goals

We're going to keep chasing this idea of simplicity. In the future, you'll be able to do this for any type of app. It doesn't need to be React or even Next. Our goal is to let you install Payload wherever you need it, and simplify your stack.

We're also already working on being able to deploy Payload within edge functions. We've got a bit of work to go on that, but it'll happen.

Serverless not your thing? Can't deal with cold starts?

Then you can combine Payload and NextJS into a single server-based repo as well. You can even deploy it on Payload Cloud.

There are edge cases, of course

I've been going on about how most people always deploy CMS in a website, blah blah. But that doesn't mean that Payload is going to lose track of our API-based DNA. There are lots of cases where deploying a CMS separately will still be the move, and any CMS should have omnichannel capabilities nowadays via REST / GraphQL / etc. no matter where or how it's deployed. I just think that is a given at this point.

Conclusion

It's time the headless CMS paradigm moved back toward simplicity. With our launch of the next-payload package, we're taking an important first step towards restoring simplicity.

I'm not sure of what the word should be that describes what I'm trying to get to but I hate coining new words for obvious concepts.

Some other CMS use the word "composable", but I feel like that's obvious if you're working with an API-based CMS. But what is true composability? Microservice / SaaS hell? Yes, let me go sign up for a SaaS CMS, then go sign up for a forms provider, then go sign up for Hubspot, then go sign up for a mail service, and then deploy my site on Next / Vercel. All just for a website? I don't care how big the site is, that doesn't sit right with me. Actually that makes me kinda want to puke.

Let's fix the complexities inherent with headless CMS and see how far we can take this idea of simplicity. Let's make our jobs easier. That'll allow us to deliver better products.

Launch Week Day 3 - Bulk Operations

Sean Zubrickas — Wed, 05 Apr 2023 14:23:52 +0000

The long awaited new feature lets editors edit, delete and publish many documents of a collection all at once.

We’ve improved the editor experience by adding selection in the collection list view and new controls to Edit, Delete, and if drafts are enabled, Publish, and Unpublish. We also added API endpoints to handle the changes and also extended the local API for programmatic access. The new features are available in v1.6.24 and later.

Delete, Publish, Unpublish Many

The workflow for these are all much the same, select a bunch of documents and go for it. You’ll get a prompt to make sure you are happy with your life choices before submitting. The changes are all handled in one request. After submitting, the UI shows the number of updated documents. If there are any errors that occur due to validation or any faults in a hook on the backend, the number of documents that didn’t get updated due to error is also shown. The results are more detailed in the HTTP response or local API for your apps to deal with.

Edit Many

The editing experience for multiple documents in a collection allows the editor to choose which fields to update. You can access all fields within a nested structure with the field selector and input your changes before saving. Fields that are hidden, unique or read-only are not available, and you can also configure the admin.disableBulkEdit option to remove certain fields.

When drafts are enabled for a collection, you also have the choice to publish or save as draft. That gives you three ways to submit:

Save updates the published document or most recent draft document in place without changing any statuses.
Publish takes your changes, adds it to the most recent document version and publishes the results.
Draft saves a draft version of your changes along with the most recent version of each document and does not affect what you currently have published.

Filter and Select All

Instead of selecting individual rows in the list, an editor can select all documents in the list. The select-all option can be used with the existing search and filter options to only include all documents matching certain criteria. With this, the bulk edit, publish, unpublish and delete workflows will use the query to perform the operation against all the matching items.

API Changes

The new functionality extends to the backend and local API as well.

There are new REST endpoints for collections to allow for bulk delete and updates:

PATCH /api/pages
DELETE /api/pages Each endpoint takes a query in the same form as a GET request would to make our changes against. The local APIs have also been extended to take either an id or where query.

const result = await payload.update({
      collection: 'posts',
      where: {
        id: { in: ids },
      },
      data: {
        title: 'Doc Title',
      },
    });

// result: 
// { 
//    docs: [{...}]
//    errors: []
// }

Try it out

Update your own Payload project or head on over to the public demo and give it a shot.

Launch Week Day 2 - Community Help

Sean Zubrickas — Tue, 04 Apr 2023 15:03:07 +0000

Being able to find solutions easily and leverage an active community all sharing knowledge together has a huge impact on both the quality of your code and the quality of your life.

With this in mind, we’re excited to introduce our new Community Help archive.

Community Help builds upon our active and supportive communities on Discord and GitHub. With over 500 resolved threads, there's a good chance that your question has been asked before, a similar issue has been encountered or a code example that you are looking for has been shared.

But the problem up until now was that GitHub Discussions are terrible for SEO for some reason, and Discord help threads are locked behind needing to download yet another app.

So to make this information way more accessible, we’re directly fetching all this data from Discord/GitHub and displaying it on the Payload website’s Community Help page. (p.s. don’t forget we are open source so feel free to check out how we did this!)

To help you find what you need faster, we've integrated Algolia Search to index every question, answer, and comment. This lets you use keywords to search on any part of the thread so you won’t miss out on anything relevant. You can also view the thread directly in your browser without needing to visit or sign up for external sites.

The first thing most of us do when we need help is turn to a search engine (i.e…. we bing it….just kidding). But when’s the last time you ever landed on a GitHub discussion from Google? Think about it… You might land on an issue, but rarely on a discussion.

With all of our GitHub Discussions and Discord community help threads output as static pages in our NextJS site, over time, we’re also hoping to start to see way more results from the Payload community directly in your Google search results.
This section of our site will continue to evolve and become more powerful as our archive of answers expands.

We’re extremely grateful for our enthusiastic and engaging community and this would not be possible without them. A few of you are absolute maniacs about helping each other and we just want to take a second to say - - THANK YOU.

Head over to the Community Help page and let us know what you think!

Launch Week Day 1 - Payload Cloud is here

Sean Zubrickas — Tue, 04 Apr 2023 15:01:21 +0000

Payload Cloud is now available, and completely free through beta (July 1). It's by far the most seamless way to deploy Payload for production.

If you browse through our Discord community help forums, a big slice of the questions people ask are around deployment-related issues.

We want to make it easier for those of you that don't want to deal with that racket (me included). Of course, Payload will always be open-source and able to be self-hosted, but starting today, you've got a better option.

What is Cloud?

Today, we're launching the public beta of Payload Cloud. It's a deployment platform that works just like Vercel, but for regular Mongo + Express apps that run a server. Connect your GitHub repo and boom — we deploy everything you need for production instantly. It's not a SaaS CMS — instead, it's your CMS, deployed for you. We just give you the plumbing.

Every piece of infrastructure that we deploy — database, S3 storage, compute, email — is exposed to you, and you can do with it what you need. We just make it easy and tailor the experience to CMS-related expectations. No more vendor hell.

Everything is free until July 1

We are releasing Cloud as a beta, and that means you get everything for free until July 1. We'll foot the infrastructure bills for you until then in exchange for you helping us ensure our infrastructure is solid.

What Cloud gives you

Even on the smallest Standard tier, we've done the hard stuff for you. Out of the box, you get the following:

Cloudflare CDN

Your app will sit behind Cloudflare which means that you get everything that Cloudflare provides, like DDoS protection, automatic SSL certificates, a global CDN with caching, and custom domain support.

We've worked tirelessly with Cloudflare to even allow you to use apex domains, which is rare.

I should take a second here to shine some light on this.

Have you ever tried to deploy an app to Heroku or DigitalOcean's App Platform on your root domain? Let's say, example.com - NOT a sudomain like www.example.com. With most DNS providers, you can't. That's because example.com is an "apex" domain, and with most DNS providers, you need to point your apex domain to a static IP like a DigitalOcean droplet. So you're forced to jump through all sorts of hoops or just make a compromise.

But with Payload Cloud, we've configured our Cloudflare implementation with static IP support — so if you want to deploy your CMS and your frontend together, and host it directly on an apex domain, Payload Cloud gives you a static IP to point your domain to.

MongoDB Atlas

We work closely with Mongo and have partnered with them to automatically provision a database for you, running on Atlas. Payload Cloud allows you to rely on the Atlas platform's speed, stability, and scale instantly. Your database is yours. We give you the credentials. Do with it what you will.

S3 file storage

Store your files on S3 with your own bucket access. Among other things, the new @payloadcms/plugin-cloud package will handle storing all of your files on S3 seamlessly for you when deployed to Payload Cloud. As with Mongo Atlas, we give you the creds, and you can do what you want with your files. They're yours.

App layer with automatic deploys

No more pm2. No more push / pull to a DigitalOcean droplet. Just connect your repo, and automatically deploy your code on push. Manage environment variables, monitor runtime logs, and more completely out of the box.

Deploy your frontend, too

I have a theory about the state and future of headless CMS. The "headless" concept came about because people wanted to bring their own frontend. Of course, the omnichannel content aspect of headless is great, but let's not kid ourselves—many of you are just powering the content for a single website / app.

That's the funny thing about web development—the whole ecosystem is like a pendulum. It swings back and forth from complexity to simplicity and right now I think we're swinging back to simplicity.

If the majority of us are all just powering websites with headless CMS, how about we allow ourselves to combine the frontend and backend again? The CMS can still be API-based and "headless", but if we could combine the two, we can regain some of the seamlessness that we had with monolithic solutions. It's more "composable" than "headless".

That would allow us to once again do stuff like:

Build more efficiently and get our jobs done with less effort
Deploy updates to the CMS and the frontend in tandem with each other
More easily manage environments and feature sets
Share TS interfaces from backend to frontend without having a third shared utils NPM package or similar
Build a better admin UX between frontend and backend using things like showing an "admin bar" while the user is logged in and browsing the frontend

One of the coolest parts about Payload Cloud is that if you want, you can deploy your entire stack (CMS and frontend) directly on one service. You no longer need to deploy your CMS separately from your frontend if you don't want to. This can be huge for cases where you, as engineers, want to simplify and work as efficiently as possible.

At its core, Payload Cloud is built to deploy Express + Mongo apps. Nothing more. So that means you can combine your Next + Payload apps directly in one and deploy it once. Put Remix and Payload in the same server. Run Sveltekit and Payload next to each other. Roll your own React frontend with Vite and deploy it seamlessly next to Payload.

Make your job easier. There are lots of possibilities here.

Through the rest of this week, we've got more announcements that make Payload able to be "composed" within your other apps, but this is definitely one of the side-effects of Payload Cloud that I'm most excited about.

What's coming

This is the very beginning for Payload Cloud. Over the next few months until our exit from public Beta on July 1, we've got lots more coming.

Free tier

First up, we want to launch our free tier. To do so, we need to keep working on how to reduce our own cost for this, because surprise surprise, there is no free lunch. Someone's paying for free stuff and it's gonna be us. We're happy to do so, because we want to make the developer experience for Payload as beautiful as possible. But we need to make sure that this is scalable and affordable, so we're going to try and revisit this as soon as we can.

Email out-of-the-box

We're working with Resend to give you a full, modern email service for every Cloud installation. This is almost done and will be a fast-follow to our beta launch today.

Programmatic CDN and purging

We want give you a way to utilize Cloudflare's CDN for everything, programmatically, across your app + frontend. Even Payload API responses. In the future, the @payloadcms/plugin-cloud package will automatically cache all applicable API responses, and will dynamically invalidate CDN cache when documents change. We'll also be exposing a way for you, as a developer, to programmatically purge CDN cache as you need.

On-demand backups

Right now, MongoDB Atlas manages automated backups for you, so backups do exist out of the box already today. But we want to expose them to you via our UI, to allow you to manage and create your own backups at your discretion. We also want to extend the "backup" idea to connect to files as well, so that when you take a backup, or one is scheduled, we give you a tidy little package containing your DB and your files, ready to go for use somewhere else.

Environment management

We're going to be releasing a full suite of environment management controls that will allow you to sync your DB and your files from project to project seamlessly. That will allow you to build multiple environments like dev, stage, and prod, while being able to seamlessly migrate files + data from one environment to another.

Usage monitoring UI

We have usage monitoring and reporting on our side, but we want to build this into the admin UI so that you can be informed of your usage in a simple and consistent manner directly within the Payload Cloud UI.

This is only the beginning

Over time, Payload Cloud will continue to evolve to be the best way to deploy Express + Mongo apps. It's only going to get better from here, and we need your help in making it so.

Ready to dive in?

Deploy your app in minutes — get started with Payload Cloud!

Redirects in Payload — Retaining SEO Value and Avoiding 404s

Sean Zubrickas — Wed, 08 Mar 2023 13:20:42 +0000

If you're re-platforming to Payload (hooray!) you need to have a proper approach for redirects in place to ensure a successful migration.

Having bulletproof redirect functionality in place will ensure you retain your current SEO value on existing pages and avoid any 404s. Google (mainly) and other search engines have gotten much more strict about how they rank websites, specifically those that have 404s, or pages that lead to nowhere.

Additionally, the marketing team has likely done a lot of work building up their SEO ranking, and it's extremely important to keep that in place after a migration.

Surprisingly, many headless content management systems don't offer redirect functionality out of the box, and you're stuck with the hassle of building this yourself.

We've been there, and that's exactly why we built our redirects plugin. It's easy for you to integrate and even easier for marketers or content managers to use which lets you focus on the rest of your project.

To make it easy to familiarize yourself with our redirects plugin, we've built an example with it already installed. Clone down the Payload repo if you haven't already, and look in the examples folder for redirects. There is a straightforward readme that will get you up and running in minutes.

For the purposes of this post, I've already got our redirects example up and running so let's dive in!

As you can see in the screenshot below, the redirects plugin creates a new collection called Redirects, which is where you'll create and manage all of your redirects.

Now, if you take a look at the example below, you'll see our payload.config is pretty straightforward. We have a pages collection, and when we go to setup our redirects we will have the ability to select documents from that collection.

import redirects from '@payloadcms/plugin-redirects'
import path from 'path'
import { buildConfig } from 'payload/config'

import { Pages } from './collections/Pages'
import { Users } from './collections/Users'
import { MainMenu } from './globals/MainMenu'

export default buildConfig({
  collections: [Pages, Users],
  cors: ['http://localhost:3000', process.env.PAYLOAD_PUBLIC_SITE_URL],
  globals: [MainMenu],
  typescript: {
    outputFile: path.resolve(__dirname, 'payload-types.ts'),
  },
  plugins: [
    redirects({
      collections: ['pages'],
    }),
  ],
})

If you click into one of the redirects you'll see two fields. The fields themselves are pretty straightforward - you have a From URL field, which is the URL string that will be matched up against the requested path, and the To URL field, which is conditional, and provides the option to link to a custom URL or internal doc.

The nice thing is that don't need to know all the ins and outs of how the plugin works, but we suspect you're going to dig around anyway and we're all for that.

Wrap up

We understand that redirects aren't the most exciting thing in the world, but being able to simply drop this into your project will make things much easier. With our redirects plugin, you've got a solution for almost any scenario you'll be up against.

I hope you found this post helpful and that you can start utilizing this powerful plugin for your Payload project. Cheers.

Learn More

To learn more about the official redirects plugin, Payload CMS and Next.js, take a look at the following resources:

Get Started

yarn add @payloadcms/plugin-redirects

Like what we're doing? Give us a star on GitHub

We're trying to change the CMS status quo by delivering editors with a great experience, but first and foremost, giving developers a CMS that they don't absolutely despise working with. All of our new features are meant to be extensible and work simply and sanely.

Stop by GitHub and give us a star!

Announcing the Write for the Community Program

Sean Zubrickas — Thu, 16 Feb 2023 12:41:43 +0000

Payload's Write for the Community program offers a unique opportunity to reward developers for contributing to an open-source project.

Our community has been instrumental in the breadth of features we've added to Payload over the past few years. We'd like to keep that momentum going and make it a worthwhile endeavor for all involved. That's precisely why we created the Write for the Community program.

The WFC program evolved from a handful of successful collaborations with a few of our contributors. This program will encourage developers and content creators to share their knowledge and expertise with the Payload community. By contributing articles, tutorials, and other types of content, participants can help make Payload more accessible, user-friendly, and feature-rich, and get rewarded in the process.

What's in it for me, exactly?

Whether it's an article, repo, or both, we'll make it worth your while. Exact compensation will be determined by the value of the contribution. We're determined to expand our library of resources, and this program will help make that possible.

In addition to the monetary rewards, you'll have the opportunity to showcase your skills and expertise, gain exposure, and build your professional network. By contributing to the Payload community, contributors can establish themselves as thought leaders and experts on Headless CMS and web development.

Read all about the program here.

Like what we're doing? Give us a star on GitHub

Stop by GitHub and give us a star!

Get up and running with one line

Getting started with Payload is easy—and free forever. Just fire up a new terminal window and run the following command:

npx create-payload-app