Як мені найкраще обробляти дії користувацьких сторінок плагіна?

Я постійно стикаюся з тим самим роздратуванням, тому я подумав, що побачу, чи є там якісь ідеї чи досвід ...

Я створив плагін, який використовує власну сторінку адміністратора. Це повинно. Тепер, коли я розібрав речі WP_List_Table (), я повинен сказати, що це чудово ... але ....

Спеціальні сторінки плагінів завжди завантажуються так, як admin.php?page=...тільки я не хочу завантажувати їх безпосередньо з каталогу плагінів, чого я не хочу. Тепер, якщо я роблю 'дію' на цій сторінці, мені потрібно якось обробити це, а потім переадресувати назад на сторінку без параметра дії. Неважливо, чи справді я GET чи POST, дійсно.

На всіх внутрішніх сторінках WP робить це на одній сторінці, він перевіряє, чи є дія, якщо це обробляє, а потім перенаправляє до себе без дії. Це можливо, оскільки на цих сторінках admin-headerще не завантажено.

Якщо ви спробуєте це зробити на своїй власній сторінці, половина інтерфейсу адміністратора вже надіслана до браузера, тому перенаправлення вже неможливо. Зрозуміло, що рішення полягає в POST / GET безпосередньо на іншій сторінці, завантажте на неї рамки WP, виконайте обробку і перенаправлення назад на початкову сторінку ... але ... це трохи дратує, тому що ... мій оригінал сторінка завантажується за допомогою зворотного дзвінка, тому вона працює в методі мого класу. Це прекрасно.

Якщо я завантажую окрему сторінку, мені доведеться вручну включати wp-load.phpта знаходитись поза моїм класом, що дратує, і в моєму конкретному випадку особливо клопоче мене, тому що я створюю лише свій анонімно мій клас плагінів, щоб ніхто не мав доступу до нього ззовні.

Тож після цієї тривалої історії ... хтось придумав гарне рішення завантажити іншу сторінку за допомогою зворотного дзвінка, не маючи навколо себе весь інтерфейс адміністратора?

(Я знаю вирішення ... Я можу підключити функцію, load-....яка перевіряє параметр дії та робить обробку та переадресацію. Але мені цікаво, чи є кращий спосіб.)

Спасибі.

Як правило, ви повинні використовувати запит POST для більшості дій, щоб переконатися, що вони не виконані випадково . Але також є хорошою практикою переадресовувати на звичайну сторінку після запиту POST, щоб запобігти виконанню дублікатів, коли користувач оновлює сторінку.

Тож потік такий:

1. Ваша сторінка плагіна з формою POST, на яку подається
2. Сторінка, яка обробляє запит, на яку переспрямовується
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
}

Я підходив до цього дещо інакше, просто додавши noheader = true до URL-адреси дії на сторінці, де користувач подає, виконує дію

Потім мій обробник виконує дію (тобто, як правило, додавання, оновлення або видалення), а потім закінчує wp_redirect () до наступної дії сторінки (наприклад, додати сторінку -> редагувати сторінку, видалити сторінку -> сторінку списку, редагувати сторінку -> редагувати сторінку ). Я також передаю повідомлення за URL-адресою, щоб я міг відображати такий стан, як оновлення успішно чи не вдалося.

Цей підхід зберігає всі дії: список, додавання, редагування, видалення, групове видалення тощо в тому ж класі та з тим самим адміністратором, так що його досить легко підтримувати та розуміти.

Ще один інший підхід - це просто додавання прихованого поля введення до форми:

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

Таким чином, WordPress, здається, обробляє переадресацію автоматично.