Posted 11 months ago #
Nice plugin Sarah, but I wouldn't recommend using user levels. Those have been deprecated since like WordPress 2.3.
I'd recommend this bit of code instead:
add_action( 'admin_init', 'hide_update_reminder' );
function hide_update_reminder() {
if ( !current_user_can('manage_options') )
remove_action( 'admin_notices', 'update_nag', 3 );
}That's all that's needed for your plugin. :)
("admin_init" may be too early though for my code. If it is, use "admin_head".)
Posted 11 months ago #
Cheers for the code, however I'm planning to set it so that users can control who sees or doesn't see the update message. Some users may not want to see it (even as Admins) as they're aware anyway, some may want Editors to see it but not Author's etc. However I'll looking into the current_user_can() function and the remove_action hook is handy to know as I wasn't aware of that, hence why I just hid the div :)
Cheers
Posted 11 months ago #
I'm planning to set it so that users can control who sees or doesn't see the update message. Some users may not want to see it (even as Admins) as they're aware anyway, some may want Editors to see it but not Author's etc. However I'll looking into the current_user_can() function
http://codex.wordpress.org/Roles_and_Capabilities
I was mistaken. User levels have been deprecated since 2.0.
Posted 11 months ago #
Trouble is, user levels (ie. numbers) is the most logical method :)
I'll be hunting through the Codex to see if there's a way to simply say 'User is Administrator' or 'User is Editor or above' type method. This is why it's easier to say User level > X.
Posted 10 months ago #
Trouble is, user levels (ie. numbers) is the most logical method :)
Not really, especially when it comes to custom roles. I for example could create a new role that had access to literally everything but the plugins page. The role's user level wouldn't tell you that, but current_user_can() would. ;)
I'll be hunting through the Codex to see if there's a way to simply say 'User is Administrator' or 'User is Editor or above' type method.
I gave an example in my original post. ;) Checking the "manage_options" capability is a good test as it's safe to assume that if the user can't access the various settings pages, then they aren't an administrator.
An alternate (and arguably even better) capability to check could be "activate_plugins" which is the capability required to access the plugins activation menu.
Posted 10 months ago #
My point is, perhaps a user wants to set it so that they, as an Admin, can see the notice, their editors can see the notice, but their authors can't. Or their author's can, but standard subscribers can't.
Using the current_user_can() function isn't as efficient to differentiate between editors and authors. It's fine until someone changes the user roles as you say, and that's where the problem lies to find the right balance. It's easy to spot an admin, but not so easy to determine other users. The only other option would be to allow the user to set who sees the message for all their users.
It's just working out the most suitable solution :)
Posted 10 months ago #
Using the current_user_can() function isn't as efficient to differentiate between editors and authors.
One of many possible solutions:
current_user_can('unfiltered_html')
Anyway, my point is merely just because it happens to work doesn't necessarily mean it's best practice. User level X doesn't necessarily mean the ability to do Y, especially in the future.
It's your plugin, do as you wish -- I'm just giving my two cents and commenting on future proofing and such. :)
Posted 10 months ago #
No I agree, future proofing is the best way and your code has helped (when I get 5 minutes to update things!) :)
You must log in to post.
