Skip to main content
18 events
when toggle format what by license comment
Jul 29, 2011 at 12:44 comment added t31os It's possible the users who updated the codex pages in question were using the function incorrectly themselves. I can't recall the trac ticket specifically right now(it's referenced in other questions here though) but it certainly wasn't intended to take a role name, it's designed to accept a capability(or was at least last time i checked).
Jul 29, 2011 at 0:10 comment added Andrew Thanks, I went with your updated example above. The first one seemed to hide the media for the admin also. Are you sure about not passing roles through current_user_can ? Bit weird if the codex has many examples of it, but you aren't actually supposed to. I tend to rely on it heavily in some instances :)
S Jul 28, 2011 at 18:17 history suggested t31os CC BY-SA 3.0
Add missing comma in code sample / remove irrelevant first response
Jul 28, 2011 at 17:06 review Suggested edits
S Jul 28, 2011 at 18:17
Jul 28, 2011 at 13:26 comment added t31os Updated my answer with another example, you would actually need a current_user_can call still, just to deal with that parent item, the submenu items are the important ones here though, that's what sets the required cap above all else to view the given page(s).
Jul 28, 2011 at 13:25 history edited t31os CC BY-SA 3.0
Add more code / further comments
Jul 28, 2011 at 13:18 comment added t31os That's not really the way to do it, if you want it restricted to admins, update the blank space with an admin cap, ie. manage_options(remove the if condition you added). Also note current_user_can should never be passed a capability, it was never intended to accept one, and likely won't in future versions. All that said, happy i could help... ;)
Jul 28, 2011 at 13:09 vote accept Andrew
Jul 28, 2011 at 13:08 comment added Andrew Can't thank you enough :) Thanks for looking into this. I wish they left it how it used to be, but hey, at least it gets the job done. I've left the cap blank and wrapped the whole thing in a if (!current_user_can('administrator')) { ... } which should be perfect for my needs right now. Thanks again!
Jul 28, 2011 at 12:46 comment added t31os I've added in some code that i believe will address the problem, lemme know if that helps.. ;)
Jul 28, 2011 at 12:45 history edited t31os CC BY-SA 3.0
Add note following code
Jul 28, 2011 at 12:25 history edited t31os CC BY-SA 3.0
Corrections
Jul 28, 2011 at 12:22 comment added t31os Correction, i tested incorrectly first time, seems the menu related code has changed... this never use to occur.. you were indeed correct.
Jul 28, 2011 at 12:16 comment added t31os No idea, can only speculate. I can say however, having worked with the menu array alot in the past, that unsetting items from the menu does prevent access to the given page(s) and does work across roles, if it doesn't work it's highly likely the result of code you're using, be it a plugin or whatever..
Jul 28, 2011 at 12:15 comment added Andrew It says the following for remove_menu_page codex.wordpress.org/Function_Reference/remove_menu_page "Please be aware that this would not prevent a user from accessing these screens directly. Removing a menu does not replace the need to filter a user's permissions as appropriate."
Jul 28, 2011 at 12:09 comment added Andrew Actually, I'm testing with admin now, and with the code above, I can still see the upload.php page while it's hidden. Should it be throwing an error message or something?
Jul 28, 2011 at 12:04 comment added Andrew Hmm looks like a capability issue I'm having then. I have a custom wordpress role so looks like they might have a capability that is still allowing them to see the upload.php. I'll have another look, thanks for the clarification.
Jul 28, 2011 at 12:01 history answered t31os CC BY-SA 3.0