Because Payload is built as a code-first, config-based headless CMS, using third-party plugins and even writing your own is extremely straightforward. All that's necessary is a little knowledge of JavaScript, and then from there, you can extend and modify Payload in any way that you can dream up.
With Plugins, Payload can be extended and modified in a ton of ways. Over time, we're going to build up a library of commonly requested and officially supported plugins—but what's really exciting is the fact that anyone can make their own with just a little bit of JS knowledge.
Most CMS plugin systems are upsettingly difficult to learn and require you to devote yourself to learning how to build a plugin for that CMS. You might be able to cobble something together after spending a day or so of time learning how to work in someone else's system, but you'll never get that time back. Worse yet - your learning will only ever apply to that one platform.
Payload is different. Because the core infrastructure of Payload is so open-ended, being based fully on vanilla JS / TS, the knowledge that you need to build Payload plugins is universally applicable in your career as a developer. Writing a Payload plugin is as easy as taking in a config, and then returning an enhanced config. Within, you can rely on Payload's already powerful infrastructure design like Hooks, function-based access control, custom components, open-ended Express usage, and more.
The possibilities run a lot wider than what you might expect at first glance. You can add and enhance just about any part of Payload. Below, we'll write out some examples.
Imagine if your Customers
collection could be automatically synced with HubSpot, MailChimp, or similar each time a customer is created or updated.
Required plugin functions:
afterChange
hook to relevant collections that takes the incoming data and sends it to your CRMEasy. The plugin would just take in a user's config, copy it, inject some hooks containing your platform's integration logic, and return the new config.
If you're working with sensitive data, you might want to encrypt certain fields, so that even when their data is stored at rest in the database, it is not in plaintext. Common examples might be passwords, API keys, HIPAA data, credit card data, or other personally identifiable information. A Plugin could be easily written to automatically encrypt/decrypt data as it enters and exits your APIs. The plugin would need to:
beforeChange
hook to all fields needing to be encrypted that converts the incoming value to an encrypted counterpartafterRead
hook too all encrypted fields which decrypts them automatically as they are sent out by your APIsA common use case for sites and apps is to expose a fully featured Form Builder to your editors. One way to do this through a Plugin would be as follows:
blocks
field type, where each block
would represent a field type (select
, text
, checkbox
, etc.) Editors could then build out their own custom forms and build relationship
fields which would reference them.What if you needed password protection over documents in certain collections? A plugin could do this easily. It would need to:
beforeRead
hook to all appropriate collections that shows and hides the document based on if the user has accessHere are some other quick example use cases:
upload
-enabled collections with a third-party file host like S3 or CloudinaryFind more information, including a simple example plugin, in our Plugin documentation.
Need a plugin to be created? Start a GitHub discussion. If we don't build it, maybe someone else has - or will!
We've got big things planned for Payload, and we'd love to hear what you think. If you haven't yet given the CMS a shot, you can get started free with one command: