Woo-poly-integration: Problemas do WooCommerce 3.6

Olá. Aqui está um bug relacionado ao que você mencionou acima.

Você pode reproduzir esse problema no tema padrão do Wordpress (por exemplo, Storefront)?
SIM

Você pode reproduzir esse problema quando todos os outros plug-ins estão desativados, exceto WooCommerce, Polylang e Hyyan WooCommerce Polylang Integration?
SIM

Quais versões e configurações do produto você usa quando esse problema ocorre?
PHP: 7.3.1
WordPress: 5.1.1
WooCommerce: 3.6.1
Polylang: 2.5.3
Integração Hyyan WooCommerce Polylang: 1.3.0
Navegador: Chrome, Firefox

Passos para reproduzir
Defina Polylang com pelo menos 2 idiomas
Crie um produto variável no idioma padrão
Crie uma tradução do produto

O que eu esperava
O produto traduzido também é variável.

O que aconteceu em vez disso
Quando clico para adicionar uma tradução do produto, o tipo de produto dessa tradução é definido como SIMPLES.
O tipo de produto não está sincronizado.

Tipo de produto é problema 3.6.x confirmado - eu também posso reproduzir isso e também é relatado em https://wordpress.org/support/topic/variable-products-change-to-simple-in-translated-version/

O problema do tipo de produto é provavelmente causado pelo cache adicionado ao tipo de produto https://github.com/woocommerce/woocommerce/pull/22612/commits/57ccde66437ade8e91d12890245d9d4c5e5e1892
isso significa que onde o tipo de produto é atualizado por woopoly, o cache não é invalidado, então aparece como Simples.

Este é um problema diferente, mas semelhante às novas tabelas de pesquisa de dados do produto: essencialmente, todas as atualizações agora precisam passar pela API woocommerce para garantir que o cache e as tabelas de pesquisa sejam atualizadas.
Atualmente, o plug-in estende as capacidades do Polylang para copiar pós meta e taxonomias, com o mínimo de compreensão necessário de quais meta e taxonomias requerem cópia ou tradução.
Agora, os itens WooCommerce predefinidos devem ser tratados por meio da própria API WooCommerce.

Não tenho muita experiência em lidar com o código WooCommerce, mas há alguma informação sobre o cache do WooCommerce em algum lugar para que possamos tentar encontrar uma maneira de corrigir esses problemas? De acordo com suas descobertas, a função copyTerms() em Meta.php precisa ser atualizada?

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

Idealmente, todas as atualizações devem usar os objetos Woocommerce Product em vez dos objetos Wordpress Post, para garantir que qualquer cache de nível woocommerce e tabelas intermediárias (e futuras tabelas de produtos) sejam sempre consistentes. Isso pode não ser tão difícil quanto parece.

Alternativamente, também deve ser possível atualizar como está e forçar o woocommerce a refazer o cache e recalcular os objetos relevantes, mas a atualização por meio da api seria mais preparada para o futuro, e todos nós poderíamos fazer com menos manutenção e menos problemas de versões futuras do woocommerce .

As informações sobre as mudanças estão todas no primeiro link neste tópico e nas notas de lançamento das versões pontuais desde então. O link woocommerce github acima eu encontrei olhando as notas de versão que estão vinculadas às correções do github.

Em versões realmente antigas do plugin, havia uma chamada para $this->syncSelectedproductType($ID); no final da função syncProductsMeta() em Meta.php . Se eu adicionar novamente, novas traduções de produtos variáveis ​​selecionam a opção correta na lista suspensa de tipo de produto.

@mrleemon sim, que corrige o problema do tipo de produto de variação, muito bem!

É um pouco de trabalho de hack - não corrige realmente o problema subjacente, mas em vez disso usa um pouco de javascript para sincronizar o novo formulário de produto traduzido com um pouco de meta woopoly, para que funcione bem quando o produto é salvo.

A sincronização geral do produto também parece estar bem (sujeito a mais testes), apenas a nova tabela wc_product_meta_lookup não é atualizada e acredito que atualmente afeta apenas a classificação.

Portanto, precisamos copiar diretamente as propriedades do produto usando as funções WooCommerce CRUD em vez de depender do filtro pll_copy_post_metas como agora, certo?

Bem, o próprio meta parece estar funcionando, mas existe o risco de que ele possa ser armazenado em cache, por exemplo, aqui está o cache de woocommerce adicionado para atributos de variação:

    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 alguma forma, acho que o cache está sendo limpo e funcionando, pode ser mais sorte do que design.
Ainda assim, a tabela wc_product_meta_lookup precisa ser atualizada e isso poderia ser feito separadamente, atualizando os campos específicos por meio da classe do produto, mas seria mais eficiente se todas as atualizações fossem feitas por meio da classe do produto _relevant_ para evitar chamadas repetidas de banco de dados. Provavelmente precisa ser a classe de produto _relevante_, embora diferentes tipos de produtos tenham manuseio diferente.

Não sei se a seguinte função WC pode ser útil para copiar dados do produto ao criar novas traduções:

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

Ele usa um filtro woocommerce_duplicate_product_exclude_meta para impedir que os metacampos sejam copiados e um gancho woocommerce_product_duplicate_before_save para modificar o objeto do produto antes de ser criado.

@mrleemon obrigado .. nós não duplicamos o produto assim, mas talvez pudéssemos ...?

Entretanto, tenho outra solução que irei verificar.

@mrleemon Aceitei sua sugestão para $ this-> syncSelectedproductType ($ ID); e adicionou uma função para garantir que os caches do produto de tradução sejam limpos e que as tabelas de pesquisa sejam atualizadas.

Isso aborda todos os 3.6 problemas relatados até agora.
Mas não é uma revisão completa do código ...

@mrleemon obrigado .. nós não duplicamos o produto assim, mas talvez pudéssemos ...?

Sim eu conheço. Mas, provavelmente, a longo prazo, será necessário considerar a duplicação de produtos usando as funções principais do WC, visto que a equipe WC planeja mover todos os metadados do produto da tabela wp_postmeta no futuro.

A nova postagem do produto é criada pela Polylang como uma postagem em branco com dados de taxonomia para a linguagem e traduções vinculadas e meta selecionada e este plugin estende isso de uma forma genérica para lidar com opções de meta e termos adicionais e taxonomias.

Na verdade, é melhor que os termos e taxonomias sejam copiados de forma genérica, porque então eles (geralmente) funcionam (ou podem ser feitos para funcionar com filtros) em qualquer tipo de produto (incluindo tipos de produto que não conhecemos) e qualquer plugin que adiciona metadados ou taxonomias ao produto (sobre os quais os objetos woocommerce padrão não conhecem).

O objetivo de longo prazo do WooCommerce parecia ser mover os dados do produto da própria tabela de postagens, mas isso quebra todos os plugins de extensão, então é por isso que eles criaram esta tabela de pesquisa para mitigar as limitações de desempenho para os principais campos de dados usados ​​para classificação.

Oi! Este bug foi corrigido? As últimas entradas do changelog mencionam que a compatibilidade com WC 3.6 foi corrigida, mas esse problema ainda está aberto. Qual é o status? Além disso, é possível ter o plugin distribuído pelo WP (https://wordpress.org/plugins/woo-poly-integration/) atualizado?

A propósito, muito obrigado por manter este plugin a todas as pessoas envolvidas!

Este é um tópico geral para problemas de woo3.6, não se referindo a um único problema. Problemas específicos relatados até agora foram corrigidos na primeira versão 3.4 deste plugin no github. A fonte agora é 3.4.3, que irei lançar no github depois de verificar mais alguns pontos.

É sempre preferível ter mais feedback dos primeiros usuários antes de um lançamento completo no WordPress: existem tantas configurações e cenários de uso diferentes que o teste completo é realmente impossível, especialmente quando outros plug-ins são considerados - eu já tive que reverter uma alteração depois de aceitá-la porque uma mudança de compatibilidade para o benefício de um plug-in quebrou a compatibilidade de outros plug-ins (indique o seu preço versus trocadores de moeda).

Ontem o WooCommerce rejeitou uma de minhas solicitações pull relacionadas ao WooCommerce 3.6+ após aceitá-la anteriormente - considerando que eles não querem permitir que outros plug-ins possam ressincronizar a tabela de pesquisa de produto - então, a longo prazo, qualquer plug-in wordpress que trata o produto como um postar usando a API do WordPress terá problemas. Ao mesmo tempo, a única maneira confiável até agora de copiar os dados do produto para qualquer produto (incluindo tipos de produtos personalizados que têm dados que não conhecemos) é copiar todos os metadados e dados de taxonomia que existem (de acordo com as configurações e filtráveis ​​de curso).
A solução alternativa adicionada em 3.4 ainda funcionará, mas vou dar uma olhada nela antes de qualquer lançamento.

Ainda estou enfrentando esse bug no Hyyan WooCommerce Polylang Integration versão 1.4.3 no wp5.2.2

Carregar o editor para um produto variável remove os dados variáveis ​​do produto, mesmo salvando novamente os dados variáveis ​​do produto é ineficaz.

Desativar e reativar Hyyan não alterou este comportamento
houve recentemente uma atualização do Polylang
https://wordpress.org/plugins/polylang/#developers
2.6.2 (16/07/2019)
Pro: consertar administração lenta caso o servidor de atualização de traduções não possa ser alcançado
Pro: Corrigir valor não traduzido corretamente para campos de clone ACF no repetidor
Correção de traduções de strings misturadas quando registradas por meio da compatibilidade WPML. # 381

Olá, @Oclair , observe que a correção ainda está funcionando, mesmo com as atualizações mais recentes do Polylang e do WooCommerce, portanto, se você estiver tendo um problema, indique como um problema separado do github com todos os detalhes.

Observe que a solução alternativa inclui javascript, portanto, além de verificar se há erros do lado do servidor, vale a pena inspecionar as ferramentas de desenvolvedor do Chrome e verificar se há erros no console javascript.

É possível que outro problema ou outro plugin esteja afetando isso de alguma forma.

Ei, obrigado pela resposta e solução, não é uma advertência trivial ao habilitar o javascript!
Talvez o plugin possa notificar o administrador se este javascript está tendo um problema? porque a maioria das pessoas não verifica as variáveis ​​do produto se eles só precisam atualizar algum texto ....

Obrigado mais uma vez, tenha um bom dia!

Olá, @Oclair , observe que a correção ainda está funcionando, mesmo com as atualizações mais recentes do Polylang e do WooCommerce, portanto, se você estiver tendo um problema, indique como um problema separado do github com todos os detalhes.

Observe que a solução alternativa inclui javascript, portanto, além de verificar se há erros do lado do servidor, vale a pena inspecionar as ferramentas de desenvolvedor do Chrome e verificar se há erros no console javascript.

É possível que outro problema ou outro plugin esteja afetando isso de alguma forma.

Talvez o plugin possa notificar o administrador se este javascript está tendo um problema?
pode ser uma situação difícil de detectar e agir: se o problema do javascript é que ele nunca é executado, ele não seria capaz de fazer um alerta.

Na verdade, removi essa solução alternativa algumas versões atrás, pois não gosto dela e descobri que não era necessária. Infelizmente, as alterações do WooCommerce tornaram-se necessário e não consegui encontrar uma alternativa melhor.