Woo-poly-integration: Problemas com produtos variáveis

Tenho o mesmo problema, se copio de idiomas primários, mostro apenas produtos simples, sem a possibilidade de copiar variação. Como posso resolver isso?

Olá,

Você tentou instalar o plugin "jQuery Migrate Helper"?

Você pode usar o código do repositório, baixar zip diretamente do download do código e instalar, acho que pode ser resolvido, estarei testando muito na próxima semana, mas todo feedback é bem-vindo.

Você pode usar o código do repositório, baixar zip diretamente do download do código e instalar, acho que pode ser resolvido, estarei testando muito na próxima semana, mas todo feedback é bem-vindo.

Depois de baixar o zip e instalar do GitHub, tenho 2 problemas:
1) Se eu copiar um produto do idioma principal para o secundário, ele criará muitas variações (por exemplo, se eu tiver um produto com 2 cores, o segundo idioma criará 10 variações da cor)
2) Após o pedido de um cliente, o produto fica sem estoque, mesmo que ainda haja estoque.

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)

Estou tendo o mesmo problema com a versão GitHub do plugin

Parece que o último PR # 518 estragou algo relacionado a produtos variáveis.

Ok, eu li o tópico, agora o problema é um erro de ortografia em um atributo meta. Podemos resolver com uma consulta de atualização e corrigir o nome em src / Hyyan / WPI / Plugin.php?
@mrleemon vi que você é um colaborador deste projeto, se me der algumas orientações sobre esse erro posso tentar uma solução e disponibilizá-la para a comunidade.

Desculpe, só cometi algumas correções para erros de digitação há muito tempo. Meu conhecimento do funcionamento interno deste plugin é quase zero.
Não sei o que deve ser feito para consertar esse bug de variações.

No momento, acho que o único que sabe como esse plugin funciona é @ Jon007

Eu vi que o # 518 incluía esse erro de digitação que já rejeitei no # 450, pois provavelmente quebraria os sites existentes, mas @hyyan aceitou ...

Eu reverti # 518 por enquanto. E eu vou dar uma olhada mais profunda mais tarde

Obrigado!

Talvez o plug-in deva usar o filtro oficial Polylang pll_copy_taxonomies para sincronizar taxonomias WooCommerce (product_type, product_visibility e outros) em vez da forma personalizada atual, que parece vulnerável aos constantes lançamentos WooCommerce. O plugin já usa o filtro Polylang pll_copy_post_metas para copiar o meta do produto, então parece razoável usar pll_copy_taxonomies para sincronizar as taxonomias do produto.

Com este filtro, pode-se especificar as taxonomias que se deseja sincronizar ou copiar e o Polylang se encarrega da sincronização / cópia dessas taxonomias e seus termos relacionados quando se cria uma nova tradução.

Apenas uma ideia.

Eu olhei para isso, mas tudo isso está se tornando perigosamente obsoleto, à medida que o woocommerce se move mais em direção a sua própria API e suas próprias tabelas, você não pode confiar em tratar produtos como um post e usar apis baseados em post genéricos. Na melhor das hipóteses, haverá bugs com o mecanismo de armazenamento em cache do woocommerce.

Sim, eu sei disso. Eu estava pensando nisso como uma solução temporária enquanto esperamos pelas mudanças da API WC.
Enquanto isso, acho que podemos resolver a seleção incorreta de "Produto Simples" quando o produto é variável alterando o código JS em Meta.php para:

A partir de:

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

Para:

$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, o uso de attr() e removeAttr() para selecionar / desmarcar opções está obsoleto com as mudanças recentes do jQuery no WP.

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

Além disso, agora, quando o usuário clica no link do produto duplicado WC, o tipo de produto não é copiado sobre a réplica.

Eu "consertei" adicionando isto à função unlinkOrginalProductTranslations() em Duplicator.php :

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

Não sei se há algo errado com isso.

Eu gostaria de me livrar de '_translation_porduct_type' completamente, ele não deveria ser realmente necessário, ele está lá apenas para lidar com peculiaridades da interface do usuário, no entanto, o mais simples por agora é mantê-lo e fazer o que você sugere

Eu ia te perguntar sobre isso. Por que o tipo de produto traduzido está armazenado em _translation_porduct_type ? Não pode ser recuperado diretamente do produto original quando necessário?

Eu acho que é complicado porque ao traduzir polylang há tentando dar a você os detalhes do produto traduzido quando você pede o produto antigo, pelo menos, copiá-lo nos metadados é mais fácil

Acho que, para se livrar do _translation_porduct_type meta, o plug-in deve usar a função WC API WC_Product:save() para armazenar traduções em vez de depender de uma solução personalizada usando wp_insert_post ação diretamente, mas isso significa refatorar muito do código encontrado em Meta.php e não sei por onde começar.

Oi. Você resolveu este problema?

Olá, comprometi-me com algumas soluções para os problemas de produtos variáveis, incluindo alguma explicação sobre # 430 - seria ótimo se alguém pudesse testar o código mais recente e confirmar quais problemas permanecem - de preferência em um novo problema de github limpo, já que houve muitos parcialmente ou bilhetes totalmente duplicados e cada vez mais difíceis de seguir.

Obrigado pelo seu trabalho! Vou testar o código mais recente quando puder e avisarei você se houver algum problema.

Abri um problema depois de testar seu código mais recente:
https://github.com/hyyan/woo-poly-integration/issues/526

@hyyan @mrleemon Eu verifiquei algumas mudanças importantes na semana passada e

Em particular, removi a correção de contorno de @mrleemon em # 408 comentando a chamada meta.php para:
$ this-> syncSelectedproductType ($ ID);

Anteriormente, tínhamos esse problema porque a sequência de salvamento não estava correta, pelo menos no 5.0 era:

1. WordPress salva postagem
2. woopoly sincroniza a postagem (mas o WooCommerce ainda não foi salvo, então o tipo de produto não foi salvo e sincronizado corretamente)
3. WooCommerce salva produto
4. [para produto variável, WooCommerce salva variações e woopoly as sincroniza]
5. Ao visualizar a tradução do produto, a solução alternativa redefinir o formulário para mostrar o tipo de produto no _translation_porduct_type para que, ao salvar a tradução, esteja correto

As revisões de código agora pegam os ganchos logo após o salvamento do WooCommerce e foram ajustadas para trabalhar na edição rápida (# 549) e na edição em massa também para que as soluções alternativas do tipo de produto não sejam mais necessárias.

Claro que isso não é tudo - a coisa toda deve ser revisada para usar apenas a api woo e evitar a api wp - mas deve remover alguns dos comportamentos estranhos.

Excelente! Essa solução alternativa foi realmente terrível.
Então, o erro ortográfico _translation_porduct_type meta não é mais necessário?
Vou testar esta versão atualizada quando tiver um minuto.

Obrigado!

Deixei a meta atribuição _translation_porduct_type com erro ortográfico lá por enquanto, mas ela não é usada. Se esta versão for ok, um lançamento subsequente pode remover este e outros códigos redundantes

Testei esta nova versão e encontrei um problema:

1. Tenho um site com três idiomas (espanhol, inglês e francês). O espanhol é o padrão. A opção de sincronização "Tipo de produto" no woopoly está marcada.
2. Eu adiciono um novo produto em espanhol
3. Seleciono "Produto agrupado" (ou qualquer tipo de produto diferente de "Produto simples") e salvo.
4. A lista suspensa de tipo de produto mostra o tipo de produto selecionado.
5. Clico em qualquer link "+" na metabox "Idiomas" para adicionar uma tradução.
6. A lista suspensa de tipo de produto na nova tradução está desabilitada (a opção de sincronização "Tipo de produto" está marcada), mas mostra "Produto simples" em vez do tipo de produto selecionado no idioma padrão do produto.

Ok, sim, vou dar uma olhada.
Alterar os tipos de produtos (e qualquer outra propriedade) em produtos existentes deve ser adequado.

@mrleemon fez check-in: em novas traduções, é necessário manter o gancho wordpress, pois o gancho woo ainda não foi acionado

Ok, obrigado!
Vou testá-lo mais tarde, quando tiver um momento, e voltarei para você o mais rápido possível.

Testei essa nova versão e meu problema com as novas traduções foi corrigido.
Obrigado!