Payload وقتی جواب می‌دهد که مدل محتوا همان گردش کار کسب‌وکار باشد
مهاجرت به Payload CMS معمولاً با صدای بلند نمی‌شکند. سایت بالا می‌آید، ادمین باز می‌شود، و چند ماه بعد معلوم می‌شود مدل، شکل جدول قبلی را کپی کرده نه کار واقعی تیم را. فیلدها سر جایشان هستند. تصمیم‌ها نیستند.
Payload به اندازه کافی TypeScript به دستت می‌دهد که این اشتباه را نکنی. به‌جای تو فکر نمی‌کند. کالکشن باید بگوید شرکت چطور منتشر می‌کند، می‌فروشد، بازبینی می‌کند و پشتیبانی می‌دهد. اینکه فیلد قبلاً در کدام جدول WordPress بوده، سؤال دوم است.
سؤال اول طراحی این نیست که «چه کالکشنی لازم داریم». این است که دور این محتوا چه تصمیمی گرفته می‌شود. سایت شخصی به پست، صفحه، رسانه و دسته نیاز دارد. کسب‌وکار مشاوره شاید مطالعه موردی، خدمت، نقل‌قول و نقطه اثبات قابل استفاده مجدد بخواهد. تیم محصول داخلی شاید تأیید، مالک، یادداشت انتشار و نسخه منطقه‌ای بخواهد. اگر این جمله را نتوانی برای هر کالکشن بگویی، آن کالکشن احتمالاً اسم یک جدول قدیمی است.
گردش کار را قبل از فیلد مدل کن
فیلد ارزان است. گردش کار بد گران است. اگر ویراستار پیش‌نویس، پیش‌نمایش، تأیید و انتشار زمان‌بندی‌شده می‌خواهد، این‌ها باید زود در مدل باشند نه به‌صورت عادت «یک فیلد status رشته‌ای که بعداً معنی‌اش را می‌نویسیم». اگر صفحه خدمت به فراخوان مشترک و مطالعه موردی مرتبط نیاز دارد، رابطه باید این کار را آسان کند. اگر نام نویسنده باید عمومی باشد بدون اینکه رکورد کاربر لو برود، یک شکل امن از نویسنده را پر کن. کالکشن احراز هویت را به قالب عمومی نچسبان.
چون schema در کد است، می‌توانی پیکربندی کالکشن را کنار hook، قانون دسترسی و تایپ نگه داری. برای سایت سفارشی این از CMSی که هر قانون جدی‌اش مذاکره با پلاگین است مناسب‌تر است. هزینه این آزادی انضباط است. چون می‌توانی همه‌جا کد بنویسی، مدل باید آن‌قدر خسته‌کننده بماند که شش ماه بعد خودت بفهمیش.
من مرز کالکشن را کوچک و مالکیت را آشکار می‌گذارم. `posts` برای مقاله. `pages` برای صفحه انعطاف‌پذیر سایت. `services` فقط اگر صفحه خدمت چرخه حیات، فیلد، یا رفتار کوئری جدا دارد. اگر خدمت فقط یک لندینگ ثابت است، یک بلاک داخل صفحه کافی است. ساده‌ترین مدلی که ویرایش را ممکن می‌کند معمولاً همان مدل درست است. کالکشن اضافه، ادمین اضافه، دسترسی اضافه، و یک رابطه دیگر است که کسی یادش می‌رود در کوئری عمومی محدودش کند.
دسترسی، رفتار محصول است
قانون دسترسی فکر بعدی امنیتی نیست. تعریف می‌کند محصول اجازه دارد چه چیزی نشان بدهد. کاربر عمومی سند منتشرشده را می‌خواند. ادمین پیش‌نویس را می‌بیند. حالت پیش‌نمایش می‌تواند بعضی چک‌ها را دور بزند، فقط در زمینه‌ای که ثابت کند ویراستار حق پیش‌نمایش دارد. این شکاف باید هم در پیکربندی Payload دیده شود هم در کمک‌تابع کوئری فرانت.
اشتباه رایج، استفاده سرسری از `overrideAccess` است چون توسعه را راحت می‌کند. همان راحتی، پیش‌نویس خصوصی، فیلد داخلی، و رابطه پنهان را هم راحت به پروداکشن می‌رساند. برای پیش‌نمایش سمت سرورِ مورد اعتماد و برای کار مهاجرت از آن استفاده کن. کوئری عمومی را روی همان قانونی بگذار که سایت به کاربر قول داده.
برای پروژه مشتری، اعتماد اغلب همین‌جا ساخته می‌شود. CMSی که بازاریابی را سریع منتشر کند خوب است. CMSی که سریع منتشر کند و محتوای خصوصی را لو ندهد، پیش‌نمایش را نشکند، و برای هر تغییر کوچک دنبال توسعه‌دهنده نفرستد بهتر است. اگر هر استثناء دسترسی یک شرط پراکنده در Route Handler باشد، این قول روی کاغذ می‌ماند.
رابطه باید کار ویرایش را کم کند
رابطه وقتی مفید است که تصمیم تکراری را حذف کند. پست به دسته وصل می‌شود. مطالعه موردی به خدمت وصل می‌شود. صفحه خدمت نقطه اثبات را از پروژه می‌کشد. ویراستار نباید همان نقل‌قول را در شش صفحه دست کپی کند و بعد فراموش کند اصلش کجاست.
هر اسم را کالکشن نکن. برای یک فراخوان، بلاک قابل استفاده مجدد کافی است. برای لینک هدر و فوتر، global کافی است. رابطه وقتی می‌ارزد که چیز متصل چرخه حیات خودش را دارد یا در جاهای کافی تکرار می‌شود که کپی، اشتباه واقعی می‌سازد.
این‌جا Payload و Next.js خوب جفت می‌شوند. CMS محتوا را ساخت‌یافته نگه می‌دارد و فرانت با سیستم بلاک رندر می‌کند، بدون اینکه مدل داده از چشم توسعه‌دهنده قایم شود. انعطاف ویراستار را داری، بدون اینکه هر صفحه یک توده بدنه CMS باشد که نه کوئری‌اش باریک است نه سئویش فیلد درجه یک.
رابطه عمیق را پیش‌فرض هر خواندن نکن. فهرست کارت به عنوان و اسلاگ و تاریخ و یک رابطه کم‌عمق نیاز دارد، نه گراف کامل نویسنده و رسانه و نسخه پیش‌نویس. اگر مدل را درست بریده باشی، این انتخاب در کوئری طبیعی است. اگر همه‌چیز به هم گره خورده باشد، هر صفحه یا کند است یا با `overrideAccess` ناامن.
مهاجرت باید خودش را ثابت کند
مهاجرت از WordPress، Contentful، Sanity، یا پنل سفارشی باید با اثبات تمام شود نه با امید. تعداد سند را بشمار. اسلاگ را چک کن. صفحه‌های مهم را رندر کن. ریدایرکت را امتحان کن. متادیتا را مقایسه کن. نسخه تصویر را ببین. وضعیت پیش‌نویس و منتشرشده را جدا تأیید کن. URL قدیمی یا باید باز شود یا عمداً ریدایرکت شود. سکوت 404 بعد از لانچ، مهاجرت نیست.
اسکریپت لازم نیست زیبا باشد. باید تا روز لانچ قابل تکرار باشد. تبدیل را صریح نگه دار، رکورد ردشده را لاگ کن، و شناسه مبدأ را نگه دار تا اجرای دوباره امن باشد. مهاجرت‌گر عمومیِ باهوش برای یک جابه‌جایی یک‌باره به‌ندرت لازم است. یک اسکریپت ساده با چک روشن قابل اعتمادتر است.
قبل از قطع سیستم قبلی، یک مسیر را با داده واقعی تا URL زنده برو. ذخیره سبز در ادمین کافی نیست. پاسخ صفحه عمومی باید عنوان مورد انتظار را بدهد و پیش‌نویس نباید در آن پاسخ باشد. اگر این دو جمله را نمی‌توانی به کسی نشان بدهی، هنوز مهاجرت نکرده‌ای.
Payload انتخاب قوی‌ای است وقتی سایت قانون سفارشی، مالکیت واقعی TypeScript، و CMSی کنار خود اپ می‌خواهد. وقتی مدل از گردش کار کسب‌وکار شروع شود، CMS از کشوی محتوا درمی‌آید و بخشی از نحوه تحویل شرکت می‌شود. اگر مدل را از روی export دیتابیس قدیمی شروع کنی، همان کشو را با تایپ بهتر بازسازی کرده‌ای.
پرسش‌های کوتاه
اگر سایت فقط بلاگ است، این همه مدل لازم است؟ نه. پست، رسانه، دسته، و صفحه برای موارد معدود غیرمقاله کافی است. سنگینی را وقتی اضافه کن که تصمیم جدا، مثل تأیید یا نسخه منطقه‌ای، واقعاً وجود دارد.
`overrideAccess` را کاملاً ممنوع کنم؟ نه. برای مسیر مورد اعتماد سرور و مهاجرت نگه دار. برای هر خواندن عمومی که «فعلاً کار می‌کند» نه.
رابطه بهتر است یا کپی فیلد؟ اگر چیز متصل مستقل ویرایش می‌شود و در چند جا می‌آید، رابطه. اگر متن یک‌بار مصرف همان صفحه است، فیلد یا بلاک. رابطه برای شیک بودن، کار ویراستار را زیاد می‌کند.