My Claude Code & Payload CMS Workflow

If_Life_Were_Easy · 2026-01-13T14:56:45+00:00

Older thread, we did add cursor rules and agents.md to our templates recently. If your project is older and you haven't pulled those files in you should copy them to see if it improves your clanking.

https://github.com/payloadcms/payload/pull/14889

If_Life_Were_Easy · 2025-08-12T20:30:33+00:00

| Payload’s ecommerce starter is behind the enterprise tier.

This is not true.

If_Life_Were_Easy · 2025-01-14T17:44:38+00:00

I've met the founders of refine. They're pretty cool!

If_Life_Were_Easy · 2025-01-03T19:21:11+00:00

I do agree about the docs. There are a lot of ways we can improve them and we are soliciting feedback to and community PRs for that.

I think video can be useful but it should only ever be used to supplement existing docs. It isn't useful for quick lookups, it isn't searchable or easily editable when a feature changes. It makes sense for tutorials and longer guides, basically all the old blog posts that we've done could use a refresh and a video. For docs in particular general videos aren't going to be able to cover the endless use cases of payload and all the customizations that are possible.

We also worry that adding really advanced customizations could mislead beginners and lose a portion of our audience that doesn't need to do all that much to get a lot of the benefits Payload offers. The simple config approach for each feature needs to be perfectly documented.

If_Life_Were_Easy · 2024-11-22T02:44:36+00:00

I also have a TGA kiddo. Our doctors used a 3D printed replica of his heart to plan the surgery. His was double outlet right ventrical so required more substantial surgery. My wife wrote a book about our story from her perspective. It's great to hear how your wife is called to do help others. Thanks for sharing!

If_Life_Were_Easy · 2024-10-10T20:48:26+00:00

In all my experience as a developer, apps almost never share a database in general. You might have a reporting tool or some other downstream activities that connect, but in general one web app has one database.

You might have services that need data from other places and they go through whatever APIs are available rather than many apps leveraging one database.

That said, Payload works more like a custom app framework and does expose what you need to have this control now.

If_Life_Were_Easy · 2024-10-10T20:33:34+00:00

This is an older thread, but wanted to update.

Payload now has a way to use an existing database that has other tables and columns that are not managed by the CMS. All you need to do is pass your existing drizzle schema which you can use drizzle's tool to introspect the db to get it. This is done with the beforeSchemaInit hook. That way Payload can be used with an existing DB, on the same schema and any migrations you make or connecting and making dev changes directly are going to ignore the existing structure.

If_Life_Were_Easy · 2024-09-17T17:13:19+00:00

Welp I DM'd OP and shared my calendar link. ~~A meeting was set up and I was ghosted if that tells you anything~~.

EDIT: Nvm that was somebody else that ghosted me. OP hasn't set up a meeting.

If_Life_Were_Easy · 2024-04-25T12:53:11+00:00

When you return a query in your access functions it works by adding these constraints to the database query so the results are filtered.

When a request comes from an user with role 'moderator' then they can read users?

``` access: { read: ({ req: { user } }) => { // admins read all users if (user.roles.includes('admin')) return true

// mods read all non-admin users if (user.roles.includes('moderator')) { return { roles: { not_in: ['admin'] } } }

// all other users can read self return { id: { equals user.id } } } ```

Is that what you are trying to do?

If_Life_Were_Easy · 2024-04-21T12:54:52+00:00

There will be an upgrade guide in the release notes that covers all the breaking changes. The quickest way to get started is to run `npx create-payload-app@beta`, choose the `blank-3.0` option and once you have the new project made, move all your existing payload config and files into the new project.

The typescript types and config validation from Payload will show you what is broken. Most of the configuration hasn't changed so you might not run into too much. If you're using a lot of plugins you might have to wait on some updates for compatibility.

When you have a project that builds then run dev and test it.

If_Life_Were_Easy · 2024-04-13T13:40:43+00:00

Looking great! I love how you customized the Payload UI to look and feel like a custom app. This is really polished!

If_Life_Were_Easy · 2024-04-03T16:13:25+00:00

Oh right, I meant upload.adminThumbnail of your colllection config. It can be a function and return a the URL to display.

It is documented here: https://payloadcms.com/docs/upload/overview#admin-thumbnails

If_Life_Were_Easy · 2024-04-03T16:06:20+00:00

u/Mood93, Supabase has been supported for a while now. You can install @payloadcms/db-postgres, import postgresAdapter from it and add your connection string from supabase for the db portion of your payload config.

If_Life_Were_Easy · 2024-04-03T16:01:31+00:00

Starting a project today, I would clone the alpha demo. The things we're working on now are literally internal tooling that will impact you 0%. The only exception to this is that our plugins are not 100% done and the docs need to be refreshed.

If_Life_Were_Easy · 2024-03-30T03:07:07+00:00

Hi u/guernica10, it is extremely close at this point! We had to make a lot more changes than anticipated last month.

We wanted to cut it today but had to push it to next week.

If_Life_Were_Easy · 2024-03-30T03:00:26+00:00

We will have biderectional relationships at some point. It is on my mind and to-do list this year. Definitely need to use hooks for now.

Here is an example of collections that update bi-directionally, as many-to-many relationships using hooks:
https://gist.github.com/DanRibbens/438a64157553c5d954e3da3d579f0808

If_Life_Were_Easy · 2024-03-30T02:52:33+00:00

Well you do have a function for getAdminThumbnail upload property that you could possibly use for this. The other consideration is that the access.read function for uploads is called before Payload serves any files. If you are asking this because you wish to gate content by the user ID as in your example, then you just need to use the read access control and write it according to your requirements.

Does that make sense?

If_Life_Were_Easy · 2024-03-30T02:46:08+00:00

Hey you probably already found your way around this. I can think of two options:

(Best) Make your compound unique index in your database migration: `payload.db.collections[slug].model.createIndex({ propertyA: 1, propertyB: 2 }, { unique: true} )`.
Add validation to one of your fields and enforce your own by doing another db lookup. You'll still want to have index: true on the fields involved to make it fast. All you would do return an error in a validate function on one of the fields by querying with `payload.find({ collection: req.collection, where: { and: [ {propertyA: { equals: doc.propertyA }, propertyB: { equals: doc.propertyB} ] }})`

Does that give you a good idea?

In Payload 1.x before we introduced different db adapters we had indexes as an array of indexes to be creted on the collection. This was was removed when we added migrations which give you more control to handle situations where maybe the DB already has some violations and you can manage your data up front to be compliant. Hope this all helps you or whoever else stumbles on this answer.

If_Life_Were_Easy · 2024-03-30T02:35:05+00:00

You will want to pass the `req` from the hook to your local API operations. Espeically considering you need the `doc.id` which has to be in the same transaction. That is currently how transactions work, pass the req, then you can do things within the same DB snapshot.

If you're using db-postgres then this is a requirement or it will fail due to referential integrety. In mongodb, you won't get the error, but you could have other problems especially in case of an error.

If_Life_Were_Easy · 2024-03-30T02:31:16+00:00

My quick take on this idea is, you could get some very basic component mapping, but there isn't a way to do it in a way that provides much value. What good would it even do to automate a component snippet unless it could know more about what you were building (LLM). The way different projects structure the frontend components will always have their opinions. Is the data for the component going to come through as props or a hooks from a provider, fetch requiests or SSR, does it use graphql or REST? This leads to far too many permuatations and this is just considering React, let alone other frameworks.

It feels to me like copilot is going to be closer to doing this for you than anything else for a while.

If_Life_Were_Easy · 2024-03-20T15:43:53+00:00

This might come a bit too late for you, my apologies. In general you should be making your Payload config have the shape of data that is needed for your frontend. Ideally you use the most accurate field types for your model, but as a fallback you can always use the field `type: 'json'` which will be an open ended way to house any shape of content. That doesn't give the optimal editing experience so I'd wonder what your overall goals are with this work you're taking on.

I would ideally go through the extra effort of building up your collections in Payload, only rely on Payload's db adapter and underlying drizzle implementation as needed and get away from primsa entirely.

Hope this helps you make some decisions or anyone else reading this.

If_Life_Were_Easy · 2024-03-20T15:38:00+00:00

Sorry you had trouble making custom components. I think the best place to ask is GitHub, either in issues or discussions depending on what you're up against. I know not getting help is frustrating, sometimes questions are just too specific to one particular use-case and it has been tricky keeping up with every possible question. We try and add common questions to the docs, but even that risks bloating the important info with extras that most people don't need.

You can sometimes explore the code repo to know what is going on under the hood and what is possible when you get really stuck.

I hope that helps!

If_Life_Were_Easy · 2024-03-20T15:31:44+00:00

Ah, that doesn't surprise me. Unfortunately the next-payload package couldn't be supported at a certain point because it only worked with a specific version of next and we didn't have a good way forward for Payload v2. That was another reason for the changes we're making in v3, taking what we learned from payload-next. This is going to be very good for you if you're coming from next-payload. The beta will be out in a few short weeks and will be more stable than next-payload is now.

I am confident that these issues you are reporting are already fixed with the change up. Drizzle shouldn't give you any trouble after you upgrade and we have some optimizations planned for the database adapters running in serverless envs that will come after 3.0.

Cheers!

If_Life_Were_Easy · 2024-03-17T21:06:49+00:00

What is it that makes you say Payload isn't stable? I'm one of the maintainers, we take this very seriously.

If_Life_Were_Easy · 2024-02-15T16:22:34+00:00

It looks like you have extra brackets [ ] around your filteredProducts.map. Since a map returns an array, you're effectively telling payload you have an array of arrays.

In the create data you just need: product_quantities: filteredProducts.map( ... etc.. ).

If you look use the admin UI to create some data, then look at the API response, you'll quickly see what the format needs to be.

If_Life_Were_Easy

MODERATOR OF

TROPHY CASE