چرا قالب‌های بلاکی آینده وردپرس هستند و کلاسیک‌ها منقرض می‌شوند؟

وقتی وردپرس ۵.۹ در ژانویه ۲۰۲۲ منتشر شد، برای اولین بار یک قالب پیش‌فرض (Twenty Twenty-Two) ارائه شد که کاملاً بر پایه بلاک‌ها ساخته شده بود و هیچ فایل PHP Template سنتی نداشت. آن لحظه، نقطه عطفی در تاریخ وردپرس بود: مسیری که از سال ۲۰۰۳ با قالب‌های کلاسیک شروع شده بود، به سمت معماری جدیدی تغییر جهت داد که در آن، مرز بین محتوا و طراحی برداشته می‌شود.

قالب‌های بلاکی چیستند و چه تفاوتی با کلاسیک دارند؟

قالب بلاکی (Block Theme) یا همان Full Site Editing Theme، نوعی قالب وردپرس است که در آن تمام بخش‌های سایت — هدر، فوتر، نوار کناری، صفحات، آرشیوها و حتی صفحات محصول — با بلاک‌های گوتنبرگ ساخته و ویرایش می‌شوند. در مقابل، قالب کلاسیک (Classic Theme) بر پایه فایل‌های PHP Template کار می‌کند که ساختار HTML را در کد تعریف می‌کنند و تغییر آن نیازمند ویرایش مستقیم فایل‌ها یا استفاده از Customizer است.

تفاوت بنیادین این دو نوع قالب در سه لایه قابل تحلیل است. لایه اول، ساختار فایل‌ها: قالب کلاسیک از header.php، footer.php، index.php، single.php و ده‌ها فایل PHP دیگر تشکیل می‌شود. قالب بلاکی از templates/ با فایل‌های HTML، parts/ برای بخش‌های قابل بازاستفاده، و theme.json برای تعریف تنظیمات استفاده می‌کند. لایه دوم، مدل ویرایش: در قالب کلاسیک، کاربر برای تغییر ساختار به Customizer یا Page Builder نیاز دارد. در قالب بلاکی، همان ویرایشگر گوتنبرگ که برای نوشتن پست استفاده می‌شود، برای ویرایش کل سایت به کار می‌رود. لایه سوم، معماری داده: قالب کلاسیک تنظیمات را در دیتابیس (wp_options) و فایل‌های PHP ذخیره می‌کند. قالب بلاکی همان تنظیمات را در theme.json و بلاک‌های قابل بازاستفاده (Synced Patterns) نگه می‌دارد.

«قالب بلاکی، وردپرس را از یک CMS با قالب‌های کدنویسی‌شده به یک پلتفرم طراحی بصری تبدیل می‌کند که در آن، کاربر نهایی کنترل کاملی بر ظاهر سایت دارد.»

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

نکته مهم این است که بلاک تم‌ها فقط یک نوع جدید قالب نیستند؛ آن‌ها یک پارادایم جدید در توسعه وردپرس هستند. در این پارادایم، مرز بین «قالب» و «محتوا» محو می‌شود. هدر و فوتر که قبلاً بخشی از قالب بودند، حالا بخشی از محتوای قابل ویرایش هستند. این تغییر، پیامدهای عمیقی برای توسعه‌دهندگان، طراحان و کاربران نهایی دارد.

تفاوت معماری: PHP Template در برابر HTML Block Template

درک تفاوت معماری بین قالب کلاسیک و بلاکی، پیش‌نیاز تصمیم‌گیری آگاهانه است. در قالب کلاسیک، چرخه رندر به این شکل است:

1. وردپرس تشخیص می‌دهد که کاربر کدام صفحه را درخواست کرده است.
2. بر اساس سلسله‌مراتب قالب، فایل PHP مناسب انتخاب می‌شود (مثلاً single.php).
3. فایل PHP با توابعی مثل get_header()، the_post()، get_footer() اجرا می‌شود.
4. خروجی HTML به مرورگر ارسال می‌شود.

در قالب بلاکی، همان چرخه به شکل متفاوتی اجرا می‌شود:

1. وردپرس تشخیص می‌دهد که کاربر کدام صفحه را درخواست کرده است.
2. بر اساس سلسله‌مراتب قالب، فایل HTML مناسب انتخاب می‌شود (مثلاً templates/single.html).
3. محتوای بلاک‌ها از دیتابیس خوانده می‌شود.
4. هر بلاک با تابع رندر خود (Render Callback) اجرا می‌شود.
5. خروجی HTML به مرورگر ارسال می‌شود.

تفاوت کلیدی در گام دوم و چهارم است. در قالب کلاسیک، ساختار HTML در فایل PHP Hard-coded شده است. در قالب بلاکی، ساختار HTML در فایل‌های HTML Template توصیف می‌شود و محتوای واقعی از بلاک‌های ذخیره‌شده در دیتابیس می‌آید. اگر با فایل‌های ضروری قالب وردپرس و وظیفه هرکدام آشنا شده باشید، این تفاوت را در سطح ساختار فایل‌ها نیز مشاهده می‌کنید.

نکته حیاتی در معماری بلاک تم‌ها، مفهوم Block Bindings است. این ویژگی که در وردپرس ۶.۵ معرفی شد، به بلاک‌ها اجازه می‌دهد داده‌های خود را از منابع خارجی (مثل Custom Fields یا Metadata) دریافت کنند. این یعنی بلاک‌های داینامیک می‌توانند بدون کدنویسی PHP، داده‌های واقعی را نمایش دهند. اگر با قالب وردپرس از نگاه یک توسعه‌دهنده آشنا شده باشید، این تحول را به‌عنوان یک جهش معماری می‌شناسید.

theme.json: قلب تپنده بلاک تم‌ها

فایل theme.json مهم‌ترین فایل در یک بلاک تم است. این فایل، تنظیمات ظاهری سایت را به‌صورت متمرکز تعریف می‌کند: پالت رنگ، تایپوگرافی، فاصله‌ها، Layout، و تنظیمات پیش‌فرض بلاک‌ها. قبل از theme.json، این تنظیمات در چندین جا پخش بودند: functions.php برای add_theme_support()، Customizer برای رنگ‌ها، و CSS برای استایل‌ها.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "appearanceTools": true,
    "layout": {
      "contentSize": "720px",
      "wideSize": "1200px"
    },
    "color": {
      "palette": [
        { "slug": "primary", "color": "#005fcc", "name": "Primary" },
        { "slug": "secondary", "color": "#1a1a1a", "name": "Secondary" },
        { "slug": "background", "color": "#ffffff", "name": "Background" }
      ]
    },
    "typography": {
      "fontFamilies": [
        {
          "fontFamily": "'Inter', sans-serif",
          "name": "Inter",
          "slug": "inter"
        }
      ],
      "fontSizes": [
        { "slug": "small", "size": "0.875rem", "name": "Small" },
        { "slug": "medium", "size": "1rem", "name": "Medium" },
        { "slug": "large", "size": "1.5rem", "name": "Large" },
        { "slug": "x-large", "size": "2.5rem", "name": "Extra Large" }
      ]
    },
    "spacing": {
      "units": [ "px", "em", "rem", "%", "vw", "vh" ]
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--background)",
      "text": "var(--wp--preset--color--secondary)"
    },
    "typography": {
      "fontFamily": "var(--wp--preset--font-family--inter)",
      "fontSize": "var(--wp--preset--font-size--medium)"
    },
    "elements": {
      "link": {
        "color": { "text": "var(--wp--preset--color--primary)" }
      }
    }
  }
}

این فایل، چند مزیت کلیدی دارد. اول، CSS Variables بومی: هر مقدار در theme.json به یک CSS Custom Property تبدیل می‌شود که در تمام بخش‌های سایت قابل استفاده است. این یعنی تغییر یک رنگ در theme.json، تمام سایت را به‌روزرسانی می‌کند. دوم، Consistency: چون تمام تنظیمات در یک فایل تعریف می‌شوند، تیم توسعه و تیم طراحی یک منبع حقیقت واحد دارند. سوم، Type Safety: با افزودن $schema، ویرایشگرهای کد می‌توانند Auto-completion و Validation ارائه دهند.

در نسخه ۳ theme.json که در وردپرس ۶.۶ معرفی شد، چند قابلیت جدید اضافه شده: پشتیبانی از defaultFontSizes: false برای حذف سایزهای پیش‌فرض، fluid برای Typography تطبیقی، و shadow برای سایه‌ها. اگر با ساختار فایل‌های یک قالب استاندارد وردپرس آشنا شده باشید، می‌دانید که theme.json جایگزین بخش بزرگی از functions.php و Customizer شده است.

Full Site Editing و پایان عصر Customizer

Full Site Editing (FSE) مجموعه‌ای از قابلیت‌هاست که ویرایش کل سایت را با بلاک‌ها ممکن می‌کند. این قابلیت‌ها شامل:

• Site Editor: محیطی در پنل مدیریت که کل ساختار سایت را نمایش می‌دهد.
• Template Editor: امکان ویرایش قالب‌های صفحه (Single، Archive، 404) با بلاک‌ها.
• Template Parts: بخش‌های قابل بازاستفاده مثل هدر، فوتر، و Sidebar.
• Global Styles: پنل تنظیمات سراسری برای رنگ، تایپوگرافی، و Layout.
• Synced Patterns: بلاک‌های قابل بازاستفاده که در تمام سایت همگام‌سازی می‌شوند.
• Navigation Block: منوی قابل ویرایش با بلاک‌ها.

این مجموعه، Customizer را تا حد زیادی منسوخ می‌کند. Customizer یک محیط محدود برای تنظیمات ظاهری بود: رنگ هدر، لوگو، و چند گزینه دیگر. FSE محیطی است که تمام جنبه‌های ظاهری و ساختاری را پوشش می‌دهد. اگر با سفارشی‌سازی قالب وردپرس در سطح متوسط آشنا شده باشید، می‌دانید که Customizer محدودیت‌های جدی داشت و کاربران برای تغییرات عمیق‌تر به کدنویسی نیاز داشتند.

«Customizer یک پنجره بود که از آن، بخش کوچکی از قالب را می‌دیدید. FSE یک در است که شما را به تمام خانه می‌برد.»

نکته مهم این است که FSE در ابتدا محدودیت‌هایی داشت: عدم پشتیبانی از Custom Post Type (CPT) در Template Editor، محدودیت در ویرایش Template Parts در بعضی Queryها، و نبود کنترل کامل بر Query Loop. اما هر نسخه از وردپرس این محدودیت‌ها را کاهش داده است. در وردپرس ۶.۵، Block Bindings اضافه شد که به بلاک‌ها اجازه می‌دهد داده‌های خارجی را نمایش دهند. در وردپرس ۶.۶، theme.json نسخه ۳ با قابلیت‌های جدید معرفی شد. اگر با گوتنبرگ و تحول ویرایش محتوا در وردپرس آشنا شده باشید، این تحولات را به‌عنوان بخشی از یک مسیر تکاملی می‌شناسید.

Site Editor و Developer Mode

یکی از چالش‌های FSE برای توسعه‌دهندگان، Sync بین فایل‌های HTML و دیتابیس است. وقتی کاربر یک Template را در Site Editor ویرایش می‌کند، تغییرات در دیتابیس ذخیره می‌شود و فایل HTML اصلی دست‌نخورده می‌ماند. این یعنی اگر توسعه‌دهنده فایل HTML را به‌روزرسانی کند، تغییرات کاربر ممکن است نادیده گرفته شود.

وردپرس برای حل این مشکل، یک حالت Developer Mode معرفی کرده که با فیلتر زیر فعال می‌شود:

// wp-config.php
define( 'WP_DEVELOPMENT_MODE', 'theme' );

در این حالت، Site Editor تغییرات را در فایل‌های HTML ذخیره می‌کند، نه در دیتابیس. این یعنی فایل‌های HTML منبع حقیقت هستند و می‌توانند در Git نگهداری شوند. اگر با گیت در توسعه وردپرس آشنا شده باشید، این رویکرد را به‌عنوان یک مزیت بزرگ برای Workflow توسعه می‌شناسید.

Style Variations و Global Styles

یکی از قدرتمندترین ویژگی‌های بلاک تم‌ها، Style Variations است. این ویژگی به یک قالب اجازه می‌دهد چندین سبک بصری مختلف ارائه دهد که کاربر می‌تواند با یک کلیک آن‌ها را تغییر دهد. هر Style Variation یک فایل JSON در پوشه styles/ است که تنظیمات theme.json را Override می‌کند.

// styles/dark.json
{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "title": "Dark Mode",
  "settings": {
    "color": {
      "palette": [
        { "slug": "background", "color": "#1a1a1a", "name": "Background" },
        { "slug": "text", "color": "#f0f0f0", "name": "Text" }
      ]
    }
  },
  "styles": {
    "color": {
      "background": "var(--wp--preset--color--background)",
      "text": "var(--wp--preset--color--text)"
    }
  }
}

با این فایل، کاربر می‌تواند در پنل Global Styles بین حالت روشن و تیره جابه‌جا شود. مزیت این رویکرد چند لایه است. اول، کاهش پیچیدگی: به‌جای ساخت چند قالب جداگانه، یک قالب با چند Style Variation کافی است. دوم، بهبود تجربه کاربری: کاربر بدون نیاز به کدنویسی، ظاهر سایت را تغییر می‌دهد. سوم، صرفه‌جویی در زمان توسعه: توسعه‌دهنده یک Base Style می‌سازد و سپس Variationها را اضافه می‌کند.

Global Styles نیز پنلی است که به کاربر اجازه می‌دهد تنظیمات theme.json را از داخل پنل مدیریت تغییر دهد. این تنظیمات در دیتابیس ذخیره می‌شوند و بر theme.json اولویت دارند. اگر با دلایل استفاده از چایلد تم وردپرس آشنا شده باشید، می‌دانید که Global Styles تا حد زیادی جایگزین چایلد تم برای تغییرات ظاهری شده است.

سلسله‌مراتب قالب‌ها در بلاک تم‌ها

سلسله‌مراتب قالب در بلاک تم‌ها مشابه قالب کلاسیک است، اما با تفاوت‌های مهم. در قالب کلاسیک، فایل‌ها پسوند .php دارند و در ریشه قالب قرار می‌گیرند. در قالب بلاکی، فایل‌ها پسوند .html دارند و در پوشه templates/ قرار می‌گیرند.

هر فایل HTML در بلاک تم، شامل یک یا چند بلاک است. برای مثال، یک templates/single.html ساده:

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

<!-- wp:group {"tagName":"main","layout":{"type":"constrained"}} -->
<main class="wp-block-group">
  <!-- wp:post-title {"level":1} /-->
  <!-- wp:post-featured-image /-->
  <!-- wp:post-content /-->
</main>
<!-- /wp:group -->

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

این ساختار، کاملاً مبتنی بر بلاک است و نیازی به PHP ندارد. اگر با ساخت بلاک سفارشی گوتنبرگ از صفر آشنا شده باشید، این ساختار برای شما آشناست: هر بلاک یک Comment خاص دارد که نوع و Attributeهای آن را تعریف می‌کند.

عملکرد: آیا بلاک تم‌ها سریع‌تر هستند؟

یکی از سؤالات رایج درباره بلاک تم‌ها، تأثیر آن‌ها بر عملکرد سایت است. پاسخ کوتاه: بستگی دارد. بلاک تم‌ها دو مزیت عملکردی دارند و دو چالش.

مزیت اول، کاهش CSS اضافی. در قالب‌های کلاسیک، بسیاری از استایل‌ها در فایل‌های CSS جداگانه تعریف می‌شوند و ممکن است بخش زیادی از آن‌ها در صفحات خاصی استفاده نشوند. در بلاک تم‌ها، CSS از theme.json و Global Styles تولید می‌شود که به‌صورت دقیق‌تر به نیازهای واقعی سایت پاسخ می‌دهد. مزیت دوم، Lazy Loading بلاک‌ها. وردپرس از نسخه ۵.۸ به بعد، فقط CSS و JS بلاک‌هایی را بارگذاری می‌کند که در صفحه استفاده شده‌اند. اگر با قالب سبک وردپرس و افزایش سرعت آشنا شده باشید، این بهینه‌سازی را به‌عنوان یک مزیت می‌شناسید.

چالش اول، حجم CSS تولیدشده. فایل global-styles.css که از theme.json تولید می‌شود، می‌تواند بزرگ باشد، به‌خصوص اگر theme.json تنظیمات زیادی داشته باشد. این حجم، در سایت‌های کوچک قابل توجه است. چالش دوم، Inline Styles. بعضی بلاک‌ها استایل‌های خود را به‌صورت Inline در HTML قرار می‌دهند که می‌تواند حجم HTML را افزایش دهد.

«عملکرد بلاک تم‌ها به کیفیت پیاده‌سازی بستگی دارد، نه به نوع قالب. یک بلاک تم بهینه‌سازی‌شده می‌تواند سریع‌تر از یک قالب کلاسیک سنگین باشد و بالعکس.»

در عمل، تجربه نشان داده که بلاک تم‌های بهینه‌سازی‌شده مثل Twenty Twenty-Four با نمره Lighthouse بالای ۹۵ عملکرد عالی دارند. اما بلاک تم‌هایی که از بلاک‌های سنگین و افزونه‌های متعدد استفاده می‌کنند، می‌توانند کند باشند. اگر با روش‌های بهبود Core Web Vitals آشنا شده باشید، می‌دانید که عملکرد نهایی به ترکیب عوامل بستگی دارد، نه فقط نوع قالب.

بهینه‌سازی بلاک تم‌ها

چند تکنیک برای بهینه‌سازی بلاک تم‌ها:

• محدود کردن پالت رنگ و تایپوگرافی در theme.json به موارد ضروری
• استفاده از fluid برای Typography تطبیقی به‌جای Media Queryهای متعدد
• غیرفعال کردن بلاک‌هایی که استفاده نمی‌شوند
• استفاده از remove_theme_support() برای حذف قابلیت‌های غیرضروری
• بهینه‌سازی تصاویر با next/image معادل (در وردپرس، wp_get_attachment_image())

تجربه توسعه‌دهنده: از PHP به CSS و JSON

یکی از بزرگ‌ترین تغییرات در بلاک تم‌ها، تغییر نقش توسعه‌دهنده است. در قالب کلاسیک، توسعه‌دهنده یک برنامه‌نویس PHP بود که Templateها، Hookها، و منطق قالب را می‌نوشت. در بلاک تم، توسعه‌دهنده بیشتر یک مهندس CSS و JSON است که تنظیمات را تعریف می‌کند و بلاک‌های سفارشی می‌سازد.

این تغییر، چند پیامد دارد. اول، کاهش نیاز به PHP: بسیاری از کارهایی که قبلاً با PHP انجام می‌شد (مثل تعریف Layout، تنظیم رنگ‌ها، اضافه کردن Widget Area) حالا با theme.json و HTML Template انجام می‌شود. دوم، افزایش اهمیت CSS: توسعه‌دهنده باید CSS مدرن (Logical Properties، Container Queries، Nesting) را عمیقاً بشناسد. سوم، نیاز به دانش React: برای ساخت بلاک‌های سفارشی، توسعه‌دهنده باید React و پکیج‌های @wordpress/* را بشناسد.

اگر با قالب فرزند وردپرس چیست آشنا شده باشید، می‌دانید که در قالب کلاسیک، Child Theme یک راه استاندارد برای سفارشی‌سازی بود. در بلاک تم‌ها، Child Theme همچنان وجود دارد اما نقش آن کاهش یافته: بسیاری از سفارشی‌سازی‌ها با Global Styles و Style Variations انجام می‌شود، بدون نیاز به Child Theme.

ابزارهای توسعه بلاک تم

چند ابزار مهم برای توسعه بلاک تم:

• create-block-theme: افزونه رسمی وردپرس که از یک قالب کلاسیک، یک بلاک تم می‌سازد.
• Block Theme Generator: ابزارهای آنلاین برای تولید اسکلت بلاک تم.
• Theme Check Plugin: بررسی سازگاری بلاک تم با استانداردهای وردپرس.
• wp-env: محیط توسعه Docker برای تست بلاک تم.

افزونه create-block-theme به‌طور خاص جالب است: این افزونه یک قالب کلاسیک را تحلیل می‌کند و یک بلاک تم معادل می‌سازد، شامل theme.json، Templateها، و Template Parts. اگر با بررسی سازگاری قالب وردپرس با افزونه‌ها آشنا شده باشید، می‌دانید که ابزارهای سازگاری در مهاجرت نقش کلیدی دارند.

مسیر مهاجرت از قالب کلاسیک به بلاکی

مهاجرت از قالب کلاسیک به بلاکی یک تصمیم مهم است که باید با برنامه‌ریزی انجام شود. سه رویکرد اصلی وجود دارد:

رویکرد اول: بازنویسی کامل. ساخت یک بلاک تم از صفر با theme.json و Templateهای HTML. این رویکرد، بیشترین کنترل را می‌دهد اما زمان‌بر است. مناسب پروژه‌هایی که می‌خواهند از پایه با معماری جدید شروع کنند.

رویکرد دوم: تبدیل تدریجی. استفاده از افزونه create-block-theme برای تبدیل قالب موجود به بلاک تم، سپس بهینه‌سازی تدریجی. این رویکرد، سریع‌تر است اما ممکن است بدهی فنی از قالب کلاسیک به ارث برسد.

رویکرد سوم: قالب ترکیبی. استفاده از یک بلاک تم پایه (مثل Twenty Twenty-Four) و سفارشی‌سازی آن با Child Theme و theme.json. این رویکرد، تعادل بین سرعت و کنترل را فراهم می‌کند.

نکته مهم در مهاجرت، حفظ محتوا است. اگر قالب کلاسیک شما از Custom Fields یا Page Builder استفاده می‌کند، این داده‌ها باید به بلاک‌های معادل تبدیل شوند. ابزارهایی مثل Block Migration و Convert to Blocks می‌توانند در این فرآیند کمک کنند.

«مهاجرت به بلاک تم، یک پروژه فنی نیست؛ یک پروژه سازمانی است که نیازمند هماهنگی تیم محتوا، تیم طراحی، و تیم توسعه است.»

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

اکوسیستم قالب‌های بلاکی در WordPress.org

اکوسیستم بلاک تم‌ها در WordPress.org در حال رشد سریع است. از سال ۲۰۲۲ که Twenty Twenty-Two منتشر شد، تعداد بلاک تم‌ها در مخزن رسمی از چند ده به بیش از ۵۰۰ قالب رسیده است. این رشد، نشان‌دهنده پذیرش سریع این معماری توسط جامعه توسعه‌دهندگان است.

چند بلاک تم محبوب در مخزن رسمی:

• Twenty Twenty-Four: قالب پیش‌فرض وردپرس، با پشتیبانی کامل از FSE
• Twenty Twenty-Five: جدیدترین قالب پیش‌فرض با Style Variations متعدد
• Astra Block Theme: نسخه بلاکی قالب محبوب Astra
• Ollie: بلاک تم مدرن با تمرکز بر سرعت
• Ona: بلاک تم تجاری از تیم Yoast

نکته مهم این است که وردپرس از سال ۲۰۲۲ به‌صورت رسمی اعلام کرده که بلاک تم‌ها مسیر اصلی توسعه هستند. تیم قالب‌های وردپرس (Themes Team) در WordPress.org اعلام کرده که از سال ۲۰۲۵، تمام قالب‌های جدید ارسالی به مخزن باید بلاک تم باشند. این تصمیم، مسیر آینده را روشن می‌کند.

اگر با تفاوت قالب رایگان و پولی وردپرس آشنا شده باشید، می‌دانید که در اکوسیستم بلاک تم‌ها، این تفاوت‌ها ممکن است تغییر کنند. چون بسیاری از قابلیت‌های ظاهری از طریق theme.json و Global Styles در دسترس هستند، تمایز بین قالب رایگان و پولی بیشتر بر پایه بلاک‌های سفارشی و Templateهای پیش‌ساخته خواهد بود.

پرسش‌های پرتکرار درباره قالب‌های بلاکی

آیا قالب‌های کلاسیک به‌طور کامل منقرض می‌شوند؟

خیر، حداقل در کوتاه‌مدت. وردپرس به سمت بلاک تم‌ها حرکت می‌کند اما قالب‌های کلاسیک برای سال‌های زیادی پشتیبانی خواهند شد. دلیل این موضوع، حجم عظیم سایت‌هایی است که بر پایه قالب‌های کلاسیک ساخته شده‌اند. وردپرس متعهد به سازگاری است و نمی‌تواند میلیون‌ها سایت فعال را بدون مسیر مهاجرت رها کند. با این حال، توسعه قالب‌های کلاسیک جدید در آینده کاهش خواهد یافت و انرژی نوآوری به سمت بلاک تم‌ها متمرکز می‌شود.

آیا بلاک تم‌ها برای همه پروژه‌ها مناسب هستند؟

خیر. بلاک تم‌ها برای اکثر پروژه‌های محتوایی، وبلاگ، سایت شرکتی و فروشگاه مناسب هستند. اما برای پروژه‌هایی که نیاز به ساختار بسیار پیچیده یا کاملاً سفارشی دارند (مثل پلتفرم‌های SaaS، مارکت‌پلیس‌های پیچیده، یا اپلیکیشن‌های وبی)، ممکن است قالب کلاسیک یا معماری Headless مناسب‌تر باشد. اگر با اتصال وردپرس به Next.js آشنا شده باشید، می‌دانید که در این معماری، وردپرس فقط به‌عنوان CMS عمل می‌کند و لایه نمایش جداگانه است.

چگونه بلاک تم خود را بسازم؟

سه گام اصلی: اول، یک پوشه قالب در wp-content/themes/my-block-theme/ بسازید و style.css با هدر قالب را اضافه کنید. دوم، فایل theme.json را با تنظیمات اولیه بسازید. سوم، پوشه‌های templates/ و parts/ را ایجاد کنید و فایل‌های HTML مناسب را اضافه نمایید. ابزار create-block-theme می‌تواند این فرآیند را سریع‌تر کند. برای آشنایی بیشتر، ساخت بلاک سفارشی گوتنبرگ از صفر نقطه شروع خوبی است.

آیا بلاک تم‌ها بر SEO تأثیر منفی دارند؟

خیر، حتی می‌توانند SEO را بهبود دهند. HTML سمنتیک، ساختار Heading صحیح، و بهینه‌سازی Core Web Vitals در بلاک تم‌ها ساده‌تر است. اگر با بهترین قالب‌های وردپرس برای سئو آشنا شده باشید، می‌دانید که انتخاب قالب مناسب، یکی از عوامل کلیدی در SEO فنی است.

تفاوت Sync Pattern و Reusable Block چیست؟

Sync Pattern (که قبلاً Reusable Block نامیده می‌شد) یک بلاک است که در چندین صفحه استفاده می‌شود و تغییر آن، تمام نمونه‌ها را به‌روزرسانی می‌کند. Sync Pattern در FSE به‌عنوان بخشی از Synced Patterns مدیریت می‌شود و قابلیت‌های بیشتری دارد: امکان تعریف Override برای بعضی Attributeها، پشتیبانی از Template Parts، و مدیریت متمرکز در Site Editor.

آیا می‌توانم از بلاک‌های سفارشی در بلاک تم استفاده کنم؟

بله، و این یکی از مزایای بلاک تم‌هاست. بلاک‌های سفارشی که با registerBlockType ساخته می‌شوند، در ویرایشگر گوتنبرگ و Site Editor قابل استفاده هستند. برای ساخت بلاک سفارشی، به ساخت بلاک سفارشی گوتنبرگ مراجعه کنید.

چگونه از بلاک تم در محیط Production استفاده کنم؟

قبل از استقرار، سه چیز را بررسی کنید: اول، سازگاری با افزونه‌های ضروری (مثل WooCommerce، Yoast، و فرم‌سازها). دوم، عملکرد Core Web Vitals با ابزارهایی مثل Lighthouse و PageSpeed Insights. سوم، تست دسترس‌پذیری طبق WCAG. اگر با دسترس‌پذیری در بلاک‌های وردپرس آشنا شده باشید، می‌دانید که دسترس‌پذیری یکی از معیارهای کلیدی کیفیت قالب است.

آیا بلاک تم‌ها با WooCommerce کار می‌کنند؟

بله، WooCommerce از نسخه ۸ به بعد پشتیبانی کامل از بلاک تم‌ها و FSE را اضافه کرده است. Templateهای WooCommerce مثل single-product.html، archive-product.html و cart.html در بلاک تم‌ها قابل ویرایش هستند. با این حال، برخی افزونه‌های جانبی WooCommerce هنوز سازگاری کامل ندارند.

آیا بلاک تم‌ها برای سایت‌های چندزبانه مناسب هستند؟

بله، با WPML یا Polylang. Templateها و Template Parts می‌توانند برای هر زبان ترجمه شوند. Global Styles نیز می‌تواند برای هر زبان تنظیمات متفاوتی داشته باشد. اگر با چگونه وردپرس چندزبانه استفاده کنیم آشنا شده باشید، این انعطاف‌پذیری را به‌عنوان یک مزیت می‌شناسید.

نگاه راهبردی به آینده قالب‌های وردپرس

آینده قالب‌های وردپرس به سمت بلاک تم‌ها حرکت می‌کند، اما این حرکت تدریجی و تکاملی است. سه روند اصلی قابل پیش‌بینی است:

روند اول، افزایش قدرت FSE. در نسخه‌های آینده وردپرس، FSE قابلیت‌های بیشتری خواهد داشت: پشتیبانی کامل از Custom Post Typeها در Template Editor، امکان تعریف Queryهای پیچیده‌تر، و ابزارهای طراحی پیشرفته‌تر. این تحول، فاصله بین بلاک تم‌ها و Page Builderها را کاهش می‌دهد.

روند دوم، همگرایی با Block Bindings و Data Sources. Block Bindings که در وردپرس ۶.۵ معرفی شد، به بلاک‌ها اجازه می‌دهد داده‌های خارجی را نمایش دهند. در آینده، این قابلیت گسترش خواهد یافت و بلاک‌ها می‌توانند به منابع داده متنوعی متصل شوند: Custom Fields، Metadata، REST APIهای خارجی، و حتی دیتابیس‌های خارجی. این تحول، بلاک تم‌ها را به یک پلتفرم داده‌محور تبدیل می‌کند.

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

تحلیل سطح معماری

از منظر معماری نرم‌افزار، بلاک تم‌ها یک نمونه جالب از Declarative Theming هستند: به‌جای نوشتن کد برای ساخت ساختار (Imperative)، ساختار را با بلاک‌ها توصیف می‌کنید (Declarative). این تغییر پارادایم، مزایای روشنی دارد: کاهش پیچیدگی، افزایش خوانایی، و جداسازی بهتر بین ساختار، ظاهر، و محتوا. اما چالش‌هایی نیز دارد: کاهش کنترل دقیق بر خروجی HTML، نیاز به دانش CSS پیشرفته‌تر برای سفارشی‌سازی، و وابستگی به APIهای گوتنبرگ که هنوز در حال تکامل هستند.

در مقیاس بزرگ — مثلاً یک آژانس طراحی که ده‌ها سایت با بلاک تم می‌سازد — مدیریت Theme.json، Style Variations، و Template Parts نیازمند یک استراتژی مشخص است. الگوی رایج، استفاده از Design Tokens در theme.json و Atomic Design در ساخت Patternهاست. اگر با طراحی معماری وب مقیاس‌پذیر آشنا شده باشید، این رویکردها را به‌عنوان بخشی از بلوغ مهندسی می‌شناسید.

چالش دیگر، Versioning و Sync است. وقتی یک بلاک تم در چند محیط (توسعه، Staging، Production) استفاده می‌شود، Sync بین تغییرات دیتابیس (Global Styles، Site Editor) و فایل‌های قالب (theme.json، Templateها) نیازمند یک Workflow مشخص است. Developer Mode که قبلاً ذکر شد، یکی از راه‌حل‌های این چالش است. راه‌حل دیگر، استفاده از Synced Patterns برای محتوای قابل بازاستفاده و Template Parts برای ساختار است.

در نهایت، بلاک تم‌ها یک Evolution هستند، نه یک Revolution. آن‌ها قالب کلاسیک را حذف نمی‌کنند، بلکه یک لایه انتزاعی جدید اضافه می‌کنند که در بسیاری از سناریوها کارآمدتر است. توسعه‌دهندگانی که این لایه را درک کنند و آن را در Workflow خود ادغام نمایند، در آینده نزدیک مزیت رقابتی خواهند داشت.

اگر این تحول را در یک پروژه واقعی تجربه کرده‌اید، جالب است بدانید کدام بخش از بلاک تم‌ها بیشترین چالش را ایجاد کرد. تجربه خودتان را در دیدگاه‌ها بنویسید؛ به‌خصوص اگر راه‌حل دیگری پیدا کرده‌اید که می‌تواند برای خواننده بعدی مفید باشد. 🧱

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