This repository contains a set of powerful plugins designed to enhance your Payload CMS projects. Whether you're managing complex content structures or optimizing the authoring experience, these plugins will help streamline your workflow.
We built these tools to solve complex Payload UX problems. Need a custom Next.js/Payload architecture, migration help, or bespoke plugins? We help product companies build custom CMS infrastructures in half the time it takes internally.
Book a technical consultation with the creators
🗺️ Roadmap & community contributions — see
ROADMAP.mdfor the per-plugin roadmap. Every item is also tracked as a public GitHub issue under theRoadMaplabel — pick one up and join the discussion on the Payload Discord #plugins channel.
-
🔐 Authorization - RBAC
Implement flexible role-based access control (RBAC) for your content. Define roles based on read/write/publish permissions for collections and globals. Easily assign custom permissions to users for granular content security. -
🧭 ABAC
Add Payload-native attribute-based access control (ABAC) on top of your existing collection access rules. Register providers such as tenant, geo, or other custom attributes, compile them into Payloadwhereclauses, and combine them with RBAC from the authorization plugin. -
👤 Authors Info
Automatically display author information in the authoring interface, including details like creator, updaters, publishers, and the last publish date.
-
🚀 Quick Filter
Transform your PayloadCMS admin experience with instant, intuitive filters that appear right where you need them. Say goodbye to clunky filter forms and hello to seamless data exploration! -
🔄 Reset List View
Add a "Reset Preferences" button to collection list views, allowing users to quickly reset their list view preferences (columns, filters, pagination, etc.) to the default state.
-
🔍 Changes Button
Add a "Changes" button to drafts-enabled collections and globals that opens a slide-in drawer showing a field-by-field diff between the currently published version and the user's unsaved edits or latest draft — letting editors review exactly what will be published before clicking Publish. -
💬 Rich-text Comments
Enable inline comments and discussions directly within the Payload authoring interface. This plugin supports rich text commenting using Lexical, perfect for content collaboration. -
📋 Right Panel
Enhance the editing experience with a custom right-side panel. This view allows you to manage related entities side-by-side, improving productivity when working with complex data relationships.
-
🔗 Cross-Collection Config
The Cross-Collection Config Plugin empowers you to modify the view of components in Payload CMS, injecting custom behaviors and offering global configuration capabilities not natively supported. -
⚙️ Field-type Component Override
Dynamically override all fields of a specific type in Payload CMS by replacing their default components with custom ones—seamlessly and automatically. This plugin allows you to define a field type once and apply your custom component globally across your collections.
-
🎨 Color Picker Field
Add a custom color selection tool to your Payload interface. Simplify content styling by allowing authors to choose colors effortlessly. You can choose between font-color and background-color for better preview of end results. -
✨ Icon Select
A handy icon picker field for selecting icons within the Payload UI from flowbite-react-icons, making it easy to enhance content with visually appealing icons.
💡 Tip: Each plugin is modular and can be integrated independently based on your project needs. Check out the linked documentation for installation instructions and configuration details.
This repository includes a GitHub Action that allows you to publish any package to NPM:
- Go to the "Actions" tab in the GitHub repository
- Select the "Publish Package to NPM" workflow
- Click "Run workflow"
- Select the package you want to publish from the dropdown
- Choose the version type (patch, minor, major) to determine how the version number will be incremented
- Click "Run workflow" to start the publishing process
Note: This action requires an NPM access token stored as a GitHub secret named NPM_TOKEN.
For maintenance purposes, you can purge all versions of a package from NPM using the "Purge Package from NPM" workflow:
- Go to the "Actions" tab in the GitHub repository
- Select the "Purge Package from NPM" workflow
- Click "Run workflow"
- Select the package you want to purge from the dropdown
- Type "PURGE" in the confirmation field (this is required to prevent accidental purges)
- Leave "Dry run" set to "true" to preview what would be unpublished without actually doing it
- Click "Run workflow" to start the process
When you're ready to actually purge the package:
- Follow the same steps, but set "Dry run" to "false"
- The workflow will unpublish all versions of the package from NPM
Warning: Purging packages is irreversible and may affect users who depend on your package. Use with caution.
This is a pnpm workspace/monorepo. Install dependencies from the repository root.
Prerequisites
- Node: ^18.20.2 or >=20.9.0 (see package.json "engines")
- pnpm: 9.x (this repo pins pnpm in package.json "packageManager")
Recommended: use Corepack to get the right pnpm version
- Enable Corepack once: corepack enable
- Activate the pinned pnpm version for this repo: corepack prepare pnpm@9.4.0 --activate
Install all workspace dependencies (from the repo root)
- pnpm install
- This will create/update a single pnpm-lock.yaml at the repository root.
- Do not expect lockfiles inside packages/*; pnpm uses a shared workspace lockfile.
Install for a single workspace package only (optional)
- You can limit installation/linking to specific packages using filter flags (still run from root):
- pnpm --filter @shefing/quickfilter install
- pnpm --filter ./packages/custom-version-view install
Clean reinstall (optional)
- From the repo root: rm -rf node_modules pnpm-lock.yaml && pnpm install
- Many packages also expose a "reinstall" script you can run inside them if needed.
Build
- Most packages can be built with: pnpm -r build (run scripts recursively)
- Or build one package: pnpm --filter @shefing/quickfilter build
- Why isn't pnpm.lock.json created when I run "pnpm i"?
- pnpm does not create a JSON lockfile. The lockfile is named "pnpm-lock.yaml".
- In a workspace/monorepo (this repo uses pnpm-workspace.yaml), pnpm creates a single shared lockfile at the repository root. You will not get a lockfile inside packages/* directories.
- You should run installs from the workspace root:
pnpm install(orpnpm -w install). - If you explicitly want per-package lockfiles (not recommended for most teams), you can set
shared-workspace-lockfile=falsein a .npmrc at the workspace root. That will generate lockfiles within individual packages, at the cost of losing a single source of truth.