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.
New community-built features:
code
field languages - thanks @willvilespreviousDoc
in afterChange
hooks - thanks @AlessioGrdate
field appearance option - thanks @rustyyBugfixes from the community:
req
bug with newer versions of Node - thanks @dsodrelationship
field searches - thanks @wezzleThis is nowhere near all of the PRs we've received since our last minor version. To everyone else that's contributed recently, THANK YOU!
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.
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:
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.
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.
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.
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).
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.
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!
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!
Getting started is easy—and free forever. Just fire up a new terminal window and run the following command: