Spent some lunch hours this week working on “post meta” hacks for WordPress. This will allow users to add arbitrary extra fields to their blog posts. Stuff like “current mood”, “now reading”, “listening to”, etc. Some prototype functions have been added to CVS, but the interface for actually adding data to posts hasn’t been done yet. We’re still discussing exactly how we’re going to implement the template functions for the new data. In my test blog, I just made a function that spits the data out as a list of key:value pairs, basically.
Related posts:
- del.icio.us daily blog post fixer plugin
" I mentioned previously that I wanted to make a WordPress plugin that would touch up the posts created by the del.icio.us “daily blog post”..." - My first WordPress plugin: HeadMeta
" Mark Pilgrim was in the #wordpress IRC channel earlier, asking if there was some way to add <link> and <meta> tags to the <head>..." - Post thumbnails changes
"If you visited my site in the last 9 hours and found it displaying nothing but an error message, my apologies. It’s part of the..." - PostMeta
" Over the past few weeks, I’ve been working on-and-off on the Post-Meta feature for WordPress that I mentioned previously. I finally got it to..." - HeadMeta 1.4
"Due to changes in the postmeta API, my HeadMeta plugin had a compatibility problem with some recent versions of WordPress. The problem appeared when there..."
5 Comments
Dougal, are you using a serialized array/object for the meta?
I’ve added a new wp_postmeta database table. The structure is simple, just four fields:
meta_id, post_id, meta_key, meta_value. The tricky part was converting that flat structure into a hierarchical struct. I build a $post_meta_cache object in wp-blog-header.php which contains the metadata for the currently selected set of posts. That way, each page view only requires one extra query to fetch the metadata.Was there a reason you decided not get it in the same query with a LEFT JOIN?
Oops, sorry was still stuck in my serialized thought process, a JOIN probably wouldn’t work well since there is a one to many relationship there.
Yeah, I almost started to do a join, but I quickly saw that it was going go get really messy trying to do it that way. That’s why I switched to just building a ‘cache’ variable with the metadata for the currently selected set of posts.
It’s only one extra query per page load, so it shouldn’t be a big deal. I just have to wonder how well optimized MySQL’s IN clause is when the $post_id_list gets big.