The hot story going through the blogosphere right now is the fact that spammers have hijacked commenting utilities to create denial-of-service attacks on ISP’s. Let’s just say that yeah, its a problem. I’ve spent a good part of my weekend dealing with b2, the old WordPress. You see, the migration procedure for b2 is less-than-native, because any sort of in-depth documentation is less-than-existent. I got so fed up today that I actually wrote my own, so I guess this is my first experience with online collaborative wiki document writing. I want it to get spidered sooner, so here’s my doc. Hope it helps others!
I found this upgrade to be challenging, largely because the documentation over-simplifies a b2->wordpress upgrade. I’ll attempt to explain in relatively simple terms. If you end up using some of the more advanced parts of this documentation, it is assumed that you are generally familiar with mysql. A graphical interface, like phpmyadmin, might be a more native interface for some users..
First, let’s assume you have a working installation of b2. B2 uses 5 tables:
categories
comments
posts
settings
users
Further assuming that you’ve completed a stock installation, b2 prepended a “b2″ to the names of these tables. In your database, you’ll see:
b2categories
b2comments
b2posts
b2settings
b2users
The general theory of operations for the b2->wp upgrade is this:
1. WordPress must first be installed and connected to the database.
2. After running the install, wordpress creates a number of tables in this database. If you’ve completed a generic installation of WordPress, a wp_ will be prepended to the newly created table names.
3. The user must then drop a few tables, and rename the existing b2 tables so they now comply with the WordPress standard.
4. The user must then run the installation script.
Let’s assume for a second that a user has completed two stock installations. The first is a stock b2 installation, and now they have installed wordpress, stock. After running wp-admin/install.php, their database would have the following tables:
b2categories
b2comments
b2posts
b2settings
b2users
wp_categories
wp_comments
wp_linkcategories
wp_links
wp_optiongroup_options
wp_optiongroups
wp_options
wp_optiontypes
wp_optionvalues
wp_post2cat
wp_posts
wp_users
The prefixes generate confusion. For a mental exercise, strip away the prepended “b2″ and “wp_” from each table in our database. You’d notice that 5 of them are duplicates. For each of these 5 duplicates, one table is your old b2 table, which contains data, and one is a new wp table, that you havent populated yet.
The somewhat tricky part is knowing that you actually need to drop the wp duplicates, and rename the b2 tables so that they conform to your newly installed table prefix structure. Complex? It is almost better explained in code.
What you need to do is the following:
First, you must drop the WP duplicates (this is a SQL query):
DROP TABLE wp_categories;
DROP TABLE wp_comments;
DROP TABLE wp_posts;
DROP TABLE wp_settings;
DROP TABLE wp_users;
Next, you must rename the b2 tables so that they conform to the current table structure (this is also a SQL query):
RENAME TABLE b2categories TO wp_categories;
RENAME TABLE b2comments TO wp_comments;
RENAME TABLE b2posts TO wp_posts;
RENAME TABLE b2settings TO wp_settings;
RENAME TABLE b2users TO wp_users;
Once you complete this, you will need to run the import-b2.php script. Magically, the upgrade will work.
The most important thing about making the upgrade from b2 to wordpress work is knowing that the prefix is important. If you try and install a wordpress with the same prefix as your b2, it won’t work. If you install it with a different prefix, the import-b2.php script won’t work out of the box. This is a fairly low-level fix, but it will work. If you aren’t comfortable running it, show this page to a reasonably technical person, and they should be able to read this and know what to do.
