Pods: Complemento de Yoast SEO

en la edición de Yoast SEO puedes leer:

Supongo que eso confirma que es un problema con el complemento Pods, no con WP SEO.

¿Quizás un momento inapropiado de register_taxonomy() ?

depuración: la función update_term () de la clase WPSEO_Taxonomy está registrada en el $ wp_filter de WP's do_action ()
pero no se llama

al guardar en una taxonomía personalizada definida por Pods
El save_taxonomy () de PodsMeta se llama DOS VECES

depuración: la función update_term () de la clase WPSEO_Taxonomy está registrada en el $ wp_filter de WP's do_action ()
pero no se llama

¿Ha determinado en qué momento (en cuanto al tiempo) enganchan la acción?

En el momento de 'init'.
Ambos están registrados en do_action () de WP
pero de alguna manera en wp-includes / plugin. php: 429 El save_taxonomy () de PodsMeta se llama DOS VECES
y la clase WPSEO_Taxonomy 'update_term () se deja fuera.

¿Quizás pods_no_conflict_on () lo causa?

pero de alguna manera en wp-includes / plugin. php: 429 El save_taxonomy () de PodsMeta se llama DOS VECES

Veré si puedo averiguar qué está causando este comportamiento en particular y si está relacionado.

¡Muchas gracias! Veo que conoces ambos complementos.

Lo que tenemos aquí es un error complicado de WordPress: http://core.trac.wordpress.org/ticket/17817 Su trabajo preliminar me ahorró mucho tiempo que podría haber pasado hurgando en áreas no relacionadas. Esto fue lo suficientemente extraño como para solucionar el problema, por lo que fue increíblemente útil.

Como puede haber descubierto, puede comentar la llamada a pods_no_conflict_on y el problema ya no se manifiesta. Hemos envuelto Pods::save con las llamadas sin conflicto para evitar llamadas de acción recursivas que de otro modo podrían suceder a través de save() . Sin embargo, debido al error de WordPress, cuando eliminamos nuestros ganchos de acción, también se llevan otros ganchos de acción de menor prioridad. Puede volver a crear esta situación por su cuenta en un tema o complemento hijo con el siguiente 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 );
}

Elegí 15 como prioridad para esta prueba, ya que se encuentra entre la prioridad 10 de Pods y la 99 de Yoast. Con ese código en un functions.php de tema infantil y los Pods, no hay llamadas de conflicto comentadas, el problema aún se manifiesta.

En el lado de Yoast, también puede solucionar el problema cambiando la prioridad 99 de la llamada add_action a 10 o menos.

Además, en mis pruebas simplificadas, puede agregar una acción propia (la función de devolución de llamada en sí misma puede ser una función vacía) con una prioridad entre Pods y Yoast y el problema se resolverá.

Todavía estamos uniendo nuestras cabezas en esto porque tiene un impacto más amplio para los tipos de contenido de WordPress en general, y estamos profundamente involucrados en ese campo.

Por cierto, ninguna de esa información es una solución sugerida en este momento. Estos son solo detalles del error y cómo se manifiesta.

esta es la solución adecuada para mí:

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 );
}

Muchas gracias.
No entiendo lo suficiente WP y codificación, soy un depurador.

Quitaría remove_action del cuerpo de la función y dejaría la función vacía. La llamada remove_action allí fue para ilustrar cómo puede hacer que el error se manifieste sin que los Pods lo causen. Tener eso ahí puede complicarle las cosas en el futuro.

Creo que también es bueno documentar aquí que el proceso que estábamos usando aquí es en realidad lo que recomienda el núcleo de WordPress (aunque, en una acción diferente):

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

Perdóneme.
¿Por qué conectar edit_term cuando no hay campos adicionales para la taxonomía personalizada?

No estoy seguro de si hay una explicación funcional detrás de eso, o si es simplemente "así es como se escribió inicialmente". Una buena pregunta que probablemente merezca una nueva edición para las consideraciones de optimización 3.0: no enganchar cosas que podamos determinar que no necesitamos enganchar en ese momento.

¿Sigue activo este problema?

¿Se lanzará alguna vez Pods v3 (campo repetidor)?

@szepeviktor Eso parece no tener relación con este tema.
En cualquier caso, la primera versión será 2.8 (campos de grupo + refactorización completa del administrador de Pods).
Para 2.9 campos repetibles, consulte: # 1095
Para campos de bucle 3.0, consulte: # 1095

Volviendo al tema, intenté reproducir esto y esto ya no parece ser un problema activo (me habría dado cuenta de que también uso Yoast SEO en varios proyectos).