Explaining Where Your Custom Field Values Are Saved in WordPress & Tips for Improved Maintainability

To understand custom fields in WordPress it's important to understand how they are saved to the database. This video demonstrates where they are stored (in the `posts` and `postmeta` tables by default) and how to save them to a custom table for improved scalability and maintainability.
Do you think deleting a custom field is deleting it from the database? Think again. This video shows you what happens when you delete a custom field from Meta Box (or ACF) and also shows how to actually delete a custom field from the database.
This video will show you how to use phpMyAdmin to actually delete a custom field and custom field values. It's easier than you think 🙂.
As a bonus this video also shows how to change the field group title so it's more clear on the post edit page.
In this video, Meta Box is used but this largely applies to other custom field and custom post type plugins like ACF and Pods.

[@gilpoulsen]

Hey, thank you for doing this, I've never really understood the whole mechanism here as far as how custom fields are stored. This seems like a much smarter way to approach CPTs/custom fields for many reasons, but I do wonder if there are any compatibility issues with other plugins that expect to see the custom field values for CPTs in the postmeta table? Just curious. Thanks again for the very thorough exploration of this issue.

[@touchdowntech]

Hey @gilpoulsen, Yes, there are some plugins that are not compatible with saving data to a custom database table.
If you have a website where the custom fields are going to be integrated with a plugin or theme, confirm they work with custom database tables before using them.
Bricks Builder's dynamic data is compatible with custom tables for Meta Box, but I'm not sure about ACF's 3rd party custom table plugin.
When you understand how to delete custom database tables and fields, it is easy and safe to test out the compatibility and then delete them if necessary to use the postmeta table.

[@jzajzz]

So what's the reason that post meta table is the go to method?
What are the downsides of using custom table..
Will there be compatibility issues with other plugins and page builders?

[@touchdowntech]

Good question. I think the reason the `postmeta` table is used by default for Meta Box and ACF is that it's an available table to use and ends up being the "junk drawer" of the database.
I've used custom tables with Bricks Builder and Oxygen. I don't know about other page builders.
The only thing to keep in mind is that in the Bricks query loop builder you can choose a meta query. That setting is looking at the `postmeta` table and not a custom table. So if you want to create a checkmark or switch field to show or hide a post from a query loop, you'll need to create a field group that uses the `postmeta` table instead of a custom table.
In the example at the end of the video where I am changing the field group title, That's an example where I used the `postmeta` table because the field was controlling the inclusion of a post in the archive.
Does that make sense?

[@jzajzz]

@@touchdowntech I think I got it. I'm not that seasoned..but I'll watch the part you mentioned in the video to see what you're talking about

[@touchdowntech]

@@jzajzz If it doesn't make sense, let me know and I can create a separate video about getting custom field values using dynamic data in Bricks Builder.

[@dynamic-homepages]

@@touchdowntech thanks for this good tip. I have events CPT where I need to access the meta_key for Date Fields for comparison. Would have put them in a custom table. But maybe there is a workaround. Guess if you would put code in the Child Theme and echo it out in the builder.

[@dynamic-homepages]

I have 8 CPT and about 600 MetaKeys xD
So I startet to use MB Custom Table. And actually if you put your Custom Fields in a Group (not Duplicate option) you can still access them regular. And they are saved in one serialized meta_key and meta value. Of course you should have really fixed custom fields, otherwise it might be really hard in future to change the meta_values inside. But for Bricks it’s easier to access them because they are all loaded one time. Instead of going over each individual meta_key. Not easy if you want to scale, but do it wrong so many times in the beginning 😂

[@touchdowntech]

Wow! That's a lot of keys to manage! I'm sure it makes for a very dynamic experience for website visitors and easier to manage the website as well. Yea, you're right about the group. I tend to avoid the group field type in general because for some fields I like to use the Meta Box shortcode for displaying a field value for a certain post type within the WordPress editor or other places that don't support dynamic data like Bricks does.
But using the group field type does have a lot of uses, like you mentioned.

[@dynamic-homepages]

@@touchdowntech i was no facing issues with using conditions inside a group. Now I know why i like to have a Switch as my default element. Because its automatically having either a "0" or "1" as a value. While other elements, might not exisit in the group because they were not saved by default.