web-dev-qa-db-fra.com

Le rôle d'utilisateur personnalisé ne peut pas voir ou modifier l'image sélectionnée

J'ai créé un type d'article personnalisé appelé Event et j'ai activé la prise en charge des images en vedette dans mon fichier functions.php, mais mon rôle d'utilisateur personnalisé ne peut toujours pas voir la méta-boîte d'image en vedette sur la page d'édition d'un événement. Si un utilisateur se connecte en tant qu'administrateur, la boîte de méta Featured Image s'affiche sans erreur.

Voici mon code pour enregistrer le CPT:

add_action('init', 'event_post_init');

function event_post_init() {
  // array of all capabilities for our CPT
  $capabilities = array(
     'publish_posts' => 'publish_events',
     'edit_posts' => 'edit_events',
     'edit_others_posts' => 'edit_others_events',
     'delete_posts' => 'delete_events',
     'delete_published_posts' => 'delete_published_events',
     'delete_others_posts' => 'delete_others_events',
     'read_private_posts' => 'read_private_events',
     'edit_post' => 'edit_event',
     'delete_post' => 'delete_event',
     'read_post' => 'read_event',
   );

   // register the CPT
   register_post_type( 'event',
      array(
         'labels' => array(
            'name' => __('Event')
         ),
         'public' => true,
         'has_archive' => true,
         'show_ui' => true,
         'menu_position' => 8,
         'capability_type' => array('event', 'events'),
         'capabilities' => $capabilities,
         'supports' => array('title', 'thumbnail', 'page-attributes'),
         'map_meta_cap' => true,
         'hierarchical' => true,
      )
   );
}

et voici comment j'ai configuré mon rôle d'utilisateur personnalisé:

function create_event_admin_role(){
   add_role('event_admin', 'Event Administrator', array(
     'publish_events' => false,
     'edit_events' => true,
     'edit_others_events' => false,
     'delete_events' => false,
     'delete_others_events' => false,
     'read_private_events' => true,
     'edit_published_events' => true,
     'read' => true,
     'assign_terms' => true,
     'edit_terms' => true,
     'manage_terms' => true,
     'read_private_pages' => true
   )
  );
}

La chose étrange est que si je regarde le balisage de la page d'édition, je peux voir l'élément #postimagediv mais pour une raison quelconque, il est masqué. Voici le balisage dans la page:

<div class="postbox  hide-if-js" id="postimagediv" style="">
   <div title="Click to toggle" class="handlediv"><br></div>
   <h3 class="hndle ui-sortable-handle"><span>Featured Image</span></h3>
   <div class="inside">
     <p class="hide-if-no-js">
       <a class="thickbox" id="set-post-thumbnail" href="http://example.com/wp-admin/media-upload.php?post_id=662&amp;type=image&amp;TB_iframe=1&amp;width=753&amp;height=294" title="Set featured image">Set featured image</a>
      </p>
    </div>
</div>

et le css qui cache la méta-boîte:

#postimagediv {
   display: hidden !important;
}

Notez que je ai activé Featured Image sous Screen Options.

Je devrais peut-être aussi signaler que j'ai essayé d'accorder le privilège upload_files au rôle ci-dessus à l'aide du code suivant:

function extend_event_admin_role() {
  $role = get_role('event_admin');

  $role->add_cap('upload_files');
}

Une autre chose à souligner est que si I do ajoute la permission upload_files, alors Featured Image est visible sous Screen Options et les autres méta-boîtes prenant en charge les médias ont un bouton Add Media qui disparaît si je fixe upload_files à false. .

 enter image description here 

 enter image description here 

Si je change le code dans wp-admin/edit-form-advanced.php qui ajoute l'image metabox en vedette, je peux dire qu'il appelle vraiment add_metabox():

if ( $thumbnail_support && current_user_can( 'upload_files' ) ):
  add_meta_box('postimagediv', __('Featured Image'), 'post_thumbnail_meta_box', null, 'side', 'low');
  print 'Support for Featured Image';
  exit;
endif;
5
Cyclonecode

J'ai finalement suivi le problème jusqu'à un plugin activé appelé Revisionary . La fonction chargée de masquer l'élément postimagediv est act_hide_admin_divs située dans revisionary/admin/admin_rvy.php. La fonction consiste à masquer les métaboxes avec un contenu qui ne prend pas en charge les révisions.

Afin d'afficher l'image sélectionnée pour mon rôle spécifique, j'ai utilisé le filtre rvy_hidden_meta_boxes:

add_filter('rvy_hidden_meta_boxes', 'revisor_show_featured_image_box');

function revisor_show_featured_image_box($unrevisable_css_ids) {
   $key = array_search('postimagediv', $unrevisable_css_ids, true);
   unset($unrevisable_css_ids[$key]);

   return $unrevisable_css_ids;
}
1
Cyclonecode

Les utilisateurs qui sont uniquement affectés à votre rôle event_admin n'ont pas la capacité upload_files, nécessaire pour afficher la méta-boîte image sélectionnée.

Voici le code pertinent du noyau:

if ( $thumbnail_support && current_user_can( 'upload_files' ) )    // <-- Notice this check
    add_meta_box( 
        'postimagediv', 
        esc_html( $post_type_object->labels->featured_image ),             
        'post_thumbnail_meta_box', 
        null, 
       'side', 
       'low'
    );

Notez que si vous essayez plus tard d'ajouter l'option:

'upload_files' => true

dans votre configuration add_role(), il se peut que la mise à jour ne soit pas mise à jour, car elle est mise en cache dans l'option wp_user_roles.

Vous devez donc mettre à jour la base de données pour l’ajuster:

Il pourrait également être possible d’utiliser des filtres comme user_has_cap pour l’ajuster de manière dynamique.

3
birgire

Selon ma compréhension, vous avez besoin d'un type de publication personnalisé Event + featured_image + Custom Role, ce que je ne comprends pas, ce sont les événements de capacité et les événements moins que et jusqu'à ce que vous personnalisiez trop, quelle est la raison ici pour une telle personnalisation?

Ce que j'ai fait ici est un rôle d'éditeur cloné en event_amdin avec toutes ses capacités et en faisant en sorte que le type de capacité puisse être page lorsque vous utilisez des attributs de page dans votre question.

Test: Création de deux utilisateurs test en tant que contributeur et cyclone en tant que Administrateur d'événements et son fonctionnement fonctionne bien. Veuillez fournir plus d'informations sur vos besoins afin que je mette à jour cette réponse. Merci!

Edit 1 : Code mis à jour, vérifiez l’édition 1 section début/fin dans la fonction cloneUserRole.

Bonne codage !!

function cloneUserRole()
{
    global $wp_roles;

    if (!isset($wp_roles))
        $wp_roles = new WP_Roles();

        $editor      = $wp_roles->get_role('editor');
        // Adding a new role with all editor caps.
        $wp_roles->add_role('event_admin', 'Event Administrator', $editor->capabilities);

        // edit 1 start : updated to add cap to new user role
        $event_admin      = $wp_roles->get_role('event_admin');

        $event_admin->add_cap( 'read_event' );
        $event_admin->add_cap( 'delete_event' );
        $event_admin->add_cap( 'edit_event' );
        $event_admin->add_cap( 'read_private_events' );
        $event_admin->add_cap( 'delete_others_events' ); // don't add
        $event_admin->add_cap( 'delete_published_events' );
        $event_admin->add_cap( 'delete_events' ); // don't add
        $event_admin->add_cap( 'edit_others_events' ); // don't add
        $event_admin->add_cap( 'edit_events' );
        $event_admin->add_cap( 'publish_events' ); // don't add
        // edit 1 ends : 

        //echo '<pre>', print_r( $wp_roles, 1), '</pre>';
        //die;
}
add_action('init', 'cloneUserRole');


function stack_event_init() {
    $labels = array(
        'name'               => _x( 'Events', 'post type general name', 'stack' ),
        'singular_name'      => _x( 'Event', 'post type singular name', 'stack' ),
        'menu_name'          => _x( 'Events', 'admin menu', 'stack' ),
        'name_admin_bar'     => _x( 'Event', 'add new on admin bar', 'stack' ),
        'add_new'            => _x( 'Add New', 'event', 'stack' ),
        'add_new_item'       => __( 'Add New Event', 'stack' ),
        'new_item'           => __( 'New Event', 'stack' ),
        'edit_item'          => __( 'Edit Event', 'stack' ),
        'view_item'          => __( 'View Event', 'stack' ),
        'all_items'          => __( 'All Events', 'stack' ),
        'search_items'       => __( 'Search Events', 'stack' ),
        'parent_item_colon'  => __( 'Parent Events:', 'stack' ),
        'not_found'          => __( 'No events found.', 'stack' ),
        'not_found_in_trash' => __( 'No events found in Trash.', 'stack' )
    );

    $args = array(
        'labels'             => $labels,
        'description'        => __( 'Description.', 'stack' ),
        'public'             => true,
        'publicly_queryable' => true,
        'show_ui'            => true,
        'show_in_nav_menus'  => true,
        'show_in_menu'       => true,
        'show_in_admin_bar'  => true,
        'query_var'          => true,
        'rewrite'            => array( 'slug' => 'event' ),
        'capability_type'    => 'page',
        'has_archive'        => true,
        'hierarchical'       => true,
        'menu_position'      => null,
        'supports'           => array( 'title', 'thumbnail', 'page-attributes' )
    );

    register_post_type( 'event', $args );
}
add_action('init', 'stack_event_init');

function my_rewrite_flush() {
    stack_event_init();
    flush_rewrite_rules();
}
add_action( 'after_switch_theme', 'my_rewrite_flush' );
  1. Rôles et capacités
  2. Enregistrer le type de message
  3. Règles de réécriture Flush
1
Webloper