Woo-poly-integration: Problemas de WooCommerce 3.6

Hola. Aquí hay un error relacionado con lo que mencionaste anteriormente.

¿Puede reproducir este problema en el tema predeterminado de Wordpress (por ejemplo, Storefront)?
SÍ

¿Puede reproducir este problema cuando todos los demás complementos están deshabilitados, excepto WooCommerce, Polylang y Hyyan WooCommerce Polylang Integration?
SÍ

¿Qué versiones y configuraciones del producto está utilizando cuando ocurre este problema?
PHP: 7.3.1
WordPress: 5.1.1
WooCommerce: 3.6.1
Polylang: 2.5.3
Integración de Hyyan WooCommerce Polylang: 1.3.0
Navegador: Chrome, Firefox

Pasos para reproducir
Establecer Polylang con al menos 2 idiomas
Crear producto variable en el idioma predeterminado
Crea una traducción del producto

Lo que esperaba
El producto traducido también es variable.

¿Qué sucedió en su lugar?
Cuando hago clic para agregar una traducción del producto, el tipo de producto de esa traducción se establece en SIMPLE.
El tipo de producto no está sincronizado.

El tipo de producto es un problema 3.6.x confirmado: también puedo reproducir esto y también se informa en https://wordpress.org/support/topic/variable-products-change-to-simple-in-translated-version/

Es probable que el problema del tipo de producto se deba al almacenamiento en caché agregado al tipo de producto https://github.com/woocommerce/woocommerce/pull/22612/commits/57ccde66437ade8e91d12890245d9d4c5e5e1892
esto significa que cuando woopoly actualiza el tipo de producto, la caché no se invalida, por lo que aparece como Simple ..

Este es un problema diferente pero similar a las nuevas tablas de búsqueda de datos de productos: esencialmente, todas las actualizaciones ahora deben pasar por la API de woocommerce para garantizar que las tablas de búsqueda y almacenamiento en caché estén actualizadas.
Actualmente, el complemento amplía las capacidades de Polylang para copiar meta y taxonomías de publicaciones, con la mínima comprensión necesaria de qué meta y taxonomías requieren copia o traducción.
Ahora, los elementos predefinidos de WooCommerce deben manejarse a través de la propia API de WooCommerce.

No tengo mucha experiencia en el manejo del código de WooCommerce, pero ¿hay alguna información sobre el almacenamiento en caché de WooCommerce en algún lugar para que podamos intentar encontrar una manera de solucionar estos problemas? De acuerdo con sus hallazgos, ¿es necesario actualizar la función copyTerms() en Meta.php ?

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

Idealmente, todas las actualizaciones deberían usar los objetos de producto de woocommerce en lugar de los objetos de publicación de wordpress, para garantizar que cualquier almacenamiento en caché de nivel de woocommerce y tablas intermedias (y tablas de productos futuras) sean siempre consistentes. Puede que esto no sea tan difícil como parece.

Alternativamente, también debería ser posible actualizar tal como está y obligar a woocommerce a volver a almacenar en caché y recalcular los objetos relevantes, pero la actualización a través de la API sería más preparada para el futuro, y todos podríamos hacerlo con menos mantenimiento y menos problemas de futuras versiones de woocommerce. .

La información sobre los cambios se encuentra en el primer enlace de este hilo y en las notas de lanzamiento de las versiones de puntos desde entonces. El enlace de github de woocommerce anterior lo encontré mirando las notas de la versión que están vinculadas a las correcciones de github.

En versiones realmente antiguas del complemento, había una llamada a $this->syncSelectedproductType($ID); al final de la función syncProductsMeta() en Meta.php . Si vuelvo a agregar esto, las nuevas traducciones de productos variables seleccionan la opción correcta en el menú desplegable del tipo de producto.

@mrleemon sí, eso soluciona el problema del tipo de producto de variación, ¡bien hecho!

Es un trabajo de piratería: en realidad no corrige el problema subyacente, sino que utiliza un poco de javascript para sincronizar el nuevo formulario de producto traducido con un poco de meta de woopoly, de modo que funcione bien cuando se guarde el producto.

La sincronización general del producto también parece estar bien (sujeta a más pruebas), solo la nueva tabla wc_product_meta_lookup no está actualizada y creo que actualmente solo afecta la clasificación.

Entonces, necesitamos copiar directamente las propiedades del producto usando las funciones CRUD de WooCommerce en lugar de confiar en el filtro pll_copy_post_metas como ahora, ¿verdad?

Bueno, el meta en sí parece estar funcionando, solo existe el riesgo de que se pueda almacenar en caché, por ejemplo, aquí está el almacenamiento en caché de woocommerce agregado para los atributos de variación:

    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 );

De alguna manera creo que la caché se está borrando y esto está funcionando, eso puede ser suerte más que diseño.
Aún así, la tabla wc_product_meta_lookup debe actualizarse y esto podría hacerse por separado actualizando los campos específicos a través de la clase de producto, pero sería más eficiente si todas las actualizaciones se hicieran a través de la clase de producto _relevant_ para evitar llamadas repetidas a la base de datos. Probablemente deba ser la clase de producto _relevante_, ya que los diferentes tipos de productos tienen un manejo diferente.

No sé si la siguiente función de WC puede ser útil para copiar datos de productos al crear nuevas traducciones:

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

Utiliza un filtro woocommerce_duplicate_product_exclude_meta para excluir los metacampos de la copia y un gancho woocommerce_product_duplicate_before_save para modificar aún más el objeto de producto antes de que se cree.

@mrleemon gracias ... no

Mientras tanto, tengo otra solución que verificaré.

@mrleemon Acepté tu sugerencia para $ this-> syncSelectedproductType ($ ID); y agregó una función para garantizar que se borren las memorias caché de los productos de traducción y que se actualicen las tablas de búsqueda.

Esto resuelve todos los problemas 3.6 reportados hasta ahora.
Pero no es una revisión completa del código ...

@mrleemon gracias ... no

Sí, lo sé. Pero, probablemente, a largo plazo, será necesario considerar la duplicación de productos utilizando las funciones principales de WC, dado que el equipo de WC planea mover todos los metadatos de productos fuera de la tabla wp_postmeta en el futuro.

Polylang crea la nueva publicación del producto como una publicación en blanco con datos de taxonomía para el idioma y las traducciones vinculadas y meta seleccionada, y este complemento lo extiende de una manera genérica para manejar las opciones meta y términos y taxonomías adicionales.

De hecho, es mejor que los términos y taxonomías se copien de forma genérica porque entonces (generalmente) funcionan (o se pueden hacer que funcionen con filtros) en cualquier tipo de producto (incluidos los tipos de productos que no conocemos) y cualquier complemento que agrega metadatos o taxonomías al producto (que los objetos estándar de woocommerce no conocen).

El objetivo a largo plazo de WooCommerce parecía ser mover los datos del producto de la tabla de publicaciones en sí, pero eso rompe todos los complementos de extensión, por eso han creado esta tabla de búsqueda para mitigar las limitaciones de rendimiento para los principales campos de datos utilizados para la clasificación.

¡Hola! ¿Se ha corregido este error? Las últimas entradas del registro de cambios mencionan que se ha corregido la compatibilidad con WC 3.6, pero este problema aún está abierto. ¿Cuál es el estado? Además, ¿es posible actualizar el complemento distribuido por WP (https://wordpress.org/plugins/woo-poly-integration/)?

Por cierto, ¡muchas gracias por mantener este complemento para todas las personas involucradas!

Este es un tema general para los problemas de woo3.6 que no se refieren a un solo problema. Los problemas específicos informados hasta ahora se solucionaron desde la primera versión 3.4 de este complemento en github. La fuente ahora es 3.4.3 que lanzaré en github después de volver a verificar algunos puntos más.

Siempre es preferible tener más comentarios de los primeros usuarios antes de un lanzamiento completo en WordPress: hay tantas configuraciones y escenarios de uso diferentes que la prueba completa es realmente imposible, especialmente cuando se consideran otros complementos; ya tuve que revertir un cambio después de aceptarlo porque un cambio de compatibilidad en beneficio de un complemento rompió la compatibilidad con otros complementos (nombre su precio frente a los cambiadores de moneda).

Ayer, WooCommerce rechazó una de mis solicitudes de extracción relacionadas con WooCommerce 3.6+ después de aceptarlo previamente, considerando que no quieren permitir que otros complementos puedan resincronizar la tabla de búsqueda de productos, por lo que a largo plazo cualquier complemento de wordpress que trate el producto como un publicar usando la API de WordPress tendrá problemas. Al mismo tiempo, la única forma confiable hasta ahora de copiar datos de productos para cualquier producto (incluidos los tipos de productos personalizados que tienen datos que no conocemos) es copiar todos los datos de meta y taxonomía que existen (de acuerdo con la configuración y filtrables de curso).
La solución alternativa agregada en 3.4 seguirá funcionando, pero la analizaré de nuevo antes de cualquier lanzamiento.

Sigo experimentando este error en Hyyan WooCommerce Polylang Integration Versión 1.4.3 en wp5.2.2

La carga del editor para un producto variable elimina los datos del producto variable, incluso volver a guardar los datos del producto variable es ineficaz.

Deshabilitar y volver a habilitar a Hyyan no cambió este comportamiento
Recientemente hubo una actualización de Polylang.
https://wordpress.org/plugins/polylang/#developers
2.6.2 (16 de julio de 2019)
Ventaja: corrige la lentitud de administración en caso de que no se pueda acceder al servidor de actualización de traducciones
Ventaja: el valor fijo no se tradujo correctamente para los campos de clonación de ACF en el repetidor
Corrija las traducciones de cadenas mezcladas cuando se registran a través de la compatibilidad con WPML. N.º 381

Hola, @Oclair , tenga en cuenta que la solución sigue funcionando incluso con las últimas actualizaciones de Polylang y WooCommerce, por lo que si tiene un problema, plantee como un problema de github separado con todos los detalles.

Tenga en cuenta que la solución incluye javascript, por lo que, además de buscar errores del lado del servidor, vale la pena inspeccionar con las herramientas de desarrollo de Chrome y verificar si hay errores en la consola de JavaScript.

Es posible que otro problema u otro complemento esté afectando esto de alguna manera.

Hola, gracias por la respuesta y la solución, ¡no una advertencia trivial que habilita javascript!
¿Quizás el complemento podría notificar al administrador si este javascript tiene un problema? porque la mayoría de la gente no verifica las variables del producto si solo necesita actualizar algún texto ...

Gracias de nuevo, ¡que tengas una buena!

Hola, @Oclair , tenga en cuenta que la solución sigue funcionando incluso con las últimas actualizaciones de Polylang y WooCommerce, por lo que si tiene un problema, plantee como un problema de github separado con todos los detalles.

Tenga en cuenta que la solución incluye javascript, por lo que, además de buscar errores del lado del servidor, vale la pena inspeccionar con las herramientas de desarrollo de Chrome y verificar si hay errores en la consola de JavaScript.

Es posible que otro problema u otro complemento esté afectando esto de alguna manera.

¿Quizás el complemento podría notificar al administrador si este javascript tiene un problema?
puede ser una situación difícil de detectar y actuar: si el problema de javascript es que nunca se ejecuta, entonces no podría generar una alerta.

De hecho, eliminé esta solución hace algunas versiones porque no me gusta y descubrí que no era necesaria. Desafortunadamente, los cambios de WooCommerce lo hicieron necesario nuevamente y no pude encontrar una mejor alternativa.