قالب بلاکی یا قالب کلاسیک وردپرس: یک مقایسهٔ بی‌تعارف

پوشهٔ قالبتان را باز کنید. اگر پوشه‌ای به نام templates با یک index.html داخلش دارد به‌علاوهٔ یک theme.json در ریشه، قالب شما بلاکی است. اگر index.php را کنار فایل‌هایی مثل header.php و footer.php دارد و نوار کناری پیشخوان مسیر نمایش سپس سفارشی‌سازی را نشان می‌دهد، قالبتان کلاسیک است.

همین یک تفاوت ساختاری تعیین می‌کند چه کسی می‌تواند چه چیزی را در سایت عوض کند، آن تغییرها کجا ذخیره می‌شوند و کدام نیمهٔ اکوسیستم افزونه‌های وردپرس عادی رفتار می‌کند.

تشخیص ۳۰ ثانیه‌ای

نشانه	قالب کلاسیک	قالب بلاکی
فایل قالب ریشه	index.php	templates/index.html
هدر و فوتر	header.php، footer.php	parts/header.html، parts/footer.html
پیکربندی سراسری	functions.php	theme.json (به‌علاوهٔ functions.php اختیاری)
منوی پیشخوان	نمایش ← سفارشی‌سازی	نمایش ← ویرایشگر
محل ذخیرهٔ تغییرات	فایل‌های روی دیسک	پایگاه داده، به شکل نوشته‌های wp_template
صفحهٔ ابزارک‌ها	دارد	ندارد

وردپرس تصمیمش را با نگاه‌کردن به وجود templates/index.html می‌گیرد. قالبی که theme.json دارد اما قالب‌های PHP خود را نگه داشته، همچنان کلاسیک حساب می‌شود — این حالت میانی رایج است و نامی هم دارد که پایین‌تر به آن می‌رسیم.

اگر به شل دسترسی دارید، یک دستور ماجرا را تمام می‌کند:

wp eval 'var_dump( wp_is_block_theme() );'

WP-CLI سریع‌ترین راه بررسی روی سایتی است که خودتان نساخته‌اید، مخصوصاً وقتی صفحه‌سازی منوهای معمول پیشخوان را پنهان کرده باشد.

چه چیزی برای کسی که سایت را ویرایش می‌کند عوض می‌شود

در قالب کلاسیک، هدر، فوتر، نوار کناری، رنگ‌ها و لوگو پشت سفارشی‌ساز قرار دارند و فقط همان کنترل‌هایی را دارید که نویسندهٔ قالب ساخته است. اگر برای متن کپی‌رایت فوتر کنترلی ثبت نکرده باشد، کنترلی وجود ندارد. یا فایل PHP را ویرایش می‌کنید یا با وضع موجود کنار می‌آیید.

در قالب بلاکی، ویرایشگر سایت کل صفحه را در دسترس می‌گذارد. هدر، فوتر، حلقهٔ نوشته‌ها، صفحهٔ ۴۰۴، چیدمان نتایج جستجو — همه بلاک‌اند و همه را کسی که هرگز PHP ندیده می‌تواند ویرایش کند. این تیتر اصلی ماجراست و واقعاً هم دستاورد بزرگی است.

هزینه‌اش این است که همه‌چیز را کسی که هرگز PHP ندیده می‌تواند ویرایش کند. مشتری می‌تواند ساعت دو بامداد عنوان سایت را از هدر پاک کند و هیچ تاریخچهٔ نسخه‌ای روی دیسک نیست که از آن بازیابی کنید — فقط نسخه‌های خود ویرایشگر سایت. قفل‌کردن بخش‌ها با قفل بلاک و محدودکردن دسترسی به ویرایشگر ممکن است، اما کاری اختیاری است که باید یادتان بماند انجامش دهید.

دو ضرر کوچک‌تر که در عمل آزاردهنده‌اند: قالب‌های بلاکی صفحهٔ ابزارک ندارند (نواحی ابزارک جای خود را به بخش‌های قالب و بلاک‌ها داده‌اند)، و منوهای کلاسیک با بلاک ناوبری جایگزین شده‌اند که آیتم‌هایش را در یک نوع محتوای جداگانه نگه می‌دارد، نه در صفحهٔ آشنای منوها.

چه چیزی برای توسعه‌دهنده عوض می‌شود

قالب‌های کلاسیک از سلسله‌مراتب قالب PHP استفاده می‌کنند. وردپرس هر درخواست را در یک زنجیرهٔ مشخص پایین می‌آید — single-{post-type}.php، بعد single.php، بعد singular.php، بعد index.php — و فایل شما اجرا می‌شود، get_header() را صدا می‌زند، حلقه را می‌چرخاند و نشانه‌گذاری‌ای چاپ می‌کند که کاراکتر به کاراکتر در اختیار شماست.

<?php get_header(); ?>
<main class="site-main">
  <?php while ( have_posts() ) : the_post(); ?>
    <h1><?php the_title(); ?></h1>
    <?php the_content(); ?>
  <?php endwhile; ?>
</main>
<?php get_footer(); ?>

قالب‌های بلاکی همان نام‌های سلسله‌مراتب را با پسوند .html به کار می‌برند، اما محتوای فایل، نشانه‌گذاری بلاکی است — یعنی HTML با جداکننده‌های بلاک داخل کامنت — و هیچ تگ قالبی در کار نیست:

<!-- wp:template-part {"slug":"header","tagName":"header"} /-->

<!-- wp:group {"tagName":"main"} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

<!-- wp:template-part {"slug":"footer","tagName":"footer"} /-->

سه پیامد که توسعه‌دهنده‌ها بلافاصله با آن روبه‌رو می‌شوند:

get_header() و get_footer() هرگز اجرا نمی‌شوند. هر چیزی که به این اکشن‌ها وصل شده باشد، در افزونه یا در یک قالب فرزند قدیمی، بی‌صدا هیچ کاری نمی‌کند. wp_head و wp_footer همچنان اجرا می‌شوند، پس بیشتر بارگذاری اسکریپت و استایل سالم می‌ماند، اما هوک‌های مخصوص هدر نه.

پایگاه داده از فایل‌های شما جلو می‌زند. لحظه‌ای که کسی قالبی را در ویرایشگر سایت ذخیره کند، وردپرس آن نسخه را به شکل نوشتهٔ wp_template نگه می‌دارد و به‌جای فایل شما سرو می‌کند. می‌توانید تمام بعدازظهر فایل HTML را ویرایش کنید و هیچ تغییری در سمت کاربر نبینید. پاک‌کردن سفارشی‌سازی همان قالب، نسخهٔ فایل را برمی‌گرداند. این رایج‌ترین گزارش «قالب بلاکی‌ام خراب است» است و اصلاً باگ نیست.

استایل‌دهی به theme.json منتقل می‌شود. رنگ‌ها، مقیاس فاصله‌گذاری، تایپوگرافی و پیش‌فرض هر بلاک به‌جای CSS به شکل داده تعریف می‌شوند و وردپرس خودش CSS را می‌سازد. تمیزتر و به‌مراتب یکدست‌تر است — تا وقتی چیزی بخواهید که اسکیما توان بیانش را ندارد؛ آن وقت باز هم CSS می‌نویسید و با ویژگی‌مندی قواعد تولیدشده دست‌وپنجه نرم می‌کنید.

{
  "version": 3,
  "settings": {
    "color": {
      "palette": [
        { "slug": "brand", "color": "#1a1a1a", "name": "Brand" }
      ]
    }
  }
}

مقدار version را با انتشار وردپرسی که رویش هستید بسنجید — اسکیما بیش از یک بار بازنگری شده و کپی‌کردن شمارهٔ نسخه از آموزشی قدیمی، تنظیماتی می‌سازد که بی‌صدا نادیده گرفته می‌شوند.

توجه کنید که functions.php از بین نمی‌رود. قالب‌های بلاکی هم برای بارگذاری اسکریپت و استایل، ثبت ورودی‌های add_image_size، نوع‌های محتوای سفارشی و هر کار PHP دیگری از آن استفاده می‌کنند. فقط کار قالب‌بندی را بسیار کمتر آنجا انجام می‌دهید.

واقعاً چه چیزی به دست می‌آورید و چه چیزی از دست می‌دهید

با رفتن به سمت بلاک به دست می‌آورید: کنترل ویرایشگر روی کل صفحه، یکدستی طراحی که theme.json تضمینش می‌کند، فایل‌های کمتر برای نگهداری، و استایل‌هایی که میان ویرایشگر و سمت کاربر بسیار بیشتر از هر قالب کلاسیکی با هم می‌خوانند.

با رفتن به سمت بلاک از دست می‌دهید: کنترل مستقیم روی نشانه‌گذاری خروجی، سفارشی‌سازی سرراست مبتنی بر هوک، سازگاری با هر چیزی که فرض می‌کند قالب‌ها PHP هستند، و این آسودگی که ظاهر سایت داخل کنترل نسخه زندگی می‌کند.

مورد آخر تأکید می‌خواهد. در قالب کلاسیک، git log به شما می‌گوید چه چیزی عوض شده. در قالب بلاکی، سهم قابل‌توجهی از ظاهر سایت داخل پایگاه داده است؛ جایی که خط استقرار شما اصلاً نگاهش نمی‌کند.

کجا قالب کلاسیک هنوز پاسخ درست است

• سایت را یک صفحه‌ساز می‌گرداند. المنتور، دیوی، بیور بیلدر و ابزارهای مشابه خودشان قالب‌بندی را در دست می‌گیرند. گذاشتن یک قالب بلاکی زیرشان یعنی افزودن سیستم قالب‌بندی دومی که هیچ کاری نمی‌کند.
• نشانه‌گذاری باید دقیق باشد. کتابخانه‌های کامپوننت اختصاصی، نشانه‌گذاری سختگیرانهٔ دسترس‌پذیری، نیازهای غیرمعمول اسکیما — خروجی بلاک محدود به چیزی است که بلاک‌ها تولید می‌کنند و جنگیدن با آن گران‌تر از نوشتن PHP تمام می‌شود.
• قالب‌بندی سنگین توسط افزونه‌ها. افزونه‌های عضویت، آموزش آنلاین، دایرکتوری و افزونه‌های تجاری قدیمی‌تر معمولاً بازنویسی قالب PHP ارائه می‌دهند. خیلی‌هایشان حالا معادل بلاکی دارند؛ خیلی‌هایشان ندارند.
• سایت تمام‌شده و کار می‌کند. قالبی با پنج سال سفارشی‌سازی انباشته، مسیر ارتقا به بلاک ندارد؛ فقط بازسازی دارد. «چون رویکرد جدیدتری است» دلیل تجاری نیست.
• هیچ‌کس جز خودتان ویرایشش نمی‌کند. سود اصلی ویرایشگر سایت، سپردن کنترل به غیربرنامه‌نویس‌هاست. اگر غیربرنامه‌نویسی در کار نیست، دارید هزینهٔ منفعتی را می‌دهید که هیچ‌کس از آن استفاده نمی‌کند.

راه میانهٔ ترکیبی

یک قالب کلاسیک می‌تواند theme.json اضافه کند و سیستم استایل‌های سراسری، پیش‌تنظیم‌های رنگ و فاصله‌گذاری و استایل یکدست ویرایشگر را به دست بیاورد — در حالی که قالب‌های PHP و سفارشی‌ساز خود را نگه داشته است. وردپرس به این قالب بلاکی نمی‌گوید و ویرایشگر سایت در دسترس نمی‌آید، اما بیشتر سود سیستم طراحی را با کسری از کار می‌گیرید.

برای سایت موجودی که عمدتاً درست کار می‌کند، معمولاً همین حرکت اول درست است. theme.json را اضافه کنید، پالت و فاصله‌گذاری‌تان را تعریف کنید، CSS‌ای را که جایگزینش شده پاک کنید و ببینید آیا هنوز بقیه‌اش را می‌خواهید یا نه.