BuddyPress.org

There’s not too much you can do–unless you made a backup of your MySQL DB before messing with it in the backend.

You should always make a backup of your DB before you do anything to it that may result in changes to the data or the data schema. In fact, make a backup of your DB at the end of each coding day just incase the unexpected happens.

I assume that you did zero customizations to the data schema of your MySQL DB. If so, then just delete your current DB and then create a new one with the exact same username and password. But, if you do this, you’ll need to reinstall BuddyPress so that BP’s tables get created in the DB. You will also have to reenter any test data, but it should get you back up an running.

Also, I’m not sure why this is an issue:

I’ve customized so much code on the back end that reinstalling buddypress would be a huge pain.

Do you mean that you have hacked the core or WPMU and / or BuddyPress? If so, you should stop doing that as every time BuddyPress is updated, your hacks will be lost.

Instead of hacking the core BP files, either create your own custom plugin(s) to hold your code, or use the bp-custom.php file. That way, if and when you need to delete your install and start from scratch, you can easily do so. Just make sure you have back ups of any custom theme files, a listing of all your plugins, a copy of your bp-custom.php file, and a copy of your wp-config.php file assuming that you want to use the same MySQL DB.

Yep, it sounds like a painful learning experience.

It happens to all of us at sometime. That’s when you finally get the point of backups and following proper coding protocol.

Should emptying the wp_users table ideally not also delete the connected user data in all the other tables, including xprofile? Or is that not how MySQL works?

No. The way the MySQL tables are set up for the *presses, is that there is no referential integrity. So, if you go into the DB’s backend and change a record or delete a record, it does not cascade the changes to sibling or child tables.

For example, assuming that you were allowed to do this by the table’s schema, if you changed the user ID in the wp_users table, it would not automatically update that ID in all other related tables to reflect the new ID number. Of course, the record ID fields in the *presses are automatically incremented, but you get the point.

Up until recently (past several years or so?), MySQL did not even offer the option of setting up tables with referential integrity. Now it does in a less-than-desirable way. It is not as simple to do in MySQL as it is in PostgreSQL, but it is straight forward enough. It requires that the tables have foreign keys and are created with the Type = InnoDB extension.

Personally, I’m a big PostgreSQL fan, but I do not want to start a PGsql vs MySQL flame war. If you use the *presses, you use MySQL. It’s as simple as that.

But, referential integrity is still not usually set up in many MySQL DBs. So, this is nothing peculiar to the *presses. Why? Because the developers make sure that the code takes care of the updates and cleanup.

This is one, of many, reasons why you really need to know what you are doing in the DB’s backend.