web-dev-qa-db-fra.com

action admin_post non utilisable si l'accès administrateur est refusé à l'utilisateur

Actuellement, les utilisateurs avec un certain rôle seraient redirigés avec un crochet dans admin_init en fonction de la condition suivante

if (is_admin() && in_array($role_id, $user->roles))

Cependant, cela empêche l'utilisateur connecté avec ce rôle d'utiliser le hook d'action admin_post. Existe-t-il un moyen de rediriger uniquement les fonctions ou l’accès au tableau de bord de l’administrateur?

J'ai cherché la meilleure option pour gérer la soumission de formulaire WordPress et lu que admin_post est le crochet à utiliser, mais maintenant, il semble que je ne peux pas l'utiliser maintenant si le rôle est redirigé lors de l'accès à wp_admin/admin-post.php?

wp-adminformsuser-access
1
TurtleTread

Qu'en est-il de (1) current_screen? crochet d'action, ou une condition pour (2) get_current_screen() dans votre conditionnel et appelez ensuite wp_redirect?

Les deux vous donnent un WP_Screen object qui a plusieurs paramètres, y compris une propriété $parent_base cela peut donner une inclusion plus large si nécessaire, aussi.

Voici la liste des propriétés du codex:

$ action Toute action associée à l'écran. 'add' pour les écrans * -add.php et * -new.php. Vide autrement.

$ base Le type de base de l'écran. C'est typiquement la même chose que $ id mais avec tous les types de post et les taxonomies supprimés. Par exemple, pour un $ id de 'edit-post', la base est 'edit'.

$ id L'identifiant unique de l'écran.

$ is_network Indique si l'écran est dans l'administrateur du réseau.

$ is_user Si l'écran est dans l'utilisateur admin.

$ parent_base Le parent du menu de base. Ceci est dérivé de $ parent_file en supprimant la chaîne de requête et toute extension .php. Les valeurs $ parent_file de 'edit.php? post_type = page' et 'edit.php? post_type = post' ont une $ parent_base de 'edit'.

$ parent_file Le $ parent_file de l'écran selon le système de menus admin. Certaines valeurs de $ parent_file sont 'edit.php? Post_type = page', 'edit.php' et 'options-general.php'.

$ post_type Le type de publication associé à l'écran, le cas échéant. L'écran 'edit.php? Post_type = page' a un type de message de 'page'. L'écran 'edit-tags.php? Taxonomy = $ taxonomy & post_type = page' a un type de message de type 'page'.

$ taxonomy La taxonomie associée à l'écran, le cas échéant. L'écran 'edit-tags.php? Taxonomy = category' a une taxonomie de 'category'.

Juste un exemple rapide d'utilisation possible, le code ne fonctionne pas tel quel:

add_action( 'current_screen', 'my_function' );

function my_function( $current_screen ) {
     //true for anything other than page prefixed with edit.php
     if ( $current_screen->parent_base !== 'edit' ) { 
          //get user role here, then:
          if ( in_array( $user->roles ) ) {
             //send to /wp-admin/ 
            //note: for multisite I don't think admin_url() is the function you need
              wp_redirect( admin_url() ); 
          }
     }
 }

Il peut y avoir une meilleure approche pour votre cas spécifique, mais en général, j’ai utilisé quelque chose de similaire comme un accès ouvert/fermé à un écran de type utilisateur ou post_type sans affecter la capacité des utilisateurs à se connecter.

1
hwl