DE {الرمز}: Gutenberg and Headless WordPress

يوفر Gutenberg ، المعروف أيضًا باسم كتل WordPress ، لمنتجي المحتوى طرقًا جديدة قوية لتخطيط المحتوى في موقع WordPress تقليدي. ولكن كيف يمكن لمطوري WordPress بدون رأس تمكين فرق التسويق بنفس القدرات؟ في جلسة DE {CODE} هذه ، يشارك مؤسس GraphQL for WordPress (WPGraphQL) ، جيسون باهل ، إمكانات جديدة وأفضل الممارسات لاستخدام محرر قوالب WordPress على موقع بلا رأس.

شرائح الجلسة

نص كامل

جيسون بال : مرحبًا. مرحبًا بكم في حديثي عن Gutenberg و Headless WordPress. اسمي جايسون باهل. أنا منشئ WPGraphQL وأمينه. أنا مهندس برمجيات رئيسي في WP Engine. يمكنك أن تجدني على Twitterjasonbahl أو أيضًا على Twitterwpgraphql.

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

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

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

إذن ما هو WordPress بلا رأس الآن؟ حتى نفهم "مقطوعة الرأس" ، دعنا نلقي نظرة على WordPress التقليدي. لذلك WordPress التقليدية ، نقوم بتسجيل الدخول إلى WordPress ، وواجهة المستخدم الإدارية ، وننشر المحتوى الخاص بنا ثم يزور المستخدمون موقعنا ، وتقوم PHP ، اللغة التي تم تضمينها في WordPress ، بعرض الصفحة. لذلك يقوم بتحميل CSS و HTML و JavaScript ويقدم الصفحة للمستخدم. هذا نوع من WordPress التقليدية.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

هذا قليلاً عن مطور Headless WordPress الذي يواجه تصميمًا قائمًا على المكونات وفوائد ذلك. الآن عندما يتعلق الأمر بـ Gutenberg ، على وجه التحديد ، لماذا تفكر في Headless WordPress مع Gutenberg على وجه التحديد؟ حسنًا ، إذا كان فريقك يستخدم Headless WordPress بالفعل ، ربما مع Advanced Custom Fields و flexfields ، وتريد تحديث تجربة المحرر لاستخدام Gutenberg ، فمن الواضح أن هذا أحد الأسباب التي قد تجعلك بلا رأس مع Gutenberg.

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

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

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

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

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

لذا فإن المحتوى هو HTML. هذا شيء يمكننا القيام به في WPGraphQL core اليوم. إذا كنت تريد الاستعلام عن الكتل كأنواع GraphQL فردية ، فهناك خياران في الوقت الحالي. لدينا GraphQL لملحق Gutenberg ، وهو امتداد للمجتمع ومن ثم لدينا WPGraphQL Block Editor ، وهو مكون إضافي تجريبي أعمل عليه شخصيًا.

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

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

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

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

أحد الخيارات الأخرى ، WPGraphQL لـ Gutenberg ، هذا مكون إضافي يديره المجتمع. وهذا سيسمح لك بالاستعلام عن كتل المحتوى ، كل كتلة على أنها نوع GraphQL الخاص بها. الطريقة التي يعمل بها هذا هي صفحة إعدادات ، يجب عليك الانتقال إلى الكتل فقط مثل المخطط ، لذلك يفتح هذا Gutenberg في إطار iframe غير مرئي ، ويحصل على سجل الكتلة من عميل JavaScript ويرسله إلى الخادم.

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

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

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

إذن المشروع التالي ، WPGraphQL Block Editor ، هذا هو مكون إضافي تجريبي أعمل عليه حاليًا. ويسمح لك هذا أيضًا بالاستعلام عن كتل المحتوى كنوع GraphQL الخاص بها وتشبه إلى حد بعيد WPGraphQL لـ Gutenberg ، يمكننا كتابة أجزاء تعيد البيانات التي نحددها. وبعد ذلك يمكننا استخدام هذه الأجزاء مع مكوناتنا في الواجهة الأمامية.

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

لا يتم التعامل مع الكتل كعقد فردية. أود أن أتعامل مع الكتل كعقد فردية ، لكن لا يوجد معرّف عالمي ، لذا عليك الوصول إلى تلك الكتل كأجزاء من كائنات أكبر مثل صفحة الملصق.

لذلك آمل أن تكون قد تعلمت شيئًا عن Headless WordPress ، وفوائد Headless WordPress ، واستخدام Headless WordPress مع Gutenberg. أدعوك لتجربة WPGraphQL اليوم. يمكنك التسجيل للحصول على حساب Atlas Sandbox مجاني على wpengine.com/atlas. وشكرا لانضمامك إلى عرضي التقديمي. مرة أخرى ، يمكنك أن تجدني على Twitter أو jasonbahl أو أيضًا على Twitterwpgraphql. شكرًا لك.