Add post meta to a theme

One of the greatest achievements I have today is not being completely plugin dependent. Seriously, it’s uncommon. I’ve worked on quite a few websites where most of my hours spent on it were from cleaning up unused and bloating plugins (Yoast’s SEO just to create a sitemap = bad). I have also come across the few that have a lot of plugins to do remedial things like creating sidebars. This is one of those times that it’s pretty easy to use Advanced Custom Fields to create and add in post metadata to a theme but in developing my own site, and most likely others, it’s a cop-out. So I learned some useful tools to add custom fields and metaboxes to posts/pages to counter the quick way and instead learn something valuable. That’s my two cents anyways.

I’m going to walk you through a couple different ways to add post meta to a theme and then give some tips on debugging. These will mainly be in the WP Loop instead of outside.

the_meta() Function:

The_meta() function displays all of the post meta for each post/page as an unordered list. Most of the time it’s not going to be the best way to do it and I highly recommend NOT using it and I’ll tell you why. It shows up as an unordered list which is highly impractical. It’s like going to McDonald’s to lose weight. Here’s what the code would look like in an otherwise empty Loop:

Your end result will end up looking kind of funny most of the time because it will dump every post meta you have. Not the greatest function out there but it has it’s uses.

Why is it good?

This function is very useful when something isn’t working and you have to debug it. It dumps out everything for your eyes to see without delving into your database. It’s not hard to find in the database when it’s labelled wp_postmeta but the problem with looking in your database is finding the exact words for the post or page you’re looking at. That’s only after you’ve lost your temper and you should probably know what you’re doing before messing with your database in the first place. Otherwise, welcome to a place I like to call, “Reinstall.”

get_post_meta() Function:

This function should be self-explanatory but in case you’ve been looking at your computer screen for hours, pulling your hair out trying to figure this menace out, it gets the post metadata for the post. The syntax looks like this:

That syntax will display whatever the post meta you’re aiming for in the code itself and I’ll explain what I mean. $post_id is the ID of the post which can be retrieved by using either the get_the_id() function or by $post->ID instead. I would recommend $post->ID instead only because it can get hard to read when you’re adding a function as an argument INSIDE a function.

$key is a string that is the name of the custom field. This will mostly be the ID of the custom field with a prefix of some sort. For one of my custom fields it would be “jl_custom_field”. It can also be the most dangerous one if you have renamed your custom fields as I had to find out first hand after about nine hours on the computer racking my brain as to why it’s not showing up. Most of the time it wouldn’t bug me but when you have to spend all day debugging something and you’ve gone through all of your files to figure out why something doesn’t work is because YOU changed it.

Triple-facepalm

Anyways, $single is a boolean so it’d be either TRUE or FALSE. If it is set to true it will be displayed as a string which in most cases will do just fine for almost anything. If it’s set to false it will come out as an array which you could have some fun and do something like this:

It takes the entries from the array and and displays each as an <H3>. That’s neat and is probably best if you know how each one will show up in your theme.

**NOTE** I probably wouldn’t copy and paste the “foreach” as is because known my luck it’s most likely not right. I didn’t test it out yet.

Debugging:

This isn’t really hard to debug. Most of the time it will revolve around correct syntax, the $post_id, the ID of the custom field, and whether or not you actually put something down in the fields. If you’ve changed the name of the custom field it’ll change in the database and you won’t be able to retrieve anything until you put some new metadata in. I found that one out the hard way. If push comes to shove look at your database through either PHPMyAdmin or whatever you’re using as a host and navigate to the WP_POSTMETA table and look at what’s been saved in your posts. It’ll tell you. In my case, I run my localhost off of Microsoft WebMatrix, so the ports being listened to don’t conflict with my Spotify running or anything else as a matter of fact.

I highly recommend this way because of it’s overall simplicity and you can physically see and know what it’s doing. There’s obviously other ways and I’ll know those ways too but in the mean time, if it works I’m using it.

get_post_custom() Function:

Much like everything in the world there’s always a better way to do things and here’s a different ways to use retrieve your post metadata that I’m not going to go into detail with. You can view WP’s Codex for instructions and stuff.

I’m not going to go into detail because I’ve never used this one but get_post_custom() will retrieve ALL custom fields as a multidimensional array. If you need a quick view of what that looks like you can view it on my last post here. It’s kind of crazy trying to read multidimensional arrays but intriguing at the same time. So one way to use get_post_custom() is to use a “foreach” statement. It automatically uses the current post as the default argument so you wouldn’t have to worry about that too much.

Debugging

I haven’t used this function yet. I tried it and I was at the point of throwing my laptop through the window so I switched methods and got it to work that way. I’ll probably try it out at some point so I can either say, “I did it!” or because I’m bored and want to try something new.

Let me know in the comments if you know any better ways or maybe some CONSTRUCTIVE criticism.