Invalid Post ID Error When Migrating

The Pods Component, ‘Migrate: Packages’ only does an export of your ‘structure’ and import of your structure. It is not used to migrate actual data.

If you want to migrate data, post-types, relationships, etc. without losing all your connections, you’re better off using a site migration tool like WP DB Migrate Pro or UpDraft. Trying to do a piecemeal import of just a few custom post types with relationships will not work, because you can’t import and export relationships without using one of the premium plugins that work on top of WP All Import Pro (CIO Custom Fields Importer and their premium plugin. They are not affiliated with the Pods Framework but many people have used their plugin for performing complicated multi-relationship imports of Pods configurations with great success.

If you’re trying to work your solution in it’s own tables, you should be looking at the table storage option for ‘meta’ where the custom meta is written into its own tables and only the wp_posts stores the main post types content so your content can still work with most of the WordPress plugins.

As to the error you’re receiving on the live site, we’d need to know more details to help you troubleshoot the problem. Is the only error you’re getting ‘Invalid post ID’ when you attempt to do the Migrate: Packages, Import and what type of configuration are you importing?

• This reply was modified 6 years, 11 months ago by Jim True.

Hi Jim,

Perhaps a mix-up in language, but to me “structure” is data, and was thereby unable to migrate.

Here is what I discovered since my post –

• CIO Custom Fields Importer does not function as advertised. It deleted all relationships and duplicated all of the posts I was attempting to move.
• UpDraft also does not function as advertised and like CIO, also deleted all relationships and duplicated the posts.
• All Import – same as the above

As for the “Migrate Packages” error, Pods was holding onto previous import attempts without exposing them in the admin UI. I ended up truncating the tables in the database and running the import again so as to get the structure moved over. As for the custom posts, I’m wholly at a loss now that I’m having to chase down several different plugin developers to refund my purchases since all three have effectively killed all relationships and duplicated the posts.

Thoughts?

Updraft is for FULL site migrations. You can’t use it for a partial migration of a handful of post types and relationships. That sounds like what you’re attempting to do.

Did you open a ticket at CIO Custom Fields Importer since it sounds like you purchased their premium product and discuss with them the issues you had with your import?

WP All Import won’t do relationships at all. The premium version of CIO Custom Fields Importer will in combination with WP All Import, but as I mentioned above, we don’t support it. The creator of that plugin does that.

Did you get the structure imported now that you discovered what the problem was with the Migrate: Packages import? ie, do you have the custom post types and relationships created in your live installation just without the data? You will probably have to visit each of those new pods you created and their relationships in the Pods Admin to make sure the relationships ‘stick’ before you import content.

It also might help if you explain exactly what you’re trying to do instead of just what you’ve done to try to resolve it. What exists in the Development site that doesn’t exist in the Live site? Are you attempting to import new entries into your production posts on your import? Or are you importing new posts into new custom post types that has connections to existing posts in your live site?

If you’re attempting to do either of those, you’re better off with a tool like WP DB Migrate Pro, since it works more like GitHub. You pull from live to development and freeze production. Add your changes to development and then push back to production. You also have the ability to only pick specific post types with WP DB Migrate Pro, but you would also need to include the wp_podsrel table if you’re doing relationships and if you started with two completely different copies of data (production and live) they’ve more than likely got completely different post id’s which mean your relationships will be all out of whack.

That’s why a tool like WP DB Migrate Pro is better, because you’ll get an exact copy of your production server on your development server, but you do have to ‘freeze’ all changes on production while you integrate your changes before pushing back up to production from development. Or, plan on deploying your solution as just the structure, import any new data into new post types and then recreate your relationships.

• This reply was modified 6 years, 11 months ago by Jim True. Reason: clarifying my sentences above

Hi Jim,

The data I’m attempting to port over does not exist on the live site at all, so I didn’t have any need for a tool like WP Migrate Pro. It is simply a brand new post type that I need to shift from one location to the next. There are roughly 350 of these custom posts that I need to have be 100% portable, and it doesn’t appear as though there is truly a means of doing it without losing data from the live site (which will amount to a considerable loss).

I did indeed get the structure imported to the live site, and it did “stick” so there isn’t a concern there.

CIO doesn’t show any of the relational data at all. While I have now sussed a means of exporting these custom posts to either JSON, XML, and CSV the import functions in CIO and Import All duplicate all of the custom posts and strip them of the Pods data. Both frameworks appear to also arbitrarily decide to skip either the first endpoint (JSON/XML) or column (CSV), and the imports fail 4 out of 5 times. I could easily push support requests forward, but one would think given the “premium” status and the cost associated that they would work out of the box.

Thanks very much for your time. It’s looking more and more like I need to move on from Pods as a solution for my client.

Okay, so you’re importing 350 of these custom post types that have to be completely independently portable, correct? Where do the relationships enter into this configuration?

Independently portable, meaning they’ll always contain the same 350 posts with the same data or will need to consistently be able to migrate the data in these tables in and out of the installation? If it’s the latter, you should look at Advanced Content Types (instead of Custom Post Types), probably, since those are independent tables and you can do standard MySQL import and export with them.

As to the premium solutions, again, they weren’t created by us and aren’t supported by us, so that’s not under our control unfortunately. You might have a configuration issue problem or mistaken something in their documentation and that’s why I suggested you escalate to CIO directly for assistance. From all I’ve heard, they are very helpful.

We typically point people at WP DB Migrate Pro because it works for so many other things than just Pods and it’s much easier to pick and choose what you’re migrating, especially if you’re being specific about what you’re importing and exporting and you have more of that control with the Pro version. They also have a new product called ‘MergeBot’ which supposedly does the work of ‘snapshotting’ your data and only importing/exporting the changes.

WP All Import/Export (Regular and Pro) is primarily when you need to create a consistent regular import routine (ie product list or price list from an inventory company) and have it scheduled to update your content. We haven’t been able to get them to create a dedicated Pods integration or we would recommend that directly and we haven’t had the resources to dedicate any time to creating one ourselves.

• This reply was modified 6 years, 11 months ago by Jim True.

Hi Jim,

Turns out there wasn’t a need for any of these high dollar, premium plugins. The native WordPress import function worked perfectly. There were a handful of media links that were dropped, but it was a tiny percentage and the native feature worked like a dream.

Off to chase refunds!

Glad you figured it out. You did make it sound like you had a complicated configuration. Sounds like it wasn’t that complicated at all. Good luck on the refunds.

Hey Jim,

It was really, really simple and what I think was making it more complex than necessary was sorting a means of integrating/merging the new post type since work is being done daily on the live site, and thereby difficult to freeze it for any length of time.

One thing I have noticed in the last couple of days is that a large amount of our media (i.e. images and PDFs) was duplicated on import. WordPress additionally decided to make JPGs of PDF files, which is odd. All in all and despite a handful of hiccups, the native import feature did exactly what I needed it to.

I did take another long look at those premium plugins, and tried them in a couple different environments before giving up on them completely. They need some love, so maybe step carefully before recommending a $100 solution when the native WP features might be more than enough to get the job done.

Thanks again for your time, Jim.