The first step in handling custom fields our way is to get WordPress' handling out of the picture. To do this, we need to make use of the remove_meta_box() function.
The secret here is tying into the do_meta_boxes action, which is called when the meta box is being created.
Update your index.php file so it ties into the do_meta_boxes action.
add_action( 'do_meta_boxes', 'StandardizedCustomContent::remove_
default_custom_fields', 10, 3 );
You can see that we are planning on calling a static function named remove_
default_custom_fields (more on that in the next step), but this is the first time we have used the third and fourth arguments to the add_action() function. We're throwing the third argument a default value (10) because what we really care about is the fourth argument. The function triggered by the do_meta_boxes action accepts three arguments. How did we know that? Well, unfortunately, it's not from any of WordPress' documentation. Adam Brown is our savior here (http://goo.gl/wEHo).
We can have a look inside the wp-admin/edit-form-advanced.php file to see where this action is called:
do_action('do_meta_boxes', $post_type, 'normal', $post);
do_action() is the magic function that makes all of our action events happen, so it can be useful to see how it triggers an event. From that call, we can see that there are three additional arguments passed after the name of the action, therefore, we know that if we hook into this action, we need to include 3 as the fourth argument to add_
action(). See the official documentation for the add_action() function if you need more clarification (http://goo.gl/77Os).
If this seems fantastical that we somehow knew of this action and how to use it, it is.
The actions and filters are currently lacking in documentation, so sometimes figuring out which one to use can be a laborious process. The following is a tip on how to find which actions and filters are firing:
• Look at the file being called in your URL (wp-admin/post.php, in this case)
• Search for any instances of the do_action() or apply_filter() functions in that file
• Look for any calls to include(), require(), include_once(), or require_
once()—from this we know that edit-form-advanced.php is included on that page
• Check the included files for the do_action() or apply_filter() functions It's not an easy process, but it is one that you can use to help find events (actions or filters) that you can hook into.
An amazingly useful tool available for finding text is the command line tool grep, which is standard in any Unix shell (that is Linux and Mac OS X). You can recursively search an entire directory for any files containing a certain string:
grep -rl 'search-term-here' . Where "." is short for the current directory.
Our next task is to update the StandardizedCustomContent.php file so that it contains the following two functions along with the public static variable $content_
types_array: /**
* Which types of content do we want to standardize? Here you can list WP
* built-in content types (aka post-types) e.g. 'page', 'post', or * any custom post-types you define.
*/
public static $content_types_array = array('post');
/**
* This plugin is meant to be configured so it acts on a specified list of content
* types, e.g. post, page, or any custom content types that are registered.
* FUTURE: read this from the database.
* @return array Array of strings, each string being the name of a WP post-type
*/
private static function _get_active_content_types() { return self::$content_types_array;
} /**
* Remove the default Custom Fields meta box. Only affects the content types that
public static function remove_default_custom_fields( $type, $context,
$post ) {
$content_types_array = self::_get_active_content_types();
foreach ( array( 'normal', 'advanced', 'side' ) as $context ) {
From the remove_default_custom_fields() function we are calling the _get_
active_content_types() function. If you noticed our comments, you can see that we are anticipating future development of this plugin beyond what we will complete in this chapter, but it brings up an important architectural point: there are times when you should use getter and setter functions instead of accessing class variables directly.
For the record, we could have bypassed the _get_active_content_types() function entirely by using the following line in our remove_default_custom_
fields() function:
$content_types_array = self::$content_types_array;
However, we are anticipating that we will eventually read that value from the database, so we will route all requests for that variable to a getter function, which we can later rewrite so it gets its data from the database. When time comes for us to rewrite the next version of this plugin, it will be much easier if we know our edits will be isolated to this particular function. Until then, the function will remain a one-liner that simply returns our class variable.
Understanding $this vs. self
We are once again using static functions in our class. Nothing in this plugin requires objects, so we have opted to create a class of static functions that requires no instantiation. In static classes, self:: takes the place of $this->, and it is used to refer to class variables and methods, for example, self::$my_var or self::my_function().
Static functions are not allowed to use $this-> because it refers to a specific instance of the class, and the whole point of using static functions is that there are no instances of the class. In fact, if you use the $this->
construct anywhere outside of an instantiated class, PHP will die with a fatal error: Fatal error: Using $this when not in object context.
Save your work and refresh the WordPress Dashboard. The functions here are simple enough for you to be able to quickly track down errors. Remember what we said in Chapter 1 about keeping your "units" of code small? If your functions are too long, they become more difficult to understand and debug.
Edit the post you created previously that contained custom fields. Notice that the whole section for custom fields is now gone from the Dashboard. We have successfully removed it from the post edit page. To prove this, you can temporarily deactivate the plugin and try viewing this post again—the custom fields should be visible once more. Please reactivate the plugin before you continue.