web-dev-qa-db-fra.com

Comment gérer au mieux les actions de page de plugin personnalisées?

Je rencontre constamment le même ennui, alors je me suis dit que je verrais s'il y a des idées ou de l'expérience là-bas ...

J'ai créé un plugin qui utilise sa propre page d'administration. Il doit. Maintenant que j'ai réglé le problème WP_List_Table (), je dois dire que c'est génial ... mais ...

Les pages de plug-in personnalisées se chargent toujours en tant que admin.php?page=..., sauf si je souhaite les charger directement à partir du répertoire du plug-in, ce que je ne fais pas. Maintenant, si je fais une 'action' à partir de cette page, j'ai besoin de la traiter d'une manière ou d'une autre, puis de la rediriger vers la page sans le paramètre d'action. Peu importe si je fais un GET ou un POST, vraiment.

Sur toutes ses pages internes, WP le fait sur la même page, il vérifie s'il y a une action, si c'est le cas, puis se redirige vers lui-même sans l'action. C'est possible car sur ces pages, le admin-header n'a pas encore été chargé.

Si vous essayez de le faire sur votre propre page, cependant, la moitié de l'interface d'administration a déjà été envoyée au navigateur, de sorte qu'une redirection n'est plus possible. Clairement, la solution consiste à POST/GET directement sur une autre page, chargez le cadre WP sur celui-ci, effectuez le traitement puis redirigez vers la page d'origine ... mais ... c'est un peu ennuyeux, parce que ... ma page d'origine est chargée via un rappel, elle est donc exécutée dans une méthode de ma classe. C'est beau.

Si je charge une page séparée, je dois inclure manuellement wp-load.php et je suis en dehors de ma classe, ce qui est gênant et, dans mon cas particulier, me perturbe particulièrement, parce que je n'instancie anonymement ma classe de plug-in afin que personne ne puisse y accéder ça de l'extérieur.

Donc, après cette longue histoire ... quelqu'un a-t-il trouvé une bonne solution pour charger une autre page via un rappel sans / avec toute l'interface d'administration déjà configurée?

(Je connais une solution de contournement ... Je peux relier une fonction à load-.... qui vérifie le paramètre d'action et effectue le traitement et la redirection. Mais je me demande s'il existe un meilleur moyen.)

Merci.

plugin-developmentwp-admincustomization
21
wyrfel

En règle générale, vous devez utiliser une requête POST pour la plupart des actions, afin de vous assurer qu'elles ne sont pas exécutées par accident . Toutefois, il est également recommandé de rediriger vers une page normale après une demande POST, afin d'éviter toute exécution en double lorsque l'utilisateur actualise la page.

Donc, le flux est comme ça:

  1. Votre page de plugin avec un formulaire POST, qui se soumet à
  2. Une page qui gère la demande, qui redirige vers
  3. Votre page de plugin, qui montre le résultat de l'action

La page du milieu ne doit pas nécessairement être votre page de plugin. Cela signifie que vous pouvez utiliser le gestionnaire "generic POST _" inclus il y a trois ans, le hook 'admin_action_' . $_REQUEST['action'] dans admin.php .

Un exemple d'utilisateur est le plugin Akismet . Si vous voulez l'utiliser de manière fiable, vous devez soumettre à admin.php directement , et non à une autre page contenant le admin.php.

Voici un exemple très basique d'utilisation:

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
}
28
Jan Fabry

J'ai abordé cette question légèrement différemment en ajoutant simplement noheader = true à l'URL de l'action sur la page où l'utilisateur soumet cette action.

Mon gestionnaire exécute ensuite l'action (c'est-à-dire généralement un ajout, une mise à jour ou une suppression), puis se termine par une action wp_redirect () vers la page suivante (par exemple, ajouter une page -> modifier une page, supprimer une page -> modifier une page -> modifier une page ). Je passe également un message sur l'URL afin de pouvoir afficher un statut tel qu'une mise à jour réussie ou échouée.

Cette approche conserve toutes les actions: lister, ajouter, éditer, supprimer, supprimer en bloc, etc. dans la même classe et avec le même slug d’administrateur, de sorte qu’il est assez facile à maintenir et à comprendre.

3
Russell Jamieson

Une autre approche consiste simplement à ajouter un champ de saisie masqué au formulaire:

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

De cette façon, WordPress semble gérer la redirection automatiquement.

0
simonthesorcerer