Woo-poly-integration: Problemas con productos variables

Tengo el mismo problema, si copio desde idiomas primarios, muestro solo productos simples, sin posibilidad de variación de copia. ¿Como puedo resolver esto?

Hola,

¿Intentó instalar el complemento "jQuery Migrate Helper"?

¿Puede usar el código del repositorio, descargar zip directamente desde el código de descarga e instalarlo? Creo que podría resolverse, lo probaré mucho la próxima semana, pero todos los comentarios son bienvenidos.

¿Puede usar el código del repositorio, descargar zip directamente desde el código de descarga e instalarlo? Creo que podría resolverse, lo probaré mucho la próxima semana, pero todos los comentarios son bienvenidos.

Después de descargar zip e instalar desde GitHub, tengo 2 problemas:
1) Si copio un producto del idioma principal al secundario, crea muchas variaciones (por ejemplo, si tengo un producto con 2 colores, el segundo idioma crea 10 variaciones del color)
2) Después del pedido de un cliente, el producto se agota incluso si todavía hay existencias.

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)

Tengo el mismo problema con la versión de GitHub del complemento

Parece que el último PR # 518 ha estropeado algo relacionado con productos variables.

Ok, leí el tema, ahora el problema es una falta de ortografía en un meta atributo. ¿Podemos resolver con una consulta de actualización y corregir el nombre en src / Hyyan / WPI / Plugin.php?
@mrleemon vi que eres un colaborador en este proyecto, si me das algunas pautas sobre este error puedo probar una solución y ponerla a disposición de la comunidad.

Lo siento, solo cometí algunas correcciones por errores tipográficos hace mucho tiempo. Mi conocimiento del funcionamiento interno de este complemento es casi nulo.
No sé qué se debe hacer para corregir este error de variaciones.

En este momento, creo que el único que sabe cómo funciona este complemento es @ Jon007

Vi que el n. ° 518 incluía esta corrección de errores tipográficos que ya rechacé en el n. ° 450, ya que es probable que rompa los sitios existentes, pero @hyyan lo ha aceptado ...

Revertí el # 518 por ahora. Y echaré un vistazo más profundo más tarde.

¡Gracias!

Tal vez el complemento debería usar el filtro oficial Polylang pll_copy_taxonomies para sincronizar las taxonomías de WooCommerce (product_type, product_visibility y otras) en lugar de la forma personalizada actual, que parece vulnerable a los constantes lanzamientos de WooCommerce. El complemento ya usa el filtro Polylang pll_copy_post_metas para copiar el meta del producto, por lo que parece razonable usar pll_copy_taxonomies para sincronizar taxonomías de productos.

Con este filtro, uno puede especificar las taxonomías que desea sincronizar o copiar y Polylang se encarga de la sincronización / copia de dichas taxonomías y sus términos relacionados cuando se crea una nueva traducción.

Solo una idea.

Lo miré, pero todos estos se están volviendo peligrosamente obsoletos, a medida que woocommerce se mueve más hacia su propia api y sus propias tablas, no puede confiar en tratar los productos como una publicación y usar apis genéricas basadas en publicaciones. En el mejor de los casos, habrá errores con el mecanismo de almacenamiento en caché de woocommerce.

Si lo sé. Estaba pensando en ello como una solución temporal mientras esperamos los cambios de la API de WC.
Mientras tanto, creo que podemos resolver la selección incorrecta de "Producto simple" cuando el producto es variable cambiando el código JS en Meta.php a:

Desde:

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

A:

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

Aparentemente, el uso de attr() y removeAttr() para seleccionar / deseleccionar opciones está obsoleto con los cambios recientes de jQuery en WP.

Desde 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.

Además, ahora mismo, cuando el usuario hace clic en el enlace de producto duplicado de WC, el tipo de producto no se copia en la réplica.

Lo "arreglé" agregando esto a la función unlinkOrginalProductTranslations() en Duplicator.php :

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

No sé si hay algo de malo en esto.

Me gustaría deshacerme de '_translation_porduct_type' por completo, en realidad no debería ser necesario, solo está ahí para hacer frente a las peculiaridades de la interfaz de usuario, sin embargo, lo más simple por ahora es mantenerlo y hacer lo que sugieras.

Te iba a preguntar sobre esto. ¿Por qué el tipo de producto traducido se almacena en _translation_porduct_type ? ¿No se puede recuperar directamente del producto original cuando sea necesario?

Creo que es complicado porque cuando se traduce polylang, hay que tratar de proporcionarle los detalles del producto traducido cuando solicita el producto anterior, al menos, copiarlo en los metadatos es más fácil.

Creo que para deshacerse de _translation_porduct_type meta, el complemento debe usar la función WC API WC_Product:save() para almacenar traducciones en lugar de confiar en una solución personalizada usando wp_insert_post acción directamente, pero esto significa refactorizar gran parte del código que se encuentra en Meta.php y no sé por dónde empezar.

Hola. ¿Has resuelto este problema?

Hola, comprometí algunas soluciones a los problemas de los productos variables, incluida una explicación sobre el n. ° 430; sería genial si alguien pudiera probar el código más reciente y confirmar qué problemas quedan, idealmente en un nuevo problema de github limpio, ya que ha habido muchos parciales o Entradas totalmente duplicadas y cada vez más difíciles de seguir.

¡Gracias por tu trabajo! Probaré el código más reciente cuando tenga la oportunidad y te avisaré si surge algún problema.

Abrí un problema después de probar su último código:
https://github.com/hyyan/woo-poly-integration/issues/526

@hyyan @mrleemon Revisé algunos cambios importantes la semana pasada y etiqueté 5.1

En particular, eliminé la solución alternativa de
$ this-> syncSelectedproductType ($ ID);

Anteriormente teníamos este problema porque la secuencia de guardado no era correcta al menos en 5.0 era:

1. WordPress guarda publicación
2. woopoly sincroniza la publicación (pero WooCommerce aún no se ha guardado, por lo que el tipo de producto no se guarda y sincroniza correctamente)
3. WooCommerce ahorra producto
4. [para productos variables, WooCommerce guarda variaciones y Woopoly las sincroniza]
5. Al ver la traducción del producto, la solución alternativa restablece el formulario para mostrar el tipo de producto en _translation_porduct_type para que al guardar la traducción sea correcta

Las revisiones del código ahora recogen los ganchos justo después de guardar WooCommerce, y se han ajustado para trabajar en la edición rápida (# 549) y la edición masiva también, por lo que las soluciones alternativas del tipo de producto ya no son necesarias.

Por supuesto, este no es el final, todo debe volver a revisarse para usar solo la API de woo y evitar la API de wp, pero debería eliminar algunos de los comportamientos extraños.

¡Estupendo! Esa solución alternativa fue realmente terrible.
Entonces, ¿el meta _translation_porduct_type mal escrito ya no es necesario?
Voy a probar esta versión actualizada cuando tenga un minuto.

¡Gracias!

Dejé la metaasignación _translation_porduct_type mal escrita allí por ahora, pero no se usa. Si esta versión funciona correctamente, una versión posterior podría eliminar este y otros códigos redundantes.

Probé esta nueva versión y encontré un problema:

1. Tengo un sitio con tres idiomas (español, inglés y francés). El español es el predeterminado. La opción de sincronización "Tipo de producto" en woopoly está marcada.
2. Agrego un nuevo producto en español
3. Selecciono "Producto agrupado" (o cualquier tipo de producto que no sea "Producto simple") y guardo.
4. El menú desplegable de tipo de producto muestra el tipo de producto seleccionado.
5. Hago clic en cualquier enlace "+" en el metabox "Idiomas" para agregar una traducción.
6. El menú desplegable de tipo de producto en la nueva traducción está deshabilitado (la opción de sincronización "Tipo de producto" está marcada) pero muestra "Producto simple" en lugar del tipo de producto seleccionado en el producto de idioma predeterminado.

Ok, sí, echaré un vistazo.
Cambiar los tipos de productos (y cualquier otra propiedad) en productos existentes debería estar bien.

@mrleemon registrado: en nuevas traducciones necesarias para mantener el gancho de wordpress ya que el gancho de cortejo aún no se ha disparado

¡OK gracias!
Lo probaré más tarde cuando tenga un momento y volveré contigo lo antes posible.

Probé esta nueva versión y se solucionó mi problema con las nuevas traducciones.
¡Gracias!