http://sltaylor.co.uk/blog/wordpress-custom-fields-reloaded/

The reasons for the prefix are (1) to make sure the values managed by this code don’t pop up in the default custom fields interface, if that’s left in place (the initial underscore makes sure of that), and (2) general good coding practice of avoiding field name clashes with plugins, etc.

If you hide the default custom fields meta box (which the above code does by default), and you’re happy that your existing field names won’t clash with anything, I don’t see why your code won’t work. Maybe set the prefix to any empty string rather than comment it out though? Also, go through every place where the prefix is used, I’m not sure if there might be other impacts.

I am a bit new to this as well, and I have a question about existing data. Basically, if I comment out your prefix var will content from currently populated customfields display in applicable fields defined by this code?

For instance: I have been adding a custom field manually via the default drop down, the key is TKRNumber and a value could be 0123

I have created a custom field array that looks like so:


array(
"name"=>"TKRNumber",
"title"=>"TKR Number",
"description"=>"Optional TKR Number for album release posts.",
"type"=>"text",
"scope"=>array( "post" ),
"capability"=>"edit_posts"
)


Currently existing data isn’t populating this field, so I’m wondering if deleting the prefix would solve this, or if I need to do something else?

Thanks again.
-g

Note that this was just a “notice”, i.e. I don’t think it wasn’t really affecting the functionality of the code. A number of plugins, and possibly some core code, generate notice-level errors. They’re just alerting you to things that mean your code isn’t perfect, but the problem isn’t necessarily going to break anything. If you were seeing this error, I assume it was on a development server? If it’s on your live site, you might look into disabling PHP error output.

Very nice tutorial, and just what I was looking for. One problem I’m seeing is that I’m getting a “Undefined index: my-custom-fields_wpnonce” as well as a header already sent warning. Not sure if it’s happening on an autosave or not. The undefined index is happening on the second reference to the wpnonce. Using 2.9.1.1. Any tips appreciated.

I have the same error! Please help :)
Using version 3.0.1

I figured I’d send you this improvement. I didn’t like the fact that you couldn’t easily create a field that allowed a field on both pages and posts for people who have permissions to edit either (not that someone without edit_page permission would end up editing or creating a page).

I also didn’t like your way of testing permissions. its a matter of taste but I like using array_reduce (I’m not really a PHP guy, more Ruby with some Java). I noodled around and I think that this is a more robust system:

var $customFields = array(
 array(
 "name" =_ "...",
 "title" =_ "...",
 "description" =_ "...",
 "type" =_ "...",
 "permission" =_ array(
 array( "scope" =_ "post", "capability" =_"edit_posts"),
 array( "scope" =_ "page", "capability" =_"edit_pages"),
 array(
 "scope" =_ array("type-one", "type-2"),
 "capability" =_ array("cap1", "cap2")
 ),
 )
 )
);
function reduce_scope ($memo, $scope){
 global $post;
 return $memo || (basename( $_SERVER['SCRIPT_FILENAME'] ) == $scope . "-new.php" || $post-_post_type == $scope);
}
function reduce_capability ($memo, $cap){
 global $post;
 return $memo || current_user_can( $cap, $post-_ID );
}
function reduce_permissions( $memo, $permssion){
 $scopes = is_array($val) ? $permission['scope'] : array($permission['scope']);
 $capabilities = is_array($val) ? $permission['capability'] : array($permission['capability']);
 return $memo || (array_reduce($scopes, "reduce_scope", false) && array_reduce($scopes, "reduce_capability", capabilities));
}
function can_show($permissions){
 return array_reduce($permissions, "reduce_permissions", false);
}

You can now replace this code:

foreach ( $scope as $scopeItem ) {
       switch ( $scopeItem ) {
               case "post": {
                       // Output on any post screen
                       if ( basename( $_SERVER['SCRIPT_FILENAME'] )=="post-new.php" || $post-_post_type=="post" )
                               $output = true;
                       break;
               }
               case "page": {
                       // Output on any page screen
                       if ( basename( $_SERVER['SCRIPT_FILENAME'] )=="page-new.php" || $post-_post_type=="page" )
                               $output = true;
                       break;
               }
       }
       if ( $output ) break;
}
// Check capability
if ( !current_user_can( $customField['capability'], $post-_ID ) )
 $output = false;

with simply:

$output = $this-_can_show($customField['permission']);

(You’ll have to put the reduce_* functions outside the class definition).

Now, aside from simplifying the code (I’m a big fan of breaking down my functions so they are no more than 20 lines of code if possible), the permission system is now a lot more flexible.

The logic is this:

• You can show the field if any of the permissions is satisfied
• A permission is satisfied if one of its scopes and one of its capabilities are satisfied
• A scope is satisfied if the script filename is $scope . “-new.php” or the post_type == $scope
• A capability is satisfied if the current user is capable of that action on the current post.

This method of determining permissions has an interesting side effect (which is not necessary for typical WP installs, but interesting none the less). It lends itself to a “map-reduce” algo where you first map the arrays to booleans, which can be done in parallel (say over many processor cores and/or machines), then reduce the array to a boolean, which cannot be done in parallel but its comparitively efficient to reduce booleans.