متى ومتى لا تستخدم WordPress بلا رأس

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

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

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

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

ما هو WordPress مقطوعة الرأس

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

هذا يعني أنه على الرغم من أن تجربة الواجهة الخلفية التقليدية لـ WordPress هي نفسها ، فإن WordPress غير مسؤول عن تقديم أي قالب أو محتوى متعلق بالقالب.

في إعداد بدون رأس ، يقوم WordPress بإخراج كل محتوى الموقع من خلال نقاط نهاية API (عادةً إما WordPress REST API أو WP GraphQL). يتم استهلاك نقاط نهاية API هذه بواسطة واجهة أمامية منفصلة مسؤولة تمامًا عن التعامل مع عرض المحتوى.

في كثير من الحالات ، يكون هذا موقعًا مع أحد أطر عمل جافا سكريبت الشهيرة ، أو تطبيق جوال ، أو تطبيق محادثة مدعوم من Alexa أو Google Home أو تقريبًا أي واجهة يمكنها استهلاك المحتوى عبر API. ألق نظرة على فيديو WPCasts أدناه لترى كيف يمكن أن يبدو.

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

فوائد WordPress مقطوعة الرأس

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

يمكن للفرق المختلفة أن تفعل ما تفعله بشكل أفضل

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

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

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

يمكن للمحررين استخدام WordPress المألوفين معهم

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

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

يمكن لواجهات برمجة التطبيقات الخلفية تشغيل منصات مختلفة

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

يمكن لنقاط نهاية API نفسها التي تُخرج المحتوى الخاص بك إلى الويب أيضًا تشغيل تطبيقات الهاتف المحمول ، والتفاعل مع نظام إدارة محتوى آخر يعمل على تشغيل منشور مطبوع ، وتكون مزود المحتوى لتطبيق صوتي مع Alexa أو Google Home وغير ذلك الكثير.

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

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

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

لا تعمل المكونات الإضافية دائمًا

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

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

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

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

الفرق المألوفة في WordPress لا "تصبح" دائمًا بلا رأس

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

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

يمكن أن يصبح التصحيح أكثر صعوبة

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

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

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

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

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

WYSIWYG أكثر صعوبة

أحد الوعود الرئيسية لمحرر Block Editor في WordPress هو أنه يقترب كثيرًا من تجربة WordPress الخاصة بك إلى أحد المثل العليا للعديد من منصات CMS - مما يوفر تجربة "ما تراه هو ما تحصل عليه" مع انتقال المحتوى من المحرر إلى الواجهة الأمامية للموقع.

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

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

إذن أيهما أفضل؟

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

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

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

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

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

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