J'ai construit un plugin qui affiche une table en utilisant la classe WP_List_Table. Le tableau affiche les entrées sur lesquelles il est possible d'appliquer un filtre et des actions en bloc.
Le problème est que lorsque je clique plusieurs fois sur le bouton "Filtrer" ou "Appliquer l'action en bloc", le paramètre _wp_http_referer est ajouté à l'URL et continue à être de plus en plus long chaque fois que je clique sur le bouton.
Finalement, l'URL est si longue que je reçois une page vierge dans le navigateur avec le message d'erreur suivant:
Request-URI Too Large
The requested URL's length exceeds the capacity limit for this server.
Je pense avoir correctement configuré les filtres et les actions de sélection en bloc dans une simple balise de formulaire:
form action method="get"
Le même problème semble avoir été décrit ici: Comment empêcher _wpnonce et _wp_http_referer d’apparaître dans l’URL . Je suis confronté au même problème et je me demande si quelqu'un aurait la moindre idée de la façon de supprimer le paramètre paramètre _wp_http_referer de l'URL après avoir cliqué sur les boutons d'action du formulaire.
Merci
Comme le dernier commentateur l'a suggéré, vous devriez probablement rechercher des actions, supprimer les arguments de requête et les rediriger. Quelque chose comme:
$doaction = $wp_list_table->current_action();
if ( $doaction && isset( $_REQUEST['SOMEVAR'] ) ) {
// do stuff
} elseif ( ! empty( $_GET['_wp_http_referer'] ) ) {
wp_redirect( remove_query_arg( array( '_wp_http_referer', '_wpnonce' ), stripslashes( $_SERVER['REQUEST_URI'] ) ) );
exit;
}
Donnez le script suivant en pied de page ou tout js commun
La réponse acceptée est la meilleure façon de le faire, mais si la table de liste apparaît sur une page d'administrateur personnalisée, vous rencontrerez des erreurs dans les en-têtes déjà envoyés.
Le mieux que je puisse trouver est de détecter un _wp_http_referer
imbriqué sur admin_init
et de faire la redirection là-bas.
add_action( 'admin_init', 'wpse_80112' );
function wpse_80112() {
// If we're on an admin page with the referer passed in the QS, prevent it nesting and becoming too long.
global $pagenow;
if( 'admin.php' === $pagenow && isset( $_GET['_wp_http_referer'] ) && preg_match( '/_wp_http_referer/', $_GET['_wp_http_referer'] ) ) :
wp_redirect( remove_query_arg( array( '_wp_http_referer', '_wpnonce' ), wp_unslash( $_SERVER['REQUEST_URI'] ) ) );
exit;
endif;
}
Soyez conscient du timing de votre code. Si vous gérez les actions de la table de liste après ce raccordement (par exemple, au sein de votre classe de table de liste), il existe un risque de redirection avant l'exécution de l'action. Par conséquent, il sera ignoré et nécessitera une deuxième demande. Assurez-vous de gérer cela dans votre propre implémentation, le cas échéant.
Vous pouvez envisager d'utiliser l'action load-{page-hook}
pour gérer les actions, où {page-hook} est le retour de votre appel add_submenu_page
(ou similaire).
Laissez-moi vous aider! Remplacez la méthode parent display_tablenav de la classe WP_List_Table en supprimant l'exécution de wp_nonce_field.
/**
* Generates the table navigation above or bellow the table and removes the
* _wp_http_referrer and _wpnonce because it generates a error about URL too large
*
* @param string $which
* @return void
*/
function display_tablenav( $which )
{
?>
<div class="tablenav <?php echo esc_attr( $which ); ?>">
<div class="alignleft actions">
<?php $this->bulk_actions(); ?>
</div>
<?php
$this->extra_tablenav( $which );
$this->pagination( $which );
?>
<br class="clear" />
</div>
<?php
}
Voici le code qui fait l'affaire:
public function strip_wp_http_referrer () {
$current_url = "http://$_SERVER[HTTP_Host]$_SERVER[REQUEST_URI]";
if (strpos($current_url, '_wp_http_referer') !== false) {
$new_url = remove_query_arg( array( '_wp_http_referer', '_wpnonce' ), stripslashes($current_url));
wp_redirect ($new_url);
}
}
Je sais que c’est une vieille question, mais j’ai opté pour une version modifiée de l’avertissement de Sijo Thomas Maprayil.
jQuery("input[name='_wp_http_referer'], input[name='_wpnonce']").remove();
Pas besoin de délai d'expiration tant que le script est exécuté sous le champ de recherche.
Je me demande pourquoi ces champs sont même ajoutés si wordpress effectue une redirection pour les supprimer à nouveau. Très sous optimal pour dire le moins.