i am writing a plugin that injects unescaped content (including javascript) into a post. i'm storing this content as a custom field, and am wondering if there are any built in ways to prevent users from editing specific custom fields.
2 Answers
Simply use a Custom Field with its name starting with an underscore, so it won't show up in the CF meta box, eg, _field_name
instead of .field_name
It will be hidden for all roles, but if you are manipulating its value only through code, then no problem.
If you need to manipulate the value on the edit screen, then you'll need a Custom Meta Box and control its appearance according to the user role.
[ update: looks like this kind of field can only be entered dynamically, it dumps an error if you try in the admin interface ]
-
very cool thanks! and your update suggests a user cannot update this field even with a special request, so i don't have to worry about users being able to write their own XSS-y scripts in that field– schpetCommented Jan 17, 2013 at 23:31
-
I'm not finding the documentation about this feature, but I'd risk to say that yes, you don't have to worry about users messing with it. Commented Jan 17, 2013 at 23:34
-
i found it after reading your answer: codex.wordpress.org/Function_Reference/…– schpetCommented Jan 17, 2013 at 23:49
-
Without code, it is hard to give you anything specific. A lot depends on what you are doing and where you need to do it.
In addition to what brasofilo suggested, you can always wrap individual blocks of code with current_user_can
. For example...
if (current_user_can('administrator')) {
echo "You are awesome";
} else {
echo "Ha! Ha! You can't do stuff";
}
Note: the Codex page for current_user_can
warns against using a role name, but the source documentation states "@param string $capability Capability or role name
". I do not know why they differ and I have never had a problem with a role name, but be aware.
-
Nowadays, I use a custom function
current_user_has_role
. If remembering well, I had problems withcurrent_user_can
in the first versions of this A. Commented Jan 17, 2013 at 23:33 -
Were you using role names in those functions? The current versions use capabilities.– s_ha_dumCommented Jan 17, 2013 at 23:43
-
Yes, I edited the role names out in favor of capabilities. The whole
*_user_can
issue seems a bit murky... Commented Jan 18, 2013 at 0:37