私はプラグインを使用していて、購読者フォーム用のカスタムフィールド(ドロップダウン)を自動生成しようとしています。なぜならそれは動的なデータ(Webサイトのコンテンツに関連する)をリストする必要があるからです。
このプラグインには、私が見ることができる限り、この目的のためのフィルタやアクションはありません。これは私がこれに対処するために別の方法で考えることを余儀なくさせます。
プラグインはカスタムテーブル(WPネイティブ/組み込みのテーブルではありません)を使用するので、データがこれらのカスタムテーブルのいずれかに保存されたときに発生するアクションまたはフィルタがあるかどうかを考えていました。
このプラグインは、おそらく(または:うまくいけば)カスタムテーブルを追加するためにwpdb
-クラスのインスタンスである$wpdb
オブジェクトを使用しました。もしそうなら(そしてその場合のみ)、その作者はおそらくrows /エントリをテーブルに追加するために$wpdb->insert()
も使うでしょう。
wpdb::insert()
を見て、その ソース を見てください。このメソッドは単に wpdb::_insert_replace_helper()
の便利なラッパーであり、$type
引数をINSERT
に設定します。このメソッドdoes notはフィルタを持っていますが、ソースはこの関数が実際に使用していることを明らかにしています
return $this->query( $this->prepare( $sql, $values ) );
wpdb::prepare()
ではフィルタによる修正はできませんが、 wpdb::query()
を見てみましょう。そこに次のフィルタがあります。
$query = apply_filters( 'query', $query );
変更を追加できるentry pointができたので、次に、データで埋められたカスタムテーブルを識別する方法について説明しましょう。実行のためにステートメントに入れ込まれるSQLステートメントを見ると、次の行に気付くでしょう。
$sql = "$type INTO `$table` ($fields) VALUES ($formats)";
$table
変数は関数定義から来ています。これは$wpdb->insert()
呼び出しの最初の引数です。通常、接頭辞を付けられたテーブルが"{$wpdb->prefix}custom_table_name"
の内側のwp_
から変更された場合に壊れたプラグインを避けるために、普通の開発者はそこでwp-config.php
を使用します。
最後に:
<?
/* Plugin Name: Do something when a custom table gets data added or altered */
add_filter( 'query', function( $query ) {
// Return SQL unmodified. Not the table we are targeting.
if ( false === strstr( $query, "{$wpdb->prefix}custom_table_name" ) ) {
return $query;
}
// Return SQL unmodified. Not the actions we are targeting.
# @TODO If you only want to act on either of them, modify the if-clause
if (
false === strstr( $query, "INSERT" )
AND false === strstr( $query, "REPLACE" )
) {
return $query;
}
# @TODO Do your custom task here and…
# …modify according the query to your likings.
return $query;
} );
このプラグインは各クエリ1つで実行されることに注意してください。 is_admin()
のようなチェックを追加し、コードのブロック全体をより排他的なフックにアタッチされた関数でラップして、実行回数を減らすことができます。さもなければあなたはあなたのサイトをかなり遅くするかもしれません。