أهلاً بك يا بطل في المحطة رقم 99 من رحلتنا المعمارية الاستثنائية في عالم ووردبريس! لما بتدخل على لوحة التحكم وتضغط على Appearance > Editor، بيفتح قدامك تطبيق ويب متكامل ومبهر مبني بالكامل بـ React، بيسمح لك تتنقل بين صفحات موقعك، وتعدل الهيدر، الفوتر، القوالب، أنماط الألوان والخطوط، وتشوف كل ده لايف قدام عينك!

لكن هل سألت نفسك يوماً كمهندس برمجيات: “إيه اللي بيحصل تحت الكبوت بالظبط لما المحرر ده يفتح؟ إزاي المتصفح بيعزل الـ CSS عشان ما يبوظش لوحة تحكم ووردبريس؟ إزاي لما بتضغط ‘Save’ بيتم حفظ عدة كيانات برمجية في نفس اللحظة (Multi-entity Saving)؟ وإزاي قاعدة البيانات بتسجل التعديلات دي كمنشورات مخصصة بدون ما تلمس ملفات الثيم الأصلية؟”. في هذا الدليل المعمق، هنشرح Site Editor Internals تشريحاً جراحياً دقيقاً، هنفكك دورة حياة الطلب عبر REST API، وهنشوف دراسة حالة واقعية لحل كارثة في بوابة توظيف كبرى بالمعادي مع كود عملي و 20 سؤالاً وجواباً متقدماً!

المعمارية العامة: كيف تم بناء Site Editor كتطبيق Single Page App؟

محرر الموقع (Site Editor) ليس مجرد صفحة إدارة تقليدية في ووردبريس؛ بل هو Single Page Application (SPA) متكامل يتم تحميله عبر الحزمة البرمجية @wordpress/edit-site. عندما يفتح المدير صفحة المحرر، يتم تنفيذ تسلسل إقلاع دقيق:

1. تحميل واجهة التوجيه (Client-Side Router) التي تتيح التنقل السلس بين تصفح القوالب (Templates)، الأنماط (Patterns)، الصفحات (Pages)، والأنماط العامة (Styles) دون إعادة تحميل الصفحة (No Full-Page Reload).
2. تهيئة مستودعات بيانات Redux المدمجة في ووردبريس (core/edit-site و core).
3. إرسال طلبات متوازية عبر wp.apiFetch إلى نهايات REST API لجلب بيانات القالب النشط، الأنماط، ومحتوى ملفات الـ HTML من السيرفر.

بيئة العرض المنعزلة: معمارية الـ Canvas Iframe وتجنب تلوث الأنماط

أكبر مشكلة واجهت مطوري ووردبريس في بداية مشروع Gutenberg كانت “تلوث الـ CSS”: أنماط لوحة التحكم الخاصة بـ wp-admin كانت تتداخل مع أنماط القالب، وكان الخط أو الزرار يظهر في المحرر بشكل مختلف تماماً عن شكله في الواجهة الأمامية للزائر!

لحل هذه المشكلة المعمارية، قام فريق النواة بعزل مساحة التحرير بالكامل داخل Iframe معزول (Isolated Canvas). داخل هذا الـ Iframe:

• يتم تحميل وثيقة HTML مستقلة تماماً لا تتأثر بأي CSS قادم من لوحة تحكم ووردبريس.
• يتم حقن أنماط الـ Global Styles الناتجة عن theme.json، وخطوط الويب المخصصة، وتنسيقات القالب بدقة متطابقة بنسبة 100% مع بيئة الإنتاج الحية.
• يتم ربط أحداث الماوس ولوحة المفاتيح عبر جسر برمجي (Event Bridge) بين الوثيقة الرئيسية والـ Iframe لتمكين السحب والإفلات (Drag and Drop) وتحديد الكتل بسلاسة فائقة.

نموذج التخزين في قاعدة البيانات: تشريح wp_template و wp_template_part

عندما يقوم المستخدم بإجراء أي تعديل على قالب في محرر الموقع ويضغط “Save”، أين تذهب هذه البيانات؟ ووردبريس لا يلمس ملفات الكود في مجلد القالب إطلاقاً! بدلاً من ذلك، يستخدم نموذج تخزين مدمج في جدول wp_posts:

• سجلات القوالب (post_type = 'wp_template'): يتم إنشاء منشور مخصص لكل قالب معدل. يحمل حقل post_name معرف القالب (Slug) مثل single أو archive، ويحمل حقل post_content كود الـ Block Grammar المعدل بالكامل.
• سجلات الأجزاء (post_type = 'wp_template_part'): يتم إنشاء منشور مخصص لكل جزء معدل مثل header أو footer.
• علاقة التصنيف والتخصيص (Taxonomy Relationship): لضمان عدم اختلاط تعديلات ثيم بثيم آخر، يقوم ووردبريس بربط كل سجل بتصنيف تكسونومي غير مرئي اسمه wp_theme، حيث تكون قيمة الـ Term هي اسم القالب النشط (Theme Slug). عندما تغير القالب إلى ثيم آخر، تختفي التعديلات تلقائياً، ولو رجعت للقالب القديم، تعود التعديلات للظهور فوراً!

جدول المقارنة المعمارية: Theme Customizer مقابل Post Editor مقابل Site Editor

دورة الحفظ متعدد الكيانات (Multi-entity Saving Pipeline) عبر REST API

واحدة من أعظم الميزات الهندسية في الـ Site Editor هي Multi-entity Saving. تخيل أنك فتحت صفحة مقال داخل محرر الموقع، وغيرت لوجو الموقع في الهيدر، وعدلت نصاً في جسم المقال، وغيرت لون الروابط في الـ Global Styles، ثم ضغطت على زر “Save” الأزرق.

المحرر لن يحفظ عشوائياً، بل يفتح لك نافذة منبثقة أنيقة تعرض لك قائمة الكيانات التي تغيرت (Entities Changed): 1. جزء القالب: Header (سجل wp_template_part). 2. المقال: Single Post (سجل post). 3. الأنماط العامة: Global Styles (سجل wp_global_styles).

عندما تضغط تأكيد، يقوم مستودع core بإطلاق عدة طلبات متزامنة أو متتالية عبر مسارات REST API المخصصة:

• POST /wp/v2/templates/{id}
• POST /wp/v2/template-parts/{id}
• POST /wp/v2/global-styles/{id}

تتم معالجة كل طلب عبر الـ REST Controller المقابل (مثل WP_REST_Templates_Controller)، ويتم فحص الصلاحيات الأمنية لكل كيان على حدة والتأكد من مطابقة المعايير قبل كتابة البيانات في قاعدة البيانات!

محرك المراجعات وإعادة التعيين (Revisions & Clear Customizations)

ماذا لو قام مدير الموقع بتعديل القالب وأفسد التخطيط بالكامل، وأراد العودة للتصميم الأصلي المبرمج في ملفات الثيم؟ ووردبريس يوفر آليتين معماريتين للإنقاذ:

1. محرك المراجعات (Template Revisions): كل عملية حفظ للقالب تنشئ نسخة مراجعة في جدول wp_posts كـ inherit، تماماً مثل مراجعات المقالات، مما يتيح استعراض سجل التعديلات بالوقت والمحرر والعودة لأي نقطة سابقة.
2. إعادة التعيين التامة (Clear Customizations): من داخل محرر الموقع، يمكنك الضغط على “Clear Customizations”؛ فيقوم الكور بحذف سجل الـ CPT المقابل من جدول wp_posts فوراً! بمجرد حذف السجل، يسقط محرك البحث التلقائي (Template Hierarchy Fallback) على ملف الـ HTML الأصلي الموجود داخل مجلد القالب على السيرفر!

كود عملي متقدم: فحص وإدارة قوالب قاعدة البيانات برمجياً عبر PHP و WP-CLI

إليك كود برمجي احترافي يمكن استخدامه داخل إضافة صيانة أو سكربت CLI لفحص القوالب المخصصة في قاعدة البيانات ومعرفة ما إذا كانت تتطابق مع ملفات الثيم أو تم تعديلها:

/**
 * كود برمجي لفحص ومراجعة القوالب المعدلة في قاعدة البيانات مقارنة بملفات الثيم
 */
function abozaid_audit_database_templates() {
    $current_theme = get_stylesheet();

    // جلب كافة القوالب المعدلة والمحفوظة في قاعدة البيانات للقالب الحالي
    $db_templates = get_posts( array(
        'post_type'      => array( 'wp_template', 'wp_template_part' ),
        'post_status'    => 'publish',
        'posts_per_page' => -1,
        'tax_query'      => array(
            array(
                'taxonomy' => 'wp_theme',
                'field'    => 'slug',
                'terms'    => $current_theme,
            ),
        ),
    ) );

    $report = array();

    foreach ( $db_templates as $tmpl ) {
        // فحص وجود ملف أصلي للقالب في مجلدات الثيم
        $folder = ( 'wp_template_part' === $tmpl->post_type ) ? 'parts' : 'templates';
        $file_path = get_theme_file_path( $folder . '/' . $tmpl->post_name . '.html' );
        $has_source_file = file_exists( $file_path );

        $report[] = array(
            'ID'             => $tmpl->ID,
            'Name'           => $tmpl->post_name,
            'Type'           => $tmpl->post_type,
            'Has_Disk_File'  => $has_source_file ? 'نعم (يوجد ملف أصلي)' : 'لا (قالب مخصص تم إنشاؤه في المحرر فقط)',
            'Last_Modified'  => $tmpl->post_modified,
            'Author_ID'      => $tmpl->post_author,
        );
    }

    return $report;
}

دراسة حالة حقيقية: بوابة توظيف في المعادي وأزمة انهيار حفظ التعديلات

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

1. احرص على سلامة نهايات REST API: لا تعطل مسارات /wp/v2/templates أو template-parts في إضافات الأمان لأنها شريان حياة المحرر.
2. لا تعدل سجلات wp_template يدوياً في MySQL: دع ووردبريس يدير عمليات الحفظ والتشفير والتطهير عبر الـ API لمنع تلف البيانات.
3. صدّر التعديلات قبل ترقية القوالب الأساسية: إذا قمت بتعديل قوالب تابعة لثيم خارجي، صدّر تعديلاتك كملفات لتجنب فقدانها عند تحديث القالب.
4. استخدم خاصية Clear Customizations بأمان: تذكر أن زر إعادة التعيين يحذف السجل من قاعدة البيانات بشكل نهائي، فاحرص على أخذ نسخة احتياطية أولاً.
5. راقب حجم وسوم الـ Canvas Iframe: تأكد من أن القالب لا يقوم بتحميل مكتبات جافا سكريبت ضخمة وغير لازمة داخل مساحة الـ Iframe.
6. نظم صلاحيات التحرير المعمارية: لا تمنح صلاحية edit_theme_options للمحررين العاديين، واقصر الوصول إلى محرر الموقع على المهندسين المؤهلين.
7. افحص رسائل الـ Console في المتصفح بانتظام: أخطاء الجافا سكريبت في الـ Console هي أول مؤشر على وجود تعارضات بين الكتل في الـ Canvas.
8. حدد عدد مراجعات القوالب: اضبط حداً أقصى للمراجعات عبر WP_POST_REVISIONS لمنع تضخم جدول wp_posts بمراجعات القوالب القديمة.
9. احذر من تداخل أسماء الـ Slugs: لا تنشئ قالباً مخصصاً يحمل نفس اسم قالب قياسي إلا إذا كنت تقصد استبداله عمداً في التسلسل الهرمي.
10. اختبر الموقع على متصفحات مختلفة: تأكد من أن محرر الموقع يعمل بسلاسة على بيئات كروم وسفاري وفايرفوكس الحديثة دون مشاكل في الـ Iframe.

معمارية شجرة التراجعات (Undo/Redo History Stacks) في محرر الموقع

يا صديقي المهندس، واحدة من أكثر التجارب تعقيداً على مستوى الواجهة الأمامية هي توفير أزرار التراجع والإعادة (Undo/Redo) عندما يكون المستخدم يعدل عدة مكونات معاً داخل الـ Site Editor. فكر فيها للحظة: لو حركت كتلة في الهيدر، ثم غيرت لون زرار في المقال، ثم عدلت نص في الفوتر وضغطت Ctrl+Z، إزاي المحرر بيعرف يرجع الخطوة الأخيرة فقط بدون ما يلخبط باقي الكيانات؟

السر يكمن في مكتبة @wordpress/data وتحديداً في نظام History Reducers. محرر الموقع لا يقوم بعمل Snapshot لكامل وثيقة الـ DOM، لأن ذلك سيكون كارثياً على أداء الرام؛ بدلاً من ذلك، هو يسجل سلسلة إجراءات موجهة (Delta Actions). كل إجراء يحمل نوع التعديل، الكيان المستهدف (Entity Record)، والخاصية السابقة والجديدة. عندما تضغط تراجع، يتم عكس الـ Delta Action المقابلة فقط وتحديث متجر Redux دون المساس بباقي شجرة الكتل.

// تشريح مبسط لآلية تسجيل الـ Action Delta في متجر البيانات
const undoableAction = {
    type: 'core/edit-site/UPDATE_ENTITY_RECORD',
    kind: 'postType',
    name: 'wp_template_part',
    id: 'my-theme//header',
    changes: {
        content: '
محمد أبو زيد | WordPress Architect & Full-Stack Developer
',
    },
    previous: {
        content: '
محمد أبو زيد | WordPress Architect & Full-Stack Developer
',
    },
};

هذا التصميم الدقيق يجعل استهلاك الذاكرة في المتصفح محدوداً جداً حتى لو قام المستخدم بمئات العمليات والتعديلات المتتالية أثناء جلسة التصميم الطويلة.

استراتيجيات المزامنة المعمارية بين قاعدة البيانات ومستودع Git (CI/CD)

في الشركات الكبرى والمؤسسات، أكبر خطر هو قيام المطورين برفع تحديثات عبر Git تقوم بالكتابة فوق تعديلات حية قام بها مدير الموقع في قاعدة البيانات، أو العكس (Database overwriting Code). لحل هذا النزاع المعماري:

1. أتمتة فحص التباين (Diff Automation): بناء سكريبت في الـ Deployment Pipeline يقوم بمقارنة تواريخ تعديل ملفات templates/*.html مع حقل post_modified لسجلات wp_template في قاعدة البيانات.
2. تنبيهات التعارض (Conflict Warnings): في حال وجود تعديل أحدث في قاعدة البيانات، يقوم السكريبت بإيقاف النشر التلقائي وإرسال إشعار للمطور لمراجعة التعديلات ودمجها يدوياً.
3. أمر wp-cli للدمج الآمن: استخدام أوامر WP-CLI لتصدير القوالب المعدلة وحفظها كملفات Commit جديدة في مستودع الكود لضمان أن Git يظل دائماً هو المصدر النهائي للحقيقة (Single Source of Truth).

الاعتبارات الأمنية وصلاحية unfiltered_html في محرر الموقع

واحدة من أهم النقاط الأمنية في محرر الموقع هي كيفية معالجة الأكواد البرمجية المحقونة. ووردبريس يطبق قاعدة صارمة جداً: تعديل كود الـ Block Grammar في قوالب wp_template يتطلب امتلاك صلاحية unfiltered_html بالإضافة لصلاحية edit_theme_options. إذا لم يكن المستخدم يمتلك صلاحية الـ HTML غير المصفى (مثل المديرين في شبكات المواقع المتعددة Multisite)، يقوم معالج الـ REST API بفحص المحتوى وتجريد أي وسوم <script> أو <iframe> مريبة لمنع هجمات الاستيلاء على الحسابات وحماية زوار الموقع من أي اختراق أمني.

مستقبل Site Editor: التحرير التشاركي المباشر (Real-time Collaboration)

وفق خارطة طريق مشروع Gutenberg للمرحلة الثالثة (Phase 3: Collaboration)، فإن محرر الموقع يستعد لدعم التحرير التشاركي اللحظي المتزامن بين عدة مستخدمين، تماماً كما هو الحال في Google Docs و Figma. سيعتمد هذا التطور على تقنيات الـ WebSockets وبروتوكولات CRDT (Conflict-free Replicated Data Types)، مما سيسمح لعدة مطورين ومصممين في مصر والعالم بالعمل معاً في نفس القالب في آن واحد ورؤية مؤشرات الماوس والتعديلات لحظة بلحظة دون أي تعارضات في الحفظ أو تضارب في البيانات.