Pods: YoastSEOプラグイン

作成日 2013年12月30日  ·  18コメント  ·  ソース: pods-framework/pods

SEOのタイトルと説明が保存されない
https://github.com/Yoast/wordpress-seo/issues/508

Integration Inactive Puntable Help Wanted Researched Bug

全てのコメント18件

Yoast SEOの問題では、次のように読むことができます。

これは、WPSEOではなくPodsプラグインの問題であることを確認していると思います。

たぶんregister_taxonomy()不適切な時間?

デバッグ:WPSEO_Taxonomyクラスのupdate_term()関数がWPのdo_action()の$ wp_filterに登録されています
呼び出されない

ポッドによって定義されたカスタム分類法に保存する場合
PodsMetaのsave_taxonomy()はTWICEと呼ばれます

デバッグ:WPSEO_Taxonomyクラスのupdate_term()関数がWPのdo_action()の$ wp_filterに登録されています
呼び出されない

彼らがどの時点で(タイミング的に)アクションをフックするかを決定しましたか?

'init'時に。
どちらもWPのdo_action()に登録されています
しかし、どういうわけかwp-includes / pluginにあります。 php:429 PodsMetaのsave_taxonomy()はTWICEと呼ばれます
また、WPSEO_Taxonomyクラスのupdate_term()は省略されています。

たぶんpods_no_conflict_on()がそれを引き起こしますか?

しかし、どういうわけかwp-includes / pluginにあります。 php:429 PodsMetaのsave_taxonomy()はTWICEと呼ばれます

この特定の動作の原因と、それが関連しているかどうかを確認できます。

どうもありがとうございました! 両方のプラグインをご存知だと思います。

ここにあるのは、WordPressのトリッキーなバグです。http

お気づきかもしれませんが、 pods_no_conflict_onへの呼び出しをコメントアウトすると、問題は発生しなくなります。 save()介して発生する可能性のある再帰的なアクション呼び出しを回避するために、競合のない呼び出しでPods::saveをラップしました。 ただし、WordPressのバグが原因で、アクションフックを削除すると、他の優先度の低いアクションフックも一緒に使用されます。 次のコードを使用して、子テーマまたはプラグインでこの状況を独自に再現できます。

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

ポッドの優先度10とYoastの99の間にあるため、このテストの優先度として15を選択しました。子テーマfunctions.phpとポッドのコードを使用すると、競合の呼び出しはコメントされませんでした。

Yoast側では、 add_action呼び出しの99の優先度を10以下に変更することで、問題を解決することもできます。

また、私の簡略化されたテストでは、ポッドとYoastの間の優先度で独自のアクションを追加でき(コールバック関数自体は空の関数にすることができます)、問題は解決します。

これは一般的にWordPressのコンテンツタイプに幅広い影響を与えるため、私たちはまだこれに頭を悩ませています。私たちはその分野に深く関わっています。

ところで、その情報のどれも現時点で提案された修正ではありません。 これは、バグの詳細とその兆候です。

これは私にとって適切な修正です:

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

どうもありがとうございました。
私はWPとコーディングを十分に理解していません。私はデバッガーです。

関数本体からremove_action取り出し、関数を空のままにします。 そこでのremove_action呼び出しは、ポッドが原因でバグを顕在化させる方法を説明するためのものでした。 そこにそれがあると、将来あなたにとって問題が複雑になる可能性があります。

ここで使用していたプロセスが実際にはWordPressコアによって推奨されているものであることをここに文書化することも良いと思います(ただし、別のアクションで):

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

すみません。
カスタム分類法に追加のフィールドがないのに、なぜedit_termをフックするのですか?

その背後に機能的な説明があるのか​​、それとも単に「それが最初に書かれた方法」なのかはわかりません。 3.0最適化の考慮事項については、おそらく新しい問題に値する良い質問です。フックする必要がないと判断できるものをフックしないことです。

この問題はまだ発生していますか?

Pods v3(リピーターフィールド)はリリースされますか?

@szepeviktorそれはこのトピックとは無関係のようです。
いずれにせよ、最初のリリースは2.8になります(グループフィールド+ポッド管理者の完全なリファクタリング)。
2.9の繰り返し可能なフィールドについては、以下を参照してください:#1095
3.0ループフィールドについては、以下を参照してください:#1095

トピックに戻って、私はこれを再現しようとしましたが、これはもうアクティブな問題ではないようです(いくつかのプロジェクトでもYoast SEOを使用しているので気づいたでしょう)。

このページは役に立ちましたか?
0 / 5 - 0 評価