post types gone

The settings for the post types and taxonomies that you create are stored in the wp_options table. The posts/terms for types/taxonomies you create are stored in the wp_posts/wp_postmeta and tax related tables. When you delete a post type or taxonomy in our plugin, we simply amend the saved option, we don’t do any querying for posts/terms created under them and delete those as well. So the data should be there still, and if you didn’t delete the options, then those should still be there too. If it’s failing to recognize them after the migration, then that would sound like a bug that i’d need to investigate.

We experienced this while staging a local WordPress installation, as well.

If we var_dump( $cpt_post_types ), we were getting bool( false ) returned.

I still don’t know the solution, but we were able to force it to work (for anyone on a deadline like us).

Important: Copy and save the value from *_options.cpt_custom_post_types in your database. Make a backup of your database as well, if you’re not familiar with MySQL.

After grabbing your data from *_options.cpt_custom_post_types, go to Add Custom Post Type in your wp-admin and add a post type. It doesn’t matter what it is, it will be deleted. Please note that this will remove and replace all data in *_options.cpt_custom_post_types. You will see the new post type on Manage Post Types.

Go back to your database, and replace the value in *_options.cpt_custom_post_types with the values you copied/saved before.

Revisit Manage Post Types in wp-admin, and everything should be restored.

Hopefully this write-up will also assist the plugin author on how to fix this bug.

I’d like to also note that it may very well be an issue with WordPress.

Because when we var_dump other get_option( 'field_here'), it returns the correct value. Only when running get_option on a cpt value does it return false.

To Author: if I can be of further debugging assistance, let me know.

I’m going to try and summarize in a shorter version for what geoff67 typed out, which I am definitely appreciative of.

He basically triggered the creation of the option row in the database with some quick content and then manually replaced the option value with the original content from the dev environment.

Why ours are returning false, even temporarily, is something that’s eluding me, and the more it happens, the more irked I am regarding that fact.