カスタムフィールドを保存するときに検証とエラー処理を追加しますか？

投稿タイプのカスタムフィールドを定義する関数があります。フィールドが「サブヘッド」であるとします。

投稿が保存されたら、入力に対して何らかの検証を行い、必要に応じて投稿編集画面にエラーメッセージを表示します。何かのようなもの：

// Handle post updating
function wpse_update_post_custom_values($post_id, $post) {

    // Do some checking...
    if($_POST['subhead'] != 'value i expect') {

        // Add an error here
        $errors->add('oops', 'There was an error.');

    }

    return $errors;

} 
add_action('save_post','wpse_update_post_custom_values',1,2);

これをsave_postアクションにフックしようとしていますが、エラーの処理方法がわかりません。関数に渡されたエラーオブジェクトは存在しないようで、独自のWP_Error objを作成してそれを返す場合、ポスト編集ページでエラーを吐き出すメカニズムによって尊重されません。

現在、カスタムメタボックス内にページ上のエラーメッセージがありますが、これは理想的とは言えません。WPが通常表示するような、大きくて赤くて上部にエラーがあります。

何か案は？

更新：

@Denisの回答に基づいて、いくつかの異なることを試しました。エラーをグローバルとして保存することは機能しませんでした。これは、Wordpressがsave_postプロセス中にリダイレクトを行うため、グローバルを表示する前に強制終了するためです。

私はそれらをメタフィールドに保存することになりました。これに伴う問題は、それらをクリアする必要があることです。そうしないと、別のページに移動しても消えないため、エラーをクリアするだけのadmin_footerに追加された別の関数を追加する必要がありました。

非常に一般的なもの（投稿の更新）のエラー処理がこれほど不格好になるとは思いませんでした。明らかな何かを見逃していますか、これが最良のアプローチですか？

// Handle post updating
function wpse_5102_update_post_custom_values($post_id, $post) {

    // To keep the errors in
    $errors = false;

    // Do some validation...
    if($_POST['subhead'] != 'value i expect') {

        // Add an error here
        $errors .= 'whoops...there was an error.';

    }

    update_option('my_admin_errors', $errors);

    return;

} 
add_action('save_post','wpse_5102_update_post_custom_values',1,2);


// Display any errors
function wpse_5102_admin_notice_handler() {

    $errors = get_option('my_admin_errors');

    if($errors) {

        echo '<div class="error"><p>' . $errors . '</p></div>';

    }   

}
add_action( 'admin_notices', 'wpse_5102_admin_notice_handler' );


// Clear any errors
function wpse_5102__clear_errors() {

    update_option('my_admin_errors', false);

}
add_action( 'admin_footer', 'wpse_5102_clear_errors' );

エラーをクラスまたはグローバルとして、一時的またはメタに保存し、POSTリクエストの管理通知に表示します。WPは、フラッシュメッセージハンドラーを備えていません。

セッションを使用することをお勧めします。これは、2人のユーザーが同時に編集しても、奇妙な効果が生じないためです。だからこれは私がやっていることです：

セッションはワードプレスでは開始されません。したがって、プラグイン、functions.php、またはwp-config.phpでセッションを開始する必要があります。

if (!session_id())
  session_start();

投稿を保存するときに、セッションにエラーと通知を追加します。

function my_save_post($post_id, $post) {
   if($something_went_wrong) {
     //Append error notice if something went wrong
     $_SESSION['my_admin_notices'] .= '<div class="error"><p>This or that went wrong</p></div>';
     return false; //might stop processing here
   }
   if($somthing_to_notice) {  //i.e. successful saving
     //Append notice if something went wrong
     $_SESSION['my_admin_notices'] .= '<div class="updated"><p>Post updated</p></div>';
   }

   return true;
} 
add_action('save_post','my_save_post');

通知とエラーを出力してから、セッションのメッセージを消去します。

function my_admin_notices(){
  if(!empty($_SESSION['my_admin_notices'])) print  $_SESSION['my_admin_notices'];
  unset ($_SESSION['my_admin_notices']);
}
add_action( 'admin_notices', 'my_admin_notices' );

一時的なものを使用するというpospiの提案に基づいて、私は次のことを思いつきました。唯一の問題は、メッセージを下に置くためのフックがないことですh2、他のメッセージが送信さ場所のため、そこに到達するためにjQueryハックを行う必要がありました。

まず、save_post（または同様の）ハンドラーでエラーメッセージを保存します。60秒という短い有効期間を指定しているため、リダイレクトが発生するのに十分な長さです。

if($has_error)
{
  set_transient( "acme_plugin_error_msg_$post_id", $error_msg, 60 );
}

次に、次のページの読み込み時にそのエラーメッセージを取得して表示します。また、2回表示されないように削除します。

add_action('admin_notices', 'acme_plugin_show_messages');

function acme_plugin_show_messages()
{
  global $post;
  if ( false !== ( $msg = get_transient( "acme_plugin_error_msg_{$post->ID}" ) ) && $msg) {
    delete_transient( "acme_plugin_error_msg_{$post->ID}" );
    echo "<div id=\"acme-plugin-message\" class=\"error below-h2\"><p>$msg</p></div>";
  }
}

以来admin_notices、主ページコンテンツが生成される前に、他のポスト編集メッセージが行くところ私はそこにそれを移動するには、このjQueryのを使用していたので、火災、通知は、ありません：

jQuery('h2').after(jQuery('#acme-plugin-message'));

投稿IDは一時的な名前の一部であるため、複数のユーザーが同じ投稿を同時に編集している場合を除き、これはほとんどのマルチユーザー環境で機能するはずです。

ときにsave_post実行され、それが既にデータベース上のポストを救いました。

WordPressコアコード、より具体的にはwp-includes/post.phpのupdate_post()関数を見ると、データベースに保存される前にリクエストをインターセプトする組み込みの方法はありません。

しかし、フックpre_post_updateを使用header()しget_post_edit_link()て、投稿が保存されないようにすることができます。

<?php

/**
*   Performs validation before saving/inserting custom post type
*/
function custom_post_site_save($post_id, $post_data) {
    // If this is just a revision, don't do anything.
    if (wp_is_post_revision($post_id))
        return;

    if ($post_data['post_type'] == 'my_custom_post_type') {
        // Deny post titles with less than 5 characters
        if (strlen($post_data['post_title'] < 5)) {
            header('Location: '.get_edit_post_link($post_id, 'redirect'));
            exit;
        }
    }
}
add_action( 'pre_post_update', 'custom_post_site_save', 10, 2);

問題をユーザーに通知するには、次の要点を確認してください：https : //gist.github.com/Luc45/09f2f9d0c0e574c0285051b288a0f935

Javascriptを使用してフィールドを検証しないのはなぜですか？これが最善のアプローチだと思います。

上記のスクリプトを使用しようとすると、奇妙な問題に遭遇しました。更新後、編集画面に2つのメッセージが表示されます。1つは以前の保存のコンテンツの状態を示し、もう1つは現在の保存の状態を示しています。たとえば、投稿を適切に保存してからエラーを作成すると、最初の投稿は「エラー」、2番目の投稿は「OK」になりますが、同時に生成されます。スクリプトを変更して1つのメッセージ（たとえば「エラー」）のみを追加した場合、「エラー」で1つの更新を開始し、その後「OK」、「エラー」メッセージで別の更新を開始します（2度目に表示されます）。もう一度「ok」で保存する必要があります。何が間違っているのか本当にわかりません。3つの異なるローカルサーバーでテストしましたが、それぞれに同じ問題があります。

投稿編集画面のフラッシュエラー処理を追加し、必須フィールドに入力するまで投稿が公開されないようにするプラグインを作成しました。

https://github.com/interconnectit/required-fields

投稿フィールドを必須にすることができますが、提供されているAPIを使用して、カスタマイズ可能なエラーメッセージと検証機能を備えた必要なカスタムフィールドも作成できます。デフォルトでは、フィールドが空かどうかをチェックします。