متى تلجأ إلى WordPress بنمط headless (ومتى لا تفعل)

WordPress بنمط headless — أي إبقاء WordPress بيئةً للتحرير وعرض الواجهة الأمامية بأداة مثل Next.js — هو المعمارية الأكثر طلبًا والأكثر ندمًا عليها بين ما يُطرح علينا. وهو فعلًا الجواب الصحيح أحيانًا. لكنه في الأغلب فاتورة كبيرة مقابل فوائد كان بوسع الفريق الحصول عليها بطريقة أخرى.

وفيما يلي الإطار الذي نستخدمه فعلًا حين يسألنا عميل.

ما الذي تكسبه فعلًا

• نموذج مكوّنات حقيقي. React وخصائص (props) مُنمَّطة بالأنواع ونظام تصميم مشترك مع بقية المنتج. إذا كان ينبغي أن يتطابق الموقع التسويقي مع التطبيق، فهذه أقوى حجة في القائمة.
• تحكم في العرض. توليد ثابت، وإعادة تحقق تدريجية، وتخزين مؤقت على الحافة لكل مسار، بدلًا من إضافة تخزين مؤقت للصفحات تضبطها وتأمل أن تعمل.
• قابلية التركيب. يمكن للواجهة الأمامية أن تسحب من WordPress وواجهة API للتجارة الإلكترونية ونظام DAM وفهرس بحث، وتقدّمها كمنتج واحد. أما القالب (theme) فيقاومك في كل خطوة هنا.
• سطح هجوم أصغر على الحافة العامة. المصدر الذي يحتفظ بمحتواك ليس هو المصدر الذي يخدم زيارات موقعك.

ما الذي يكلّفه فعلًا

هذه هي التكاليف التي تستهين بها الفرق، مرتبةً بحسب ترتيب إيلامها عادةً.

1. 01المعاينة لم تعد مجانية. في القالب، المعاينة مجرد رابط. أما مع headless فهي مسار لجلب المسودات بمصادقة، له معالجته الخاصة للرموز (tokens) وقواعده الخاصة للتخزين المؤقت وأعطاله الخاصة. يلاحظ المحررون ذلك من اليوم الأول، وهو أكبر مصدر احتكاك بعد الإطلاق.
2. 02كل إضافة تُخرج HTML تتوقف عن العمل. النماذج والمعارض ومخرجات SEO والمقالات ذات الصلة وشرائط ملفات تعريف الارتباط. الإضافة تنتمي إلى طبقة القالب؛ وأنت الآن تتولى مهمتها بنفسك. خصّص ميزانية لإعادة تنفيذ كل واحدة منها.
3. 03يصبح Gutenberg مشكلتك. تُصدر الكتل شيفرة HTML وCSS. وفي headless، إما أن تحلّل HTML الكتل في الواجهة الأمامية، أو تربط كل كتلة بمكوّن React وتُبقي الاثنين متزامنين إلى الأبد.
4. 04نشران، وبيئتا تشغيل، وسطحان للمناوبة. قد تحتاج تعديلات المحتوى الآن إلى خطّاف إعادة تحقق (revalidation hook) كي تظهر. وحين لا يظهر شيء، يمر مسار تتبّع الخلل عبر نظامين.
5. 05يفقد المحررون عقد WYSIWYG. ما يرونه في المحرر لم يعد ما يُنشر، ما لم تستثمر تحديدًا في إبقائهما متطابقين.

القرار، بالترتيب الذي نطرحه به

1. هل الواجهة الأمامية تطبيق بحق؟

لوحات تحكم بمصادقة، ومُهيِّئات، وبيانات آنية، وتدفقات معقدة متعددة الخطوات — إذا كان الموقع تطبيقًا تلحق به مقالات، فالأرجح أن headless هو الصحيح. أما إذا كان موقعًا تسويقيًا مع مدونة، فالأرجح أنه ليس كذلك.

2. هل يأتي المحتوى من أكثر من مصدر؟

نظام إدارة محتوى واحد وموقع واحد وجمهور واحد هو الحالة التي يتعامل معها القالب على أفضل وجه. وما إن تبدأ بدمج WordPress مع PIM أو واجهة تجارة إلكترونية خلفية أو مصدر وثائق منفصل، حتى تثبت طبقة التركيب جدواها.

3. هل يوجد نظام تصميم React بالفعل؟

إذا كان لدى تطبيق المنتج نظام كهذا ويجب أن يطابقه الموقع التسويقي تمامًا، فإن headless يزيل فئة كاملة من الانحراف. أما إذا كنت ستنشئ واحدًا لهذا الموقع وحده، فهذه التكلفة جزء من المقارنة.

4. من يحرّر، وكم مرة؟

فريق صغير ينشر أسبوعيًا يتكيّف. أما غرفة أخبار تنشر عشرين مرة يوميًا، مع مستقلين تدرّبوا على التدفق التقليدي، فستلتفّ على تجربة التحرير الأسوأ — عادةً بأن تطلب من مطوّر أن يتولى الأمر، وهي النتيجة التي لم يرغب فيها أحد.

5. ما السبب الحقيقي؟

إذا كان الجواب «الموقع بطيء»، فهذه مشكلة أداء ولها حل أرخص بكثير. فقد نقلنا مواقع من أربع ثوانٍ في التحميل إلى أقل من ثانية دون المساس بالمعمارية، بإصلاح الاستعلامات وضبط التخزين المؤقت ومعالجة مسار الصور. headless ليس استراتيجية أداء؛ بل خيار معماري يجعل تنفيذ استراتيجية الأداء أسهل.

المسار الوسط الذي ينبغي لمعظم الفرق سلوكه أولًا

قبل إعادة البناء، نجرّب في الغالب النسخة التي تُبقي على القالب وتزيل الألم الحقيقي:

• قالب كتل مبني يدويًا دون منشئ صفحات. معظم مشكلات أداء WordPress سببها Elementor أو Divi اللذان يُخرجان مئات الكيلوبايتات من CSS وسلسلة اعتماديات على jQuery.
• تخزين مؤقت للصفحة كاملة على الحافة مع استراتيجية تفريغ سليمة عند النشر.
• انضباط في الاستعلامات — أصلح N+1 في الحلقة، وأضف الفهرس الناقص، وامنع meta_query من مسح جدول postmeta بأكمله.
• مسار صور يقدّم فعلًا AVIF/WebP بالأبعاد الصحيحة.
• كشف REST API أو WPGraphQL للأداة الوحيدة التي تحتاج فعلًا إلى React، وتضمينها كجزيرة في صفحة تُعرض على الخادم في بقيتها.

هذه النقطة الأخيرة تستحق التأكيد. headless ليس خيارًا ثنائيًا. قالب يُعرض على الخادم مع جزيرتي React أو ثلاث يحقق معظم فوائد نموذج المكوّنات بجزء من الكلفة، وتبقى المعاينة تعمل.

إذا اخترت headless، فاحسم هذه الأمور من اليوم الأول

1. 01REST أم GraphQL. يمنحك WPGraphQL استعلامات دقيقة ورحلة واحدة لكل عرض؛ أما REST API فمدمجة وأبسط في التشغيل. اختر واحدًا ولا تشغّل الاثنين.
2. 02معمارية المعاينة، قبل أي شيء آخر. جلب المسودات، وعمر الرمز (token)، ومسار معاينة يستطيع المحررون الوصول إليه دون مطوّر.
3. 03استراتيجية إعادة التحقق. خطّاف webhook على save_post يستدعي نقطة إعادة تحقق عند الطلب، مع وسم لكل نوع محتوى. إعادة التحقق المعتمدة على الوقت وحدها ستنتج تذاكر «لماذا لا يظهر تعديلي» إلى الأبد.
4. 04ربط الكتل بالمكوّنات، مع بديل موثّق للكتل غير المربوطة، كي يحصل المحرر الذي يستخدم كتلة جديدة على مخرجات مبسّطة بدلًا من انهيار.
5. 05أين تعيش النماذج. فهي أكثر ما ينكسر، وأكثر ما يكلّف اكتشاف كسره.

// Push content changes to the front end instead of waiting for a timer.
add_action('save_post', function (int $post_id, WP_Post $post): void {
    if (wp_is_post_revision($post_id) || $post->post_status !== 'publish') {
        return;
    }

    wp_remote_post(FRONTEND_ORIGIN . '/api/revalidate', [
        'timeout'  => 5,
        'blocking' => false, // never make an editor wait on the front end
        'headers'  => ['Content-Type' => 'application/json'],
        'body'     => wp_json_encode([
            'secret' => REVALIDATE_SECRET,
            'tags'   => [$post->post_type, "post:{$post_id}"],
        ]),
    ]);
}, 10, 2);

الخلاصة

اختر headless حين تكون الواجهة الأمامية تطبيقًا، أو حين يأتي المحتوى فعلًا من عدة أنظمة، أو حين يجعل نظام تصميم قائم التركيب بلا كلفة. وابقَ مع قالب جيد البناء حين تكون المهمة موقع محتوى سريعًا ومنظّمًا جيدًا — وأنفق الفارق على أعمال الأداء التي ستظهر في الأرقام في الحالتين.

headless يحل مشكلة معمارية. وفي معظم الأحيان تكون مشكلة الفريق مشكلة أداء، وللمشكلتين أسعار مختلفة جدًا.