قبل
تعریف فیلدها در گزینه‌ای با autoload است و در هر درخواست باز می‌شود، حتی صفحهٔ ورود و کرون.
بعد
تعریف‌ها در پرونده‌اند و فقط وقتی لازم است خوانده می‌شوند؛ نسخهٔ دیتابیس هم autoload ندارد.
در حال آماده‌سازی فهرست افزونه‌ها…
ساختن نوع پست سفارشی کار تازه‌ای نیست؛ ده افزونهٔ دیگر هم این کار را می‌کنند. تفاوت اینجا دو تصمیم ذخیره‌سازی است. مقدار فیلدها متای معمولی پست است، نه جدول اختصاصی — چون جدول اختصاصی در بنچمارک بهتر است و WP_Query نمی‌بیندش. تعریف‌ها در یک پروندهٔ JSON می‌نشیند نه در گزینه‌ای با autoload — چون سایتی با سی گروه فیلد صد کیلوبایت را در هر درخواست باز می‌کند، از جمله اکثریتی که هرگز به فیلدی نگاه نمی‌کنند. افزونه از همان مقادیر JSON-LD می‌سازد و یک پروندهٔ PHP مستقل برای قالب فرزند بیرون می‌دهد.
این یک دستهٔ شلوغ است و «نوع پست می‌سازد» حرف تازه‌ای نیست. سؤالی که کمتر پرسیده می‌شود این است که چنین افزونه‌ای در هر درخواست چقدر از سایت می‌گیرد — و جواب آن از دو تصمیم ذخیره‌سازی می‌آید که در هر دو مورد غریزهٔ رایج اشتباه است.
تصمیم اول: مقدار فیلدها در postmeta می‌رود، به شکل متای معمولی، نه در جدول اختصاصی. جدول اختصاصی در بنچمارک بهتر است و در عمل بی‌فایده: WP_Query نمی‌بیندش، orderby => meta_value_num رویش کار نمی‌کند، REST API نشانش نمی‌دهد و هیچ افزونهٔ دیگری خبر ندارد آنجا را نگاه کند. مهم‌تر اینکه شکل ذخیره‌سازی هم به اندازهٔ خود جدول اهمیت دارد: گالری‌ای که به‌صورت آرایهٔ سریالایز‌شده در یک ردیف بنشیند، برای همیشه از دید هر مقایسهٔ SQL پنهان است. اینجا هر مقدار یک ردیف جدا زیر یک کلید است — یک ردیف بیشتر به‌ازای هر آیتم، در ازای اینکه اصلاً قابل جست‌وجو باشد.
تصمیم دوم: تعریف‌ها در یک پروندهٔ JSON می‌روند، نه در گزینه‌ای با autoload — و صریحاً نه به این دلیل که «پرونده از دیتابیس سریع‌تر است»، که خودِ README می‌گوید درست نیست. گزینهٔ autoload هیچ کوئری اضافه‌ای ندارد؛ داخل همان یک کوئری alloptions می‌آید و برای مقدار کوچک برنده است. دلیل واقعی وقتی است که مقدار کوچک نماند: سایتی با سی گروه فیلد صد کیلوبایت دارد که در هر درخواست باز می‌شود — صفحهٔ ورود، admin-ajax، REST، کرون — از جمله اکثریتی که هرگز به فیلدی نگاه نمی‌کنند. یک نسخه با autoload خاموش در دیتابیس می‌ماند، تا سیستم پروندهٔ فقط‌خواندنی کمی سرعت هزینه کند نه همهٔ نوع‌های پست سایت.
قوی‌ترین حرف این افزونه نتیجهٔ همین تصمیم است: پرونده در uploads می‌نشیند، پس هر چیزی که بتواند آنجا بنویسد آن را کنترل می‌کند. بنابراین محتوایش دقیقاً به اندازهٔ یک فرم ارسالی نامعتبر تلقی می‌شود — با json_decode خوانده می‌شود و هرگز با include یا unserialize، و هر مقدار از همان پاک‌سازی‌ای می‌گذرد که مقدار ارسالی از فرم؛ بدون این، یک برچسب می‌توانست <img src=x onerror=…> باشد و وردپرس name_admin_bar را بدون فرار چاپ می‌کند، یعنی اجرای اسکریپت روی هر صفحهٔ پیشخوان. سقف روی تعداد ورودی‌ها هست، روی فهرست‌های تودرتو، و روی حاصل‌ضرب نوع پست × فیلد — چون محدود کردن حجم پرونده هیچ‌کدام را محدود نمی‌کند: یک پروندهٔ ۱۴ کیلوبایتی می‌تواند بیست هزار فراخوانی register_post_meta روی init بسازد. ذخیرهٔ بیش از سقف هم رد می‌شود، نه اینکه بی‌صدا بریده شود.
افزونه علاوه بر این، نام‌هایی را که سایت را خراب می‌کنند رد می‌کند و می‌گوید چه اتفاقی می‌افتاد: نام‌های خود وردپرس، متغیرهای پرس‌وجو مثل author و name، و هر نامی بلندتر از ۲۰ نویسه، چون ستون دیتابیس ۲۰ است و بلندتر بی‌صدا بریده می‌شود. از همان مقادیر هم JSON-LD می‌سازد و نگاشت ناقص را چاپ نمی‌کند بلکه هشدار می‌دهد؛ و یک پروندهٔ PHP مستقل برای قالب فرزند بیرون می‌دهد که بعد از آن می‌توان افزونه را غیرفعال کرد و نوع‌های پست، کلیدهای متا و محتوا سر جایشان می‌مانند.
قبل
تعریف فیلدها در گزینه‌ای با autoload است و در هر درخواست باز می‌شود، حتی صفحهٔ ورود و کرون.
بعد
تعریف‌ها در پرونده‌اند و فقط وقتی لازم است خوانده می‌شوند؛ نسخهٔ دیتابیس هم autoload ندارد.
قبل
گالری و چک‌باکس به شکل آرایهٔ سریالایز‌شده در یک ردیف نشسته‌اند و هیچ کوئری نمی‌تواند داخلشان را ببیند.
بعد
هر مقدار یک ردیف جدا زیر همان کلید، پس meta_query و orderby واقعاً کار می‌کنند.
قبل
نوع پستی به اسم author ساختید، خطایی ندادید، و ماه‌ها بعد فهمیدید بایگانی‌اش هیچ‌وقت باز نمی‌شود.
بعد
نام رد می‌شود و افزونه می‌گوید چه اتفاقی می‌افتاد — پیش از اینکه چیزی ساخته شود.
از منوی «CPT و اسکیما» روی افزودن نوع پست بزنید. نام را با حروف کوچک انگلیسی بنویسید؛ اگر نامی سایت را خراب کند، همان‌جا رد می‌شود و دلیلش گفته می‌شود.
انتخاب کنید گروه روی کدام نوع‌های پست ظاهر شود، بعد فیلدهایش را اضافه کنید. هر نوع فیلد کنار خودش می‌نویسد چطور ذخیره می‌شود و چه چیزی از آن قابل مرتب‌سازی است.
با یکی از دو بلوک در ویرایشگر، یا با یک تابع در قالب. هر دو مقدار را در زمان ساخته شدن صفحه می‌خوانند، نه از چیزی که در محتوای پست منجمد شده باشد.
سایت‌هایی که نوع پست سفارشی لازم دارند · فروشگاه‌ها و کاتالوگ‌هایی که باید روی فیلد مرتب و فیلتر کنند · سایت‌های محتوایی که دادهٔ ساختاریافته می‌خواهند بدون افزونهٔ سئو · توسعه‌دهندگانی که نمی‌خواهند در هر درخواست صد کیلوبایت autoload بپردازند · طراحانی که سایت را با افزونه می‌سازند و می‌خواهند بعد آن را بردارند · آژانس‌هایی که سایت مشتری را تحویل می‌دهند و نمی‌خواهند ساختار داده گروگان بماند · هر کسی که یک بار نوع پستی به اسم author ساخته است.
بدون Composer، بدون جدول اختصاصی در دیتابیس، بدون سرویس بیرونی و بدون jQuery. آنچه می‌سازید همان‌جایی می‌ماند که وردپرس نگه می‌دارد.
جدول اختصاصی در بنچمارک بهتر است و در عمل بی‌فایده: WP_Query نمی‌بیندش، orderby => meta_value_num رویش کار نمی‌کند، REST API نشانش نمی‌دهد و هیچ افزونهٔ دیگری خبر ندارد آنجا را نگاه کند. اینجا هر مقدار متای معمولی پست است، با پیشوند hd_ncs_ و بدون زیرخط ابتدایی — چون متای مخفی همان متایی است که صاحب سایت وقتی چیزی خراب می‌شود نمی‌تواند ببیند یا درست کند.
گالری‌ای که به‌صورت آرایهٔ سریالایز‌شده در یک ردیف ذخیره شود، در دیتابیس چیزی شبیه a:3:{i:0;s:2:"12";…} است؛ هیچ مقایسهٔ SQL نمی‌تواند داخلش را ببیند، پس برای همیشه از دید هر پرس‌وجویی پنهان می‌ماند و تنها راه اصلاحش مهاجرت داده است. اینجا فیلد تکرارشونده چند ردیف زیر یک کلید است. عدد هم عدد ذخیره می‌شود، تا در مرتب‌سازی ۱۰ بعد از ۹ بیاید نه قبل از آن.
نه به این دلیل که «پرونده از دیتابیس سریع‌تر است» — این حرف درست نیست. گزینهٔ autoload هیچ کوئری اضافه‌ای ندارد و داخل همان یک کوئری alloptions می‌آید؛ برای مقدار کوچک برنده است. دلیل واقعی وقتی است که مقدار کوچک نماند: سی گروه فیلد یعنی صد کیلوبایت که در هر درخواست باز می‌شود، از جمله اکثریتی که هرگز به فیلدی نگاه نمی‌کنند.
میزبانی واقعی کم نیست که سیستم پرونده‌اش فقط‌خواندنی باشد. اگر پرونده خوانده نشود، همه‌چیز از نسخهٔ دیتابیس کار می‌کند و صفحهٔ ابزارها می‌گوید دارد از کجا می‌خواند؛ خواندن کمی کندتر می‌شود و چیزی از دست نمی‌رود. نوشتن هم اتمیک است: پروندهٔ موقت و بعد rename، تا خواننده هیچ‌وقت نیمهٔ یک سند را نبیند.
هر چیزی که بتواند در پوشهٔ بارگذاری‌ها بنویسد این پرونده را کنترل می‌کند — افزونه‌ای دیگر، یک نقص بارگذاری جای دیگر سایت، یک حساب FTP لو‌رفته. پس با json_decode خوانده می‌شود و هرگز با include یا unserialize، و هر مقدار از همان پاک‌سازی‌ای می‌گذرد که مقدار ارسالی از فرم. بدون این، یک برچسب می‌توانست <img src=x onerror=…> باشد، و وردپرس name_admin_bar را بدون فرار چاپ می‌کند.
محدود کردن حجم پرونده هیچ‌کدام از این‌ها را محدود نمی‌کند: یک پروندهٔ ۱۴ کیلوبایتی می‌تواند صد نوع پست ضرب در دویست فیلد باشد، یعنی بیست هزار فراخوانی register_post_meta روی init در هر درخواست. پس حاصل‌ضرب هم سقف دارد و روی دو هزار ثبت بسته می‌شود. ذخیرهٔ بیش از سقف رد می‌شود، نه اینکه بی‌صدا بریده شود — از دست دادن کار مشتری و گفتن «ذخیره شد» بدتر از رد کردن است.
وردپرس نوع پستی به اسم author را با خوشحالی می‌پذیرد و بعد بایگانی‌اش را برای همیشه غیرقابل‌دسترس می‌گذارد. سه دسته رد می‌شود و دلیلش گفته می‌شود: نام‌های خود وردپرس، متغیرهای پرس‌وجو مثل author و type و name، و هر نامی بلندتر از ۲۰ نویسه، چون ستون دیتابیس ۲۰ است و نام بلندتر آنجا بریده می‌شود و در PHP کامل می‌ماند. هیچ‌کدام خطای فوری نمی‌دهند؛ ماه‌ها بعد به‌صورت اشکالی غیرقابل‌ردیابی برمی‌گردند.
متن، ناحیهٔ متن، عدد، نشانی، تصویر، گالری، انتخابگر، رادیویی، چک‌باکس و بله/خیر. ناحیهٔ متن از wp_kses_post می‌گذرد، پس یک لینک می‌ماند و یک اسکریپت نه. نشانی فقط http و https را می‌پذیرد. انتخابگر و رادیویی فقط یکی از گزینه‌های تعریف‌شده. تصویر و گالری شناسهٔ پیوست را ذخیره می‌کنند — نه نشانی، تا تغییر دامنه تصویر را نشکند — و بررسی می‌شود که شناسه واقعاً یک پیوست باشد.
یکی برای نمایش یک فیلد و یکی برای فهرست همهٔ فیلدهای پست. رندر روی سرور یعنی مقدار در زمان ساخته شدن صفحه خوانده می‌شود، نه اینکه در محتوای پست منجمد شود؛ اگر فردا مقدار عوض شود، صفحه هم عوض می‌شود. جعبه‌های ویرایشگر کلاسیک هم هست، با انتخابگر رسانه روی wp.media و بدون jQuery.
همین است که مقدار را برای REST API و در نتیجه برای ویرایشگر بلوک قابل دیدن می‌کند؛ نبودنش رایج‌ترین دلیل این است که یک جعبهٔ متای دست‌ساز «در گوتنبرگ کار نمی‌کند». نمایانی REST هر فیلد از خود نوع پست پیروی می‌کند، و فیلدی که نباید عمومی خوانده شود می‌تواند بیرون از REST بماند — با این توضیح که همچنان در دیتابیس هست و مدیر می‌بیندش.
محصول، مقاله، کسب‌وکار محلی، رویداد و پرسش‌های متداول، ساخته‌شده از فیلدهایی که خودتان تعریف کرده‌اید و تزریق‌شده در wp_head — بدون افزونهٔ سئو. فقط روی نمایش تکی، و فقط برای نوشته‌ای که بازدیدکننده واقعاً می‌تواند ببیند: نوشتهٔ رمزدار یا منتشرنشده خروجی نمی‌دهد. کدگذاری با JSON_HEX_TAG است، پس مقدار یک فیلد نمی‌تواند همان تگ script را که داخلش چاپ می‌شود ببندد.
اگر ویژگی‌های لازم یک نوع مقدار نداشته باشند — نام برای محصول، عنوان برای مقاله، نام و تاریخ شروع برای رویداد، نام و نشانی برای کسب‌وکار محلی — هیچ چیزی چاپ نمی‌شود و پیشخوان می‌گوید کدام ویژگی خالی مانده. دادهٔ ساختاریافتهٔ نصفه از نظر موتور جست‌وجو مشکل کیفی است، و هیچ بهتر از نصفه است.
یک پرونده می‌گیرید، در functions.php قالب فرزند می‌گذارید و افزونه را غیرفعال می‌کنید. نوع‌های پست، طبقه‌بندی‌ها، ثبت متا و هر مقداری که وارد شده سر جایش می‌ماند؛ آنچه می‌رود صفحه‌های پیشخوان، جعبه‌های ویرایش فیلد و خروجی JSON-LD است. هر مقدار از یک نویسندهٔ لیترال بیرون می‌آید نه از درج داخل رشته، و مجموعهٔ تست پروندهٔ تولیدشده را اجرا می‌کند تا مطمئن شود برچسب خصمانه به‌صورت رشتهٔ بی‌اثر می‌رسد.
ترجمهٔ کامل fa_IR همراه افزونه است — ۱۹۱ از ۱۹۱ رشته — و پیشخوان وقتی is_rtl() باشد admin-rtl.css را بار می‌کند. صفحه‌ها با ARIA واقعی ساخته شده‌اند: زبانه‌هایی که با کلیدهای جهت‌دار جابه‌جا می‌شوند، fieldset برچسب‌دار برای گروه‌های رادیویی و چک‌باکس، حلقهٔ فوکوس دیده‌شدنی، و رنگ وضعیت همیشه همراه یک کلمه. بدون jQuery — جاوااسکریپت وانیلا ES6، فقط روی صفحه‌های خود افزونه.
| امکان | توضیح | دارد |
|---|---|---|
| مقدارها متای معمولی پست | بدون جدول اختصاصی، با پیشوند hd_ncs_ | |
| فیلد تکرارشونده، یک ردیف برای هر مقدار | آرایهٔ سریالایز‌شده هیچ‌وقت قابل پرس‌وجو نمی‌شود | |
| عدد به‌صورت عدد | meta_value_num مرتب می‌کند: ۱۰ بعد از ۹ | |
| کلید متا بدون زیرخط ابتدایی | متای مخفی، متایی است که صاحب سایت نمی‌تواند درستش کند | |
| register_post_meta برای هر فیلد | نمایانی REST از خود نوع پست پیروی می‌کند | |
| ده نوع فیلد با پاک‌سازی اختصاصی | هر نوع می‌داند مقدار معتبرش چه شکلی است | |
| بررسی پیوست بودن شناسه | برای تصویر و گالری، تا یک عدد سرگردان به برگه اشاره نکند | |
| ناحیهٔ متن از wp_kses_post | لینک می‌ماند، اسکریپت نمی‌ماند | |
| نشانی فقط http و https | طرح‌های دیگر پذیرفته نمی‌شوند | |
| انتخابگر و رادیویی محدود به گزینه‌ها | مقداری بیرون از فهرست تعریف‌شده ذخیره نمی‌شود | |
| تعریف‌ها در پروندهٔ JSON داخل uploads | نه در گزینه‌ای با autoload | |
| نسخهٔ پشتیبان در دیتابیس | با autoload خاموش، برای سیستم پروندهٔ فقط‌خواندنی | |
| نوشتن اتمیک | پروندهٔ موقت و بعد rename؛ خواننده نیمهٔ سند را نمی‌بیند | |
| خواندن با json_decode | هرگز با include یا unserialize | |
| اعتبارسنجی دوباره در بازگشت | تعریف بدشکل رد می‌شود، نه اینکه به register_post_type برسد | |
| سقف حجم و عمق پرونده | دو مگابایت و شانزده سطح تودرتو | |
| سقف تعداد ورودی در هر بخش | دویست، که از هر سایت واقعی بیشتر است | |
| سقف روی حاصل‌ضرب نوع پست × فیلد | دو هزار ثبت متا در یک درخواست | |
| بیش از سقف رد می‌شود | به‌جای اینکه بی‌صدا بریده شود و بگوید ذخیره شد | |
| پرونده‌های نگهبان بدون symlink | لینک معلق نمی‌تواند نوشتن را به جای دیگری ببرد | |
| پوشه باید واقعاً داخل uploads باشد | مسیر پیش از استفاده resolve می‌شود | |
| نام پوشهٔ غیرقابل‌حدس | دوازده نویسهٔ تصادفی، چون .htaccess روی nginx کاری نمی‌کند | |
| رد نام‌های خود وردپرس | post، page، attachment، wp_block و بقیه | |
| رد متغیرهای پرس‌وجو | author، type، name، year، order و بقیه | |
| رد نام بلندتر از ۲۰ نویسه | ستون دیتابیس ۲۰ است و بلندتر بی‌صدا بریده می‌شود | |
| نوع پستِ ثبت‌شده توسط دیگری رد می‌شود | به‌جای بازنویسی‌اش، با نمایش دلیل | |
| آیکون منو محدود | یک نام Dashicons یا یک data URI با SVG در base64 | |
| پاک شدن کش در switch_blog | یک سایت شبکه نمی‌تواند نوع پست سایت دیگر را ثبت کند | |
| قفل مهاجرت با توکن | قفل فقط توسط دارندهٔ خودش آزاد می‌شود | |
| هر مسیر REST پشت بررسی دسترسی | بدون آرگومان الزامی، تا تماس ناشناس به permission_callback برسد | |
| JSON-LD با JSON_HEX_TAG | مقدار یک فیلد نمی‌تواند تگ script را ببندد | |
| نگاشت ناقص: هشدار و بدون خروجی | به‌جای دادهٔ ساختاریافتهٔ نصفه | |
| PHP تولیدشده از نویسندهٔ لیترال | برچسب خصمانه رشته می‌شود، نه کد |
| مورد | حداقل |
|---|---|
| وردپرس | ۶.۲ به بالا، تست‌شده تا ۶.۸ |
| PHP | ۸.۰ تا ۸.۳ — افزونه هر دو را بررسی می‌کند و به‌جای خطای مرگبار با توضیح بالا نمی‌آید |
| پوشهٔ بارگذاری‌ها | اگر قابل نوشتن باشد بهتر است؛ اگر نبود همه‌چیز از نسخهٔ دیتابیس کار می‌کند و صفحهٔ ابزارها همین را می‌گوید |
| دسترسی | manage_options برای مدیریت افزونه، با فیلتر hd_ncs_manage_capability قابل تغییر |
| وابستگی | هیچ — بدون Composer، بدون پوشهٔ vendor، بدون سرویس بیرونی و بدون جدول اختصاصی در دیتابیس |
برای سایتی که واقعاً به نوع پست سفارشی و فیلد نیاز دارد و قرار است سال‌ها با آن کار کند: کاتالوگ، پروژه، مطالعه موردی، فهرست ملک یا هر چیزی که باید رویش مرتب‌سازی و فیلتر کنید. اگر فقط دو فیلد اضافه لازم دارید، هر راهی جواب می‌دهد و این افزونه حرف زیادی برای گفتن ندارد. مخاطب دومش طراح یا آژانسی است که سایت را می‌سازد و تحویل می‌دهد و نمی‌خواهد ساختار داده تا ابد به یک افزونه گره بخورد — که دقیقاً کاری است که خروجی PHP مستقل حل می‌کند.
در بنچمارک بله، در عمل نه. جدول اختصاصی را WP_Query نمی‌بیند، orderby => meta_value_num رویش کار نمی‌کند، REST API نشانش نمی‌دهد و هیچ افزونهٔ دیگری خبر ندارد آنجا را نگاه کند — یعنی هر جایی که بخواهید از مقدار استفاده کنید باید کد اختصاصی بنویسید. متای معمولی کمی سنگین‌تر است و همه‌جا کار می‌کند. شکل ذخیره‌سازی هم به همان اندازه مهم است: فیلد تکرارشونده چند ردیف زیر یک کلید می‌شود، نه یک آرایهٔ سریالایز‌شده که هیچ مقایسهٔ SQL نمی‌تواند داخلش را ببیند.
هست، و برای همین با آن مثل یک فرم ارسالی نامعتبر رفتار می‌شود. هر چیزی که بتواند در پوشهٔ بارگذاری‌ها بنویسد این پرونده را کنترل می‌کند، پس: با json_decode خوانده می‌شود و هرگز با include یا unserialize؛ هر مقدار از همان پاک‌سازی‌ای می‌گذرد که مقدار فرم، چون بدون آن یک برچسب می‌توانست <img src=x onerror=…> باشد و وردپرس name_admin_bar را بدون فرار چاپ می‌کند؛ سقف روی تعداد ورودی‌ها، فهرست‌های تودرتو و حاصل‌ضرب نوع پست × فیلد هست، چون محدود کردن حجم پرونده هیچ‌کدام را محدود نمی‌کند؛ و پوشه و پرونده‌های نگهبان هرگز از طریق symlink نوشته نمی‌شوند و پوشه باید واقعاً داخل uploads باشد.
در پوشهٔ بارگذاری‌ها، داخل پوشه‌ای به نام native-cpt-schema- به‌علاوهٔ دوازده نویسهٔ تصادفی. آن بخش تصادفی راز نیست — پرونده نام و برچسب فیلدها را دارد، نه رمز و کلید — ولی .htaccess روی nginx کاری نمی‌کند، و مسیر غیرقابل‌حدس بیشترین کاری است که یک افزونه می‌تواند دربارهٔ پوشه‌ای بکند که وب‌سرور اصرار دارد سرو کند. پرونده‌های نگهبان هم کنارش نوشته می‌شوند.
همه‌چیز از نسخهٔ دیتابیس کار می‌کند و صفحهٔ ابزارها می‌گوید دارد از کجا می‌خواند. نسخهٔ دیتابیس autoload ندارد، پس هزینه‌اش یک کوئری جدا روی درخواست‌هایی است که واقعاً به فیلد نگاه می‌کنند. خواندن کمی کندتر می‌شود و چیزی از دست نمی‌رود. اگر ترجیح می‌دهید اصلاً سراغ پرونده نرود، یک گزینه در تنظیمات همین کار را می‌کند.
چون یکی از سه دسته‌ای بوده که سایت را خراب می‌کنند. نام‌های خود وردپرس مثل post و page و attachment: ثبت روی آن‌ها خطا نمی‌دهد و باعث می‌شود نوع داخلی رفتار عجیبی پیدا کند. متغیرهای پرس‌وجو مثل author و type و name و year: نوع پستی با این نام‌ها بایگانی خودش را غیرقابل‌دسترس می‌کند. و نام بلندتر از ۲۰ نویسه: وردپرس آن را در ستونی به همین کوتاهی نگه می‌دارد، پس در دیتابیس بریده می‌شود و در PHP کامل می‌ماند. هر سه بدون خطا شروع می‌شوند و ماه‌ها بعد به‌صورت اشکالی غیرقابل‌ردیابی برمی‌گردند؛ افزونه به‌جای پذیرفتن، دلیل را می‌گوید.
هیچ. نوشته‌ها در دیتابیس می‌مانند و همان لحظه‌ای که آن نوع پست دوباره تعریف شود برمی‌گردند — چه با همین افزونه، چه با پروندهٔ خروجی PHP، چه با هر چیز دیگری. همین دربارهٔ حذف کامل افزونه هم صادق است: محتوا هرگز حذف نمی‌شود.
بله، و کل طراحی ذخیره‌سازی برای همین است. عددها به‌صورت عدد ذخیره می‌شوند تا meta_value_num درست مرتبشان کند — ۱۰ بعد از ۹، نه قبلش. فیلد تکرارشونده چند ردیف زیر یک کلید است، پس meta_query می‌تواند تک‌تک مقدارها را ببیند؛ اگر همان‌ها در یک آرایهٔ سریالایز‌شده بودند، هیچ‌وقت نمی‌شد.
بله. مقدارها متای معمولی پست‌اند، و همین چیزی است که قابلیت دادهٔ پویا در هر صفحه‌سازی می‌خواند. هیچ چیز اینجا مخصوص ویرایشگر بلوک نیست؛ بلوک‌ها و جعبه‌های ویرایشگر کلاسیک فقط دو راه نمایش از میان چند راه‌اند.
یک فایل ZIP که همهٔ قابلیت‌ها در آن است: نوع پست و طبقه‌بندی با تمام سطح پارامترهای وردپرس، رد کردن نام‌های خطرناک، ده نوع فیلد با ذخیره‌سازی قابل پرس‌وجو، register_post_meta و دو بلوک رندرشده روی سرور — به‌علاوهٔ خروجی JSON-LD برای محصول، مقاله، کسب‌وکار محلی، رویداد و پرسش‌های متداول، و خروجی PHP مستقل برای قالب فرزند. چیزی جدا دانلود نمی‌شود و هیچ بخشی پشت یک بررسی قفل نشده.
صفحه‌های پیشخوان، جعبه‌های ویرایش فیلد روی صفحهٔ نوشته، و خروجی JSON-LD. آنچه می‌ماند: نوع‌های پست، طبقه‌بندی‌ها، ثبت متا و هر مقداری که تا آن لحظه وارد شده. یعنی می‌توانید سایت را با افزونه بسازید، خروجی را در قالب فرزند بگذارید و افزونه را بردارید؛ ساختار داده گروگان نمی‌ماند. کد تولیدشده هیچ‌وقت توسط خود افزونه اجرا نمی‌شود و هر مقدار از یک نویسندهٔ لیترال بیرون می‌آید، تا برچسبی که شبیه کد است به‌صورت رشته برسد.
پیش‌فرض این است که هیچ چیزی پاک نشود. کسی که افزونه‌ای را حذف می‌کند اغلب دارد افزونهٔ دیگری را امتحان می‌کند یا میزبان عوض می‌کند، و افزونه‌ای که سر راه خروج تعریف‌ها و مقدارها را می‌برد ساعت‌ها کار را نابود کرده است. یک گزینه در تنظیمات هست که اگر خودتان روشنش کنید، حذف افزونه تعریف‌ها، تنظیمات و مقدارهای فیلد را پاک می‌کند. حتی در آن حالت هم نوشته‌ها پاک نمی‌شوند.
رفع باگ افزونه، راهنمایی نصب و راه‌اندازی، کمک برای طراحی نوع پست و گروه فیلد، و راهنمایی برای نگاشت اسکیما. نوشتن قالب و کد اختصاصی برای نمایش مقدارها، بهینه‌سازی خود سایت، و مشکلات ناشی از قالب یا افزونه‌های دیگر خارج از پشتیبانی و با توافق جداگانه است.