اضغط على هذا: WPGraphQL و Faust.js

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

مدعوم من RedCircle

Doc Pop : أنت تستمع إلى Press This ، a WordPress Community Podcast on WMR. كل أسبوع نسلط الضوء على أعضاء مجتمع WordPress. أنا مضيفك يا دوك بوب. أنا أدعم مجتمع WordPress من خلال دوري في WP Engine ، ومساهماتي في TorqueMag. حيث يمكنني القيام بالبودكاست ورسم الرسوم المتحركة ومقاطع الفيديو التعليمية. تحقق من ذلك.

يمكنك الاشتراك في Press This على Red Circle أو iTunes أو Spotify أو يمكنك تنزيل الحلقات مباشرةً على wmr.fm.

في هذه الحلقة من برنامج Press This ، نتحدث عن Headless WordPress و GraphQL و Faust.js. كيف يمكن استخدام هذه الأدوات معًا وما نوع التكلفة التي يمكن ربطها بـ Headless WordPress. سنحاول نوعًا ما التعمق في هذا الأمر ، وقد انضم إليّ ضيفان عظيمان اليوم ، لدي جيسون باهل ، مهندس برمجيات رئيسي في WP Engine ومقرها في دنفر ، كولورادو ، حيث يحافظ على WPGraphQL . ولدينا كريس ويجمان ، مدير هندسي يعمل على Faust.js. عادةً ما أرغب في بدء هذه العروض لسؤال الضيوف عن قصص أصل WordPress الخاصة بهم ، لكنني اعتقدت أنني سأغير الأمور قليلاً هنا.

جايسون ، هل يمكن أن تخبرنا ما هي WPgraphQL وما هي قصة أصل الكلمة.

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

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

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

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

موانئ دبي: حسنًا ، رائع. كريس ، هل يمكنك إخبارنا بقصة مماثلة حول ما هو فاوست وكيف حدث؟

كريس ويجمان: تم إطلاق سراح فاوست رسميًا مؤخرًا اعتبارًا من هذا الأسبوع للجمهور ، وأعيد إصداره للإطار العام لبناء مواقع WordPress بدون رؤوس باستخدام GraphQL. بدأ التطوير الجيد فيه في عام 2020 ، وكان نوعًا من مشروع غير رسمي لـ WP Engine ، وهذا هو المحور الرئيسي الثالث.

لقد بدؤوا به كامتداد لـ DevRel ، نوعًا ما بدأوا في جعله رسميًا بدرجة أكبر قليلاً وتحولوا إلى شيء يسمى GQty وعقلية JavaScript ، أول مطور. وبعد ذلك عندما توليت مسؤولية الفريق في الأول من ديسمبر من العام الماضي ، أدركنا أن هذا لم يكن سوقنا المستهدف.

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

موانئ دبي: جيسون كنت قد غردت مؤخرًا بأنك أطلقت موقع wpgraphql.com الجديد على Faust.js. الموقع السابق ، أعتقد أنه كان بلا رأس ووردبريس. هل يمكنك أن تخبرنا فقط عن هذا التغيير الذي قمت به وأنت تعرف ، ما هي التحسينات التي تقولها؟

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

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

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

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

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

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

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

موانئ دبي: كريس ، لقد ذكرت أن فاوست خضع لبعض التغييرات. ما هي تلك التغييرات؟ كما تعلم ، جيسون كان يذكرهم. ما هي بعض تلك التغييرات التي جعلت هذا التحسين ممكنًا؟

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

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

علاوة على ذلك ، عندما تم تصميمه بإصدار GQty ، لم يكن هناك أي اهتمام لمشكلة التوجيه التي تحدث عنها Jason. من يتولى التوجيه؟ يريد WordPress التعامل مع التوجيه من خلال ماهية المحتوى ، إنه نظام إدارة محتوى ، لذا فإن كل التوجيه و WordPress يعتمدان إلى حد كبير على المحتوى.

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

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

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

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

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

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

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

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

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

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

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

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

ويجعل فاوست من الأسهل بكثير الاستفادة من ذلك وشيء يمكنك بناءه في يوم واحد بدلاً من شهر.

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

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

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

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

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

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

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

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

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

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

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

وأعتقد أنه في المستقبل غير البعيد ، قد يكون البناء مقطوع الرأس أرخص من عدم البناء بدون رأس.

موانئ دبي: كريس ، هل لديك أي شيء تريد إضافته إلى ما قد تحتاج الوكالات إلى التفكير فيه فيما يتعلق بتكاليف WordPress بلا رأس؟

CW: أعتقد أن جيسون أصاب رأسه حقًا.

وهذا شيء أحبه في WPGraphQL هو أن فريقي يعمل بعد ذلك على توسيع WordPress في هذا الاتجاه بما نسميه ، عنوان العمل لدينا هو React Gutenberg Bridge ، لكنها مشكلة في WordPress أيضًا. كيف تعيد استخدام هذه المكونات؟ لا أريد استخدام كلمة مكون فقط ، لأنها لا تنطبق على جانب WordPress بنفس الطريقة التي تنطبق على جانب JavaScript ، أليس كذلك؟

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

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

موانئ دبي: نعم ، بالتأكيد. كما تعلم ، قادمًا من خلفية صحفية ، أعمل في ويكليز في توين سيتيز وفي ناشفيل ، جايسون ، يمكنني أن أتخيل كيف سيكون الأمر لو تخبر 56 جرائدك ألا تنشر ليوم واحد.

لا توجد أخبار اليوم ، لأننا نقوم بتحديث الموقع.

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

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

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

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

JB: أجل. هذا في الواقع شيء مثير للاهتمام. لذلك تم بناء Faust الجديد مع بنية البرنامج المساعد نفسها. لذا ، كما هو الحال خارج الصندوق ، سيأتي مع عميل ، إنه يستخدم عميل Apollo حتى تتمكن من جلب البيانات من WPGraphQL ، ويمكنك الحصول على بيانات WordPress الخاصة بك ، ولكن يمكنك إنشاء مكونات إضافية بحيث ، دعنا نقول أنك فعلت ، مثلك المذكورة ، قم بتثبيت Yoast SEO على موقع WordPress الخاص بك.

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

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

موانئ دبي: هذا مكان جيد لاستراحة أخيرة هنا في Press This ، وعندما نعود ، سنختتم محادثتنا مع كريس ويجمان وجيسون باهل. ابقوا متابعين.

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

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

CW: بالتأكيد. في الواقع ، لدينا بالفعل. نشير إليها باسم Blueprints لأنها تعمل بكثافة مع Local. سيقوم معظم الأشخاص بإجراء نوع من التغيير والتبديل على هذه الأشياء قبل إطلاقها على منصة مثل WP Engine. لذلك اقترضنا اسم Blueprints الخاص بـ Local.

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

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

موانئ دبي: هذا رائع للتفكير فيه. هذا نوع مختلف تمامًا من النظام البيئي للدخول إليه.

وكما تعلم ، جايسون ، لقد أجريت مقابلة معك من قبل ، وأنا متأكد من أن هذا السؤال يظهر طوال الوقت ، لكن في كل مرة أسمع فيها عن WPGraphQL ، أعتقد أن هذا يبدو كثيرًا مثل ما تفعله REST API. في الواقع ، يبدو هذا أقوى بكثير مما تفعله REST API و REST API جزء أساسي وأنا أتساءل نوعًا ما ، هل تشعر أن WPGraphQL يجب أن تكون جزءًا من WordPress Core؟

JB: ربما يومًا ما. لا أعتقد أننا هناك بعد. عندما يتم دمج الأشياء في WordPress Core ، ربما باستثناء Gutenberg ، يتوقف الابتكار. واجهة برمجة تطبيقات REST ، على سبيل المثال ، لا يزال هناك خطأ أشرت إليه لأشخاص لا يزال موجودًا منذ عام 2016. لذلك أعني ، عندما تدخل الأشياء إلى جوهرها ، فأنت تضيف ميزة معينة إلى 40٪ من الويب و لذلك يجب إجراء التغييرات بوتيرة أبطأ بكثير ، حيث إذا كان مكونًا إضافيًا ، فيمكنك السماح للأشخاص بالاشتراك في الإصدار الذي يريدون الاشتراك فيه ويمكنك التكرار بشكل أسرع لأنه يمكنهم اختيار الإصدار الأفضل لمشروعهم.

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

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

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

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

لذا فإن القيام بذلك كمكوِّن إضافي بالنسبة لي لا يزال منطقيًا.

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

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

في حلقة الأسبوع المقبل ، سيكون لدينا آن مكارثي ، منسقة المنتج في Automatic ، تتحدث عن التغييرات في Site Editing و 6.1 وما الذي سيحدث مع 6.2. شكرًا مجددًا على الاستماع إلى Press This.

يمكنك متابعة مغامراتي مع مجلة Torque على تويترthetorquemag أو يمكنك الذهاب إلى torquemag.io حيث نساهم بدروس تعليمية وفيديوهات ومقابلات كهذه كل يوم. لذا تحقق من torquemag.io أو تابعنا على Twitter. يمكنك الاشتراك في Press This على Red Circle أو iTunes أو Spotify أو يمكنك تنزيله مباشرةً على wmr.fm كل أسبوع. أنا مضيفك Doctor Popular أنا أدعم مجتمع WordPress من خلال دوري في WP Engine. وأحب إلقاء الضوء على أعضاء المجتمع كل أسبوع في Press This.