ویرایش کامل سایت وردپرس؛ گوتنبرگ، Block Theme و مهاجرت

فعال‌کردن یک Block Theme روی سایت زنده می‌تواند در چند ثانیه هدر، منو، Template آرشیو و استایل‌های سراسری را عوض کند؛ اما بازگرداندن یک فروشگاه قدیمی با Shortcode، Widget و Page Builder لزوماً به همان سادگی نیست. تصمیم میان گوتنبرگ، Site Editor، قالب کلاسیک و صفحه‌ساز باید بر اساس محتوای موجود، مهارت تیم، Performance واقعی و هزینه مهاجرت گرفته شود، نه وعده «بدون کدنویسی» یا «سرعت قطعی».

پاسخ کوتاه: برای یک سایت محتوایی جدید که Design system مشخص و نیازهای استاندارد دارد، Block Theme و Site Editor معمولاً Shortlist خوبی هستند. برای سایت کلاسیک یا Page Builder فعال، مهاجرت کامل فقط وقتی توجیه دارد که Inventory، Prototype و Regression test نشان دهند سود نگهداری و عملکرد از هزینه تبدیل بیشتر است. می‌توان Block Editor را داخل قالب کلاسیک نگه داشت و مرحله‌ای جلو رفت؛ انتخاب الزاماً صفر و یک نیست.

Snapshot نسخه: این مقاله در ۶ اوت ۲۰۲۶ بازبینی شده است. در این تاریخ WordPress 7.0.1 نسخه پایدار اعلام‌شده و ۷.۱ در Roadmap برای ۱۹ اوت برنامه‌ریزی شده است؛ بنابراین قابلیت‌های نسخه آینده را Production-ready فرض نمی‌کنیم. Core، Gutenberg plugin، Theme و افزونه‌ها را با نسخه دقیق محیط خود روی Staging آزمایش کنید.

گوتنبرگ، Block Editor، FSE و Site Editor چه تفاوتی دارند؟

این اصطلاح‌ها در گفتگوهای وردپرس اغلب به‌جای هم استفاده می‌شوند، اما دامنه متفاوتی دارند:

طبق مستندات رسمی Site Editor، این رابط فقط با Block Theme فعال می‌شود. در مقابل، استفاده از Block Editor برای محتوای نوشته‌ها به Block Theme وابسته نیست؛ یک قالب کلاسیک هم می‌تواند تجربه Block-based مناسبی داشته باشد.

Block Theme چه چیزی را تغییر می‌دهد؟

قالب کلاسیک معمولاً Templateهای PHP، functions.php، Widget area، Menus و Customizer دارد. Block Theme ساختار اصلی را با فایل‌های HTML بلوکی، Template part، Pattern و theme.json تعریف می‌کند. کاربر می‌تواند بخش‌هایی مثل Header، Footer، Single، Archive و ۴۰۴ را در Site Editor ویرایش کند.

Template و Template Part

Template چیدمان یک نوع صفحه است؛ مثلاً Single post یا Search result. Template Part بخش تکرارشونده مانند Header یا Footer است. تغییر یک Template می‌تواند تعداد زیادی URL را هم‌زمان تحت‌تأثیر قرار دهد؛ بنابراین دسترسی، Revision، QA و Rollback برای آن مهم‌تر از ویرایش یک نوشته است.

Global Styles و Style Variation

رنگ، Typography، فاصله، Layout و Style بلوک‌ها را می‌توان در سطح Theme تعریف کرد و برای سایت Variation ساخت. این قابلیت زمانی ارزشمند است که Design token مشخص داشته باشید؛ آزادی نامحدود به هر نویسنده معمولاً به ناهماهنگی بصری منجر می‌شود.

Navigation و Query Loop

Navigation block منو و Query Loop فهرست محتوا را می‌سازند. انعطاف آن‌ها بالا است، اما تغییر Route، Query، Pagination یا ساختار Heading باید با SEO، Accessibility و Cache تست شود. «قابل‌ویرایش بودن» به‌معنای «بی‌خطر بودن تغییر» نیست.

الگوها؛ نام Reusable Block دیگر دقیق نیست

از WordPress ۶.۳، اصطلاح قدیمی Reusable Block به Synced Pattern تغییر کرده است. سه سناریو را جدا کنید:

Pattern Overrides از WordPress ۶.۶ مسیر ساخت تجربه Curated را گسترش داده است. پیش از استفاده گسترده، پشتیبانی Blockهای موردنیاز، رفتار Update و دسترسی Editor را روی نسخه واقعی سایت آزمایش کنید.

آیا گوتنبرگ و FSE همیشه سریع‌ترند؟

خیر. Core block و Block Theme سبک می‌توانند خروجی کم‌هزینه‌ای بسازند، اما نوع Editor به‌تنهایی Core Web Vitals را تعیین نمی‌کند. Theme، Block pack، فونت، تصویر، Script ثالث، WooCommerce، Cache، Hosting و نحوه ساخت صفحه مهم‌اند. یک Block Theme با چند مجموعه Block و Animation می‌تواند از یک قالب کلاسیک مهندسی‌شده سنگین‌تر باشد.

مزیت‌های بالقوه معماری Block

• استفاده از theme.json برای Style و Preset به‌جای CSS پراکنده؛
• امکان بارگذاری Style مرتبط با Block و کاهش Asset غیرضروری؛
• کاهش نیاز به بعضی افزونه‌های Layout؛
• Markup قابل‌پیش‌بینی‌تر در Core blockهای ساده؛
• Design token مشترک میان Editor و Frontend.

مستندات Global Settings & Styles توضیح می‌دهد که theme.json چگونه Setting و Style را مدیریت می‌کند و می‌تواند از بارگذاری CSS تکراری بکاهد؛ اما این مزیت به پیاده‌سازی Theme و Block وابسته است.

منابع رایج Bloat

• نصب چند Block library با قابلیت هم‌پوشان؛
• CSS سراسری بزرگ برای بلوک‌هایی که در صفحه نیستند؛
• JavaScript، Slider، Animation و Popup بدون Budget؛
• DOM عمیق ناشی از Group/Columns تودرتو؛
• Font family/weight متعدد و فونت فارسی بدون Subset مناسب؛
• تصویر Hero بزرگ، Embed و Tag manager؛
• Query Loop سنگین و Query دیتابیس بدون Cache.

Performance را با چه چیزی بسنجیم؟

مقایسه یک Demo خالی FSE با سایت واقعی Elementor نتیجه معنادار نمی‌دهد. دو Prototype هم‌ارز با محتوا، تصاویر، فونت، Analytics، فرم و تعداد Component یکسان بسازید.

راهنمای رسمی WordPress Performance نیز Hosting، Theme، Plugin، تصویر، Cache و Database را عوامل هم‌زمان می‌داند. برای اجرای Cache و عیب‌یابی نسخه قدیمی، راهنمای کش وردپرس را ببینید.

تعداد افزونه معیار Performance نیست

عبارت «افزونه کمتر همیشه سریع‌تر است» دقیق نیست. یک افزونه کوچک Admin-only می‌تواند اثر Frontend نداشته باشد و یک افزونه واحد صدها KB Script یا Query سنگین اضافه کند. برای هر Plugin یا Block pack این موارد را بسنجید:

• Asset در کدام Route و برای کدام Block بارگذاری می‌شود؟
• Query، Cron، Autoloaded option و External call دارد؟
• اگر حذف شود چه Markup، Shortcode یا Data باقی می‌ماند؟
• Update، Security history، Support و Compatibility چگونه است؟
• آیا قابلیت آن با Core یا بسته دیگری تکراری است؟

مدل TCO و Provenance در راهنمای قالب و افزونه رایگان یا Premium برای انتخاب Block library نیز قابل‌استفاده است.

تجربه نویسنده؛ آزادی بیشتر همیشه UX بهتر نیست

کاربر مبتدی ممکن است با Selection بلوک تودرتو، List View، Template/Content context و Global change اشتباه کند. از طرف دیگر، Pattern و کنترل‌های محدودشده می‌توانند انتشار را سریع و یکدست کنند. کیفیت تجربه به «طراحی محیط ویرایش» وابسته است.

Curated editing

• Palette، Font size و Spacing را به Tokenهای تأییدشده محدود کنید؛
• برای صفحه‌های پرتکرار Pattern و Starter layout بسازید؛
• Layoutهای حساس را Lock یا Content-only کنید؛
• نام Pattern و Block را فارسی و قابل‌فهم نگه دارید؛
• Role نویسنده، طراح و توسعه‌دهنده را تفکیک کنید؛
• راهنمای کوتاه و مثال واقعی داخل Workflow بدهید.

آزمون کاربردپذیری Editor

پنج کار واقعی مانند ساخت مقاله، تعویض تصویر، افزودن CTA، اصلاح منو و بازگردانی اشتباه تعریف کنید. Success rate، زمان، خطا و درخواست کمک را ثبت کنید. مقاله تست کاربردپذیری روش طراحی Task و تحلیل مشکل را توضیح می‌دهد.

theme.json؛ Design system یا محل Override جدید؟

theme.json می‌تواند رنگ، Typography، spacing، layout، Style عناصر و قابلیت‌های هر Block را تعریف کند. نسخه Schema باید با Core هدف هماهنگ باشد؛ مستندات Trunk ممکن است قابلیتی داشته باشند که نسخه Production هنوز ندارد.

{
  "$schema": "https://schemas.wp.org/trunk/theme.json",
  "version": 3,
  "settings": {
    "color": {
      "custom": false,
      "palette": [
        { "slug": "brand", "color": "#2457d6", "name": "Brand" }
      ]
    },
    "typography": {
      "customFontSize": false
    }
  }
}

این نمونه جهت معماری است؛ Schema و Propertyها را برای نسخه Pin‌شده بررسی کنید. Token را ابتدا در Figma/CSS/Brand source تعریف و سپس mapping کنید. اگر کاربر در Site Editor Override پایگاه‌داده‌ای بسازد، فایل Theme و ظاهر زنده ممکن است از هم فاصله بگیرند؛ Export، Source of truth و Change policy لازم است.

Specificity و منبع Style را مدیریت کنید

Style می‌تواند از Core، Theme، Style variation، Block، Plugin و User customization بیاید. وقتی تیم بدون قاعده میان theme.json، CSS سفارشی، Inline style و Plugin جابه‌جا می‌شود، Debug و Migration دشوار می‌شود.

Block Theme، Classic Theme یا Hybrid؟

چه زمانی Block Theme انتخاب قوی است؟

• سایت جدید یا Redesign واقعی دارید؛
• صفحات بر Component و Pattern تکرارشونده بنا می‌شوند؛
• تیم می‌تواند Theme، Block و Update را نگه‌داری کند؛
• افزونه‌های حیاتی با Site Editor و Templateهای لازم سازگارند؛
• آزادی Editor با Governance متعادل می‌شود.

چه زمانی مهاجرت کامل را عقب بیندازیم؟

• Page builder هزاران صفحه و Dynamic template کنترل می‌کند؛
• WooCommerce، Membership یا LMS به Hook/Template خاص متکی است؛
• Inventory محتوای Shortcode/Widget/Custom field ندارید؛
• Staging واقع‌گرایانه یا Rollback قابل‌اعتماد ندارید؛
• هدف فقط «امتیاز PageSpeed» است اما Bottleneck از Theme نیست.

مقایسه با Elementor، Divi و سایت‌ساز SaaS

هیچ برنده مطلقی وجود ندارد. Page Builder ممکن است Widget و Workflow بالغ‌تری برای تیم فعلی داشته باشد؛ Block system ممکن است وابستگی کمتر و Design governance بهتری بدهد. سایت‌ساز SaaS مسئولیت Hosting و Update را کم می‌کند اما Export، Integration و Lock-in متفاوتی دارد.

عبارت «وردپرس مالکیت کامل می‌دهد» نیز نیاز به دقت دارد: نرم‌افزار و Database در کنترل شماست، اما Font، CDN، Plugin SaaS، Analytics و License می‌توانند وابستگی بیرونی بسازند.

SEO در Block Theme

Google برای استفاده از Gutenberg امتیاز جداگانه نمی‌دهد. اثر SEO از خروجی HTML، قابلیت Crawl، URL، Metadata، لینک، Structured data، Performance و کیفیت محتوا می‌آید.

• در هر Template یک H1 منطقی و Heading hierarchy درست بسازید؛
• Query Loop و Pagination را Crawlable و Canonical را درست نگه دارید؛
• Archive، Search و ۴۰۴ را پس از تغییر Template بررسی کنید؛
• Alt تصویر، Caption و Link text را در Pattern فراموش نکنید؛
• Schema افزونه SEO و Theme را برای Duplicate یا Missing تست کنید؛
• DOM تودرتو، Lazy loading و Hero/LCP را با داده بسنجید.

چک‌لیست سئو داخلی را روی Template نمونه و حداقل ده URL از هر نوع اجرا کنید.

Accessibility و RTL

Core block نقطه شروع است، نه تضمین WCAG. Color contrast، Focus، ترتیب Heading، Keyboard navigation، Label فرم و Announcement تعاملی به ترکیب Theme، Block و Content وابسته‌اند.

موارد فارسی و راست‌به‌چپ

• Navigation، Submenu، Icon direction و Keyboard را در RTL تست کنید؛
• ترکیب متن فارسی/لاتین، عدد، کد، URL و قیمت را بررسی کنید؛
• فونت فارسی را با Weight واقعی و Fallback مناسب بارگذاری کنید؛
• Line height و طول سطر را برای خوانایی فارسی تنظیم کنید؛
• جدول، Breadcrumb، Pagination و فرم آدرس را روی موبایل بسنجید؛
• Editor و Frontend را هر دو با زبان fa_IR آزمایش کنید.

Phase ۳ و Multilingual؛ Roadmap را قابلیت موجود ندانید

Roadmap رسمی WordPress می‌گوید Phase ۳ با تمرکز بر Collaboration و Workflow در جریان است. Phase ۴ برای Multilingual در نقشه بلندمدت قرار دارد. این یعنی نباید Real-time collaboration کامل یا چندزبانه بومی را صرفاً بر اساس Roadmap به Proposal مشتری اضافه کرد.

• قابلیت موردنیاز را روی Stable release و بدون Gutenberg plugin آزمایشی Verify کنید؛
• برای Editorial workflow، Lock، Revision، Approval و Notification فعلی را مستند کنید؛
• برای چندزبانه، Plugin/Architecture موجود، URL، hreflang و Translation workflow لازم است؛
• Projected date را Contract یا برنامه مهاجرت قطعی ندانید.

Governance برای تیم محتوایی

Site Editor می‌تواند تغییر سراسری را برای افراد بیشتری ممکن کند. این قدرت بدون Role design و Change process ریسک دارد.

مهاجرت از Classic Theme یا Page Builder

Switch Theme تنها مرحله آخر است. ابتدا Dependency و هزینه تبدیل را بفهمید.

۱. Inventory

• نوع URL: Home، Page، Post، Archive، Product، Cart/Checkout، Account و ۴۰۴؛
• Page builder template، Shortcode، Widget، Custom field و Custom post type؛
• Header/Footer/Menu، Hook، Snippet و Child theme override؛
• Pluginهای فرم، SEO، Cache، فروشگاه، عضویت و ترجمه؛
• فونت، Icon، Script ثالث و Analytics؛
• صفحات پرترافیک/درآمدزا و URLهای Organic.

۲. Dependency map و Exit test

یک کپی Staging بسازید و افزونه Builder را موقتاً غیرفعال کنید: چه Markup یا Shortcode باقی می‌ماند؟ Content قابل‌استخراج است؟ Dynamic template و Form data کجاست؟ این آزمون Lock-in را از حدس به شاهد تبدیل می‌کند.

۳. Design token و Component map

رنگ، Typography، spacing، container و Componentهای پرتکرار را تعریف کنید. هر Widget را به Core block، Pattern، Custom block یا Plugin منتخب map کنید. برای قابلیت کم‌استفاده Custom block نسازید.

۴. Vertical slice

یک مسیر کامل و کم‌ریسک انتخاب کنید: مثلاً Landing page، فرم و Thank-you. آن را با Block Theme بسازید و Frontend، Editor، Analytics، SEO، Accessibility و عملیات را هم‌زمان تست کنید.

۵. Pilot و انتشار مرحله‌ای

ابتدا URLهای کم‌ریسک، سپس Templateهای عمومی و در پایان صفحات درآمدزا را منتقل کنید. Redirect فقط وقتی URL واقعاً تغییر می‌کند. Sitemap، Canonical، Structured data، Event tracking و Cache را بعد از هر Wave Verify کنید.

۶. Rollback

Backup فایل/Database، فهرست تغییرات، Snapshot Theme، معیار توقف و زمان بازگشت مشخص باشد. تغییر Template در Database و فایل Theme هر دو در Scope بازیابی قرار گیرند. برای Workflow کامل، راهنمای Staging، تست و Rollback وردپرس را دنبال کنید.

Test matrix پیش از Go-live

ملاحظات عملی برای سایت ایرانی

هاست و مسیر کاربر

Performance را از شبکه داخل ایران و چند اپراتور بسنجید. TTFB، Cache و اندازه Asset را جدا کنید؛ تغییر Editor مشکل CPU ضعیف، Database کند یا CDN بدپیکربندی را حل نمی‌کند.

فونت فارسی و مجوز

فونت را Self-host یا از منبع پایدار و مجاز ارائه کنید، Weightهای استفاده‌نشده را حذف و Preload را فقط برای فایل واقعاً LCP اعمال کنید. فونت خارجی می‌تواند با اختلال یا محدودیت دسترسی تجربه را خراب کند.

دسترسی به License و Update

Block pack یا Builder خارجی ممکن است برای فعال‌سازی، دانلود Template یا Update به سرویس بیرونی وابسته باشد. Update path، Mirror مجاز، Backup و خروج را پیش از خرید بررسی کنید؛ نسخه Nulled راه‌حل ریسک دسترسی نیست.

فروشگاه و درگاه

Theme switch می‌تواند Hook، Fragment، Cache exclusion یا Styling Checkout را تغییر دهد. خرید موفق/ناموفق، بازگشت درگاه، Coupon، حمل‌ونقل، ایمیل و موبایل RTL در Gate انتشار باشند.

Scorecard انتخاب معماری ویرایش

به هر گزینه از ۱ تا ۵ امتیاز دهید و امتیاز را به Evidence لینک کنید. یک Gate بحرانی مانند خراب‌شدن Checkout یا نبود Rollback با مجموع امتیاز بالا جبران نمی‌شود.

برنامه ۳۰روزه تصمیم‌گیری

هفته اول: Baseline

• Inventory URL، Template، Plugin و Content dependency؛
• اندازه‌گیری Performance و Editor workflow فعلی؛
• تعریف سه سناریوی کسب‌وکار و Gateها.

هفته دوم: Prototype

• ساخت Theme/Pattern حداقلی روی Staging؛
• تبدیل Home، Article و یک مسیر Conversion؛
• پیاده‌سازی Token و RTL.

هفته سوم: PoC و تست تیم

• Benchmark هم‌ارز، Accessibility و SEO؛
• Task test نویسنده و Admin؛
• Update/Restore و Exit test.

هفته چهارم: ADR و نقشه مهاجرت

• Scorecard، ریسک و TCO؛
• ثبت تصمیم در Architecture Decision Record؛
• Wave، Owner، Rollback و معیار توقف؛
• ثبت Debtهای پذیرفته‌شده با تاریخ بازبینی.

اگر مهاجرت برای اکنون توجیه ندارد، این هم یک تصمیم معتبر است. Debt و Trigger بازنگری را در دفتر بدهی فنی ثبت کنید.

اشتباه‌های رایج

• «Block Theme بدون کدنویسی است»: کاربر می‌تواند Layout را ویرایش کند، اما Theme حرفه‌ای، Integration و Custom block هنوز مهندسی می‌خواهند.
• «Core همیشه سریع‌تر است»: خروجی واقعی و Assetهای Third-party تعیین‌کننده‌اند.
• «FSE همه افزونه‌ها را حذف می‌کند»: Site Editor Layout را پوشش می‌دهد، نه CRM، پرداخت، Membership یا SEO کامل.
• «همه صفحات را یک‌باره تبدیل کنیم»: Big-bang دامنه Regression و Rollback را بزرگ می‌کند.
• «Roadmap یعنی قابلیت آماده»: Phase و تاریخ برنامه‌ریزی‌شده با Stable release فرق دارد.
• «آزادی بیشتر برای نویسنده بهتر است»: بدون Token، Lock و Pattern، Design drift و خطا بیشتر می‌شود.
• «Switch Theme محتوا را مهاجرت می‌دهد»: Shortcode، Widget، Template و Plugin data نیاز به Inventory دارند.

سوالات متداول گوتنبرگ و FSE

آیا FSE همان Site Editor است؟

FSE نام رایج مجموعه قابلیت‌های ویرایش کل سایت است؛ رابط فعلی WordPress با نام Site Editor شناخته می‌شود و با فعال‌بودن Block Theme در Appearance → Editor در دسترس است.

آیا Block Theme از Elementor سریع‌تر است؟

به‌صورت قطعی نه. یک پیاده‌سازی سبک Block می‌تواند Asset و DOM کمتری داشته باشد، اما Theme، Block pack، تصویر، فونت، Script و Hosting نتیجه را تعیین می‌کنند. فقط Benchmark دو Prototype هم‌ارز پاسخ معتبر می‌دهد.

برای استفاده از Block Editor باید قالب بلوکی نصب کنیم؟

خیر. Block Editor محتوا با قالب کلاسیک هم کار می‌کند. Block Theme برای Site Editor و ویرایش Block-based کل Templateها لازم است.

آیا باید سایت کلاسیک موجود را فوراً به FSE مهاجرت دهیم؟

خیر. اگر سایت پایدار، درآمدزا و وابسته به Builder/Templateهای خاص است، ابتدا Inventory، Exit test و Vertical slice بسازید. نگه‌داشتن قالب کلاسیک با Block Editor یا مهاجرت مرحله‌ای ممکن است کم‌ریسک‌تر باشد.

آیا WordPress اکنون چندزبانه و ویرایش هم‌زمان بومی کامل دارد؟

Roadmap رسمی می‌گوید Phase ۳ Collaboration در حال اجرا است و Multilingual در Phase ۴ قرار دارد. نیاز Production را با نسخه پایدار و افزونه/Workflow فعلی حل و قابلیت آینده را تضمین‌شده فرض نکنید.

جمع‌بندی

گوتنبرگ و Site Editor ابزارهای بالغ و مهمی در معماری وردپرس‌اند، اما ارزش آن‌ها زمانی آشکار می‌شود که با Design token، Pattern، Governance، Test و Rollback همراه باشند. برای سایت جدید، Block Theme را جدی ارزیابی کنید؛ برای سایت موجود، از Baseline و Prototype شروع کنید و فقط با Evidence مهاجرت کنید. اگر برای Inventory، PoC و نقشه مهاجرت WordPress به تصمیم مستقل نیاز دارید، درخواست مشاوره طراحی و توسعه وردپرس را ثبت کنید.