Qual é a maneira recomendada de criar formulários de administração de plugins?

Eu vi e usei a seguinte técnica para adicionar scripts php ao meu plugin para manipular formulários personalizados em um plugin wordpress.

do plugin do quizzin:

$code_pages = array('quiz_form.php','quiz_action.php', 'question_form.php', 'question.php'); foreach($code_pages as $code_page) { $hookname = get_plugin_page_hookname("quizzin/$code_page", '' ); $_registered_pages[$hookname] = true; 

Por exemplo, o ‘quiz_action.php’ é usado mais tarde como alvo para um formulário de administração (esses formulários são usados ​​apenas no wp-admin)

  <form name="post" action="/quiz_action.php" method="post" id="post"> 

UPDATE: este método é discutido aqui – canvas de configuração do administrador sem menu

O comentário final abaixo por um desenvolvedor central do WordPress parece desencorajar isso:

http://wordpress.org/support/topic/how-can-i-execute-php-scripts-in-my-plugin-folder

Então, o que é melhor prática aqui? Os formulários de administração devem ser postados para wp-admin / admin.php? Action = foo ou wp-admin / edit.php? Action = bar. Como registrar essas ações? Isso está documentado em qualquer lugar? Para ser claro, esses arquivos não devem ser vinculados a partir de um menu de administração.

Estou usando o WordPress 3.0.4

Obrigado!

Solutions Collecting From Web of "Qual é a maneira recomendada de criar formulários de administração de plugins?"

Eu, pessoalmente, apenas adiciono um link de menu e na function para ele lidar com o formulário. Com $ _SERVER [‘REQUEST_URI’] como a ação. Exemplo abaixo.

 add_action("admin_menu", "menu" ); function menu(){ add_menu_page('Test form', 'Test form', 'manage_options', 'show_form' ); } function show_form(){ if ( $_SERVER["REQUEST_METHOD"] == "POST" ){ print "do stuff"; } else { ?>
< ?php } }

Basicamente, parece que existem duas maneiras de fazer isso:

1) A maneira $_registered_pages detalhada na pergunta original. Isso parece um pouco não-padrão e pode confundir alguém olhando seu código.

2) Publique seu formulário para um URL de administração como admin_url('admin.php?page=show_form') onde show_form() é um item / function de menu registrado. Dentro de show_form() , você pode ativar se um formulário foi ou não enviado. Se você pode include outro arquivo php condicionalmente, ou seja:

 function show_form() { if ( $_SERVER["REQUEST_METHOD"] == "POST" && isset($_POST['submit'])) { require_once('name_of_your_processing_script.php'); } else { //do something else. } } 

Ou apenas inclua o arquivo e faça qualquer processamento / mudança lá (provavelmente limpo).

Se você tentar e usar apenas um arquivo que você criou como ação de publicação do formulário, você receberá um erro. Conforme mencionado nos comentários acima acima, você deve impedir que seus arquivos sejam chamados diretamente e proteja e proteja contra ataques CSRF usando nonces.

Desculpas pelo longo tópico de comentários. Seria grato se as pessoas pudessem confirmar isso é o que eles queriam dizer.

Minha abordagem nos últimos 12 meses foi chamar todas as funções que processam a solicitação $ _POST ou $ _GET. Dentro de cada function, alguns valores, às vezes mais, são verificados para determinar se essa function é aplicável, ou seja, um nome de formulário e um valor específico do formulário ou URL em que a validação de dados também pode ser aplicada.

Coloco todos os $ _POST e $ _GET através de uma única function que verifica o nonce, de modo que a function nonce não seja chamada dentro de cada function. Essa function process_POST_GET () inclui () funções de processamento de formulário.

 add_action('admin_init,process_POST_GET'); 

Funciona bem e não apresenta desvantagens de desempenho. Estamos simplesmente falando sobre 100 x se (isset ()) e uma maneira muito simples de manter tudo arrumado. Eu considerei um add_action () para cada function e percebi que isso adiciona mais trabalho para o WordPress do que a minha abordagem porque ele ainda precisa chamar todas as funções.

O exemplo abaixo tem um monte de “wpecus_” porque eu não estava usando classs originalmente. Nós não precisamos prefixar tudo de outra forma.

eval ()

Hoje eu estou pensando em usar eval () para chamar a function usando o nome do formulário.

 /** * $_POST and $_GET request processing procedure. * * Checks nonce from any form or URL, then includes functions that processing submission, then includes the * file that determines which function to use to process the submission. * * @package WP e-Customers * @since 0.0.1 */ public function process_POST_GET(){ // form submission if(isset($_POST['wpecus_post_processing_required']) && $_POST['wpecus_post_processing_required'] == true){ if(isset($_POST['wpecus_admin_referer'])){ // a few forms have the wpecus_admin_referer where the default hidden values are not in use check_admin_referer( $_POST['wpecus_admin_referer'] ); }else{ // 99% of forms will use this method check_admin_referer( $_POST['wpecus_hidden_panel_name'] ); } } // url submission if(isset($_GET['wpecusprocess']) && isset($_GET['nonceaction'])){ check_admin_referer( $_GET['nonceaction'] ); } // arriving here means check_admin_referer() security is positive global $wpecus_debug_mode,$cont,$wpecus_is_free; // if $wpecus_debug_mode set to true or 1 on wpecustomers.php we dump $_POST if($wpecus_debug_mode){ echo '

$_POST

'; wpecus_var_dump($_POST); echo '

$_GET

'; wpecus_var_dump($_GET); } // include form processing functions require_once(WTG_WPECUS_PATH . 'processing/wpecus_form_two.php'); require_once(WTG_WPECUS_PATH . 'processing/wpecus_form_one.php'); eval('wpecus_postget_' . $_POST['wpecus_form_name']); }

WP e-Customers Espero que os WP e-Customers tenham cerca de 200 formulários de administração até 2015. Haverá uma grande coleção de “Ferramentas” para que os administradores executem todo tipo de tarefas no WordPress e no phpBB através do administrador do WordPress.

Debug var_dump () Minha abordagem para colocar todas as solicitações através de uma única function cria um bom ponto para fazer um despejo. Você pode querer fazer isso sem os headers. Minha function wpecus_var_dump () também garante que um administrador esteja logado, segurança importante. Outro ponto a considerar é $ wpecus_debug_mode só é definido como verdadeiro quando o plugin está no blog de desenvolvimento. Ele verifica o domínio e o caminho de instalação no arquivo principal dos plugins. Isso significa que eu posso distribuir rapidamente uma cópia dos meus plugins e a debugging é automaticamente desligada. Accidentalmente deixá-lo ligado é fatal, então, se você quiser configurar um procedimento para depurar os pedidos WordPress $ _POST e $ _GET, não use apenas var_dump (). Você quer que os despejos desapareçam quando você não está a ver a canvas.