カスタムプラグインページアクションを最適に処理するにはどうすればよいですか？

私は常に同じ悩みにぶつかっていますので、アイデアや経験があるかどうか見てみたいと思いました...

独自の管理ページを使用するプラグインを作成しました。しなければなりません。WP_List_Table（）を整理したので、それは素晴らしいと言わざるを得ません...しかし....

カスタムプラグインページadmin.php?page=...は、プラグインディレクトリから直接ロードする場合を除き、常にロードされますが、そうではありません。そのページから「アクション」を実行する場合、どういうわけかそれを処理してから、アクションパラメーターなしでページにリダイレクトする必要があります。GETまたはPOSTを実行しても、実際には関係ありません。

内部ページすべてで、WPは同じページでこれを行い、アクションがあるかどうかを確認し、アクションがある場合はそれを処理し、アクションなしで自分自身にリダイレクトします。これらのページでadmin-headerはまだロードされていないため、これは可能です。

ただし、自分のページで実行しようとすると、管理インターフェイスの半分が既にブラウザに送信されているため、リダイレクトはもうできません。明らかに、解決策は、別のページに直接POST / GETし、その上にWPフレームワークをロードし、処理を行ってから元のページにリダイレクトすることですが...しかし...それは少し面倒です...ページはコールバック経由でロードされるため、クラスのメソッド内で実行されます。美しいです。

別のページを読み込むと、手動でwp-load.phpクラスの外に追加する必要があり、クラスの外にいますが、これは迷惑であり、特にバグがあります。これは、プラグインクラスを匿名でインスタンス化するだけで誰にもアクセスできないためです外部から。

それで、この長い話の後に...だれかが管理インターフェイス全体を既にセットアップせずに、コールバックを介して別のページを読み込むための良い解決策を思いつきましたか？

（回避策を知っています... load-....アクションパラメーターをチェックし、処理とリダイレクトを行う関数にフックすることができます。しかし、もっと良い方法があるかどうか疑問に思っています。）

ありがとう。

plugin-development wp-admin customization

— ウィルフェル
ソース

なぜこれがタグ付けされてい[plugin-wp-pagenavi]ますか？[plugin-development]ここでは大歓迎です。

— ヤンファブリ

@Jan Fabry：何のplugin-wp-pagenaviためかわからない...私はそれがプラグインと管理メニューの相関関係に関するものだと思っていた。私の質問はそれに関連しているので、そのタグを選択しました。

— wyrfel

WP-PageNaviは、フロントエンド用のより高度なページングナビゲーションを備えたプラグインです。[admin-menu]ここで使用することもできますが、実際にそれに関連するとは思いません。タグを適切と思われるものに変更しました。もちろん、再度編集することができます。

— ヤンファブリ

@Jan Fabry：タグ付けをやり直してくれてありがとう...まだタグプール全体に精通しているわけではありませんが（明らかに）。

— ウィルフェル

回答:

経験則として、ほとんどのアクションに対してPOSTリクエストを使用して、誤って実行されないようにする必要があります。ただし、POSTリクエストの後に通常のページにリダイレクトして、ユーザーがページを更新したときに実行が重複しないようにすることもお勧めします。

そのため、フローは次のようになります。

に送信するPOSTフォームを含むプラグインページ
にリダイレクトするリクエストを処理するページ
アクションの結果を表示するプラグインページ

中央のページはプラグインページである必要はありません。これは、3年前に含まれていた「汎用POSTハンドラー」、の'admin_action_' . $_REQUEST['action']フックをadmin.php使用できることを意味します。

例のユーザーはAkismetプラグインです。確実に使用する場合は、admin.phpを含む別のページではなく、に直接送信する必要がありますadmin.php。

使用方法の非常に基本的な例を次に示します。

add_action( 'admin_action_wpse10500', 'wpse10500_admin_action' );
function wpse10500_admin_action()
{
    // Do your stuff here

    wp_redirect( $_SERVER['HTTP_REFERER'] );
    exit();
}

add_action( 'admin_menu', 'wpse10500_admin_menu' );
function wpse10500_admin_menu()
{
    add_management_page( 'WPSE 10500 Test page', 'WPSE 10500 Test page', 'administrator', 'wpse10500', 'wpse10500_do_page' );
}

function wpse10500_do_page()
{
?>
<form method="POST" action="<?php echo admin_url( 'admin.php' ); ?>">
    <input type="hidden" name="action" value="wpse10500" />
    <input type="submit" value="Do it!" />
</form>
<?php
}

— ヤン・ファブリー
ソース

ヘイ、私は再びコードを見ていきますが、私は明らかにそれを見ませんでしたが、単に確認するために...あなたが言っているのは、ページパラメータなしで直接admin.phpを呼び出すと、すべてのページがスキップされるということです読み込みと初期化を行い、フックを実行しますか？それはすごいだろう...（ページを読み込む前にフックを付けなかった理由がまだわからない）。

— ウィルフェル

@wyrfel：はい、admin.php直接呼び出すことはAkismetのソースが教えてくれた「トリック」です。フォームを表示しているときにエラーが発生した場合にフォームを再表示するのは正しいことです。宛先がプラグインページであるが、開始時にフックがあれば簡単です（成功した場合はリダイレクトするか、エラーメッセージが表示された場合は、再度フォームを作成してください）。たぶんTracチケットでそれを提案しますか？

— ヤンファブリー

チケットを提出します。回避策として、私は動作する'load-<pagehook>'フックを見つけました...それはページがロードされる前に呼び出されます...しかし、admin_action_...コンセプトは全体的にずっと良く、より具体的に見えます。また、メモでは、POSTを実行し、リロード時に再投稿したくない場合、エラーメッセージは依然として問題になりますが、それは別のトピックです。

— ウィルフェル

@wyrfel：エラーメッセージが依然として問題になるのはなぜですか？エラーメッセージがある場合は、ページにとどまり、メッセージと共にフォームを再度表示します（もちろん、ここでは更新してもあまり意味がありませんが、エラーはまだ存在し、アクションは行われないため、害はありません）実行されます）。エラーがなければ、アクションを実行し、「安全な」概要ページにリダイレクトします。これは動作します- admin_action_フックがプラグインページローダーの前に移動される場合。

— ヤンファブリ

わかりました...私は複雑すぎると考えていました。

— ウィルフェル

ユーザーが送信するアクションを実行するページのアクションURLにnoheader = trueを追加するだけで、これとは少し異なります。

その後、ハンドラーはアクション（通常、追加、更新、または削除）を実行し、次のページアクションへのwp_redirect（）で終了します（例：ページの追加->ページの編集、ページの削除->リストページ、ページの編集->ページの編集）。また、更新に成功したか失敗したかなどのステータスを表示できるように、URLにメッセージを渡します。

このアプローチでは、リスト、追加、編集、削除、一括削除などのすべてのアクションが同じクラスに同じ管理スラッグで保持されるため、保守と理解が非常に簡単です。

— ラッセル・ジェイミーソン
ソース

男、あなたは天才だ！私は2日間ずっと苦労してきましたが、必要なのは「noheader = true」の部分だけだったようです。ありがとう！

— r00m 14

別の異なるアプローチは、非表示の入力フィールドをフォームに追加するだけです。

<input type="hidden" name="page" value="your-page-slug" />

このように、WordPressはリダイレクトを自動的に処理するようです。

— simonthesorcerer
ソース