I hope that WordPress will provide some automation to migrate users from WordPress 2.9.x and earlier to the soon-to-be-released WordPress 3.0 running multi-sites (this shouldn’t be an issue with WP3 running single sites). Unfortunately, I haven’t be able to find any definitive word about that. Since I don’t want to be caught with my proverbial pants down, I’ve been hacking together a little migration program. It’s still in WIP-form (Work-in-Progress), but so far things haven’t broken so that I’ve noticed.
WordPress (any version) maintains a blog’s user list in a database table named ‘wp_users’. Even when running in multi-site mode, the users from all of the sites are kept in one single ‘wp_users’ table. It’s when you start migrating existing sites into WP3 that things get interesting. The User_IDs from the old single-site blog will change just as soon as you append them into the new multi-site table. This messes up info on who authored posts, comments, and some plug-ins (such as forums) that deal with the user base. PLUS, you have to keep track of what blog or blogs users have signed onto (nevermind their permissions). So yeah, it’s a lot of fun.
When you add in the fact that while I used to be a programmer, I don’t do it a lot anymore; I’m not a WordPress coding guru; and some info is just plain badly-documented (if at all)…well, it turns everything into an interesting exercise.
So… my plan of attack:
- Prep the tables. Create an empty site in WP3. Export the necessary tables. Table prefixes, site links, and uploaded file locations need to be updated before the tables can be imported into the new site in the db.
- Find all of the new users that aren’t already in the database and add them (plus simple meta data). Use the new user_IDs to update post and comment user_ID fields.
- Find all users that share login name and email addresses. Update the meta data for the new blog. Use the WP3 user_IDs to update post and comment user_ID fields.
- Any other users will be flagged to be dealt with manually.
- In a separate program: Update any plug-in user_ID references (e.g. for a Simple:Press forum).
- Cross your fingers and think happy thoughts.
Initial tests have been very favorable. Some data will be lost in the process simply because a lot of meta data is difficult to trace to various programs and some codes that are stored aren’t obvious. The overriding goal is for users to still be able to log in and access their posts and comments. If other settings need to be reset, it’s a smaller price to pay, I think, than having to re-register and losing access to your previous contributions.
We’ll see what happens. I’m about done with “3″ and “4″. There’s still some writing and a lot of testing yet to do before I’d risk this on a live site.
There’s a follow-up to this post that has the procedure I used when I did my migration. Beta: Migrate Users From One or More WP Blogs Into WordPress 3.0 Multi-site
Well, i dont know alot about the WordPress data system, but thinking that it is a simple db of users with PrimKey a numeric ID, and some basic data like name, email and pass.
And in other table you would have the posts with a ID (numeric PrimKey) and in one parametre a autor ID.
I see your way very valid.
The metod is like a NoRepList + NoRepList. You Add the first elem of list B to the last of List A if it doesn’t exist already. (In DB the last is create a new elem with new ID).
Like i said i dont domine the wordpress system, but if i can help you with something ask for it.
I appreciate the offer. WP3′s tables aren’t too onerous, but as you add sites they multiply. The trick, I’ve found, is to do the updates while also not causing things to go brain-dead…which is what simply moving tables does.
Things are actually going well. Users are migrating into the user and user-meta tables and they are being recognized by WP. Next step is updating message tables. I’ve had to add a couple of tables for this routine so that updating tables doesn’t have to be done all at once. Why? Well, while the posts and comments will likely have come in with the initial migration, admins might delay reinstalling plugins and their tables. I wanted to have that option. Also, it serves as a check to make sure a post/comment/whatever is only updated once, as any further updates could scramble things up again.
I’m hopeful that, time permitting, I’ll have something ready in a few days.