Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

up vote 3 down vote accepted

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 ]

share|improve this answer
    
+1, good tip with the underscore –  bungeshea Jan 17 '13 at 23:18
    
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 –  PETER 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/… –  PETER 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.

share|improve this answer
    
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

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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