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.


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
    – schpet
    Jan 17 '13 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.
    – brasofilo
    Jan 17 '13 at 23:34
  • i found it after reading your answer: codex.wordpress.org/Function_Reference/…
    – schpet
    Jan 17 '13 at 23:49
  • @PETER, thx, added the link to the Answer.
    – brasofilo
    Jan 18 '13 at 0:40

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 with current_user_can in the first versions of this A.
    – brasofilo
    Jan 17 '13 at 23:33
  • Were you using role names in those functions? The current versions use capabilities.
    – s_ha_dum
    Jan 17 '13 at 23:43
  • Yes, I edited the role names out in favor of capabilities. The whole *_user_can issue seems a bit murky...
    – brasofilo
    Jan 18 '13 at 0:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.