标签：#payload

Running 23 European e-commerce shops on Payload CMS v3 taught me that some things simply don't exist yet. So I built them. Background I maintain a multi-clone e-commerce infrastructure — 23 Next.js + Payload CMS v3 shops deployed across Europe, each on its own subdomain and language. Think fr.myshop.com , de.myshop.com , sk.myshop.com ... all running on the same codebase with country-specific patches. While building this, I kept running into two missing pieces that no one had published for Payload v3: A customer reviews system with admin moderation and Google star ratings Complete Schema.org JSON-LD for Google rich snippets (Product, BreadcrumbList, ItemList, AggregateRating) Both are now published on npm. Here's what I built, the bugs I hit, and how I solved them. Part 1 — The Reviews Plugin What didn't exist Search npm for payload reviews or payload ratings — you'll find nothing for v3. The official plugin ecosystem covers SEO, forms, redirects, Stripe... but not customer reviews. Building the collection The reviews collection itself is straightforward — relationship to products , rating (1-5), status select (pending/approved/rejected), author fields. The tricky parts came later. Access control gotcha: Payload v3 uses a roles array, not a role string. This breaks if you copy v2 patterns: // ❌ Wrong — always returns false update : ({ req }) => req . user ?. role === ' admin ' , // ✅ Correct for v3 update : ({ req }) => req . user ?. roles ?. includes ( ' admin ' ), Prevent self-verification: Users can POST any field on create: () => true collections. Lock verified in a beforeChange hook: hooks : { beforeChange : [ ({ data }) => { if ( ! data . status ) data . status = ' pending ' data . verified = false // admin-only, always reset on create return data }, ], }, Email protection: read: () => true on the collection exposes authorEmail in the public API. Add field-level access: { name : ' authorEmail ' , type : ' email ' , access : { read : ({ req }) => req . user ?.