Woo-poly-integration: Проблемы с WooCommerce 3.6

Привет. Вот ошибка, связанная с тем, что вы упомянули выше.

Можете ли вы воспроизвести эту проблему в теме Wordpress по умолчанию (например, Storefront)?
ДА

Можете ли вы воспроизвести эту проблему, когда все остальные плагины отключены, кроме WooCommerce, Polylang и Hyyan WooCommerce Polylang Integration?
ДА

Какие версии продукта и настройки вы используете при возникновении этой проблемы?
PHP: 7.3.1
WordPress: 5.1.1
WooCommerce: 3.6.1
Полиланг: 2.5.3
Интеграция Hyyan WooCommerce с Polylang: 1.3.0
Браузер: Chrome, Firefox

Действия по воспроизведению
Установите Polylang как минимум на 2 языка
Создать переменный продукт на языке по умолчанию
Создать перевод продукта

Что я ожидал
Переведенный продукт тоже вариативен.

Что случилось вместо
Когда я нажимаю, чтобы добавить перевод продукта, тип продукта этого перевода устанавливается на ПРОСТОЙ.
Тип продукта не синхронизирован.

Тип продукта подтвержден проблема 3.6.x - я также могу воспроизвести это, и о нем также сообщается на https://wordpress.org/support/topic/variable-products-change-to-simple-in-translated-version/

Проблема типа продукта, вероятно, вызвана кешированием, добавленным к типу продукта https://github.com/woocommerce/woocommerce/pull/22612/commit/57ccde66437ade8e91d12890245d9d4c5e5e1892
это означает, что при обновлении типа продукта с помощью woopoly кеш не становится недействительным, поэтому он отображается как простой.

Это другая, но похожая проблема с новыми таблицами поиска данных о товарах: по сути, все обновления теперь должны проходить через woocommerce api, чтобы обеспечить обновление таблиц кеширования и поиска.
В настоящее время плагин расширяет возможности Polylang для копирования метаданных и таксономий постов с минимально необходимым пониманием того, какие мета и таксономии требуют копирования или перевода.
Теперь предопределенные элементы WooCommerce должны обрабатываться через сам API WooCommerce.

У меня нет большого опыта работы с кодом 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 повторно кэшировать и пересчитывать соответствующие объекты, но обновление через api будет более перспективным, и мы все могли бы обойтись с меньшими затратами на обслуживание и меньшими проблемами из будущих выпусков woocommerce. .

Информация об изменениях содержится в первой ссылке в этой ветке и примечаниях к выпуску версий точки с тех пор. Ссылку на github woocommerce выше я нашел, просматривая примечания к выпуску, которые связаны с исправлениями github.

В действительно старых версиях плагина был вызов $this->syncSelectedproductType($ID); в конце функции syncProductsMeta() в Meta.php . Если я добавлю это повторно, для новых переводов переменных продуктов выберите правильный вариант в раскрывающемся списке типа продукта.

@mrleemon да, это исправляет проблему с вариативным типом продукта, молодец!

Это немного хакерская работа - на самом деле это не исправляет основную проблему, а вместо этого использует немного javascript для синхронизации переведенной формы нового продукта с небольшим количеством woopoly meta, так что он отлично работает при сохранении продукта.

Общая синхронизация продуктов тоже в порядке (подлежит дополнительному тестированию), только новая таблица 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 должна быть обновлена, и это можно было бы сделать отдельно, обновив определенные поля через класс продукта, но было бы более эффективно, если бы все обновления выполнялись через класс продукта _relevant_, чтобы избежать повторных вызовов базы данных. Вероятно, это должен быть _relevant_ класс продукта, поскольку разные типы продуктов имеют разную обработку ..

Я не знаю, может ли следующая функция 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 этого плагина на github. Исходный код теперь - 3.4.3, который я выпущу на github после перепроверки еще нескольких пунктов.

Всегда желательно получить больше отзывов от ранних последователей перед полной версией WordPress: существует так много различных настроек и сценариев использования, что полное тестирование фактически невозможно, особенно когда рассматриваются другие плагины - мне уже пришлось отменить одно изменение после его принятия потому что изменение совместимости в пользу одного плагина нарушило совместимость с другими плагинами (назовите свою цену и переключатели валют).

Вчера WooCommerce отклонила один из моих связанных запросов на вытягивание к WooCommerce 3.6+ после его предварительного принятия - учитывая, что они не хотят, чтобы другие плагины могли повторно синхронизировать таблицу поиска продукта, поэтому в долгосрочной перспективе любой плагин wordpress, который рассматривает продукт как публикация с использованием WordPress API будет иметь проблемы. В то же время единственный надежный способ копирования данных о продукте для любого продукта (включая пользовательские типы продуктов, о которых мы не знаем) - это копирование всех имеющихся метаданных и данных таксономии (в соответствии с настройками и возможностью фильтрации курс).
Обходной путь, добавленный в 3.4, по-прежнему будет работать, но я еще раз посмотрю на него перед выпуском любого выпуска.

Я все еще испытываю эту ошибку в Hyyan WooCommerce Polylang Integration Version 1.4.3 на wp5.2.2

Загрузка редактора для переменного продукта удаляет переменные данные продукта, даже повторное сохранение переменных данных продукта неэффективно.

Отключение и повторное включение Hyyan не повлияло на это поведение
недавно было обновление для Polylang
https://wordpress.org/plugins/polylang/#developers
2.6.2 (16.07.2019)
Pro: исправить медленную работу администратора, если сервер обновления переводов недоступен.
Pro: Исправить значение, неправильно переведенное для полей клонирования ACF в репитере.
Исправьте смешанные переводы строк при регистрации через совместимость с WPML. # 381

Привет, @Oclair, обратите внимание, что исправление все еще работает даже с последними обновлениями Polylang и WooCommerce, поэтому, если у вас возникла проблема, пожалуйста, поднимите отдельную проблему на github с полной информацией.

Обратите внимание, что обходной путь включает javascript, поэтому, помимо проверки ошибок на стороне сервера, стоит проверить с помощью инструментов разработчика Chrome и проверить консоль javascript на наличие ошибок.

Возможно, на это каким-то образом влияет другая проблема или другой плагин.

Привет, спасибо за ответ и решение, а не за тривиальное предупреждение о включении javascript!
Может быть, плагин может уведомить администратора, если с этим javascript возникла проблема? потому что большинство людей не проверяют переменные продукта, если им нужно только обновить какой-то текст ....

Еще раз спасибо, хорошего вам!

Привет, @Oclair, обратите внимание, что исправление все еще работает даже с последними обновлениями Polylang и WooCommerce, поэтому, если у вас возникла проблема, пожалуйста, поднимите отдельную проблему на github с полной информацией.

Обратите внимание, что обходной путь включает javascript, поэтому, помимо проверки ошибок на стороне сервера, стоит проверить с помощью инструментов разработчика Chrome и проверить консоль javascript на наличие ошибок.

Возможно, на это каким-то образом влияет другая проблема или другой плагин.

Может быть, плагин может уведомить администратора, если с этим javascript возникла проблема?
это может быть трудная ситуация для обнаружения и принятия мер: если проблема с javascript заключается в том, что он никогда не выполняется, он не сможет выдать предупреждение.

Я фактически удалил этот обходной путь несколько версий назад, так как он мне не нравится, и я обнаружил, что в нем нет необходимости. К сожалению, изменения WooCommerce сделали это необходимым снова, и я не мог найти лучшей альтернативы.