Import WordPress WXR – Category IDs changed

The problem here is I am using IDs hard-coded in my template files for various purposes, such as navigation, conditional functions, etc.

And that’s why relying on ids for conditionals isn’t a Good Idea. Try using page, post and catgeory names instead.

https://codex.www.ads-software.com/Conditional_Tags

And that’s why relying on ids for conditionals isn’t a Good Idea. Try using page, post and catgeory names instead.

Except that I cannot hard-code in those names as the client may change them (in my custom theme schema, that is an option)… but he will NOT change the IDs. That is why (IMHO) using IDs in conditionals is actually better…

But back to the point then, any idea WHY the ID was changed during the import? And how to avoid that from happening? Thanks!

I think it’s because WP adds the categories to the database rather than replacing existing categories. So the categories just get the next available id as they’re imported.

I think it’s because WP adds the categories to the database rather than replacing existing categories. So the categories just get the next available id as they’re imported.

Thanks esmi – that would have been my guess, too, except this was a fresh install of WP on the client’s server. The database was new. So there was no existing category ID to conflict with…

Anywho… I tried making the DB updates directly, correcting the ID back to what is should be. But I’m not a relational database guy, and I clearly missed something b/c now the subcategories under the specific cat in question are no longer showing up in the Categories panel. I’m guessing there’s something I didn’t do correctly with the wp_term_relationships table.

Think I’m going to just have to suck it up and go with two code versions instead.

But this is a very common workflow scheme for me (export -> import and using IDs in themes), so if anybody comes across a way to avoid this renumbering of IDs upon import, I’d appreciate hearing from you. Thanks.

OK – here’s the solution that worked for me, though it doesn’t address WHY the data was corrupted upon import in the first place… it is at least a workaround.

I am defining constants for the category IDs in my functions.php file – i.e.

// Set the theme categories
define('VIDEO', 6); /* on locahost this is '6', on client's server this must be updated to '7' */

Then I just reference that constant in all my theme’s files, and I only need to update the functions.php when the ID needs to be changed.

However, I’d like to leave this thread “unresolved” as the core issue with export/import still remains: All the ids should be preserved, but for whatever reason it doesn’t always work right (for me) and IDs occasionally get changed. So again, if anybody has info on that, it’d be appreciated.

I experienced the same issue today when migrating from a dev to the live server. A handful of categories had different IDs, as did a few of the pages.

I made sure that on the live server, it was a fresh install of WP and I also deleted the dummy page and post that come with a fresh install. And made sure to empty the trash for both pages and posts. I thought this would take care of the IDs but it did not.

After reading esmi’s quote above, it seems that the IDs aren’t preserved from the import, which really doesn’t make sense. Perhaps WP just adds new records to each database table to avoid a conflicting ID if there are already records in the table?

My solution was the same as luispunchy, I used PHP’s define() to set constants in wp-config.php, then referenced these constants throughout my custom code instead of the actual IDs. This is a pretty good solution and just gives one place to update IDs after the migration.

I think the better solution when doing a migration is to export the database itself. This way the IDs will be preserved. But will there be any problems with WordPress?