WordPressでメタボックスを作成する

プラグインによってサイト構造に導入された投稿の特定のプロパティは、メタボックスを使用して設定されます。 これらは、必要なすべての設定を含むパネルです。 これらは編集画面にあります。

新しいプロパティの場合、メタボックスなしではできません
*ほとんどの投稿に関与。
*厳密な制限がある（例：特定の形式の番号）;
*文字列の形式で入力することは困難または不便です（たとえば、リストの値）。
*は相互に接続されており、1つです。

プロパティを文字列として表示でき、少数の投稿に影響し、厳密な形式制限がない場合は、投稿の編集ページでカスタムフィールドメタボックスを使用できます。

ビレット

実験目的のために、1つのスクリプトで構成される最も単純なプラグインを作成します。 metatest.phpと呼び、wp-contentに直接配置します。

プラグインをアクティブにした後、ポスト編集ページにメタボックスを表示するために最低限必要なのは次のとおりです。

<?php /* * Plugin Name: metatest */ add_action('add_meta_boxes', 'metatest_init'); function metatest_init() { add_meta_box('metatest', 'MetaTest- ', 'metatest_showup', 'post', 'side', 'default'); } function metatest_showup() { echo '<p>   </p>'; } ?> 

独自のメタボックスを作成する必要があるときに、add_meta_boxesフックがアクティブになります。 metatest_init関数を追加し、投稿編集画面のサイドパネルに「MetaTest-post parameters」ボックスを作成しました。 その内容は、metatest_showup関数によって形成されます。 結果は、「サムネイル記録」ボックスと「タグ」ボックスの間にあります。



ここでのすべての作業は、add_meta_box関数によって行われます。 その定義は次のようになります。

 function add_meta_box( $id, $title, $callback, $screen = null, $context = 'advanced', $priority = 'default', $callback_args = null) ... 

外観と内容は、最初の3つの引数で指定されます：$ id-メタボックス識別子、$ title-タイトル、$ callback-メタボックスの内容を返す関数。

画面を形成するとき、メタボックスを含むセクションに識別子$ idが与えられます。 ボックス表示を定義し、画面設定にあるチェックボックスの識別子は、「{$ id} -hide」として形成されます。



これは、スタイルを設定するとき、またはスクリプトで使用するときに役立ちます。

他のすべての引数はオプションです。

次の3つが場所を決定します。

実際、$ screen引数の値は、編集ページが意図されている投稿のタイプです。 WordPressが元々所有している標準的なもののうち、これらは「投稿」（投稿）、「ページ」（ページ）、および「添付」（メディアおよびその他の添付）です。 値が設定されていない（またはnullに等しい）場合、編集中の投稿のタイプに関係なく、メタボックスはすべての画面に表示されます。

$コンテキストで指定される位置は、次のいずれかです。「normal」-メインの編集要素-中央の列の上部。 'advanced'-追加の要素-中央の柱の下部。 'side'-サイドパネル、画面には2列あります。 手動で変更した後、WordPressはメタボックスの位置を記憶し、add_meta_boxで指定されたデフォルトを無視します。 したがって、配置に慣れるために、異なるコンテキストで同じボックスをさらに3つ追加できます。

 foreach (array('normal', 'advanced', 'side') as $context) add_meta_box('metatest_' . $context, 'MetaTest ' . $context, 'metatest_meta_box_showup', 'post', $context, 'default'); 

$ priority引数は、パネル配置の優先順位を他のものよりも設定します。 優先度が高いほど、パネルが早く描画されます。 優先順位の可能な値、降順：「高」、「コア」、「デフォルト」、「低」。

$ callback_argsでは、$コールバック関数に任意のパラメーターが渡されます。 編集可能な投稿（WP_Postクラスのインスタンス）とメタボックス情報の2つの引数を取ります。 情報は、引数add_meta_boxとほぼ同じキーを持つ配列に含まれています： 'id'、 'title'、 'callback'、および 'args'。 $ callback_argsの値は「args」に配置されます。

 function showup_fn($post, $box) { $args = $box['args']; ... } 

複数の引数を配列として渡すことができます

 array('var0' => $var0, 'var1' => $var1, ...) 

関数式の内部

 extract($box['args']); 

$ varN変数を現在のスコープに配置します。

メタデータ

メタボックスの主なタスクの1つは、投稿関連データの編集です。 「カスタムフィールド」パネルも同様のタスクを実行しますが、名前がアンダースコアで始まるフィールドは無視します。 制御されていない変更からデータを保護するには、これを覚えておく必要があります。

入力フィールドの形成と利用可能な値（またはデフォルト値）の出力は、メタボックス描画機能に割り当てられます。 データベースから情報が抽出され、入力フィールドに配置されます。

 function metatest_showup($post, $box) { //    $data = get_post_meta($post->ID, '_metatest_data', true); //   echo '<p>: <input type="text" name="metadata_field" value="' . esc_attr($data) . '"/></p>'; } 

現時点では、必要なメタデータはデータベースに含まれておらず、入力フィールドは空です。 記入してもまだ何も得られません。 保存は実装されておらず、WordPressはフィールドに応答しません。

保存機能

編集した情報は、「保存」または「公開/更新」ボタンを押してユーザーから取得します。 それを受信すると、WordPressはsave_postフックをアクティブにします。 メタデータを確認してデータベースに書き込む関数を添付する必要があります。

 add_action('save_post', 'metatest_save'); function metatest_save($postID) { ... } 

関数の最初の（この場合は唯一の）引数は、保存される投稿の識別子です。 保存された投稿自体は、get_post（$ postID）を呼び出すか、2番目の引数で取得できます。

 function metatest_save($postID, $post) ... 

この場合、受け入れられる引数の数は、4番目のadd_actionパラメーターで明示的に設定する必要があります。

 add_action('save_post', 'metatest_save', 10, 2); 

最後から2番目のパラメーターとして-関数の実行の優先順位として-デフォルト値（wp-includes / plugin.phpから）が取得されます。

'save_post'アクションは2つの引数で実行されます：投稿識別子と、WP_Postクラスのインスタンスとしての投稿自体です。 したがって、より多くの議論では意味がありません。

metatest_save関数は、プラグインの他の関数よりも少し複雑です。 彼女の計画は次のようになります。
*メタボックスからの情報の可用性を確認してください。
*受け入れている投稿を確認してください。
*ソースの信頼性を確認してください。
*データの正確性を制御し、潜在的に危険なシーケンスを排除します。
*最後に、クリーンな情報をデータベースに保存します。

チェック

ユーザーが送信するすべての情報は、グローバルな$ _POST配列にあります。 ただし、さまざまな理由でメタデータのフィールドがそうでない場合があります。自動保存時、異なるタイプの投稿の保存時、編集画面の形成中に空の投稿を作成する時などです。 その存在のテストは非常に簡単です：

 if (!isset($_POST['metadata_field'])) return; 

フィールドがない場合は、終了します。

ターゲット投稿に関連する重要なポイントがいくつかあります。

最初の瞬間-改訂。 投稿の新しいリビジョンはそれぞれ、以前の内容をリビジョン（子の変更不可能な投稿）に置き換えます。 この場合、別の 'save_post'がアクティブになり、すでにリビジョン識別子が使用されています。 したがって、metatest_save関数は2回呼び出され、呼び出しの唯一の違いは$ postIDの値です。

メタデータの所有者は投稿です。 したがって、リビジョンの保存は無視する必要があります。

 if (wp_is_post_revision($postID)) return; 

引数で渡された識別子がリビジョンに属する場合、wp_is_post_revision関数はtrueを返します。

2番目のポイントは自動保存です。 デフォルトでは、投稿の編集時に定期的に発生します-2分ごと。 この場合の情報は不完全です-投稿のテキストに関する情報のみです。 通常、この場合、$ _POST内のデータの存在を確認するだけで十分です。 しかし、将来のバージョン（3.6以降）ではメタデータの所有権は改訂されることが約束されており、WordPressの動作はプラグインに大きく依存しているため、自動保存チェックは無視されるべきではありません。

投稿用に作成された自動保存は、改訂の一種です。 その識別子に応じて、wp_is_post_revision関数もtrueを返します。 しかし、落とし穴があります：下書きを自動保存すると、save_postフックが投稿自体の識別子でアクティブになり、この関数は機能しません。

特殊なwp_is_post_autosaveについても同じことが言えます。投稿が既に自動保存されている場合にのみ機能します。

 if (wp_is_post_autosave($postID)) { //    ,  $postID //   . } 

この場合、wp_ajax_autosave関数によってtrueに設定された定数DOING_AUTOSAVEに依存する必要があります。wp_ajax_autosave関数は、自動保存されたデータを受信するときにサーバーによって呼び出されます。 （wp_ajax_autosave関数はwp-adminにあり、includes / ajax-actions.php）。 対応するコードは、たとえば次のようになります。

 if (exists('DOING_AUTOSAVE') && DOING_AUTOSAVE) return; 

発生する自動保存は、$ _POST ['action'] == 'autosave'の値によっても決定できます。

ソース認証は、入力フィールドへのフォームに埋め込まれたワンタイムコードに基づいています。 CSRFなどの攻撃からサイトを保護するのに役立ちます。 このような攻撃では、許可されたユーザーのブラウザが攻撃者のコードを実行し、このユーザーの権限でアクションを実行します。 この場合、メタデータの固有値を設定します。

インストールは、メタボックスのボディ形成コードに配置する必要があります。

 wp_nonce_field("metatest_action", "metatest_nonce");           : check_admin_referer("metatest_action", "metatest_nonce"); 

正確性管理

ターゲットポストで作業するとき、必要なフィールドがあり、ソースの信頼性に自信があるので、処理に進むことができます。

まず、保存されたメタデータの正確性を確認する必要があります。 次の2つの条件を満たす必要があります。
1）データは受け入れ可能です。
2）データは安全です。

受け入れ基準は、解決される問題に完全に依存します-転送の許容値、テキストに冒proがないことなど

セキュリティ関数update_post_metaは、データベースに関連するメタデータのセキュリティを管理します。

サイトとユーザーに関連して、データセキュリティはアプリケーションの方法によって決定されます。 制御されていないHTMLコード、解釈される任意のJavaScript、悪意のあるURLの抜け穴などがないようにしてください。

この場合、メタデータは文字列です。 したがって、不必要なスペース、ハイフネーション、および誤ったUnicode文字から彼女を救うことは理にかなっています。 これらの目的のために、引数文字列の修正バージョンを返すsanitize_text_field関数が使用されます。

 $string = sanitize_text_field($string); 

保存中

データの記録-機能の目的-は1回の呼び出しで行われます。

 update_post_meta($postID, '_metatest_data', $string); 

フィールド名が始まるアンダースコアに注意してください。 任意のフィールドパネルからフィールドにアクセスできなくなります。

まとめ

ここで、実際に提示された理論全体を適用します。 プラグインヘッダーは同じように見えますが、保存機能の登録のみが追加されます。

 <?php /* * Plugin Name: metatest */ //      //     : add_action('add_meta_boxes', 'metatest_init'); add_action('save_post', 'metatest_save'); function metatest_init() { add_meta_box('metatest', 'MetaTest- ', 'metatest_showup', 'post', 'side', 'default'); } 

メタボックス描画関数は、1回限りのコードの形成で補充され、次のようになりました。

 function metatest_showup($post, $box) { //    $data = get_post_meta($post->ID, '_metatest_data', true); //      wp_nonce_field('metatest_action', 'metatest_nonce'); //    echo '<p>: <input type="text" name="metadata_field" value="' . esc_attr($data) . '"/></p>'; } 

次に、データストレージ機能を示します。

 function metatest_save($postID) { //     ? if (!isset($_POST['metadata_field'])) return; //    ? if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) return; //    ? if (wp_is_post_revision($postID)) return; //    check_admin_referer('metatest_action', 'metatest_nonce'); //   $data = sanitize_text_field($_POST['metadata_field']); //  update_post_meta($postID, '_metatest_data', $data); } ?> 

「Hello、world！」という行を保存し、ページを更新すると、結果は次のようになります。



ご覧のとおり、最も単純なメタボックスは簡単に作成できます。 「add_meta_box」と「save_post」の2つのフックに依存し、フォーム本体の出力とデータの保存という2つの機能で構成されています。

しかし、これは出発点にすぎません。 実際には、より多くのフィールドがあり、フォームはより複雑で、データは相互に接続され、プラグインおよびテーマコンポーネントの機能と接続されています。 したがって、解決するタスクの複雑さも、メタボックスの充填も制限されません。