J'ai vu et utilisé la technique suivante pour ajouter des scripts php à mon plugin afin de gérer des formulaires personnalisés dans un plugin wordpress.
depuis le plugin 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;
Par exemple, le 'quiz_action.php' est utilisé plus tard comme cible pour un formulaire d'administration (ces formulaires sont utilisés uniquement dans wp-admin)
<form name="post" action="<?php echo $GLOBALS['my_plugin_folder'] ?>/quiz_action.php" method="post" id="post">
UPDATE: Cette méthode est décrite ici - Ecran de configuration administrateur sans menu
Le commentaire final ci-dessous par un développeur Wordpress semble décourager ceci:
http://wordpress.org/support/topic/how-can-i-execute-php-scripts-in-my-plugin-folder
Alors, quelle est la meilleure pratique ici? Les formulaires d’administration doivent-ils être postés sur wp-admin/admin.php? Action = foo ou wp-admin/edit.php? Action = bar. Comment enregistre-t-on ces actions? Est-ce documenté quelque part? Pour être clair, ces fichiers ne doivent pas être liés depuis un menu administrateur.
J'utilise Wordpress 3.0.4
Merci!
Fondamentalement, il semble y avoir deux façons de procéder:
1) La manière dont $_registered_pages
est détaillée dans la question initiale. Cela semble un peu non standard et pourrait dérouter quelqu'un qui regarde votre code.
2) Postez votre formulaire dans une URL d'administrateur telle que admin_url('admin.php?page=show_form')
, où show_form()
est un élément de menu/une fonction enregistré. Dans show_form()
, vous pouvez activer si un formulaire a été soumis ou non. Si tel est le cas, vous pouvez inclure un autre fichier php sous condition:
function show_form()
{
if ( $_SERVER["REQUEST_METHOD"] == "POST" && isset($_POST['submit'])) {
require_once('name_of_your_processing_script.php');
} else {
//do something else.
}
}
Ou tout simplement inclure le fichier et faire un traitement/basculement dedans (probablement plus propre).
Si vous essayez simplement d'utiliser un fichier que vous avez créé comme action de publication du formulaire, vous obtiendrez une erreur. Comme mentionné dans les commentaires ci-dessus, vous devez empêcher l’appel direct de vos fichiers et protéger et vous protéger contre les attaques CSRF utilisant des nonces.
Toutes mes excuses pour le long fil de commentaires. Serait reconnaissant si les gens pouvaient confirmer c'est ce qu'ils voulaient dire.
Personnellement, je viens d'ajouter un lien de menu et dans la fonction pour gérer le formulaire. Avec $ _SERVER ['REQUEST_URI'] comme action. Exemple ci-dessous.
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 {
?><form method="post" action="<?php echo $_SERVER['REQUEST_URI']; ?>"><input type="submit" /></form><?php
}
}
Au cours des 12 derniers mois, mon approche a consisté à appeler toutes les fonctions traitant des demandes $ _POST ou $ _GET. Au sein de chaque fonction, quelques valeurs, parfois plus, sont vérifiées pour déterminer si cette fonction est celle applicable, c'est-à-dire un nom de formulaire et une valeur spécifique du formulaire ou de l'URL auxquels la validation des données peut également être appliquée.
Je mets tous $ _POST et $ _GET dans une seule fonction qui vérifie nonce, de sorte que la fonction nonce ne soit pas appelée dans chaque fonction. Cette fonction process_POST_GET () inclut alors des fonctions de traitement de formulaire.
add_action('admin_init,process_POST_GET');
Cela fonctionne bien et n'a aucun inconvénient de performance. Nous parlons simplement de 100 x if (isset ()) et d’un moyen très simple de tout garder en ordre. J'ai envisagé un add_action () pour chaque fonction et j'ai réalisé que cela créait plus de travail pour Wordpress que mon approche car il devait toujours appeler chaque fonction.
L'exemple ci-dessous contient beaucoup de "wpecus_" car je n'utilisais pas de classes à l'origine. Nous n'aurions pas besoin de tout préfixer autrement.
eval ()
Aujourd'hui, j'envisage d'utiliser eval () pour appeler la fonction à l'aide du nom de formulaire.
/**
* $_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 '<h1>$_POST</h1>';
wpecus_var_dump($_POST);
echo '<h1>$_GET</h1>';
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-Clients Je m'attends à ce que WP e-Clients dispose d'environ 200 formulaires d'administration d'ici à 2015. Une vaste collection "d'outils" permettra aux administrateurs d'effectuer toutes les tâches sortes de tâches sur Wordpress et phpBB via l’administrateur Wordpress.
Déboguer var_dump () Mon approche consistant à placer toutes les requêtes dans une seule fonction crée un bon point de départ pour le dump. Vous voudrez peut-être faire cela sans les en-têtes. Ma fonction wpecus_var_dump () garantit également la connexion d’un administrateur, une sécurité importante. Un autre point à prendre en compte est que $ wpecus_debug_mode n'est défini sur true que lorsque le plug-in est sur le blog de développement. Il vérifie le domaine et le chemin d'installation dans le fichier principal des plugins. Cela signifie que je peux rapidement distribuer une copie de mes plugins et que le débogage est automatiquement désactivé. Le laisser accidentellement sur est fatal. Par conséquent, si vous souhaitez configurer une procédure de débogage des requêtes Wordpress $ _POST et $ _GET, n'utilisez pas simplement var_dump (). Vous voulez que les sauvegardes disparaissent lorsque vous n'êtes pas celui qui regarde l'écran.