Open dawnbuie opened 6 years ago
OK - update - so I figured out my PODs were destroyed by a content import tool I was using DrupaltoWordpress Plugin.
I thought the pluging had worked perfectly - because I was able to assined the custom content type from Drupal to my newly created Wordpress PODs - and the populated the content types correctly! However when I went back to edit the PODs themselves I saw their pod names had been changed from something like 'update' to the title of the last Update items imported - with spaces so 'A Great Story about Surfing".
I then tried editing the POD name manually to set it back to 'update' but when I saved that I was locked out of the PODs Admin page - getting 'you are not allowed to access this page' message.
Luckily I had done many backup version of the database - so I restored the version before importing all that content - and then I was able to export the PODs and import into a new WP site.
However I still have this import issue. Why did the POD structural data get overwritten so easily? Would it be safer for me to enable the Table Storage component:
| Enable a custom database table for your custom fields on Post Types, Media, Taxonomies, Users, and
Or the Advanced Content Types:
A content type that exists outside of the WordPress post and postmeta table and uses custom tables
I have made custom content types in WP manually before and I thought PODs would save me a lot of time (I love the HTML field options too) - but if they get destroyed/overwritten this easily I don't feel good using them.
Here is my export code for the PODs:
It sounds like a few things may be happening here:
The script will truncate (delete all records) for the options you select. This means original WordPress content will be lost, if you have any. (This is to keep the content IDs matching for all options)
Nothing you have described seems to be Pods-specific. I really do wish it was so we could fix it all for you. I'm sorry you experienced this problem with that script, I hope your setup is working for you now that you were able to to the backup/restore.
Hi there - thanks for the reply. I did try some other migrations scripts that did the same thing - and every realized:
Pods configurations are stored as post types. If a plugin deletes all posts, then the configurations get lost at the same time
That's why I asked about protecting existing PODs but turning on the Table Storage component:
| Enable a custom database table for your custom fields on Post Types, Media, Taxonomies, Users, and
I did try that but it didn't seem to have an effect.
Pods hooks into the normal post/meta API, so even though it's content could be stored in a table, that does not mean it gets retained. If wp_delete_post is called, it will delete that data wherever it exists.
Describe the bug I can't migrate my 8 PODs to a new Wordpress install.
To Reproduce I have 8 functional PODs that are based on Page Types I turned on the Migrate Packages component and check all boxes. These are the results I get:
{"meta":{"version":"2.7.6","build":1532480499},"pods":[]}
I did try pasting that code in the Import Migrate section of the POD area in the new site but not surprisingly - it did nothing.
Expected behavior Have the POD types defined in the new Wordpress installation
Pods Version
Version 2.7.6
WordPress Environment
Pods Package Export (helpful!)
Additional context Add any other context about the problem here.
Possible Workaround If you have discovered a workaround, please include it below.