Pods: Plug-in Yoast SEO

no problema Yoast SEO, você pode ler:

Eu acho que isso confirma que é um problema com o plugin Pods, não com WP SEO.

Talvez hora inadequada de register_taxonomy() ?

debug: a função update_term () da classe WPSEO_Taxonomy está registrada no $ wp_filter do WP do_action ()
mas não é chamado

ao salvar em uma taxonomia personalizada definida por Pods
O save_taxonomy () de PodsMeta é chamado DUAS VEZES

debug: a função update_term () da classe WPSEO_Taxonomy está registrada no $ wp_filter do WP do_action ()
mas não é chamado

Você determinou em que ponto (em termos de tempo) eles enganam a ação?

No momento 'init'.
Ambos estão registrados em do_action () do WP
mas de alguma forma em wp-includes / plugin. php: 429 O save_taxonomy () de PodsMeta é chamado DUAS VEZES
e a classe WPSEO_Taxonomy 'update_term () é omitida.

Talvez pods_no_conflict_on () causa isso?

mas de alguma forma em wp-includes / plugin. php: 429 O save_taxonomy () de PodsMeta é chamado DUAS VEZES

Vou ver se consigo descobrir o que está causando esse comportamento específico e se está relacionado.

Muito obrigado! Vejo que você conhece os dois plug-ins.

O que temos aqui é um bug complicado do WordPress: http://core.trac.wordpress.org/ticket/17817 Seu trabalho manual me salvou muito tempo que eu poderia ter gasto mexendo em áreas não relacionadas. Isso era estranho o suficiente para solucionar o problema, pois era incrivelmente útil.

Como você deve ter descoberto, você pode comentar a chamada para pods_no_conflict_on e o problema não se manifestará mais. Encapsulamos Pods::save com chamadas sem conflito para evitar chamadas de ação recursiva que poderiam acontecer por meio de save() . Devido ao bug do WordPress, no entanto, quando removemos nossos ganchos de ação, ele também leva outros ganchos de ação de prioridade mais baixa com ele. Você pode recriar essa situação sozinho em um tema filho ou plug-in com o seguinte código:

add_action( 'edit_term', 'test_17817', 15, 3 );
function test_17817( $term_id, $tt_id, $taxonomy ) {
    remove_action( 'edit_term', 'test_17817', 15 );
}

Eu escolhi 15 como a prioridade para este teste, pois fica entre a prioridade de Pods de 10 e Yoast de 99. Com esse código em um child-theme functions.php e os Pods, nenhuma chamada de conflito comentou o problema ainda se manifestando.

No lado Yoast, você também pode resolver o problema alterando a prioridade 99 da chamada add_action para 10 ou menos.

Além disso, em meu teste simplificado, você pode adicionar uma ação própria (a função de retorno de chamada em si pode ser apenas uma função vazia) com uma prioridade entre Pods e Yoast e o problema será resolvido.

Ainda estamos pensando nisso porque tem um impacto mais amplo para os tipos de conteúdo do WordPress em geral, e estamos profundamente envolvidos nessa área.

BTW, nenhuma dessas informações é uma correção sugerida neste momento. Estes são apenas detalhes do bug e como ele se manifesta.

esta é a solução adequada para mim:

add_action( 'edit_term', 'test_17817', 15, 3 );
function test_17817( $term_id, $tt_id, $taxonomy ) {
    // http://core.trac.wordpress.org/ticket/17817
    remove_action( 'edit_term', 'test_17817', 15 );
}

Muito obrigado.
Não entendo WP e codificação o suficiente, sou um depurador.

Eu tiraria remove_action do corpo da função e apenas deixaria a função vazia. A chamada remove_action foi para ilustrar como você pode fazer o manifesto do bug sem que os pods o causem. Ter isso aí pode complicar as coisas para você no futuro.

Eu acho que também é bom documentar aqui que o processo que estávamos usando aqui é, na verdade, o que é recomendado pelo núcleo do WordPress (embora, em uma ação diferente):

http://codex.wordpress.org/Plugin_API/Action_Reference/save_post#Avoiding_infinite_loops

Com licença.
Por que enganchar edit_term quando não há campos extras para a taxonomia personalizada?

Não tenho certeza se há uma explicação funcional por trás disso, ou se é simplesmente "é assim que foi escrito inicialmente". Uma boa pergunta que provavelmente vale a pena ser um novo problema para considerações de otimização 3.0: não enganchar coisas que podemos determinar que não precisamos enganchar no momento.

Este problema ainda está ativo?

Os pods v3 (campo repetidor) serão lançados?

@szepeviktor Isso parece não ter relação com este tópico.
Em qualquer caso, o primeiro lançamento será 2.8 (campos de grupo + refatoração completa de administração de pods).
Para campos repetíveis 2.9, consulte: # 1095
Para campos de loop 3.0, consulte: # 1095

Voltando ao tópico, tentei reproduzir isso e isso não parece ser mais um problema ativo (eu teria notado isso porque também uso o Yoast SEO em vários projetos).