I have made a simple code that will only save to a simple database.
I have this code:

register_activation_hook(samplePath, 'sample_install');
add_action('admin_menu', 'main');
add_action('user_admin_menu', 'main');

and a function like this :

function main(){


<?php if (current_user_can('smessage')) { 
echo("admin");}
else{
if(current_user_can('rmessage')){
echo("other user");
}
}


}

and this the sample_install function from another php file :

$wpdb->query($structure);
    $a = get_role('administrator');
    $a->add_cap('smessage'); 
    $s = get_role('author');
    $s->add_cap('rmessage');

I can see the code if I login as an adminstrator but using other roles like author, subscriber, I couldn't see the plugin any more...can someone help me with this? I'm new in using wordpress...

Thank you in advance.

Dani AI

Generated

As suggested, this is almost always a privileges / capability mismatch rather than a UI bug. In 's case the symptom — the plugin UI shows for administrators but not for authors/subscribers — points to one of three things: the activation routine that grants the custom capability never ran, the menu was registered with a capability those roles do not have, or a PHP placement/syntax mistake prevents the menu registration from executing for non-admins.

Typical fixes and checks

  • Ensure the activation hook actually ran (use the plugin file path constant when registering it) and that the custom capability is added to every role that should see the menu. Also remove those caps on deactivation.
  • Register the admin menu using the exact same capability string that was granted to roles.
  • Look for PHP mistakes (for example, opening a second <?php inside an already-open PHP block will break execution in that file and stop the menu from being added).

Example activation / deactivation pattern (adapt names to the plugin):

register_activation_hook( __FILE__, 'myplugin_activate' );
function myplugin_activate() {
  $r = get_role( 'author' );
  if ( $r ) { $r->add_cap( 'myplugin_view' ); }
  $s = get_role( 'subscriber' );
  if ( $s ) { $s->add_cap( 'myplugin_view' ); }
}

register_deactivation_hook( __FILE__, 'myplugin_deactivate' );
function myplugin_deactivate() {
  $r = get_role( 'author' );
  if ( $r ) { $r->remove_cap( 'myplugin_view' ); }
  $s = get_role( 'subscriber' );
  if ( $s ) { $s->remove_cap( 'myplugin_view' ); }
}

Example menu registration (must use same capability string):

add_action( 'admin_menu', 'myplugin_admin_menu' );
function myplugin_admin_menu() {
  add_menu_page( 'My Plugin', 'My Plugin', 'myplugin_view', 'myplugin-slug', 'myplugin_page_cb' );
}

Quick debugging tips: after changes, deactivate/reactivate the plugin to trigger the activation hook; create a temporary test user with the target role; enable WP_DEBUG and log the result of current_user_can('myplugin_view'). Avoid granting wide capabilities (like manage_options) to low-privileged roles; use a narrowly named capability or a built-in author capability (for example edit_posts) if that matches the required access level.

Have you checked user priviledges for the plugin?

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.