Pods: Yoast SEO-Plugin

Erstellt am 30. Dez. 2013  ·  18Kommentare  ·  Quelle: pods-framework/pods

SEO-Titel und -Beschreibung werden nicht gespeichert
https://github.com/Yoast/wordpress-seo/issues/508

Integration Inactive Puntable Help Wanted Researched Bug

Alle 18 Kommentare

In der Yoast SEO-Ausgabe können Sie lesen:

Ich denke, das bestätigt, dass es ein Problem mit dem Pods-Plugin ist, nicht mit WP SEO.

Vielleicht unangemessene Zeit von register_taxonomy() ?

Debug: Die Funktion update_term() der WPSEO_Taxonomy-Klasse ist in $wp_filter von WPs do_action() registriert
wird aber nicht angerufen

beim Speichern in einer von Pods definierten benutzerdefinierten Taxonomie
Save_taxonomy() von PodsMeta wird ZWEIMAL aufgerufen

Debug: Die Funktion update_term() der WPSEO_Taxonomy-Klasse ist in $wp_filter von WPs do_action() registriert
wird aber nicht angerufen

Haben Sie festgestellt, zu welchem ​​Zeitpunkt (zeitlich) sie die Aktion anhaken?

Zur 'init'-Zeit.
Beide sind in do_action() von WP registriert.
aber irgendwie in wp-includes/plugin. php:429 PodsMetas save_taxonomy() wird ZWEIMAL aufgerufen
und update_term() der WPSEO_Taxonomy-Klasse wird weggelassen.

Vielleicht verursacht pods_no_conflict_on() es?

aber irgendwie in wp-includes/plugin. php:429 PodsMetas save_taxonomy() wird ZWEIMAL aufgerufen

Ich werde sehen, ob ich herausfinden kann, was dieses spezielle Verhalten verursacht und ob es damit zusammenhängt.

Vielen Dank! Ich sehe, du kennst beide Plugins.

Was wir hier haben, ist ein kniffliger WordPress-Bug: http://core.trac.wordpress.org/ticket/17817 Ihre Beinarbeit hat mir viel Zeit erspart, die ich möglicherweise damit verbracht hätte, in nicht verwandten Bereichen zu stöbern. Dies war seltsam genug, um Fehler zu beheben, da es unglaublich hilfreich war.

Wie Sie vielleicht festgestellt haben, können Sie den Anruf an pods_no_conflict_on und das Problem tritt nicht mehr auf. Wir haben Pods::save in konfliktfreie Aufrufe eingeschlossen, um rekursive Aktionsaufrufe zu vermeiden, die andernfalls über save() könnten. Aufgrund des WordPress-Bugs werden jedoch, wenn wir unsere Action-Hooks entfernen, auch alle anderen Action-Hooks mit niedrigerer Priorität mitgenommen. Sie können diese Situation selbst in einem Child-Theme oder Plugin mit dem folgenden Code nachbilden:

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

Ich habe 15 als Priorität für diesen Test gewählt, da sie zwischen der Pods-Priorität von 10 und Yoasts 99 liegt. Mit diesem Code in einem Child-Theme Functions.php und den Pods, die keine Konfliktaufrufe auskommentiert, manifestiert sich das Problem immer noch.

Auf der Yoast-Seite können Sie das Problem auch beheben, indem Sie die 99-Priorität des add_action Aufrufs auf 10 oder weniger ändern.

Auch in meinen vereinfachten Tests können Sie eine eigene Aktion (die Rückruffunktion selbst kann nur eine leere Funktion sein) mit einer Priorität zwischen Pods und Yoast hinzufügen und das Problem wird behoben.

Wir stecken noch immer unsere Köpfe zusammen, weil es einen größeren Einfluss auf WordPress-Inhaltstypen im Allgemeinen hat, und wir sind stark in diese Arena involviert.

Übrigens, keine dieser Informationen ist an dieser Stelle eine vorgeschlagene Lösung. Dies sind nur Details des Fehlers und wie er sich manifestiert.

das ist für mich die passende Lösung:

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

Vielen Dank.
Ich verstehe WP und Codierung nicht genug, ich bin ein Debugger.

Ich würde remove_action aus dem Funktionsrumpf nehmen und die Funktion einfach leer lassen. Der Aufruf von remove_action sollte veranschaulichen, wie Sie den Fehler manifestieren können, ohne dass Pods ihn verursachen. Wenn das drin ist, kann dies die Angelegenheit für Sie in Zukunft möglicherweise erschweren.

Ich denke, es ist auch gut, hier zu dokumentieren, dass der Prozess, den wir hier verwenden, tatsächlich vom WordPress-Core empfohlen wird (allerdings bei einer anderen Aktion):

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

Entschuldigen Sie mich.
Warum edit_term wenn es keine zusätzlichen Felder für die benutzerdefinierte Taxonomie gibt?

Ich bin mir nicht sicher, ob dahinter eine funktionale Erklärung steckt oder ob es einfach "so war es ursprünglich geschrieben" ist. Eine gute Frage, die für 3.0-Optimierungsüberlegungen wahrscheinlich eine neue Ausgabe wert ist: Dinge nicht einhaken, von denen wir feststellen können, dass wir sie zu diesem Zeitpunkt nicht benötigen.

Ist dieses Problem noch aktiv?

Wird Pods v3 (Repeater Field) jemals veröffentlicht?

@szepeviktor Das scheint nichts mit diesem Thema zu
In jedem Fall wird die erste Version 2.8 sein (Gruppenfelder + vollständige Umgestaltung des Pods-Administrators).
Für 2.9 wiederholbare Felder siehe: #1095
Für 3.0-Schleifenfelder siehe: #1095

Zurück zum Thema, ich habe versucht, dies zu reproduzieren, und dies scheint kein aktives Problem mehr zu sein (hätte das bemerkt, da ich Yoast SEO auch bei mehreren Projekten verwende).

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen