Updating Plugin lost post types
-
So updating from a pretty old version of this plugin to the latest has caused some of the custom post types to be missing. Has anyone experienced this before?
I can revert the backup on the dev environment before the update and all of the custom post types show up in CPT UI, again, after updating this plugin, they disappear.
-
What version are you updating from?
I’m curious if there’s some sort of slug change somehow occurring and the actual post data is still present in the database. If there is somehow a changed slug for what gets registered, then it’d appear like everything got lost, but actually is still available once re-matched up.
For what it’s worth, we don’t touch the posts table ever with an update process, with our code. Only time we come close is when switching post type slugs and we provide a chance to convert post types for found posts from the old slug. That’s a manual choice by the user though.
Just checked and it’s updating from 0.9.5
I searched the db for one of the missing post types and they are all still in the database, they just aren’t showing in the admin where they should be or anywhere. They also do not show in CPT UI either. The export/import code also does not show the missing post types.
Searched the database with SELECT * FROM
wp_postsWHEREpost_type=’cptslug’Before updating the plugin, or if rolling back a backup before the update shows the missing post types, and shows them in CPT UI. So this really seems like something in one of the plugin updates is causing this.
So rolled the backup back to before the update. Disabled all other plugins, and took a loot at the db, and the code in the plugin. This appears to be an issue with the function that converts the post types to the new db table cptui_convert_settings it appears this is getting all the posts from cpt_custom_post_types and converting them into a new table called cptui_post_types, and some of the posts are not being converted and added to the serialized array in the new table.
I will keep digging through and let you know if I find what exactly is causing it. Let me know if you have any ideas. One specific post type was registered with a – instead of a _ and also has a rewrite slug. Example is slug was customer-spotlight and rewrite was customer-spotlights. However there are other posts that are using dashes that are still populating example name/slug = case-study rewrite = case-studies
-
This reply was modified 7 years, 2 months ago by
bowenac.
Was able to compare the two db records, and re-serialize the data and add the missing post types to the new db record, post types are now showing up. So this leads me to believe there is an issue when converting the old db record to the new db record.
-
This reply was modified 7 years, 2 months ago by
bowenac.
Oof, yeah, that’s a long jump, but in terms of existing settings, not a huge amount that should be affected.
First up, part of what ended up being the 1.0.0 release was a conversion of the existing settings to what I’ll call a more stable version. Forgive moments of techy/code-y talk, but basically converting an indexed array to a named array for the CPTUI settings storage. One smart thing I did at the time was not delete the pre-1.0.0 option, in case rollbacks were needed.
You are not quite right in part of your statement above. With that update routine, we do not affect the posts, we do affect the saved option for our settings and create a new setting. Also nitpicky terminology, we don’t create any new tables, just an option row in the wp_options tables. Just clarifying.
As is, the dashes should end up remaining as part of the found settings, but once you go in and try to edit them, there is javascript tied to JUST the slug field to convert them to underscores. The rewrite slugs should remain untouched. If somehow the post type slugs are being converted to underscores as part of the settings updates, then that’s an odd, unintended, case, but also probably the primary source of headache here. I do know there are in fact ways around this and can go into better detail about it, if needed.
That said, it’s good to hear that the content is in fact still in the database like you desired and I expected. Just a matter of getting slug details matched up so that the appropriate custom post types can start getting registered again and the site going forward like everyone hopes.
Yes you’re correct sorry I meant the db records. Still it appears when you’re converting the post types from the old db record into the new db record something is happening.
What I did to fix it was I copied the serialized array from the old db record, and copied the serialized array from the new record. I then manually re created the new serialized array with the missing post types data from the old record into the new format. Then replaced the serialized data in the new db record with the fixed/updated array, I was then able to see the custom post types that had been missing.
I still have the data from the old record and the record after updating the plugin, and then the data I fixed and replaced on the new record if you would like to review that data to try and determine what could have went wrong. Let me know if you would like to see that data, I could email it to you or something.
-
This reply was modified 7 years, 2 months ago by
bowenac.
I can’t promise anything, but I won’t argue against having a copy of your pre-converted option rows just to try with. I know I was testing a lot before the release way back when, and I know majority of our users are above that version by now. However just in case something is found that can be done, I can always touch up the conversion function. Email it to [email protected]
Any news or changes with this one @bowenac ?
-
This reply was modified 7 years, 2 months ago by
The topic ‘Updating Plugin lost post types’ is closed to new replies.