Hidden or Secret Custom Post Types are just like any other post type you may have in your WordPress admin dashboard, just not directly visible, or highly customized. However, are they are a good way to store custom data? What are the benefits?
Before we start on some of the pros and cons, I’d like to start out with the fact that WordPress by default, uses secret post types. Navigation Menus are a custom post type. When you create a menu and menu items, that is a custom post type with data.
When a post’s default data is not enough, you add in custom post meta whether through custom code or a plugin like ACF. How about when you want a whole new wrapper for that data? What if that wrapper isn’t content specifically, but you would like to be able to get the data just as easily as any other post type? That is when a Secret Custom Post Type comes in handy.
Matt gave a great example that they use in the Give plugin. Payments made through any Give form on a website using the Give plugin for donations, are stored using a custom post type. This data is then stored in post meta fields for each individual post. For example when making a donation, a new post (of payment) gets created, then all associated data (like amount) get added to that post via post meta.
This setup makes it easy for the plugin, other plugins, and theme developers to get this data and then do with it as they please. For example I wrote an article on how to get this Give data though the Give API to create ChartJS powered charts. Another great example was being able to show who has donated right next to the donation form (add-on coming).
I’ve used secret post types plenty in the past to store data that isn’t really content for the site somewhere wrapped, but that is easy to get to.
Secret Post Types may make your life easier, but also can be a bad way to store data and make your database much more bloated than it needs to be.
Josh brought up many great points as to why a custom table solution, might be better, than just creating as secret CPT to store data in. He cited a few instances and articles by Pippin, including an article which talks about extending the get_metadata api. This would allow a custom table to be created but still be able to use basic WordPress functions to get the data.
The last thing that I really wanted to talk about and never thought about before, is a hybrid approach. The best of both worlds. We used WooCommerce’s Orders as an example, a secret post type that really doesn’t do much for content on the site, but mainly stores data. What if the Order ID’s and basic data were a post, but all the custom data were stored in a custom table? Even if the custom table was just order_id and values, which values being an array, it would allow you to quickly grab all order data without adding so much data the default database tables.
Josh brought up the get_metadata api article again, mainly because WordPress cache’s the data, so a custom table might not be beneficial if you constantly need to call it as apposed to automatically getting info from cache.
I think this may be the best solution though, allowing you to quickly utilize WP_Query to get posts, but still storing data in another table out of the default post_meta table.
What do you think? What approach do you take, have you used?