أهلاً بك يا صديقي في المحطة رقم 94 من رحلتنا المعمارية العميقة داخل نواة ووردبريس! لو كنت فاكر إن تطوير ثيمات ووردبريس لسه معتمد على ملف header.php وملف footer.php وحشر أكواد PHP داخل ملفات الـ HTML، فاسمح لي أقولك إن القطار اتحرك، والمشهد اتغير بالكامل. ووردبريس مع ظهور محرر الموقع بالكامل (Full Site Editing أو FSE) أحدثت ثورة جذرية وانتقلت من النموذج القديم (Classic Themes) إلى نموذج قوالب الكتل (Block Themes).

في هذا الدليل العملي المعمق، مش هنكتفي بسرد نظري؛ إحنا هنشرح معمارية الـ Block Theme تشريحاً جراحياً دقيقاً، هنشوف إزاي الكور بيفسر ملفات الـ HTML، إزاي شجرة الـ Templates و Template Parts بتتركب، إزاي ملف theme.json بقى هو العقل المدبر لكل خصائص التصميم، وهنبني مع بعض هيكل ثيم متكامل بأعلى معايير الأداء والإنتاجية مع كود وشرح تفصيلي ودراسة حالة حية من قلب السوق المصري!

الثورة المعمارية: وداعاً لـ PHP Spaghetti وأهلاً بالـ Declarative Templates

في الثيمات التقليدية (Classic Themes)، كان المتصفح بيستلم صفحة HTML ناتجة عن تنفيذ مئات الدوال الشرطية داخل PHP: if ( have_posts() ) : while ( have_posts() ) : the_post(); وملفات متناثرة زي sidebar.php و comments.php. لو العميل حب يغير موضع الـ Header أو ينقل اللوجو من اليمين للشمال، كان لازم المطور يفتح الكود ويعدل في الـ HTML والـ CSS، أو يتم بناء خيارات معقدة في الـ Customizer تبطئ الموقع وتخزن خيارات لا نهاية لها في جدول wp_options.

قوالب الكتل (Block Themes) غيرت الفلسفة دي 180 درجة إلى أسلوب الـ Declarative Templating. الثيم أصبح عبارة عن ملفات HTML نقية تحتوي على Block Grammar Comments (مثل <!-- wp:site-title /-->)، وملف تهيئة مركزي واحد بصيغة JSON هو theme.json. المحرر (Site Editor) بيقرأ هذه القوالب ويعرضها للمستخدم بطريقة WYSIWYG حقيقية بنسبة 100%، ولما المستخدم يعدل أي حاجة في الواجهة، التعديل بيتحفظ في قاعدة البيانات كـ Custom Post Type بدون المساس بملفات الكود الأصلية للثيم!

التشريح الجراحي لهيكل الـ Block Theme: المكونات والملفات الإلزامية

عشان ووردبريس يتعرف على الثيم كـ Block Theme حقيقي، في متطلبات بنيوية واضحة جداً. الملفات لم تعد ملفات PHP تنفيذية، بل مجلدات وهياكل قياسية كالتالي:

my-custom-block-theme/
├── style.css               # الترويسة التعريفية بالثيم (Theme Headers) وتنسيقات CSS الأساسية
├── theme.json              # العقل المدبر: إعدادات الألوان، الخطوط، التباعد، وأنماط الكتل
├── index.php               # ملف فارغ تماماً للأمان والتوافق العكسي (Fallback)
├── functions.php           # تسجيل الأنماط، الكتل الخاصة، ودعم الميزات (اختياري لكن مهم)
├── templates/              # قوالب الصفحات الكاملة بصيغة HTML
│   ├── index.html          # القالب الإلزامي الرئيسي
│   ├── single.html         # قالب تدوينة المقال الفردي
│   ├── page.html           # قالب الصفحات الثابتة
│   ├── archive.html        # قالب الأرشيف والتصنيفات
│   └── 404.html            # قالب صفحة الخطأ 404
├── parts/                  # أجزاء القوالب القابلة لإعادة الاستخدام (Template Parts)
│   ├── header.html         # رأس الموقع
│   ├── footer.html         # تذييل الموقع
│   └── sidebar.html        # الشريط الجانبي
└── patterns/               # الأنماط الجاهزة المسجلة تلقائياً بصيغة PHP أو HTML
    ├── hero-banner.php
    └── call-to-action.php

جدول المقارنة المعمارية: Classic Themes مقابل Block Themes

الجدول التالي بيلخص الفروق الجذرية بين معمارية الثيمات الكلاسيكية وقوالب الكتل الحديثة:

كيف يعمل Block Template Hierarchy في نواة WordPress Core؟

نواة ووردبريس ما زالت تحتفظ بنفس منطق التسلسل الهرمي للقوالب (Template Hierarchy) المعروف للمطورين، لكن مع تغيير مسار البحث عن الملفات:

1. أولاً: فحص قاعدة البيانات: يبحث ووردبريس أولاً عما إذا كان مدير الموقع قد قام بتعديل القالب وحفظه عبر محرر الموقع (Site Editor). يتم البحث في جدول wp_posts عن منشور بنوع wp_template أو wp_template_part يحمل نفس الـ Slug وحالته publish.
2. ثانياً: فحص قوالب الـ Block Theme في الملفات: إذا لم يجد نسخة مخصصة في قاعدة البيانات، ينتقل الكور إلى مجلد templates/ داخل الثيم للبحث عن ملف .html مطابق للتسلسل الهرمي القياسي (مثلاً: single-product.html ثم single.html ثم singular.html ثم index.html).
3. ثالثاً: السقوط الاحتياطي (Fallback): في حال عدم العثور على أي قالب كتل، يعود النظام إلى ملف index.html الإلزامي، وإذا لم يكن موجوداً يسقط على index.php الكلاسيكي.

كود عملي متقدم: بناء Block Theme جاهز للإنتاج من الصفر

تعال نبني مع بعض ملفات ثيم عملي احترافي يحقق أعلى معايير الجودة:

1. ملف style.css التعريفي

/*
Theme Name: Abozaid Cairo Block Theme
Theme URI: https://abozaid.net/block-theme
Author: Mohamed Abozaid
Author URI: https://abozaid.net
Description: قالب كتل متطور مصمم وفق أحدث معايير Full Site Editing في ووردبريس.
Version: 1.0.0
Requires at least: 6.5
Tested up to: 6.7
Requires PHP: 8.1
License: GNU General Public License v2 or later
License URI: http://www.gnu.org/licenses/gpl-2.0.html
Text Domain: abozaid-block
Tags: full-site-editing, block-patterns, custom-colors, custom-spacing, translation-ready
*/

/* تنسيقات تكميلية دقيقة لا يغطيها theme.json */
.az-custom-focus:focus-visible {
    outline: 2px solid var(--wp--preset--color--primary);
    outline-offset: 4px;
}

2. أجزاء القوالب: parts/header.html و parts/footer.html

    
    

        

        
محمد أبو زيد | WordPress Architect & Full-Stack Developer
        
    
    

3. القالب الرئيسي: templates/index.html

اطلب مشروعك الآن






    
    

        

            

            
معمارية قوالب الكتل: هيكل Block Theme ومصادر التخصيص
            
معمارية قوالب الكتل: Block Theme ينظم الموقع بقوالب وأجزاء مبنية من بلوكات، مع theme.json لإعدادات التصميم
اقرأ المزيد
            
نوفمبر 2, 2026
        

        
    
    

ملف theme.json: الجسر بين الكود ونظام التصميم العالمي (Design System)

الملف ده هو الجوهرة الحقيقية لـ Block Themes. من خلاله بتحدد لوحة الألوان (Color Palette)، مقاسات الخطوط (Font Sizes)، هوامش التباعد (Spacing Scale)، وكمان بتتحكم في الخصائص اللي يقدر مدير الموقع يعدلها في محرر جوتنبرج أو تمنعها عنه عشان تحافظ على اتساق الهوية البصرية.

{
    "$schema": "https://schemas.wp.org/trunk/theme.json",
    "version": 3,
    "settings": {
        "appearanceTools": true,
        "layout": {
            "contentSize": "840px",
            "wideSize": "1200px"
        },
        "color": {
            "custom": false,
            "palette": [
                {
                    "slug": "primary",
                    "color": "#0d9488",
                    "name": "أخضر تيل أساسي"
                },
                {
                    "slug": "contrast",
                    "color": "#0f172a",
                    "name": "كحلي داكن"
                },
                {
                    "slug": "base",
                    "color": "#ffffff",
                    "name": "أبيض نقي"
                }
            ]
        },
        "typography": {
            "fluid": true,
            "fontFamilies": [
                {
                    "fontFamily": "Cairo, sans-serif",
                    "name": "Cairo",
                    "slug": "cairo"
                }
            ]
        }
    },
    "styles": {
        "color": {
            "background": "var(--wp--preset--color--base)",
            "text": "var(--wp--preset--color--contrast)"
        },
        "typography": {
            "fontFamily": "var(--wp--preset--font-family--cairo)",
            "lineHeight": "1.75"
        }
    }
}

دراسة حالة حقيقية: تحويل متجر أثاث في دمياط إلى Block Theme

الوصايا العشر لمهندسي قوالب الكتل الحديثة

1. اجعل ملف theme.json مرجعك الأوحد: لا تكتب أكواد CSS يدوية لأمور يمكن تعريفها بسهولة في ملف theme.json مثل الألوان والهوامش ومقاسات الخطوط.
2. لا تحذف index.php أبداً: حتى في قوالب الكتل النقية بنسبة 100%، وجود ملف index.php فارغ يضمن حماية المجلد ويمنع أخطاء السقوط عند استعراض ملفات القالب.
3. اعتمد على Block Patterns بدلاً من القوالب الصلبة: أنماط الكتل (Patterns) تمنح العملاء مرونة رهيبة في إعادة استخدام التخطيطات بدون المساس بهيكل القالب الأساسي.
4. استخدم Semantic HTML Tags في الحاويات: احرص على تحديد "tagName": "header" أو "main" أو "aside" في كتل Group و Template Parts لدعم إمكانية الوصول (Accessibility).
5. فعّل خاصية Fluid Typography: اجعل نصوص موقعك تتكيف تلقائياً مع أحجام الشاشات المختلفة دون الحاجة لكتابة عشرات من الـ Media Queries اليدوية.
6. نظف صلاحيات المستخدم في محرر الكتل: أغلق الخيارات غير الضرورية (مثل Custom Colors) لمنع المحررين من تخريب الهوية البصرية المتفق عليها.
7. لا تضع أكواد منطق برمجية داخل templates HTML: ملفات الـ HTML داخل مجلد templates/ مخصصة لتمثيل الكتل فقط؛ أي معالجة PHP مكانها في functions.php أو إضافات مخصصة.
8. استخدم Dynamic Block Rendering عند الحاجة للبيانات الحية: إذا كان لديك عنصر يعتمد على جلسات المستخدم أو بيانات تتغير في كل ثانية، استخدم كتلة ديناميكية (Dynamic Block) وليس كتلة ثابتة.
9. افحص القوالب المحفوظة في قاعدة البيانات قبل النشر: تذكر أن التعديلات التي يجريها العميل في الـ Site Editor تُخزن في الـ DB ولن تظهر في ملفات Git الخاصة بك إلا إذا قمت بتصديرها أو مزامنتها.
10. اعتمد معايير WordPress Coding Standards: حافظ على وضوح الـ Block Grammar وتوثيق الأنماط لتسهيل الصيانة المستقبلية وتسليم المشروع للفرق التقنية.

القوالب الابنة في Block Themes وتقنية Block Hooks API الثورية

واحدة من أعظم التطورات اللي حصلت في ووردبريس 6.4 وما بعدها هي إمكانية بناء قوالب ابنة (Child Themes) تعتمد فقط على ملف theme.json دون الحاجة لكتابة سطر PHP واحد! في النموذج الكلاسيكي، كنت مضطر تعمل Child Theme وتنسخ ملفات ضخمة عشان تغير لون زرار أو حجم خط. في الـ Block Themes، تقدر تعمل مجلد جديد يحتوي على:

• ملف style.css يشير إلى الـ Template الأب عبر Template: parent-theme-slug.
• ملف theme.json فرعي يقوم بعمل دمج وراثي (Inheritance Merge)؛ يعني بتكتب فيه فقط القيم اللي عايز تغيرها، ونواة ووردبريس تدمجها أوتوماتيكياً مع إعدادات القالب الأب مع أسبقية للقالب الابن.

مش بس كده، ووردبريس قدمت ميزة ثورية اسمها Block Hooks API (المعروفة سابقاً بـ Auto-inserting Blocks). الفكرة دي بتشبه فكرة الـ Action Hooks في PHP، لكنها مخصصة للكتل في قوالب الكتل! تخيل إنك بتطور إضافة تسويق أو زر إعجاب، وعايز الكتلة بتاعتك تظهر تلقائياً بعد كتلة core/post-content أو قبل core/comments في كل صفحات الموقع بدون ما تطلب من المستخدم يفتح محرر الموقع ويضيفها يدوي!

// functions.php أو ملف الإضافة المخصصة
add_filter( 'hooked_block_types', function( $hooked_blocks, $position, $anchor_block, $context ) {
    // عايزين نحقن بلوك شريط التنبيهات المخصص قبل الهيدر في القالب الرئيسي
    if ( 'core/template-part' === $anchor_block && 'before' === $position ) {
        // نتحقق من أن الجزء المستهدف هو الهيدر
        if ( isset( $context['attributes']['slug'] ) && 'header' === $context['attributes']['slug'] ) {
            $hooked_blocks[] = 'abozaid/emergency-top-alert';
        }
    }
    return $hooked_blocks;
}, 10, 4 );

الكود ده بيوضح إزاي نواة ووردبريس أثناء عملية تحليل الـ Block Templates بتفحص الخطافات البرمجية، وتحقن الكتلة ديناميكياً في شجرة الـ DOM. ده بيعطي مطوري الإضافات في مصر والعالم العربي قوة غير مسبوقة لبناء حلول تتكامل بنعومة متناهية مع أي Block Theme حديث دون كسر تصميم العميل.

دورة حياة معالجة القالب (Template Resolution Lifecycle) خلف الكواليس

لما الزائر يفتح صفحة مقال، الكور بينفذ الخطوات التالية بدقة متناهية: 1. استدعاء ملف template-loader.php. 2. الدالة locate_block_template() بتفحص إذا كان في كتل معرفة لهذا الرابط. 3. الدالة _get_block_template_file() بتحدد الملف الفيزيائي في الثيم أو السجل المخصص في جدول المنشورات. 4. الدالة do_blocks() بتستلم شجرة الـ HTML الناتجة وتبدأ تحللها عبر Block Parser. 5. استدعاء كل Render Callbacks للكتل الديناميكية، ودمج أنماط Global Styles المجمعة من theme.json داخل وسم <style id="wp-block-theme-inline-css"> في رأس الصفحة. 6. تسليم وثيقة HTML خفيفة وصاروخية للمتصفح في أجزاء من الثانية!

استراتيجيات الاختبار والاعتماد البرمجي لقوالب الكتل قبل النشر في الإنتاج

عشان تضمن إن قالب الكتل بتاعك خالي من الأخطاء العميقة، بننصح باتباع مصفوفة اختبار ثلاثية المحاور: أولاً، فحص سلامة ملف theme.json عبر أدوات الـ JSON Schema ومطابقته مع مستودع ووردبريس الرسمي للتأكد من عدم وجود خواص مكتوبة بطريقة خاطئة أو ألوان ناقصة. ثانياً، فحص التوافقية العكسية عبر تفعيل الإضافات الشائعة مثل WooCommerce و Yoast SEO والتأكد من أن كتل المحتوى والحقول المخصصة تظهر في أماكنها الطبيعية دون تشويه في الـ CSS Grid أو Flexbox Layouts. ثالثاً، قياس واختبار مؤشرات الأداء الحيوية (Core Web Vitals) باستخدام أدوات Lighthouse و PageSpeed Insights على أجهزة موبايل حقيقية بشبكات 4G متوسطة، والتأكد من بقاء مؤشر Cumulative Layout Shift (CLS) عند الصفر المطلق ومؤشر LCP تحت 1.2 ثانية.