WordPress مقطوعة الرأس: ما هو وهل تحتاجه؟

في Servebolt ، نحن من المدافعين الكبار عن WordPress ونظامه البيئي. نستخدمه أيضًا لمواقعنا الخاصة لأننا نجد حقًا أنه أفضل نظام لإدارة المحتوى ، حيث تستمر الإحصائيات في الظهور عامًا بعد عام. إنه مفتوح المصدر ومتعدد الاستخدامات وببساطة ، من السهل للغاية معرفة سبب تشغيله لأكثر من 40٪ من جميع مواقع الويب على الإنترنت.

مع حجم النظام البيئي ومجتمع المطورين الذي يحيط بـ WordPress ، فليس من المستغرب أن يستخدم الناس WordPress بطرق مختلفة. أحد هذه الأساليب هو استخدام WordPress كنظام CMS مقطوع الرأس - باختصار ، يشار إليه باسم WordPress بدون رأس ، والذي يزداد شعبيته.

في هذا الدليل ، سنقوم بتفصيل كل ما تحتاج لمعرفته حول WordPress بدون رأس ، ومزاياه وعيوبه والمزيد من التجربة المباشرة لفريقنا.

ما هو وورد بلا رأس؟

لفهم WordPress بدون رأس ، يجب أن تعرف ماهية WordPress المتجانسة. Monolithic ، أو WordPress في شكله التقليدي ، هو WordPress كما تعرفه. إنه نظام إدارة محتوى يمكنك استخدامه لإدارة كل المحتوى على موقعك.

بشكل عام ، يحتوي WordPress على الواجهة الخلفية (نظام إدارة المحتوى) وطبقة العرض التقديمي ، والتي تتيح لك تصميم موقع الويب الخاص بك. ومع ذلك ، فإن مواقع WordPress بدون رأس هي تلك التي تعتمد ببساطة على WordPress كنظام لإدارة المحتوى وتستخدم حزمة أمامية مختلفة لعرض المحتوى.

هذا يسمح لمزيد من المرونة من حيث التنمية. بشكل أساسي ، بمساعدة واجهة برمجة تطبيقات REST ، يمكنك استخدام WordPress لوظائف إدارة المحتوى الخاصة به أثناء إقرانه بواجهة أمامية مبنية بشكل منفصل في إطار عمل مثل Vue.js أو React (على سبيل المثال لا الحصر ، هناك مجموعة كاملة من أخرى الأطر وأدوات الواجهة الأمامية المتاحة).

يعتبر WordPress بنية CMS مقترنة لأن جميع أدوات التحرير الأمامية ووظائف إدارة المحتوى (التحرير) الخلفية مقترنة. يتيح ذلك لفرق من المطورين والمحررين وكتّاب الإعلانات وغيرهم إدارة طبقة العرض التقديمي والمحتوى. على عكس مواقع WordPress بدون رأس والتي تتبع بنية منفصلة حيث يتم فصل طبقة العرض التقديمي والمحتوى - كما يوحي الاسم -.

تكامل REST و GraphQL و Flat-File

يستخدم إعداد CMS بدون رأس واجهات برمجة التطبيقات و CDN لتقديم المحتوى. وفي الوقت الحالي ، هناك ثلاثة خيارات متاحة - واجهة برمجة تطبيقات REST وتكامل الملفات المسطحة و GraphQL.

يستخدم WordPress واجهة برمجة تطبيقات REST للسماح لك بتوصيل الواجهة الأمامية بنظام إدارة المحتوى. واجهة برمجة تطبيقات REST هي ببساطة واجهة برمجة تطبيق تتبع قيود بنية REST ، مما يوفر واجهة موحدة تتيح للخوادم والعملاء نقل البيانات بين بعضهم البعض. يسمح REST للمطورين بكشف واستخدام بيانات محددة ، إذا كانت نقطة نهاية REST لا تحتوي على البيانات المتاحة مباشرة ، فستحتاج إلى تطوير إضافي.

بديل آخر هو GraphQL (QL اختصار لـ Query Language). تجعل GraphQL من السهل الاستعلام عن واجهات برمجة التطبيقات باستخدام حقول وعلاقات محددة ، تمامًا كما تفعل مع قاعدة البيانات. يعد هذا تحسينًا كبيرًا ، وهناك مكون إضافي يجعل واجهة برمجة تطبيقات GraphQL متاحة على WordPress . قد يعني هذا أنه لا توجد حاجة إلى مزيد من التطوير لاستغلال محتوى CMS حيث أن GraphQL لديها حق الوصول إليه بالفعل ، والجزء الأكثر تعقيدًا هو طلب الاستعلامات الفعالة المناسبة للحصول عليه.

الخيار الآخر هو تكامل الملفات الثابتة. يتيح لك تكامل الملفات المسطحة تصدير البيانات التي يتم تقديمها عادةً عبر REST أو GraphQL كملف .JSON ، مما يسمح للخادم بتخزينها مؤقتًا وعدم الحاجة إلى إنشائها عند كل طلب ، مما يجعلها أسرع بكثير. سيؤدي استخدام هذه الطريقة إلى إنشاء مجموعة جديدة من ملفات .JSON تلقائيًا مع كل تغيير في قاعدة البيانات. هذا عادة ما يكون تنفيذًا مفصلًا وليس مجرد مكون إضافي. لذلك ، هناك حاجة إلى مطور لإعداده.

إيجابيات وسلبيات WordPress مقطوعة الرأس

الآن بعد أن عرفت ما هو WordPress بدون رأس وكيف يختلف عن إعداد WordPress التقليدي ، إليك الجوانب الإيجابية والسلبية التي يجب أن تعرفها قبل اتخاذ قرار.

تطوير مرن بينما لا تزال تستخدم WordPress كنظام إدارة المحتوى الخاص بك ، فإن فصل WordPress يمنح مطوريك المرونة في البناء باستخدام تقنيات الواجهة الأمامية المختارة - مثل أطر عمل مثل Next.js. على مستوى السطح ، هذا يعني المزيد من الحرية في البناء.

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

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

بناء تطبيقات الأجهزة المحمولة مع خلفية WordPress

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

التطبيقات معقدة ، أكثر بكثير من إنشاء مواقع الويب من البداية (أي باستخدام WordPress أو بدونه) - لذلك إذا انتهى بك الأمر إلى السير في هذا الطريق ، بينما سيكون المحتوى مدفوعًا بواجهة برمجة التطبيقات ، فإن الكثير من الباقي سيعتمد على ميزات الجهاز الأصلية بمساعدة أطر مثل React Native. فيما يلي مقارنة رائعة بين الطرق المختلفة لإنشاء تطبيقات الهاتف المحمول من Scott Bollinger من AppPresser. أحدها ، كما قد تكون خمنت ، AppPresser ، وهو تطبيق رائع لهذا لأولئك الذين يريدون البدء خارج الصندوق. إنه - بالطبع - مدعوم من WordPress ، باستخدام مكونات WordPress الإضافية والسمات وواجهة برمجة تطبيقات REST لتشغيل تطبيقات iOS و Android للهواتف المحمولة الأصلية / الهجينة.

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

أداء أفضل ، مع المفاضلات.

هناك ثلاث طرق أساسية يمكن من خلالها تطوير مقطوعة الرأس

1. من جانب العميل : كل شيء مبني على المتصفح باستخدام جافا سكريبت مع المحتوى الذي تم تحميله من الخادم عند الوصول إليه. على سبيل المثال ، باستخدام React حيث يحصل المحرك على البيانات عبر ، على سبيل المثال ، واجهة برمجة تطبيقات REST. عندما يتم تغيير الصفحة ، هناك طلب لمزيد من البيانات لواجهة برمجة التطبيقات ، ويتم إنشاء صفحة جديدة على العميل. غالبًا ما تستخدم في تطبيقات الصفحة الواحدة (SPA)
2. تم نشر ثابت : تم بالفعل إنشاء كل شيء وتصديره بتنسيق HTML و CSS و JS على الخادم. نظرًا لأنها تخدم فقط ملفات ثابتة ، ولا تنشئ الصفحة ديناميكيًا ، فيمكن تخزينها على خادم أو CDN منخفض الطاقة للغاية. هذه الطريقة سريعة البرق. غالبًا ما يتم ذلك باستخدام شيء مثل Next.js. عندما يتم تغيير الصفحة ، يتم تنزيل صفحة HTML جديدة من الخادم وتظهر. غالبًا ما تستخدم على المواقع التي لا تتغير كثيرًا ، مثل مواقع الكتيبات أو الوثائق.
3. الصفحات المتشابهة : صفحة الويب الأولى التي يتم الوصول إليها هي عرض جانب الخادم (SSR) بتنسيق HTML ولكن يتم إنشاء جميع الصفحات اللاحقة الأخرى على جانب العميل إذا كان العميل قادرًا على ذلك. إذا لم يتمكن العميل من إنشاء الصفحة ، فسيطلبها من الخادم. غالبًا ما تستخدم في تطبيقات الويب التقدمية (PWA) ، أو المواقع الديناميكية للغاية ، أو تلك التي يجب أن تخدم متصفحات الويب القديمة. غالبًا ما يتم استخدام إطار عمل مثل Svelte.kit لهذا الغرض.

يمكن للطريقتين رقم 1 و 3 استخدام ملفات البيانات المسطحة لإنشاء HTML ، مما يجعلها قابلة للمقارنة مع موقع ثابت منشور ، ولكن استخدام REST أو GraphQL سيبطئها قليلاً حيث قد تضطر إلى إنشاء محتوى JSON مع كل طلب.

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

لنأخذ نموذج الاتصال كمثال ، يجب إنشاء النموذج للعمل على جانب العميل والقدرة على إرسال معلوماته عبر Javascript / AJAX مرة أخرى إلى الخادم ، حيث يتم فحصها وتعقيمها وإدراجها في جهة الاتصال شكل نظام إدارة البرنامج المساعد. نظرًا لأن هذه طريقة عمل مختلفة تمامًا ، فلا يمكن الاعتماد على صانع المكون الإضافي لنموذج الاتصال لتوفير هذا أو ذاك ، مثل أواني العسل وغيرها من وسائل الحماية من البريد العشوائي. قد يحتاج إلى مطور لإنشاء نقطة نهاية REST وجعلها تعمل حسب الحاجة. أكثر تعقيدًا بكثير.

التعليقات ، من الناحية النظرية ، أسهل كثيرًا نظرًا لوجود نقاط نهاية REST بالفعل ، ولكن مع ذلك ، ستكون هناك حاجة للمطور لإتاحة إمكانية استرداد التعليقات المعتمدة وتقديمها في تخطيط مترابط ، وتحميل تعليقات جديدة في عملية الموافقة ، وبالطبع التعامل مع الرسائل غير المرغوب فيها.

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

تصور هناك الكثير من المعلومات الخاطئة حول أمان WordPress مقطوعة الرأس. يعد تشغيل إعداد موقع ثابت باستخدام CDN إجراء وقائيًا جيدًا ضد هجمات DDoS. ولكن في النهاية ، يمكن أن يكون أي خادم ضحية لهجوم DDoS إذا لم تضع الأنظمة اللازمة (مثل Cloudflare ، إلخ). تعمل إعدادات WordPress المنفصلة مع WordPress المثبت على مجال منفصل أو مجال فرعي ، مع الواجهة الأمامية على المجال القياسي.

على سبيل المثال ، إذا أردنا استخدام موقع الويب هذا ، فسنستمر في استخدام servebolt.com كموقعنا متاح للجميع أثناء إعداد وعلى سبيل المثال ، فإن استخدام الواجهة الأمامية Next.js كمثال يعني أن لديك خيارًا لاستخدام SSR (عرض من جانب الخادم) ، حيث يتم إنشاء صفحة HTML عند كل طلب ، أو SSG (إنشاء ثابت) ، حيث تكون الصفحة HTML يتم إنشاؤه في وقت البناء. يسمح الجيل الثابت بإعادة استخدام HTML لكل طلب مما يسمح بتخزينه مؤقتًا بواسطة CDN.

في كلتا الحالتين ، لا تزال طبقة العرض تتواصل وتطلب المحتوى من طبقة المحتوى التي تقوم بتشغيل WordPress. هذا يعني أن المنطقة التي تستضيف طبقة إدارة المحتوى لإعداد WordPress بدون رأس ستظل تعمل بنظام WordPress.

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

عندما تعمل مع موفر استضافة WordPress يجلب الكفاءة في الأمان والتوسع والأداء بالطريقة التي نقوم بها في Servebolt ، فلا يزال من الممكن جدًا الحفاظ على أمان مواقعك دون التضحية بكل ما يمكنك القيام به باستخدام WordPress - الاضطرار إلى تحمل تكاليف التطوير الباهظة تكاليف إعادة البناء من الألف إلى الياء.

المزيد من الجوانب السلبية التي من المحتمل أن تواجهها مقطوعة الرأس

تكاليف WordPress مقطوعة الرأس

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

يفقد فريقك القدرة على التحرك السريع والتكرار دون الحاجة إلى الاعتماد على المهندسين داخل الشركة (أو وكالة).

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

قد يكون من الصعب العثور على مطورين جيدين يعرفون ما يفعلونه

لا يزال WordPress مقطوع الرأس إعدادًا جديدًا نسبيًا. لذلك ، على الرغم من أن العثور على مطوري JavaScript على دراية بـ JavaScript (وأطر مثل React و Vue و Svelte و Gatsby) ليس بالأمر الصعب بشكل خاص - وربما أسهل من العثور على مطوري WordPress الرائعين في الوقت الحالي ، أولئك الذين هم بالفعل على دراية بدمج طبقة الواجهة الأمامية مع تميل WordPress بالطريقة التقليدية التي تلتزم بأفضل الممارسات إلى أن تكون أكثر صعوبة.

ليس دائمًا أسرع من التخزين المؤقت لحافة الصفحة الكاملة

هناك مسارات أسهل - وربما أفضل - إلى موقع ويب أسرع.

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

متى يجب تجنب WordPress مقطوعة الرأس؟

كقاعدة عامة ، WordPress بدون رأس ليس مناسبًا لمعظم الشركات التي تنشئ باستخدام WordPress. باختصار ، أولئك الذين:

• ترغب في تجنب الاحتفاظ بطبقتين منفصلتين (طبقة المحتوى والعرض التقديمي).
• لا ترغب في التخلي عن سير العمل التحريري وإدارة المحتوى الذي يشتهر به WordPress.
• دع فريقهم يتمتع بالتحكم والمرونة في العمل دون الحاجة باستمرار إلى الاعتماد على مطوريك.
• تريد توفير الموارد (الوقت والمال).
• ليس لديك مطورون متمرسون متاحون لاتخاذ الخيارات الصحيحة حول كيفية عمل النظام.
• هل تتطلع إلى توظيف عمال مؤقتين أو أن تقوم وكالة بتطوير موقعك مع التركيز على التطورات المستقبلية اللاحقة؟

لمن يصلح وورد بريس مقطوعة الرأس؟

يمكن أن يكون WordPress بدون رأس خيارًا جيدًا لفريقك إذا:

• فريق التطوير الخاص بك ماهر في البناء باستخدام أطر عمل JavaScript ، والعثور على مطور WordPress ليس خيارًا (لأي سبب قد يكون). ولكن يريد أيضًا الاستمرار في استخدام WordPress كنظام لإدارة المحتوى ، يمكن أن يكون WordPress بدون رأس خيارًا جيدًا.
• يرغب فريقك في تحقيق أشياء محددة ، مثل الاستمرارية بين تصميم النظام الأساسي SaaS الذي تم إنشاؤه بالفعل ، مما يجعل إعادة بنائها والحفاظ عليها في WordPress المزيد من العمل. في هذه الحالة ، يمكن أن يكون فصل المحتوى وطبقة العرض خيارًا جيدًا.
• أنت مصمم على عدم البناء ضمن حدود سمات WordPress ولا تعتمد بشكل خاص على أي وظائف إضافية توفرها المكونات الإضافية.
• بصفتك صاحب عمل ، فأنت ترغب في تدريب فريقك الفني باستمرار على أحدث المهارات وتعرف من خلال منحهم هذه المعرفة ، فمن المرجح أن يظلوا معك لفترة أطول.
• هدفك هو إجراء تحسينات من الدرجة n على جميع أجزاء المكدس.

أمثلة على مواقع الويب التي تم إنشاؤها باستخدام WordPress بدون رأس

هيلثلاين

تك كرانش

المواجهة

باكلينكو

روديس

تقرير ما بعد العمل - تقييم حالة مقطوعة الرأس كحل

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

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

ما زلت تتساءل عما إذا كان WordPress مقطوع الرأس يتوافق مع ما يبحث عنه فريقك؟ لا تتردد في حجز مكالمة معنا وسنكون سعداء للتحدث عن المشكلات التي تواجهها ونفكر في تطبيق WordPress بدون رأس لحلها.

أو ، إذا كان هذا الدليل قد أجاب بالفعل على جميع أسئلتك وكنت مستعدًا لتجربة نهج Servebolt:

هل أنت مهتم بالاستضافة المدارة الأسرع تجريبياً؟ جرب أسلوبنا في استضافة WordPress :

• قابلية التوسع: في اختبارات عبء عمل المستخدم الحقيقي ، قدم Servebolt متوسط ​​أوقات استجابة 65 مللي ثانية ، وأوقات استجابة أسرع 4.9 مرة من ثاني أفضل.
• أسرع أوقات تحميل عالمية: يضعنا متوسط ​​أوقات تحميل الصفحة البالغة 1.26 ثانية على رأس قائمة نتائج WebPageTest العالمية.
• أسرع سرعة للحوسبة: توفر خوادم Servebolt سرعات قاعدة بيانات لم يسمع بها من قبل ، وتعالج 2.44 مرة استعلامات في الثانية أكثر من المتوسط ​​وتشغيل PHP 2.6 مرة أسرع من ثاني أفضل!
• أمان مثالي ووقت تشغيل: مع وقت تشغيل بنسبة 100٪ على جميع الشاشات ، وتقييم A + على تطبيق SSL الخاص بنا ، يمكنك التأكد من أن موقعك متصل وآمن.