We couldn't be more thankful of the support and reception that we're seeing. Below, we're going to go through some of the more noteworthy features and enhancements that Payload now supports as of 1.1.1.

Community spotlight

New community-built features:

Enable drag-and-drop reordering of Relationship and Select fields - thanks @afzaalahmad
Expose ALL Sharp formatting options for uploads - thanks @khakimvinh
Allow tabs to have an optional "name" property to make them function like groups - thanks @slavanossar
Allow for the search in Collections List view to be able to search many fields - thanks @christian-reichart
Add more supported code field languages - thanks @willviles
Ability to get the previousDoc in afterChange hooks - thanks @AlessioGr
Add new "monthOnly" date field appearance option - thanks @rustyy
Allow custom auth strategies to be named and receive Payload as an arg - thanks @lucianogreiner
Default collapsible state for Blocks, Arrays, and Collapsible component - thanks @liorix
Allow for overriding built-in Rich Text plugins - thanks @EasonSoong

Bugfixes from the community:

Use ID in JWT matching instead of email - thanks @lucianogreiner
Improve field name validation - thanks @TimHal
More accurate GraphQL types - thanks @chaoky
Fix an obscure req bug with newer versions of Node - thanks @dsod
Fix for relationship field searches - thanks @wezzle
Fix for a PUT vs. PATCH conflict - thanks @hunghvu
Fix for saving versions with unique constraints - thanks @KGZM

This is nowhere near all of the PRs we've received since our last minor version. To everyone else that's contributed recently, THANK YOU!

New features

Overhauled rich text links

We've completely rewritten our Rich Text Link element (fully backwards-compatible), which allows you to dynamically link other docs and much more.

Have you ever used a CMS that only allows you to enter text-based links in their rich text editor? This is a problem that many engineers face, because you have to store a "hard-coded" URL that points to another resource directly in the rich text itself. And then if the URL to that document changes or gets updated, the link(s) that exist in your rich text will start to 404.

Instead, rich text links should be dynamic so that you can truly link to another document in your CMS, rather than copy-paste its URL. That way, if a document changes its URL, you don't have to manually query for all references to its old URL and update each one.

You can still enter a text-based URL, but dynamic is the way to go if you're linking to other docs in your CMS. When you dynamically link, Payload will automatically populate the linked document, directly in your rich text, so you can use the data seamlessly on your frontend(s). See if other headless CMS can do that.

Custom rich text link fields

In addition to being able to link to other docs in your CMS, you can now easily inject custom fields into your rich text links themselves. Let's say you want to add a rel field, which would allow your editors to set a link's nofollow property, among others. In 1.1.1, you can now add your own fields directly into the rich text link editor just by passing them to your richText field config.

You can add whatever fields you want. If your frontend calls for differently colored links, or maybe even styled buttons, you can easily add a color field, or a type field, or anything else - and the data will show up right in your rich text JSON.

Here's an example Rich Text field with a custom field added to the Link:

1import type { Field } from 'payload/types'
2
3const myRichText: Field = {
name: 'content',
type: 'richText',
required: true,
admin: {
  link: {
    fields: [
      {
        name: 'rel',
        label: 'Rel Attribute',
        type: 'select',
        hasMany: true,
        options: [
          'noopener', 'noreferrer', 'nofollow',
        ],
      },
    ],
  },
},
22};

Navigation groups

Many users have asked us for a way to "group together" items in the left-hand sidebar nav, and we're happy to report that this is now possible with the new admin.groups property on Collections and Globals. You can now organize your nav items however you want - group them by Content, Settings, Admin, and more.

As you can see in the screenshot above, if you group all of your Collections and Globals, the default top-level groups are disabled automatically.

In addition to the groups themselves, you can now collapse / expand groups as you need. The collapsed state of nav items is persisted and will be remembered on return visits automatically.

Gravatar & custom user profile images

Payload's Admin UI has always shown a little gray "person" icon in the bottom-left corner, which links to your Account view. Now, you can easily customize the profile photo that is used by adding your own React component to the Payload config's admin.avatar property. Within the custom React component, you can reference a user's avatar upload field or similar. Then, you can render the avatar image in your React component, and it will automatically show up in that space. Alternatively, you can pass a string of gravatar and Payload will automatically render the gravatar associated with the logged in user's email address.

Dataloader

Once you've used GraphQL for a while (and especially tried to optimize its performance), you may come across the "GraphQL N+1 problem". It's basically a common issue with many GraphQL endpoints in that due to the atomic nature of GraphQL queries, you often have to make many trips to the database to fetch documents, and they all need to be "staggered" after one another, separately, because you need to actually retrieve the data for the parent document before you know which documents you need to retrieve for the lower-level documents. And this problem becomes quite a bit worse when you have complex queries, where different fields are responsible for different queries.

Many GraphQL implementations will query the database separately for each field resolver that returns a relationship document, but Payload has recently implemented the dataloader pattern, which dramatically improves Payload's API response times across the board. This is a completely behind-the-scenes optimization and has absolutely no breaking changes for end users of Payload.

Lots more

This is just scratching the surface. There have been so many other changes. Check out the Changelog for a glimpse of everything that's happened since our last minor release (1.0.0).

Breaking changes

Spoiler alert: there are none. As always, Payload strives to keep breaking changes to an absolute minimum. Since 1.0.0, we've released 36 patch versions, and none had any breaking changes.

More to come

Now that we're wrapping up with Y Combinator, we're going to add a few new faces to Payload and double-down on our efforts. Our team's capacity will improve and we're going to start producing lots more videos, tutorials, boilerplates, and more.

Keep an eye out for more to come - and as always, we'd love to know what you think. Head over to join our GitHub Discussions if you have questions, thoughts, feedback, or feature requests!

Give us a star on GitHub

Join our community on Discord

We've recently started a Discord community for the Payload community to interact in realtime. Often, Discord will be the first to hear about announcements like this move to open-source, and it can prove to be a great resource if you need help building with Payload. Click here to join!

Get up and running with one line

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

1npx create-payload-app