Pods: Plugin Yoast SEO

dans le numéro de Yoast SEO, vous pouvez lire :

Je suppose que cela confirme qu'il s'agit d'un problème avec le plugin Pods, pas avec WP SEO.

Peut-être une heure inappropriée de register_taxonomy() ?

débogage : la fonction update_term() de la classe WPSEO_Taxonomy est enregistrée dans le $wp_filter de do_action() de WP
mais n'est pas appelé

lors de l'enregistrement dans une taxonomie personnalisée définie par les pods
Save_taxonomy() de PodsMeta s'appelle DEUX FOIS

débogage : la fonction update_term() de la classe WPSEO_Taxonomy est enregistrée dans le $wp_filter de do_action() de WP
mais n'est pas appelé

Avez-vous déterminé à quel moment (en termes de timing) ils accrochent l'action ?

Au moment 'init'.
Les deux sont enregistrés dans le do_action () de WP
mais en quelque sorte dans wp-includes/plugin. php:429 La fonction save_taxonomy() de PodsMeta est appelée DEUX FOIS
et update_term() de la classe WPSEO_Taxonomy est omis.

Peut-être que pods_no_conflict_on() en est la cause ?

mais en quelque sorte dans wp-includes/plugin. php:429 La fonction save_taxonomy() de PodsMeta est appelée DEUX FOIS

Je vais voir si je peux découvrir ce qui cause ce comportement particulier et si c'est lié.

Merci beaucoup! Je vois que vous connaissez les deux plugins.

Ce que nous avons ici est un bug WordPress délicat : http://core.trac.wordpress.org/ticket/17817 Votre travail sur les jambes m'a fait gagner beaucoup de temps que j'aurais peut-être passé à fouiller dans des domaines sans rapport. C'était assez étrange pour dépanner car c'était incroyablement utile.

Comme vous l'avez peut-être trouvé, vous pouvez commenter l'appel à pods_no_conflict_on et le problème ne se manifeste plus. Nous avons enveloppé Pods::save avec les appels sans conflit pour éviter les appels d'action récursifs qui pourraient autrement se produire via save() . En raison du bogue WordPress, cependant, lorsque nous supprimons nos crochets d'action, il prend également tous les autres crochets d'action de priorité inférieure. Vous pouvez recréer cette situation par vous-même dans un thème enfant ou un plugin avec le code suivant :

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

J'ai choisi 15 comme priorité pour ce test car il se situe entre la priorité des pods de 10 et celle de Yoast de 99. Avec ce code dans un thème enfant functions.php et les pods sans appels de conflit ont commenté le problème se manifeste toujours.

Du côté de Yoast, vous pouvez également résoudre le problème en modifiant la priorité 99 de l'appel add_action à 10 ou moins.

De plus, dans mes tests simplifiés, vous pouvez ajouter votre propre action (la fonction de rappel elle-même peut simplement être une fonction vide) avec une priorité entre Pods et Yoast et le problème disparaîtra.

Nous réfléchissons toujours à celui-ci car il a un impact plus large sur les types de contenu WordPress en général, et nous sommes profondément impliqués dans ce domaine.

BTW, aucune de ces informations n'est une solution suggérée à ce stade. Ce ne sont que des détails sur le bogue et comment il se manifeste.

c'est une solution appropriée pour moi:

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

Merci beaucoup.
Je ne comprends pas assez WP et le codage, je suis un débogueur.

Je retirerais le remove_action du corps de la fonction et laisserais simplement la fonction vide. L'appel remove_action était là pour illustrer comment vous pouvez rendre le bogue manifeste sans que les Pods ne le provoquent. Avoir cela là-dedans peut potentiellement compliquer les choses pour vous à l'avenir.

Je pense qu'il est également bon de documenter ici que le processus que nous utilisions ici est en fait ce qui est recommandé par le noyau WordPress (bien que, sur une action différente):

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

Pardon.
Pourquoi accrocher edit_term alors qu'il n'y a pas de champs supplémentaires pour la taxonomie personnalisée ?

Je ne sais pas s'il y a une explication fonctionnelle derrière cela, ou si c'est simplement "c'est comme ça que ça a été écrit au départ". Une bonne question qui mérite probablement un nouveau numéro pour les considérations d'optimisation 3.0 : ne pas accrocher des choses que nous pouvons déterminer que nous n'avons pas besoin d'accrocher à ce moment-là.

Ce problème est-il toujours actif ?

Pods v3 (champ de répétition) sera-t-il un jour publié ?

@szepeviktor Cela semble sans rapport avec ce sujet.
Dans tous les cas, la première version sera la 2.8 (champs de groupe + refactorisation complète de l'administrateur des Pods).
Pour les champs répétables 2.9, voir : #1095
Pour les champs de boucle 3.0, voir : #1095

De retour au sujet, j'ai essayé de reproduire cela et cela ne semble plus être un problème actif (je l'aurais remarqué car j'utilise également Yoast SEO sur plusieurs projets).