Typically, WP hides meta keys that begin with an underscore / _ from the custom field (default / core) of the MetaBox.
Now imagine that you do not want the user of your plugin to be able to modify Meta data due to the incorrect and unfriendly metadata of Custom Fields. And so you create a custom meta field and a prefix for your meta key with an underscore / _ . Then the user changes his mind and deactivates or removes your plugin. What is happening now is that the user has absolutely no access to any user interface in order to change the (still present) metadata. This is really a very bad situation for the user.
So, we need a switch to disable access to MetaBox Custom Fields while your plugin is activated . Therefore, WP Core got the function is_protected_meta() . It consists mainly of two lines of code:
$protected = ( '_' == $meta_key[0] ); return apply_filters( 'is_protected_meta', $protected, $meta_key, $meta_type );
It would be nice to offer a filter for processing, WordPress today has a simple function that you can use:
register_meta( $meta_type, $key, $sanitize_callback, $auth_callback );
And the last argument, $auth_callback does the following inside this function:
if ( empty( $auth_callback ) ) { if ( is_protected_meta( $meta_key, $meta_type ) ) $auth_callback = '__return_false'; else $auth_callback = '__return_true'; } if ( is_callable( $auth_callback ) ) add_filter( "auth_{$meta_type}_meta_{$meta_key}", $auth_callback, 10, 6 );
As you can see, you just want to add '__return_false' as $auth_callback to deactivate access to custom MetaBox fields while your plugin is active. When a user deletes or deactivates your plugin, he instantly gets access to the meta-field through the standard custom text MetaBox.
Notes: WP core in version 4.0 when writing this question. Use $sanitize_callback ! Thanks to Trepmal for posting the is_protected_meta filter on my blog. Otherwise, I would never have come across a precedent for this.