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:
So If I had a ‘Global’ Custom Field for the Post Object. It might look like:
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 (
So if I had three Custom Fields:
Post Types, and
Posts, I would have three keys (each containing a value, specified when saving the Post Object):
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.
Below are the methods you can try. The first solution is probably the best. Try others if the first one doesn’t work. Senior developers aren’t just copying/pasting – they read the methods carefully & apply them wisely to each case.
If you need to search by your
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
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.