Woo-poly-integration: إصدارات WooCommerce 3.6

أهلا. إليك خطأ متعلق بما ذكرته أعلاه.

هل يمكنك إعادة إنتاج هذه المشكلة على سمة Wordpress الافتراضية (مثل واجهة المتجر)؟
نعم

هل يمكنك إعادة إظهار هذه المشكلة عند تعطيل جميع المكونات الإضافية الأخرى باستثناء WooCommerce و Polylang و Hyyan WooCommerce Polylang Integration؟
نعم

ما إصدارات المنتج والإعدادات التي تستخدمها عند حدوث هذه المشكلة؟
PHP: 7.3.1
ووردبريس: 5.1.1
WooCommerce: 3.6.1
بوليلانج: 2.5.3
تكامل Hyyan WooCommerce Polylang: 1.3.0
المتصفح: Chrome، Firefox

خطوات التكاثر
قم بتعيين Polylang مع لغتين على الأقل
إنشاء منتج متغير في اللغة الافتراضية
قم بإنشاء ترجمة للمنتج

ما توقعت
المنتج المترجم متغير أيضًا.

ماذا حدث بدلا من ذلك
عندما أنقر لإضافة ترجمة للمنتج ، يتم تعيين نوع المنتج لتلك الترجمة على SIMPLE.
نوع المنتج غير متزامن.

تم تأكيد إصدار نوع المنتج 3.6.x - يمكنني أيضًا إعادة إنتاج هذا ويتم الإبلاغ عنه أيضًا على https://wordpress.org/support/topic/variable-products-change-to-simple-in-translated-version/

من المحتمل أن تكون مشكلة نوع المنتج ناتجة عن التخزين المؤقت المضاف إلى نوع المنتج https://github.com/woocommerce/woocommerce/pull/22612/commits/57ccde66437ade8e91d12890245d9d4c5e5e1892
هذا يعني أنه عندما يتم تحديث نوع المنتج عن طريق woopoly ، لا يتم إبطال ذاكرة التخزين المؤقت لذا تظهر بعد ذلك على أنها بسيطة ..

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

ليس لدي خبرة كبيرة في التعامل مع كود WooCommerce ، ولكن هل هناك أي معلومات عن ذاكرة التخزين المؤقت لـ WooCommerce في مكان ما حتى نتمكن من محاولة إيجاد طريقة لإصلاح هذه المشكلات؟ وفقًا للنتائج التي توصلت إليها ، هل يلزم تحديث الوظيفة copyTerms() في Meta.php ؟

https://github.com/hyyan/woo-poly-integration/blob/1d83ef23e96f35c2bb008b5fa37e5157bfc388e4/src/Hyyan/WPI/Product/Meta.php#L341

من الناحية المثالية ، يجب أن تستخدم جميع التحديثات كائنات منتج woocommerce بدلاً من كائنات Wordpress Post ، لضمان تناسق أي من جداول التخزين المؤقت على مستوى woocommerce والجداول الوسيطة (وجداول المنتج المستقبلية) دائمًا. قد لا يكون هذا صعبًا كما يبدو.

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

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

في الإصدارات القديمة حقًا من المكون الإضافي ، كان هناك استدعاء لـ $this->syncSelectedproductType($ID); في نهاية الوظيفة syncProductsMeta() عند Meta.php . إذا قمت بإعادة إضافة هذا ، فستحدد الترجمات الجديدة للمنتجات المتغيرة الخيار الصحيح في القائمة المنسدلة لنوع المنتج.

mrleemon نعم الذي يعمل على إصلاح مشكلة نوع المنتج

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

يبدو أن المزامنة العامة للمنتج جيدة أيضًا (تخضع لمزيد من الاختبارات) ، فقط جدول wc_product_meta_lookup الجديد لم يتم تحديثه وأعتقد أن هذا يؤثر حاليًا على الفرز فقط.

لذلك ، نحتاج إلى نسخ خصائص المنتج مباشرةً باستخدام وظائف WooCommerce CRUD بدلاً من الاعتماد على مرشح pll_copy_post_metas كما هو الحال الآن ، أليس كذلك؟

حسنًا ، يبدو أن الميتا نفسها تعمل ، فقط هناك خطر من إمكانية تخزينها مؤقتًا ، على سبيل المثال هنا هو التخزين المؤقت woocommerce المضافة لسمات التباين:

    public function read_variation_attributes( &$product ) {
        global $wpdb;

        $variation_attributes = array();
        $attributes           = $product->get_attributes();
        $child_ids            = $product->get_children();
        $cache_key            = WC_Cache_Helper::get_cache_prefix( 'product_' . $product->get_id() ) . 'product_variation_attributes_' . $product->get_id();
        $cache_group          = 'products';
        $cached_data          = wp_cache_get( $cache_key, $cache_group );

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

لا أعرف ما إذا كانت وظيفة WC التالية مفيدة لنسخ بيانات المنتج عند إنشاء ترجمات جديدة:

https://docs.woocommerce.com/wc-apidocs/source-class-WC_Admin_Duplicate_Product.html#134

يستخدم عامل التصفية woocommerce_duplicate_product_exclude_meta لاستبعاد نسخ حقول التعريف وخطاف woocommerce_product_duplicate_before_save لتعديل عنصر المنتج بشكل أكبر قبل إنشائه.

mrleemon شكرا .. نحن لا

في غضون ذلك ، لدي حل آخر سأقوم بالتحقق منه.

mrleemon لقد قبلت اقتراحك لـ $ this-> syncSelectedproductType ($ ID) ؛ وأضفت وظيفة للتأكد من مسح ذاكرة التخزين المؤقت لمنتج الترجمة وتحديث جداول البحث.

هذا يعالج جميع القضايا 3.6 المبلغ عنها حتى الآن.
لكنها ليست مراجعة كاملة للكود ...

mrleemon شكرا .. نحن لا

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

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

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

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

أهلا! هل تم إصلاح هذا الخطأ؟ تشير إدخالات التغيير الأخير إلى أنه تم إصلاح التوافق مع WC 3.6 ، ولكن هذه المشكلة لا تزال مفتوحة. ما هو الوضع؟ أيضًا ، هل من الممكن تحديث المكون الإضافي الذي تم توزيعه بواسطة WP (https://wordpress.org/plugins/woo-poly-integration/)؟

راجع للشغل ، الكثير من الشكر للحفاظ على هذا البرنامج المساعد لجميع الأشخاص المعنيين!

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

يُفضل دائمًا الحصول على مزيد من التعليقات من المستخدمين الأوائل قبل الإصدار الكامل على WordPress: هناك العديد من الإعدادات المختلفة وسيناريوهات الاستخدام التي تجعل الاختبار الكامل مستحيلًا في الواقع خاصة عند النظر في المكونات الإضافية الأخرى - كان علي بالفعل التراجع عن تغيير واحد بعد قبوله لأن تغيير التوافق لصالح مكون إضافي كسر التوافق مع المكونات الإضافية الأخرى (حدد سعرك مقابل محولات العملات).

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

ما زلت أواجه هذا الخطأ في Hyyan WooCommerce Polylang Integration الإصدار 1.4.3 على wp5.2.2

يؤدي تحميل المحرر لمنتج متغير إلى إزالة بيانات المنتج المتغيرة ، حتى أن إعادة حفظ بيانات المنتج المتغيرة غير فعالة.

لم يغير تعطيل وإعادة تمكين Hyyan هذا السلوك
كان هناك مؤخرًا تحديث لـ Polylang
https://wordpress.org/plugins/polylang/#developers
2.6.2 (2019-07-16)
المؤيد: إصلاح بطء المسؤول في حالة تعذر الوصول إلى خادم تحديث الترجمات
المؤيد: قيمة الإصلاح غير مترجمة بشكل صحيح لحقول استنساخ ACF في المكرر
إصلاح ترجمات السلاسل المختلطة عند التسجيل عبر التوافق مع WPML. # 381

مرحبًا ، Oclair ، يرجى ملاحظة أن الإصلاح لا يزال يعمل حتى مع آخر تحديثات Polylang و WooCommerce ، لذلك إذا كنت تواجه مشكلة ، فيرجى طرح مشكلة جيثب منفصلة مع التفاصيل الكاملة.

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

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

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

شكرا مرة أخرى ، أتمنى لك واحدة لطيفة!

مرحبًا ، Oclair ، يرجى ملاحظة أن الإصلاح لا يزال يعمل حتى مع آخر تحديثات Polylang و WooCommerce ، لذلك إذا كنت تواجه مشكلة ، فيرجى طرح مشكلة جيثب منفصلة مع التفاصيل الكاملة.

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

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

ربما يخطر المكون الإضافي المسؤول إذا كانت هناك مشكلة في جافا سكريبت هذه؟
قد يكون من الصعب اكتشافه والتصرف بناءً عليه: إذا كانت مشكلة جافا سكريبت هي عدم تنفيذها مطلقًا ، فلن يكون بمقدورها إصدار تنبيه ..

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