web-dev-qa-db-fra.com

le filtre user_has_cap permet l'édition mais pas la sauvegarde

Problème

Je travaille sur un site Web sur lequel nous devons pouvoir insérer un nom d'utilisateur dans le champ personnalisé d'un type d'article personnalisé et permettre à l'utilisateur spécifié de modifier cet article et uniquement cet article. Je pensais que user_has_cap serait le crochet de filtre à utiliser, mais bizarrement, cela ne semble pas permettre à un utilisateur de mettre à jour le message.

L'utilisateur peut voir l'écran d'édition de la publication et uniquement celle qui implique que mon filtre fonctionne correctement, mais le fait de mettre à jour génère l'erreur You are not allowed to edit posts as this user. qui le contredit.

Le type de message a capability_type => post donc je pense que cela ne devrait pas être le problème.

Code

function event_cap_filter($all, $cap, $args) {
    // if not requesting edit post then return caps
    if('edit_post' != $args[0]) return $all;
    // if user can already edit others posts then return caps
    if($all['edit_others_posts']) return $all;

    // if user is the post author then return caps
    $post = get_post($args[2]);
    if($args[1] == $post->post_author) return $all;

    // query to find user in custom field
    // and therefore if they are allowed to edit this post

    if($can_edit) {
        foreach($cap as $c) {
            $all[$c] = true;
        }
    }

    return $all;
}
add_filter('user_has_cap', 'event_cap_filter', 10, 3);

Question

Si mon utilisateur peut modifier le message pour lequel il est spécifié dans le champ personnalisé que j'ai vérifié, pourquoi ne peut-il pas enregistrer ses modifications? Est-ce que je néglige quelque chose?

filterswp-admin
2
txa

Je suis aux prises avec le même problème ... lorsque args [0] est publié, args [2] n'est pas rempli. Vous devez l'obtenir à partir de l'URL.

if(substr($args[0],0,7)=="publish"){
    $postid=$_GET["post"];
    if(!isset($postid))return $allcaps;
}
else $postid=$args[2];
2
Nancy

Je pense que vous rencontrez un bogue dans _wp_translate_postdata() qui l'oblige à vérifier edit_others_posts sans fournir aucun contexte pour map_meta_cap et d'autres filtres à utiliser dans des situations comme la vôtre (où vous souhaitez qu'un utilisateur puisse modifier des publications spécifiques qui ne sont pas les leurs):

https://core.trac.wordpress.org/ticket/30452#comment:5

Cela a pour effet spécifique que l'utilisateur affecté puisse se connecter à l'éditeur de publication (ce qui signifie que cela a fonctionné), mais toute tentative de sauvegarde des modifications échouera complètement (ce qui ressemble à votre problème).

Le billet inclut une solution de Daniel Bachuber que d’autres peuvent convertir pour leurs propres besoins.

Espérons que le bug soit corrigé bientôt.

2
jerclarke