Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I work with websites which require using Post Meta for Post Objects within a particular Post Type.

I often add a Meta Box to a particular Post Type, to provide additional settings for the new Post Object being created.

You can imagine by now, I have created a few classes which make Post Meta management easier for my every day needs.

I have come to common practice of always prefixing all of my Custom Field keys. I have decided to always use my initials, and then a quick reference for what the fields are about.

So for example, if I were to add Visibility Settings to all Post Objects in a particular Post Type. A Custom Field key prefix might look like: mbe_visibility_.

So If I had a 'Global' Custom Field for the Post Object. It might look like: mbe_visibility_global.

I currently have a function that grabs all Custom Fields for the Post Object, then iterates through the fields returned, filtering out only the fields which have my field key prefix (mbe_visibility_).

So if I had three Custom Fields: Global, Post Types, and Posts, I would have three keys (each containing a value, specified when saving the Post Object): mbe_visibility_global, mbe_visibility_post_types, and mbe_visibility_posts.

Now here is where my questions begin to formulate.

I feel like it's a little over-kill, fetching/filtering ALL Custom Fields assigned by WordPress core and other miscellaneous plugins on the website.

I was thinking about just changing the way Post Meta is stored/referenced for my Custom Fields.

Instead of saving a new Post Meta key for each of the Custom Fields, save all of the Custom Fields in ONE Post Meta key for that Post Object.

My approach was to just stick all of your $_POST data into one array. So an input field in a Meta Box might look like: <input type="checkbox" name="mbe_visibility[general][global_visibility]" value="'.$value.'" />

So now when you hook into save_post you only need to check if ONE key is available.

if(isset($_POST['mbe_visibility'])) and just save that entire array into one Post Meta key.

update_post_meta($post_id, 'mbe_visibility', $_POST['mbe_visibility']) should probably sanitize / validate the data before save, but this is just for example.

Now all I have to do, to reference ANY of my Custom Fields from the Post Object's Post Meta, all I have to do is: get_post_meta($post_id, 'mbe_visibility', true) and I will have specifically what I want for this Post Object, and not have to fetch and filter through all sorts of other unneeded Post Meta from WordPress core or other miscellaneous plugins.

If you made it through my long-winded explanation, the question is: Is it a bad idea to store all of your custom fields into one post meta key, for easier data management? VS. Storing each of your custom fields in individual post meta keys for each custom field.

Of course I would like to see a valid explanation with reasoning supporting your answer.

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

If you need to search by your meta_key/meta_value then do not store them in a single key. If you store as a single key then you are going to have to store your data as serialized string, or something similar. The only way you can search that would be via an inefficient %LIKE% query which would also probably be prone to error. Something similar is true if you need to sort queries on any of your values. You can't get any reasonable kind of human-like alphabetical or numeric sorting out of a serialized string. If you expect you might need to do any manipulation at the database level, store as individual meta_keys.

If, however, all you will ever need is to pull the data by the meta_key out of the database as a monolithic block you should be fine.

share|improve this answer
    
Well if I wanted to make a search on an archive, I already have all the Post Object data available. There are probably custom fields which need to be displayed within the Post Object, which means I already ran get_post_meta() for each Post Object and the Post Meta data would already have been unserialized. The search could work by locating matches in the array of Post Data already available. I know it's not ideal, but the search could still work. You could get any kinda of sorting by pulling all of the post data and using PHP usort() –  Michael Ecklund Feb 28 '13 at 13:56
    
No. That isn't what I mean, and if I understand you, that isn't how it works either. To search for posts with, say meta_key = "animal" and meta_value = "dog" you don't pull all the posts with all the meta_data, unserialize everything, and then search the Post Objects. The overhead of that would be enormous. You-- well, WP_Query most likely-- would create a SQL statement that JOINS on the appropriate tables. The search happens in the database. You do not dump the whole database of posts and then search that. You do not have the Post Objects available. Those are created later. –  s_ha_dum Feb 28 '13 at 14:11
    
I already have all the data available, because I used it for outputting the posts in the archive template. So since I already used that data for output, I would just filter those posts for what's displayed. If there's no active search, then just display all posts with a pagination. –  Michael Ecklund Feb 28 '13 at 20:24
1  
Then what you are talking about is filtering existing content not searching content, and the answer stands. It is conditional. If you need the database to do any searching or sorting on your meta data don't store it as a single key. If that isn't a concern then go ahead and use a single key. You seem to be telling me that database level searching or sorting is not an issue, so store a serialized value in a single key. –  s_ha_dum Feb 28 '13 at 20:29
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.