Distributor: A meta de postagem nunca é realmente excluída na extremidade receptora

Criado em 6 dez. 2018 · 3Comentários · Fonte: 10up/distributor

Observado em # 258 / # 259:

set_meta() nunca realmente exclui qualquer meta de postagem. Isso parece sempre ter sido um problema, mas foi exacerbado por um bug que introduzimos em 1.3.4 que estava duplicando valores meta vazios que agora estão presos no lugar devido à maneira update_post_meta() funciona com valores anteriores.

Ainda não sei qual é a coisa certa a fazer. Poderíamos:

Tenha menos desempenho e apague tudo que não estiver na lista negra antes de adicionar novamente
Tente fazer alguns truques cortando os meta arrays existentes e comparando-os com o comprimento dos novos dados e excluindo aqueles que não estão mais representados. O problema com isso é que, para essas situações em que temos valores duplicados (não sei se há um momento em que isso é uma coisa válida que as pessoas querem fazer ??), ele vai limpar todo o meta do post com o mesmo valor independentemente de quantos itens devem existir. Eles serão adicionados de volta, provavelmente, mas isso ainda parece uma rotina estranha.
Outra coisa que não consegui pensar ainda

Acho que a maior questão para começar é: que tipo de situação haveria em que o post distribuído tivesse meta que o post de origem não tinha e precisa manter?

@ tlovett1

bug meta needs discussion

Fonte

helen

Todos 3 comentários

Criou um PR (https://github.com/10up/distributor/pull/419) onde implementou a funcionalidade 'excluir meta'. Fazendo verificações durante a pós-redistribuição (no método SubscriptionsController::receive_item(..) ) comparando os metadados da solicitação anterior armazenados (armazenados na meta chave dt_subscription_update post) com a nova e excluindo a meta meta existente na solicitação anterior mas não existe no atual.

avag-novembit em 28 jun. 2019

Discutimos esse problema com @avag-novembit e gostaria de acrescentar minhas idéias, espero que ele forneça mais informações sobre nossa abordagem e explique as relações públicas enviadas por @avag-novembit.

A base é a seguinte - É obrigatório e seguro excluir parte da postagem (neste caso, post meta), se ela tiver sido adicionada / modificada pelo Distribuidor. Em outras palavras, se deletarmos parte da postagem, que foi gerada pelo Distribuidor, está tudo bem e esperado, mas se deletarmos dados não distribuídos, de alguma forma gerados diretamente no destino - não é OK e inesperado.

Por exemplo, podemos ter um plugin na origem e no destino, e esse plugin pode adicionar / atualizar um meta em certos eventos, ele também pode deletar este meta de todos os posts sobre desativação, agora, quando iremos desativar este plugin na fonte e então atualizar uma postagem, o Distribuidor excluirá este meta no destino também e isso pode gerar problemas imprevisíveis, mas esses problemas são esperados para o mantenedor do site de destino, da mesma forma que poderíamos ter problemas ao adicionar metadados da origem.

A exclusão será inesperada para o mantenedor se o Distribuidor nunca tiver distribuído esses dados, mas de repente decidirá excluí-los. É por isso que queremos ter certeza de que a atualização mais recente da fonte trouxe esses dados, que queremos excluir agora.

Não tenho certeza se precisamos comparar os meta valores também, no caso de meta chaves duplicadas pode ser muito importante, mas por outro lado, temos muitos filtros que permitem que o código de terceiros estenda e modifique os meta valores antes que eles sejam inseridos no banco de dados (por exemplo, nosso addon ACF irá mapear o meta valor, se ele contiver um ID de anexo), no entanto, no meu ponto de vista, esses dados ainda são adicionados pelo Distribuidor e devem ser excluídos, então, comparação com os meta valores precisa considerar essas modificações também.

arsendovlatyan em 18 jul. 2019

👍1

Estou movendo isso para o marco Future Release para ser considerado juntamente com uma abordagem ampla de como lidamos com a meta remoção / exclusão de sites remotos. Peço desculpas pelo atraso na resposta a este @arsendovlatyan , mas quero ser cauteloso em como lidamos com a meta-exclusão.