Distributor: NetworkSiteConnection :: update_syndicated قيد التشغيل مبكرًا جدًا في سياق Gutenberg / REST

تم إنشاؤها على ٣ أكتوبر ٢٠١٩  ·  6تعليقات  ·  مصدر: 10up/distributor

صف الخلل
عند تحديث منشور تم توزيعه على موقع آخر في مواقع متعددة (اتصال داخلي بالشبكة) باستخدام Gutenberg ، لا يتم دفع تحديثات التعريف والمصطلحات وما إلى ذلك. يبدو أن المشكلة هنا هي أن طريقة update_syndicated في فئة NetworkSiteConnection مرتبطة بالإجراء save_post . يعمل هذا بشكل جيد عند استخدام المحرر الكلاسيكي ، ولكن عند استخدام Gutenberg ويتم حفظ المنشورات من خلال REST-api ، يبدو أن الخطاف save_post ينطلق في وقت سابق. وعند النظر إلى update_item طريقة لل WP_REST_Posts_Controller يمكن فئة واحدة ترى أن wp_update_post الذي يقوم بتشغيل save_post عمل يسمى على خط 697 ، وفقط بعد ذلك ل meta ، المصطلحات وما إلى ذلك التي يتم معالجتها بواسطة REST-api. هذا يعني أنه عند تشغيل الموزع للطريقة update_item ، لم يتم تحديث / حفظ البيانات الوصفية والمصطلحات وما إلى ذلك حتى الآن.

كعمل حول هذا الموضوع ، قمت بإضافة الكود التالي إلى مكون Mu-plugin:

add_action(
    'rest_after_insert_post',
    function( WP_Post $post ): void {
        \Distributor\InternalConnections\NetworkSiteConnection::update_syndicated( $post->ID );
    }
);

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

لست متأكدًا من أفضل حل لهذه المشكلة هو جعلها تعمل مع كل من Gutenberg والمحرر الكلاسيكي. يمكن للمرء بالطبع ربط طريقة update_syndicated (مع بعض التعديلات الطفيفة لحساب القيم المختلفة المرسلة من خلال الإجراءات save_post و rest_after_insert_{$post_type} ) إلى rest_after_insert_{$post_type} إجراء لجميع أنواع post_type حيث show_in_rest = true. هذا يعني أنه سيتم تشغيل طريقة update_syndicated مرتين ، ولكن يمكن معالجة ذلك عن طريق إحباط هذه الطريقة إذا كان شيء مثل ( ( defined( 'REST_REQUEST' ) && REST_REQUEST ) && doing_action( 'save_post' ) ) صحيحًا. لكني أشعر أنه ربما توجد طرق أكثر ذكاءً من ذلك. ؛)

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

خطوات التكاثر

  1. على موقع WordPress متعدد المواقع ، أنشئ منشورًا باستخدام Gutenberg مع عنوان وفئة وصورة مميزة على الأقل. (مهم ، لا تستخدم أي مربعات تعريف قديمة في Gutenberg لأن ذلك يؤدي إلى حفظ آخر في WP للتعامل مع التوافق الخلفي ، مما يجعل هذه المشكلة تختفي)
  2. قم بتوزيع هذا المنشور على موقع آخر في الشبكة وتحقق من أنه يبدو جيدًا.
  3. قم بتغيير العنوان والفئة والصورة المميزة وقم بتحديث المنشور.
  4. تحقق من المنشور الموزع على الموقع الآخر ولاحظ أن العنوان قد تغير ولكن ليس الفئة أو الصورة المميزة.
  5. قم بتحديث عنوان المنشور فقط.
  6. تحقق من المنشور الموزع على الموقع الآخر ولاحظ أن العنوان قد تغير وأن الفئة والصورة المميزة المحفوظة في الخطوة 3 قد تم توزيعها (حيث تم حفظهما بالفعل عند تشغيل الخطوة 5).

سلوك متوقع

يجب توزيع الميتا والمصطلحات وما إلى ذلك عند التحديث.

معلومات البيئة

  • إصدار الموزع: الأحدث من فرع التطوير.
  • الموضوع والإصدار: Twenty Nineteen 1.4.1
  • المكونات الإضافية والإصدارات الأخرى المثبتة: لا شيء.
  • ووردبريس 5.2.3
bug
مصدر
picture lakrisgubben

التعليق الأكثر فائدة

lakrisgubben شكرًا على لفت انتباهنا إلى هذا. لقد واجهت مشكلة Gutenberg مشابهة قليلاً من قبل ولكني لم أواجه هذه المشكلة بالتحديد حتى الآن.

بصراحة ، لست متأكدًا من وجود نهج رائع هنا ، لأننا نعتمد في الغالب على كيفية عمل Gutenberg. هذه مشكلة معروفة (انظر هنا للاطلاع على موضوع واحد حولها: https://github.com/WordPress/gutenberg/issues/12903) ويبدو أنهم يحاولون اكتشاف نهج جيد لسيناريوهات مماثلة.

إليك ما أقترحه ، وهو مشابه جدًا لمنهجك:

  • لدينا طريقة مساعدة is_using_gutenberg تخبرك إذا تم كتابة منشور معين باستخدام Gutenberg. أعتقد أنه يمكننا استخدام هذا ، ضمن طريقة update_syndicate ، لتحديد ما إذا كان المنشور يستخدم Gutenberg أم لا
  • إذا كان الأمر كذلك ، فيمكننا إضافة إجراء جديد ، مرتبط بـ rest_after_insert_{$post_type} ، يستدعي نفس طريقة update_syndicate . ثم عد مبكرًا ، لذلك لا يتم تشغيل باقي التعليمات البرمجية (ولا نحصل على تحديثات مزدوجة)
  • ونحن بحاجة أيضا للتحقق من عمل يعمل بنظام التشغيل، وذلك عندما update_syndicate يتم استدعاء أسلوب من قبل rest_after_insert_{$post_type} هوك، فهو يعرف في الواقع لتشغيل كافة التعليمات البرمجية في تلك المرحلة. شيء مثل \Distributor\Utils\is_using_gutenberg( $post ) && doing_action( 'save_post' )
  • ونظرًا لأن هذه الخطافات تستخدم وسيطات مختلفة (أحدها معرف الوظيفة ، والآخر هو كائن post) ، فسنحتاج إلى التعامل مع ذلك. أعتقد أنه يجب أن يكون الأمر بسيطًا مثل استدعاء get_post( $post_id ) ، لأن get_post يقبل إما معرّف أو كائن

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

picture dkotter في ٣١ يناير ٢٠٢٠
👍2

ال 6 كومينتر

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

jeffpaul picture jeffpaul في ٣٠ يناير ٢٠٢٠

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

lakrisgubben picture lakrisgubben في ٣١ يناير ٢٠٢٠

lakrisgubben شكرًا على لفت انتباهنا إلى هذا. لقد واجهت مشكلة Gutenberg مشابهة قليلاً من قبل ولكني لم أواجه هذه المشكلة بالتحديد حتى الآن.

بصراحة ، لست متأكدًا من وجود نهج رائع هنا ، لأننا نعتمد في الغالب على كيفية عمل Gutenberg. هذه مشكلة معروفة (انظر هنا للاطلاع على موضوع واحد حولها: https://github.com/WordPress/gutenberg/issues/12903) ويبدو أنهم يحاولون اكتشاف نهج جيد لسيناريوهات مماثلة.

إليك ما أقترحه ، وهو مشابه جدًا لمنهجك:

  • لدينا طريقة مساعدة is_using_gutenberg تخبرك إذا تم كتابة منشور معين باستخدام Gutenberg. أعتقد أنه يمكننا استخدام هذا ، ضمن طريقة update_syndicate ، لتحديد ما إذا كان المنشور يستخدم Gutenberg أم لا
  • إذا كان الأمر كذلك ، فيمكننا إضافة إجراء جديد ، مرتبط بـ rest_after_insert_{$post_type} ، يستدعي نفس طريقة update_syndicate . ثم عد مبكرًا ، لذلك لا يتم تشغيل باقي التعليمات البرمجية (ولا نحصل على تحديثات مزدوجة)
  • ونحن بحاجة أيضا للتحقق من عمل يعمل بنظام التشغيل، وذلك عندما update_syndicate يتم استدعاء أسلوب من قبل rest_after_insert_{$post_type} هوك، فهو يعرف في الواقع لتشغيل كافة التعليمات البرمجية في تلك المرحلة. شيء مثل \Distributor\Utils\is_using_gutenberg( $post ) && doing_action( 'save_post' )
  • ونظرًا لأن هذه الخطافات تستخدم وسيطات مختلفة (أحدها معرف الوظيفة ، والآخر هو كائن post) ، فسنحتاج إلى التعامل مع ذلك. أعتقد أنه يجب أن يكون الأمر بسيطًا مثل استدعاء get_post( $post_id ) ، لأن get_post يقبل إما معرّف أو كائن

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

dkotter picture dkotter في ٣١ يناير ٢٠٢٠
👍2

@ dkotter شكرا على الرد المفصل! لقد اتخذت طعنة في تنفيذ إصلاح بناءً على اقتراحاتك ووجدت مشكلة أخرى لم أفكر فيها من قبل. :)

إضافة شيء مثل

if ( \Distributor\Utils\is_using_gutenberg( $post ) && doing_action( 'save_post' ) ) {
    add_action( "rest_after_insert_{$post->post_type}", array( '\Distributor\InternalConnections\NetworkSiteConnection', 'update_syndicated' ) );
    return;
}

يجعل تحديث المقالة المجمعة يعمل مع كل من المحرر الكلاسيكي ومع Gutenberg باستخدام أي مربعات تعريف قديمة. ولكنه يتعطل عند استخدام Gutenberg مع مربعات التعريف القديمة لأنه يتم حفظها في طلب نشر منفصل يتم تشغيله بعد طلب الباقي الذي لا يؤدي إلى تشغيل الخطاف rest_after_insert_{$post->post_type} ، مما يعني أن البيانات الوصفية من مربعات التعريف القديمة لا يتم تجميعها عند التحديث.

كما تقول ، لا يبدو أن هناك طريقة رائعة للتعامل مع هذا الموقف ، ولكن إضافة ! isset( $_GET['meta-box-loader'] ) إلى عبارة if أعلاه تجعلها تعمل على الأقل. سيعني هذا أن المنشور المحدث يتم نشره مرتين في حالة استخدام Gutenberg وبيانات التمثيل الغذائي القديمة ، ولكن أعتقد أن هذا أفضل من أن يتم الترويج له جزئيًا وهذه هي الطريقة التي يعمل بها حاليًا.

لذا يبدو لي أن إضافة هذا إلى طريقة update_syndicated (بقدر ما تمكنت من اختباره) لجعل هذا العمل رائعًا مع كل من المحرر الكلاسيكي و Gutenberg و "حسنًا" مع Gutenberg باستخدام مربعات التعريف القديمة:

if ( \Distributor\Utils\is_using_gutenberg( $post ) && doing_action( 'save_post' ) && ! isset( $_GET['meta-box-loader'] ) ) {
    add_action( "rest_after_insert_{$post->post_type}", array( '\Distributor\InternalConnections\NetworkSiteConnection', 'update_syndicated' ) );
    return;
}

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

lakrisgubben picture lakrisgubben في ٧ فبراير ٢٠٢٠

lakrisgubben شكرًا لاختبار ذلك. كنت أعلم أن Gutenberg قدم طلبين إذا كان لديك مربع تعريف مخصص (والذي تسبب في حدوث مشكلات في مشاريع أخرى) لكنني أعتقد أنني لم أدرك أن الخطافات rest لا تنطلق في تلك الحالات (أعتقد أنها فقط إطلاق إذا تم تسجيل الميتا باستخدام register_post_meta وكانت قيمة show_in_rest صحيحة).

يبدو أنه يجب دائمًا تعيين متغير meta-box-loader إذا كنا نعالج meta المخصص ، على الرغم من أنه يبدو غير مثالي للاعتماد على ذلك. ولكن لا يبدو أن هناك طريقة أساسية لحل هذا الأمر وجميع الأساليب الأخرى التي ذكرتها تبدو غير مثالية ، لذلك أعتقد أن هذه طريقة جيدة للمضي قدمًا.

يسعدني اختبار العلاقات العامة إذا كان لديك الوقت لوضع ذلك معًا. شكرا لكل الجهد هنا!

dkotter picture dkotter في ٨ فبراير ٢٠٢٠

تمرير dkotter أولاً في العلاقات العامة هنا: https://github.com/10up/distributor/pull/518

lakrisgubben picture lakrisgubben في ٨ فبراير ٢٠٢٠
هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

avag-novembit picture avag-novembit  ·  3تعليقات
wisnetmaster picture wisnetmaster  ·  7تعليقات
aaronware picture aaronware  ·  6تعليقات
jeffpaul picture jeffpaul  ·  4تعليقات
jmslbam picture jmslbam  ·  5تعليقات