Post meta is easily one of the most useful features in WordPress from a developer’s perspective. Adding custom content to a post provides the ability to accomplish countless goals quickly and easily.
Sometimes, it makes sense to give the user access to a post meta field – for example, if they need to add a thumbnail url to a post, they’re probably going to need to access to those post meta fields. Other times, having the post meta field visible is only likely to confuse the visitor. One (extremely popular) place that I’ve seen this is the All in One SEO Plugin. All in One SEO is wildly popular, and does what it claims well. It provides a few extra fields, and a nice, easy to use interface to get at them. Here’s what it looks like when you get started:
Fantastic. It’s attractive, easy to use, and works well. So we save our post, and then later on, we go back to edit the meta description. Here’s what we get:
At this point, its pretty clear what’s going on if you understand the inner workings of WordPress – AIOSEO has saved our values to custom fields, so now they’re showing up there. However, most users dont understand, or even care about how AIOSEO works, or what custom fields are. All they know is that strange stuff is showing up, and they’re not sure where to edit their meta keywords, because they’re showing up in 2 places. Most people have the gumption to just change one and see what happens – but there will always be users who get scared and decide they want to email you about the issue, or worse, just uninstall the plugin and move on.
The WordPress developers, fortunately, thought of this. In fact, they store all kinds of stuff that they don’t want the user to see in custom fields – things like the last time the post was edited, who is currently editing it, and a few others. A quick look at the database, reveals this:
Notice a trend? The mysterious custom field key values are prepended with an underscore. Give it a try – enter a new custom field from the edit-post page, and enter a name that starts with an underscore – like _thumbnail, or _meta_keywords. Hit “Add Custom Field”, and it disappears – but if you check the database, its right where it should be.
Now get out there and start hiding things from your users!
Justin over at justintadlock.com made a post a few days ago about how to preset text in the WordPress post editor. It’s a great post, with an interesting filter detailed. In the comments, somebody mentioned that they’d like to be able to preset custom fields as well – something that seems like it shouldn’t work (Custom fields need a post id to work on, and new posts dont have a post id). Yesterday, the workaround hit me like a slap in the face while I was in the shower – so I decided to package up this, along with the original code that Justin published in a plugin.
It’s not the most elegant piece of code in the world, but it works on all the installs I’ve tried it on. I’ll try to put up a post detailing how it works soon, but in the meantime, feel free to download the plugin and give it a try.
As you may have noticed in a post I made a few days ago about widetizing wordpress plugins, I mentioned that we needed to serialize our variables before we created them as options in wordpress. As it turns out, this isn’t the case – WordPress does it for you when you go to update or create an option. This morning, while reading a post on wpengineer.com about wordpress options, I noticed that in their sample code, they weren’t serializing arrays or objects before creating them as options. Michael, the author, set me straight on why this is ok.
As it turns out, WordPress is one step ahead of me. Maybe_serialize() is called a number of times throughout wordpress, relating to these items:
So there you go. Use all the arrays and objects you want in post meta, user meta, and options – throw caution to the wind, and put them straight in. WordPress will handle the boring stuff.
Recent Comments