معمارية ووردبريس: رحلة الطلب وحدود مسؤولية Core والقالب والإضافة

تعال يا صديقي نقعد قعدة رايقة ونتكلم في أساس كل حاجة في ووردبريس؛ الأساس اللي لو فهمته صح، هتتحول من مجرد مبرمج بيكتب كود وخلاص، لمهندس برمجيات حقيقي فاهم كل ذرة في السيستم بتتحرك إزاي وبتروح فين! عمرك سألت نفسك قبل كدة: في اللحظة اللي الزائر بيكتب فيها رابط موقعك في شريط المتصفح ويدوس Enter، إيه اللي بيحصل بالضبط ورا الكواليس في أجزاء من الألف من الثانية؟ الطلب بيمشي إزاي؟ ومين أول ملف بيرد عليه؟ ومين بيحمل قواعد البيانات؟ ومين بيحدد المقال ده هيتعرض بـ قالب عامل إزاي؟ والأهم من كل ده: إيه هو الخط الفاصل اللي بيفصل بين مسؤولية نواة ووردبريس (Core)، ومسؤولية القالب (Theme)، ومسؤولية الإضافة (Plugin)؟

الخلط بين التلاتة دول هو السبب رقم واحد في 90% من الكوارث والمصايب اللي بنشوفها في المواقع؛ تلاقي عميل يقرر يغير شكل القالب بتاعه، يتفاجئ إن كل المنتجات، والكورسات، وبيانات العقارات طارت واختفت من لوحة التحكم! ليه؟ لأن المطور اللي بنى الموقع حط بيانات الشغل ومنطق العمل (Business Logic) جوة ملف functions.php بتاع القالب، فلما القالب اتغير، الموقع كله اتهد! في الدليل الهندسي العملي ده، هنفكك رحلة الطلب بالكامل بالعامية المصرية ومن الصفر، وهنرسم خريطة حدود واضحة وصارمة لكل طرف في المنظومة، عشان شغلك يفضل عايش وسريع ومستقر لسنين طويلة قدام.

1. قصة رحلة الطلب (The Request Lifecycle): من زرار Enter لحد شاشة الزائر

تعال نتخيل إن السيرفر ده عامل زي “مجمع حكومي فائق السرعة والتنظيم”، وكل ما زائر يطلب صفحة، بيعدي على مكاتب وأقسام متسلسلة بدقة ميكانيكية رهيبة:

1. المحطة الأولى: موظف الاستقبال (خادم الويب Nginx أو Apache): أول ما الطلب يوصل السيرفر، خادم الويب بيبص على الرابط؛ لو كان ملف صورة ثابتة (مثل logo.png) بيبعتها فوراً للزائر من غير ما يشغل PHP خالص. طب لو الرابط طالب مقال أو صفحة في ووردبريس؟ هنا خادم الويب بياخد الطلب ويسلمه فوراً لنقطة الدخول الرئيسية للنظام: ملف index.php في الجذر الرئيسي.
2. المحطة الثانية: المفتاح السحري (wp-blog-header.php): ملف index.php مش بيعمل حاجة غير إنه بيستدعي ملف wp-blog-header.php، والملف ده بدوره بيعمل 3 حاجات حاسمة بترتيب صارم:
   • أولاً: بيحمل ملف التمهيد والتشغيل الأساسي wp-load.php.
   • ثانياً: بيشغل كائن ووردبريس العام عبر استدعاء wp() لمعالجة الرابط والاستعلامات.
   • ثالثاً: بيشمل ملف تحميل القالب وطبقة العرض عبر wp-includes/template-loader.php.
3. المحطة الثالثة: غرفة العمليات الكبرى (wp-config.php & wp-settings.php): هنا بقى بيبدأ السحر الحقيقي؛ ووردبريس بيقرأ إعدادات الاتصال بقاعدة البيانات، وبيحدد مسار الجداول والملح الأمني (Salts)، وبعدها بيدخل على ملف wp-settings.php اللي بيبني كل الكائنات المركزية للنظام.

2. مراحل الإقلاع والتمهيد (WordPress Bootstrap Phases)

عشان نكتب كود صح، لازم نعرف الترتيب الزمني اللي ووردبريس بيحمل بيه مكوناته في الذاكرة. الترتيب ده مفيش فيه هزار، وبيحدد إمتى تقدر تستخدم دوال معينة وإمتى هتلاقي خطأ Fatal Error لو استدعيتها بدري عن وقتها:

3. الحدود الصارمة للمسؤولية: مين بيعمل إيه؟ وليه الخلط جريمة برمجية؟

بص يا هندسة، ووردبريس قايم على مبدأ معماري اسمه فصل الاهتمامات (Separation of Concerns). المثلث الذهبي لووردبريس بيتكون من تلات أضلاع، وكل ضلع له وظيفة مقدسة مينفعش يتعداها:

1. نواة ووردبريس (WordPress Core): البنية التحتية والمحرك

النواة هي الحكومة الفيدرالية للموقع؛ مسؤولة عن نظام الحسابات والمستخدمين والصلاحيات، إدارة قاعدة البيانات، معالجة الروابط الدائمة (Permalinks)، واجهة برمجة التطبيقات REST API، نظام التحديثات التلقائية، ومحرك التخزين المؤقت. قاعدة ذهبية لا تتغير: ملفات النواة خط أحمر لا يُلمس ولا يُعدل فيه سطر واحد أبداً.

2. القالب (Theme): المظهر وطبقة العرض فقط (Presentation Layer)

وظيفة القالب واحدة فقط لا غير: “إزاي المحتوى ده هيظهر لعين الزائر بأفضل شكل وأسرع أداء”. القالب مسؤول عن الألوان، والخطوط، والمسافات عبر theme.json، وتخطيط الهيدر والفوتر والسايد بار عبر ملفات الـ HTML في مجلد templates/، وتنسيقات CSS وتأثيرات الجافاسكريبت. القالب مش مسؤول أبداً عن تسجيل أنواع محتوى جديدة ولا إضافة ميزات وظيفية مستقلة عن التصميم.

3. الإضافة (Plugin): الوظائف ومنطق العمل والمحتوى (Business Logic & Data)

وظيفة الإضافة هي: “الموقع ده بيعمل إيه وبيقدم إيه للعميل كخدمة”. الإضافة هي المسؤولة عن تسجيل أنواع المنشورات المخصصة (Custom Post Types مثل: دورة تدريبية، عقار، إعلان)، وتسجيل التصنيفات (Taxonomies)، وربط بوابات الدفع، وإرسال إشعارات الواتساب والبريد، وإدارة الحقول المخصصة. كل الميزات دي لازم تكون في إضافة؛ بحيث لو العميل قرر بعد سنتين يغير تصميم موقعه ويجيب قالب جديد تماماً، كل الكورسات والبيانات والعملاء بتوعه يفضلوا موجودين وشغالين بنسبة 100% ومن غير ما يفقد حرف واحد!

4. أمثلة عملية: كود كارثي ضد كود هندسي محترف

عشان تشوف الفرق بنفسك، تعال نبص على سيناريو تسجيل نوع منشور مخصص لكورسات الأكاديمية (Course Post Type):

الكود الكارثي (وضعه داخل functions.php في القالب):

// ❌ كود سيء جداً داخل wp-content/themes/my-theme/functions.php
// الكارثة: لو العميل غير القالب، كل الكورسات هتختفي من لوحة التحكم فوراً!
add_action('init', function() {
    register_post_type('course', [
        'public' => true,
        'label'  => 'الدورات التدريبية',
        'supports' => ['title', 'editor', 'thumbnail']
    ]);
});

الكود الهندسي الصح (وضعه داخل إضافة مخصصة):

<?php
/**
 * Plugin Name: Abozaid Academy Core Engine
 * Description: المسؤولة الحصرية عن منطق العمل وتسجيل الكورسات والبيانات المستقلة عن القالب.
 * Version: 1.0.0
 * Author: Mohamed Abozaid
 */

// ✅ كود احترافي سليم داخل wp-content/plugins/abozaid-core/abozaid-core.php
namespace AbozaidCore;

if (!defined('ABSPATH')) exit;

class CourseArchitecture {
    public static function init() {
        add_action('init', [__CLASS__, 'registerCoursePostType']);
    }

    public static function registerCoursePostType() {
        register_post_type('course', [
            'public'       => true,
            'label'        => 'الدورات التدريبية',
            'has_archive'  => true,
            'show_in_rest' => true, // دعم محرر Gutenberg وميزة Block Bindings
            'supports'     => ['title', 'editor', 'thumbnail', 'custom-fields', 'excerpt'],
            'menu_icon'    => 'dashicons-welcome-learn-more'
        ]);
    }
}
CourseArchitecture::init();

5. سحر محرك الروابط (WP_Rewrite) والاستعلام الرئيسي (Main WP_Query)

من أروع الأجزاء المعمارية في ووردبريس هي كيفية تحويل رابط جميل ومفهوم للبشر (مثل: abozaid.local/courses/gutenberg/) إلى استعلام SQL دقيق في قاعدة البيانات. العملية دي بتمر بخطوتين هندسيتين:

1. تحليل الرابط (Request Parsing): كائن WP_Rewrite بياخد الرابط ويطابقه مع مئات القواعد التعبيرية (Regex Rules) المخزنة في خيار rewrite_rules. أول ما يلاقي تطابق، بيحول الرابط إلى متغيرات استعلام داخلية (Query Variables)، فيتحول الرابط لـ: course=gutenberg&post_type=course.
2. بناء وتنفيذ الاستعلام الرئيسي (The Main Query): كائن WP_Query الرئيسي بيستلم هذه المتغيرات، وبيترجمها فوراً لاستعلام SQL محسوب بدقة على جدول wp_posts، وبيجلب المقال المطلوب مع تحضير الكاش التلقائي للبيانات الوصفية والتصنيفات، ويخزن النتيجة داخل المتغير العام $wp_query.

6. آلية توجيه القوالب (Template Loader) وعصر قوالب الكتل الحديث

بعد ما الاستعلام الرئيسي ينتهي ويعرف البيانات اللي رجعت، ييجي دور ملف template-loader.php. الملف ده بيفحص نتيجة الاستعلام ويسأل نفسه شوية أسئلة منطقية:

• هل النتيجة دي مقال فردي؟ (is_single()) إذن يدور على single.html.
• هل النتيجة صفحة ثابتة؟ (is_page()) إذن يدور على page.html.
• هل النتيجة أرشيف تصنيف؟ (is_archive()) إذن يدور على archive.html.
• طب لو ملقاش أي حاجة من دول أو الرابط مش موجود أصلاً؟ (is_404()) إذن يوجه فوراً لـ 404.html.

في قوالب الكتل المعاصرة (Block Themes)، المحمل مش بيبص على ملفات PHP قديمة، بل بيبحث مباشرة في مجلد templates/ عن ملفات الـ HTML النقية، ويقوم محرك النواة Gutenberg بتصيير كتلها ودمج الترويسة والسايد بار والفوتر في جزء من الألف من الثانية وبأعلى درجات الكفاءة.

7. دراسة حالة واقعية: كارثة منصة عقارية وتصحيح المعمارية

خليني أحكيلك على كارثة واقعية اشتغلت على إنقاذها لشركة تسويق عقاري كبرى في القاهرة. الشركة كانت دافعة مبالغ ضخمة لمطور عشان يبني موقع لإدارة كمبوندات وفلل التجمع وزايد. المطور عمل إيه؟ اشترى قالب تجاري تقيل، وكتب كل أكواد تسجيل الفلل والشقق والحقول المخصصة في ملف functions.php بتاع القالب.

بعد سنتين من الشغل، وتخزين أكتر من 15,000 وحدة عقارية، الشركة قررت تعمل Re-branding وتغير شكل الموقع بقالب أحدث وأسرع. بمجرد ما فعلوا القالب الجديد، الموقع دخل في حالة شلل تام: لوحة العقارات اختفت بالكامل، الروابط كلها بقت تدي 404، والمبيعات وقفت تماماً لمدة 48 ساعة وسط حالة ذعر من الإدارة!

التدخل الهندسي السريع لعلاج المشكلة اعتمد على:

1. فصل كافة كلاسات الـ Custom Post Types والـ Taxonomies فوراً من القالب القديم ونقلها لإضافة مخصصة ومستقلة real-estate-core-plugin.
2. إعادة توليد وتحديث قواعد الروابط الدائمة (Flushing Rewrite Rules) لتعود كافة صفحات العقارات للعمل فوراً.
3. بناء قالب كتل Block Theme خفيف وسريع يعتمد فقط على عرض البيانات وتنسيقها دون التدخل في منطق العمل.

الدرس المستفاد اللي لازم يفضل محفور في دماغك: القوالب للمظهر فقط، والإضافات للوظائف والبيانات دائماً وأبداً!

8. إيه اللي بيحصل لما الطلب يكون جاي من تطبيق موبايل عبر REST API؟

طب يا هندسة، لو الطلب اللي جاي مش من متصفح عادي عايز صفحة HTML، بل جاي من تطبيق موبايل فلاتر (Flutter) أو React Native أو تطبيق Next.js طالب بيانات منتجات عبر ووردبريس REST API (زي الرابط ده: /wp-json/wp/v2/courses)؟ إيه اللي بيتغير في رحلة الطلب؟

هنا النواة بتعمل حركة ذكية جداً لتوفير موارد السيرفر:

1. الطلب بيمشي في نفس مسار التمهيد الأولي (Bootstrapping) لحد ما يوصل لخطاف parse_request.
2. ووردبريس بيكتشف إن البادئة هي wp-json، فبيعرف فوراً إن ده طلب API وليس طلب صفحة ويب.
3. يقوم خادم REST الداخلي (WP_REST_Server) بالتدخل، وبيعمل “تخطي كامل” (Bypassing) لملف template-loader.php! يعني ووردبريس مش بيحمل ملفات القالب نهائياً ولا بينفذ أكواد الـ HTML، مما يوفر أكثر من 60% من وقت المعالجة والذاكرة!
4. بيتم توجيه الطلب إلى الكنترولر المسؤول (مثلاً: WP_REST_Posts_Controller)، ويجلب البيانات من قاعدة البيانات، ويمررها على فلاتر الحماية، ويحولها إلى كائن JSON نقي ويبعتها لتطبيق الموبايل فوراً.

9. تشريح الكائن الأسطوري: كلاس WP ودواله الخمس المحورية

في قلب النواة، في ملف wp-includes/class-wp.php، بيعيش كلاس عملاق اسمه WP. لما النواة بتستدعي دالة wp()، الكلاس ده بينفذ 5 وظائف بالمللي بترتيب عسكري حاسم:

1. $this->init(): بيقوم بتهيئة المستخدم الحالي (Current User) وصلاحياته، عشان النظام يعرف مين اللي فاتح الصفحة (زائر عادي ولا أدمن ولا عميل).
2. $this->parse_request(): بيطابق الرابط بقواعد الـ Rewrite ويستخرج متغيرات الاستعلام وينقيها من أي محاولات اختراق.
3. $this->send_headers(): بيبعت ترويسات الـ HTTP للمتصفح (زي نوع المحتوى Content-Type: text/html، وإعدادات الكوكيز، وحالة التخزين المؤقت).
4. $this->query_posts(): بيشغل الاستعلام الرئيسي $wp_the_query->query($this->query_vars) لجلب محتويات الصفحة من MySQL.
5. $this->handle_404(): لو الاستعلام مرجعش أي داتا والرابط غلط، بيضبط حالة الصفحة تلقائياً لـ status_header(404) عشان جوجل يعرف إن الصفحة دي مش موجودة وميأرشفهاش غلط.

10. الهيكل المعماري لإضافة احترافية منظمة بـ OOP (Scaffold Template)

عشان نطبق كلامنا ده عملياً في مشاريعك الجاية، ده الهيكل المعماري الموصى به لتنظيم أي إضافة احترافية تبنيها لعميلك:

my-custom-plugin/
├── my-custom-plugin.php     (نقطة البداية والتعريف الأمني)
├── composer.json            (إدارة الحزم والمكتبات والـ Autoload)
├── includes/
│   ├── class-plugin-core.php  (محرك التهيئة وتسجيل الـ Hooks)
│   ├── class-post-types.php   (المسؤول عن تسجيل الـ CPT والـ Taxonomies)
│   ├── class-api-routes.php   (نقاط النهاية لـ REST API)
│   └── class-admin-ui.php     (لوحات التحكم والإعدادات الإدارية)
├── src/                     (أكواد كتل Gutenberg بـ React وJSX)
└── build/                   (الأكواد المجمعة النهائية الجاهزة للإنتاج)

بالشكل ده، كودك بقى مفصول ومنظم جداً، أي مبرمج تاني يشتغل وراك هيفهم كل ملف بيعمل إيه في ثواني معدودة، وهتضمن إن موقع عميلك مستقر وقابل للتوسع والترقية بسهولة لسنين وسنين.

11. إزاي تتعامل مع عميل عايز تعديل “ترقيع” يكسر المعمارية دي؟

كتير من المطورين لما بيبدأوا يشتغلوا كفريلانسرز، بيجيلهم عميل يقوله: “يا هندسة، إحنا مستعجلين، ادخل بس حط الكود ده في أي حتة وخليها تشتغل النهاردة والصبح يحلها ربنا!”. لو وافقت على الكلام ده، إنت اللي هتشيل الليلة لما الموقع يقع بعد شهر، والعميل هيرجع يلومك إنت مش هيفتكر إنه كان مستعجل!

المهندس الشاطر بيتعلم “فن إقناع العميل”: بتفهمه بكل هدوء إن الطريقة السريعة الغلط دي هتوقعه في خسائر مادية وتعطل مبيعاته بعدين، وإن الطريقة الهندسية الصح عبر عمل إضافة مخصصة (Site-Specific Plugin) مش هتاخد أكتر من ربع ساعة زيادة، بس هتوفر عليه وعلى شركته آلاف الدولارات في المستقبل وهتحمي بياناته للأبد. العميل لما يلاقيك خايف على مصلحته ومستقبل بيزنِسه، هيحترمك جداً وهيثق فيك ويديك مشاريع تانية وتالتة.

12. فحص رحلة الطلب عملياً عبر متصفح Chrome (DevTools Network Tab)

عشان تتأكد إن كل حاجة شغالة تمام في موقعك، افتح أي صفحة في متصفح جوجل كروم، واضغط F12 للدخول لأدوات المطورين، وروح لتبويب Network واعمل تحديث للصفحة:

• بص على أول طلب في القائمة (طلب المستند الرئيسي Document): هتلاقي حالة الاستجابة 200 OK، وزمن الـ TTFB (وقت معالجة ووردبريس على السيرفر). لو الزمن ده أقل من 200ms، اعرف إن معماريتك وكاشك شغالين بنجاح 100%.
• بص على ترويسات الاستجابة (Response Headers): هتتأكد من وجود ترويسات الأمان زي X-Content-Type-Options: nosniff وترويسات الكاش Cache-Control.
• راجع عدد طلبات الـ CSS وJS اللي تحتها: اتأكد إن مفيش إضافات محملة ملفات مش مستخدمة في الصفحة دي، عشان تحافظ على أعلى نتيجة في اختبارات Google PageSpeed.

الأسئلة الشائعة بالعامية المصرية حول معمارية ووردبريس (FAQ)

إليك إجابات شافية وكافية على أكثر الأسئلة المعمارية اللي بتبعتوها لي دائماً:

المصادر والمراجع الفنية الرسمية المعتمدة

تم إعداد هذا التوثيق المعماري بالاستناد إلى أدلة التطوير الرسمية لنواة ووردبريس ومجتمع المهندسين العالمي: