Woo-poly-integration: Проблемы с переменными продуктами

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

Привет,

Вы пробовали установить плагин «jQuery Migrate Helper»?

Не могли бы вы использовать код из репозитория, загрузить zip прямо из кода загрузки и установить, я думаю, что это может быть решено, я буду много тестировать это на следующей неделе, но любые отзывы приветствуются.

Не могли бы вы использовать код из репозитория, загрузить zip прямо из кода загрузки и установить, я думаю, что это может быть решено, я буду много тестировать это на следующей неделе, но любые отзывы приветствуются.

После загрузки zip-архива и установки с GitHub у меня возникли 2 проблемы:
1) Если я копирую продукт с основного языка на дополнительный, он создает множество вариаций (например, если у меня продукт с 2 цветами, второй язык создает 10 вариаций цвета)
2) После заказа клиента товара нет в наличии, даже если он еще есть на складе.

1. If I copy a product from the primary language into the secondary it creates many variations, (example if I have a product with 2 colors, the second language creates 10 variations from the color)

У меня такая же проблема с версией плагина GitHub

Кажется, что последний PR # 518 напортачил в чем-то, связанном с переменными продуктами.

Хорошо, я прочитал тему, теперь проблема в неправильном написании мета-атрибута. Можем ли мы решить проблему с помощью запроса на обновление и исправить имя в src / Hyyan / WPI / Plugin.php?
@mrleemon Я видел, что вы являетесь соавтором этого проекта, если вы дадите мне несколько рекомендаций по этой ошибке, я могу попробовать решение и сделать его доступным для сообщества.

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

Сейчас я думаю, что единственный, кто знает, как работает этот плагин, - это @ Jon007.

Я действительно видел, что в # 518 есть исправление опечатки, которое я уже отклонил на # 450, так как это может привести к поломке существующих сайтов, но @hyyan принял это ...

Я вернул на данный момент # 518. И я посмотрю глубже позже

Спасибо!

Возможно, плагин должен использовать официальный фильтр Polylang pll_copy_taxonomies для синхронизации таксономий WooCommerce (product_type, product_visibility и другие) вместо текущего пользовательского способа, который кажется уязвимым для постоянных выпусков WooCommerce. Плагин уже использует фильтр Polylang pll_copy_post_metas для копирования мета продуктов, поэтому кажется разумным использовать pll_copy_taxonomies для синхронизации таксономий продуктов.

С помощью этого фильтра можно указать таксономии, которые нужно синхронизировать или скопировать, а Polylang позаботится о синхронизации / копировании указанных таксономий и связанных с ними терминов при создании нового перевода.

Просто идея.

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

Да, я знаю это. Я думал об этом как о временном решении, пока мы ждем изменений API WC.
Между тем, я думаю, что мы можем решить неправильный выбор «Простого продукта», когда продукт является переменным, изменив код JS в Meta.php на:

От:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .removeAttr("selected");%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '    .attr("selected", "selected");%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

К:

$code = sprintf(
    '// <![CDATA[ %1$s'
    . ' addLoadEvent(function () { %1$s'
    . '  jQuery("#product-type option")'
    . '     .prop("selected", false);%1$s'
    . '  jQuery("#product-type option[value=\"%2$s\"]")'
    . '     .prop("selected", true);%1$s'
    . '})'
    . '// ]]>', PHP_EOL, $type[0]
);

По-видимому, использование attr() и removeAttr() для выбора / отмены выбора устарело с недавними изменениями jQuery в WP.

С https://jquery.com/upgrade-guide/3.0/ :

Breaking change: .removeAttr() no longer sets properties to false

Prior to jQuery 3.0, using .removeAttr() on a boolean attribute such as checked, selected, or readonly would also set the corresponding named property to false. This behavior was required for ancient versions of Internet Explorer but is not correct for modern browsers because the attribute represents the initial value and the property represents the current (dynamic) value.

It is almost always a mistake to use .removeAttr( "checked" ) on a DOM element. The only time it might be useful is if the DOM is later going to be serialized back to an HTML string. In all other cases, .prop( "checked", false ) should be used instead.

Кроме того, прямо сейчас, когда пользователь щелкает ссылку на дублированный продукт WC, тип продукта не копируется поверх реплики.

Я "исправил" это, добавив это к функции unlinkOrginalProductTranslations() в Duplicator.php :

$type = $product->get_type();
update_post_meta($duplicate->get_id(), '_translation_porduct_type', $type);

Я не знаю, что с этим не так.

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

Я собирался спросить тебя об этом. Почему переведенный тип продукта хранится в _translation_porduct_type ? Нельзя ли получить его напрямую из исходного продукта, когда это необходимо?

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

Я думаю, что для того, чтобы избавиться от меты _translation_porduct_type , плагин должен использовать функцию WC API WC_Product:save() для хранения переводов вместо того, чтобы полагаться на собственное решение с использованием wp_insert_post action напрямую, но это означает рефакторинг большей части кода, найденного в Meta.php и я не знаю, с чего начать.

Привет. Вы решили эту проблему?

Привет, я предпринял несколько решений для проблем с переменными продуктами, включая некоторые объяснения по # 430 - было бы здорово, если бы кто-нибудь мог протестировать последний код и подтвердить, какие проблемы остаются - в идеале, по новой чистой проблеме с github, так как их было много частично или полностью дублированные билеты, и за ними сложно следить.

Спасибо за вашу работу! Я протестирую последний код, когда у меня будет возможность, и сообщу вам, если возникнут какие-либо проблемы.

Я открыл проблему после тестирования вашего последнего кода:
https://github.com/hyyan/woo-poly-integration/issues/526

@hyyan @mrleemon Я проверил некоторые важные изменения на прошлой неделе и отметил 5.1

В частности, я удалил исправление обходного пути @mrleemon на # 408, закомментировав вызов meta.php для:
$ this-> syncSelectedproductType ($ ID);

Раньше у нас была эта проблема, потому что последовательность сохранения была неправильной, по крайней мере, в 5.0 она была:

1. WordPress сохраняет сообщение
2. woopoly синхронизирует сообщение (но WooCommerce еще не сохранен, поэтому Тип продукта не сохраняется и не синхронизируется правильно)
3. WooCommerce сохраняет товар
4. [для вариативного продукта WooCommerce сохраняет вариации и woopoly синхронизирует их]
5. При просмотре перевода продукта исправление обходного пути сбрасывает форму, чтобы отображать тип продукта в _translation_porduct_type, чтобы при сохранении перевода он был правильным

Изменения кода теперь подхватывают крючки сразу после сохранения WooCommerce и были скорректированы для работы с быстрым редактированием (# 549) и массовым редактированием, поэтому обходные пути типа продукта больше не нужны.

Конечно, это еще не конец - все должно быть пересмотрено, чтобы использовать только woo api и избегать wp api, но следует удалить некоторые странные поведения.

Здорово! Это обходное решение было действительно ужасным.
Итак, мета _translation_porduct_type с ошибкой тоже больше не нужна?
Я собираюсь протестировать эту обновленную версию, когда у меня будет минутка.

Спасибо!

Я оставил здесь мета-присвоение _translation_porduct_type с ошибкой, но оно не используется. Если эта версия пойдет нормально, последующий выпуск может удалить этот и другой избыточный код.

Я протестировал эту новую версию и обнаружил проблему:

1. У меня есть сайт на трех языках (испанском, английском и французском). Испанский язык используется по умолчанию. В woopoly отмечена опция синхронизации "Тип продукта".
2. Я добавляю новый товар на испанском языке
3. Я выбираю «Сгруппированный продукт» (или любой другой тип продукта, кроме «Простой продукт») и сохраняю.
4. В раскрывающемся списке типа продукта отображается выбранный тип продукта.
5. Я нажимаю любую ссылку «+» в метабоксе «Языки», чтобы добавить перевод.
6. Раскрывающееся меню типа продукта в новом переводе отключено (опция синхронизации «Тип продукта» отмечена), но вместо выбранного типа продукта в языковом продукте по умолчанию отображается «Простой продукт».

Хорошо, я посмотрю.
Изменение типов продуктов (и любых других свойств) существующих продуктов должно быть нормальным.

@mrleemon отмечен : о новых переводах, необходимых для сохранения хука wordpress, поскольку хук woo еще не запущен

Хорошо спасибо!
Я протестирую это позже, когда у меня будет время, и вернусь к вам как можно скорее.

Я протестировал эту новую версию, и моя проблема с новыми переводами исправлена.
Спасибо!