It’s no surprise I can be vocal when I am reviewing a theme. Many know that I’ll spurt out what I end up seeing in a lot of themes. There is one thing that really does drive me crazy though and that is when people copy and paste code to their theme without actually knowing how the code actually works.
One file that has really been rather popular is using a metabox in order to choose the layout of the post or page. That’s great. I love that ability but then again who doesn’t love having that control? I think what drives me bonkers is that this code is super predictable before the file is opened. The file adds two actions. One to add_meta_boxes and the second to the save_post hooks. Great! Very super simplistic and hard to mess up, right?
I created a gist with the name of the theme changed. The code is the same that I’ve seen in many other themes though. From authors who have several themes in the repo to new authors to the repo.
One of the first things that you may notice is the use of two globals.
global $post, $deargodwhy_sidebar_layout;
First there should be no reason for that and second those hooks pass the $post object. We’ll look at the first one: add_meta_boxes
Using the developer resources as a guide we see that the hook for adding metaboxes uses two arguments. The post type and the post.
do_action( 'add_meta_boxes', string $post_type, WP_Post $post )
The first one being the string of the current post type and the second being the WordPress post object. Now, what’s super cool about that is that we can now register a metabox in any post type we want and it does on every post type if we don’t pay attention to what we are doing. There is also one more hook we could potentially use in order to use a metabox in only one specified post type. That hook is add_meta_boxes_{$post_type} and the developer docs does explain it a little better. For example, if you wanted to add a metabox to only your EDD downloads, you could do something like:
add_action( 'add_meta_boxes_download', 'jmc_download_extra_metaboxes', 10 );
function jmc_download_extra_metaboxes( $post ) {
// Do our magic here.
}
In order to now add our metabox we do need to use the function add_meta_box() so let’s take a look at how that function is used.
add_meta_box( $id, $title, $callback, $screen = null, $context = 'advanced', $priority = 'default', $callback_args = null )
Now, if you want to take a closer look at what each one of those parameters actually does then I suggest you take a look over the developer docs. It is well worth your time if you really want to understand how to create a better user experience and understand how WordPress creates those.
Another thing I wanted to look over was the save_post callback being used. The biggest issue is the use of the foreach() loop.
foreach( $deargodwhy_sidebar_layout as $field ){
//Execute this saving function
$old = get_post_meta( $post_id, 'deargodwhy_sidebar_layout', true );
$new = sanitize_text_field( $_POST['deargodwhy_sidebar_layout'] );
if ( $new && $new != $old ) {
update_post_meta($post_id, 'deargodwhy_sidebar_layout', $new );
} elseif ('' == $new && $old ) {
delete_post_meta( $post_id,'deargodwhy_sidebar_layout', $old );
}
}
The reason is it is creating an unnecessary loop. The only thing that needs to be checked is the value being input and to make sure that it is a valid option. A quick change to the code and we have:
if ( ! empty( $_POST['deargodwhy_sidebar_layout'] )
&& in_array( $_POST['deargodwhy_sidebar_layout'], array( 'right-sidebar', 'no-sidebar' ), true )
) {
update_post_meta( $post_id, 'deargodwhy_sidebar_layout', $_POST['deargodwhy_sidebar_layout'] );
}
Knowing those things we could make changes to the file and not only will we have a better understanding of how WordPress creates metaboxes but we have a file that doesn’t pollute the $GLOBALS with info that we only use in one place. If you look at what those changes were in the diff, you will see that not a lot was changed. It only looks that way since I removed a lot of the linting errors.