Tag: multisite

Moving WordPress Multisite
I answer this a lot.

Edited to add: If you’re just moving to a new server and keeping your domain name, it’s exactly like moving Single Install WordPress. Just remember to make sure your new server is set up to handle wildcard domains, and your httpd.conf has ‘AllowOverride’ set to ‘All’ and you should be fine. If you’re moving to a new domain name, read on!

Edit #2: The Incerconnectit Search/Replace DB script is also perfect to use, though you still need to manually edit a couple places.

Moving a normal WordPress site is really easy. Copy over your data. Change your URLs, do a search/replace on your wp_posts table (to fix any internal links), go out for a beer. Some of you may need to edit a wp-config file, but mostly that’s it.

Then there’s Multisite, which sucks. See, unlike single installs of WordPress, you can’t change your site URLs easily. Don’t get me wrong, if you’re a Super Admin, you can easily go into WP Admin -> Network -> Sites and edit the sites. You’d have two places to edit it:

On the Info Tab

On the Settings Tab

But here’s where it starts to suck. If you’re changing tech.ipstenu.org to press.ipstenu.org for example, you do that and then you need to go to your database and look for the site posts table (in this case, it’s wp_2_posts) and search/replace tech.ipstenu with press.ipstenu.

That’s not terrible, right? It looks a lot like moving a single install of WordPress.

What if you have your site as subfloders, using ipstenu.org/tech and ipstenu.org/press though? And you want to move everything to lipstenu.org?

This is where it sucks.

See some widgets and theme settings store your data and include your URL. This is done with data serialization as well, which means the length of your URL matters. If you changed from ipstenu.org to Lpstenu.org, then you would be perfectly safe doing a total database search/replace of the domain name! But since I’ve proposed changing it to Lipstenu.org, I can’t do that. Any field that counted my domain name would be off by one, and thus invalid, and thus wipe out my settings. Oh and to make it worse? Depending on how you uploaded your media and included it in your site, your postmeta table might also be filled with this.

It’s important to understand two things here.
1. This situation exists on a normal single site install.
2. You don’t have to change it in those places!
And as a maybe third, I know a lot of people who do a blanket search/replace all the time and never have a single problem. But because I know enough who do have issues, I can’t safely recommend you try it unless you have a rock-solid backup of your database.

This brings us to the point. How do you move WordPress Multisite to a new domain name?

Very, very, carefully.

You’re going to have to do some work in the database, so now’s the time to get some coffee and practice not freaking out. If you have phpMyAdmin, editing your WordPress database is not terrifying, but like a cat, should be approached with caution. Remember to take a full backup of your database before you start. A good backup.

First, it’s perfectly safe to edit all wp_posts (and wp_x_posts) tables with a search/replace of your domain name. I strongly suggest using as much of the domain as you can: i.e. http://newdomain.com instead of just newdomain. This will make sure you don’t confidently change the content of your posts. The Incerconnectit Search/Replace DB script is also perfect to use here, but it won’t fix everything, which is why we have another step:

Next you need to manually go through these tables:
- wp_site
- wp_blogs
Those two tables are really straight forward, by the way. You’ll see what to edit right away.

Then you have to manually (again) review all the wp_x_options tables and look for THREE fields:
- home
- siteurl
- fileupload_url
Only edit those. And yes, you have to do it manually in each of the options table unless you used the Incerconnectit Search/Replace DB script earlier.

Once you’ve done that, go into your wp-config.php and see if you have to change define( 'DOMAIN_CURRENT_SITE', 'ipstenu.org' ); (depending on your change, you may not).

And … that should be it.

It’s a pain, but it’s not insurmountable.

Right away, though, you can see the complications if you’re moving a site from ipstenu.org/wordpress to ipstenu.org, and while most of the changes remain similar, you need to remain vigilant and attentive with every change you make. The wp_blogs table is where it gets stickiest, as you have to add in the new subfolder (or remove it) by editing a separate field in the row.

Just pay attention, read carefully, and remember to breathe.
31 January, 2012
Don’t Use WordPress MultiSite

Edit: It’s May 2015 and this post is still relevant.

I talked about this at WordCamp SF 2013. Check out my slides or watch the video.

I love MultiSite. I think it’s awesome and very helpful when you want to make a network of sites. But more and more I see people doing things where I just tilt my head and wonder why they’re using MultiSite for that particular use-case. People seem to think that simply because they can use MultiSite that they should use it, and this simply is not the case!

MultiSite, either by intention or effect, works best when you think of it as running your very own version of WordPress.com. You have a network of sites that are disconnected from each other, data wise, but share the same available user base. That means the only ‘information’ that is shared between two sites is your user ID, and even then, unless you’re explicitly granted access to the site, you’re nothing more than a subscriber. Which is to say you can read the site, and comment.(You could get nitpicky here and point out that there are a lot more things one can do as a subscriber on a site, but you understand the gist.) That means that while there are many perfectly valid reasons for having a MultiSite, it will never be a perfect solution for all people.

One of the best alternatives to MultiSite is Custom Post Types. They let you make ‘subfolder’ additions to your site and format them as you want. There is a drawback, though, in that you cannot use YYYY/MM/DD in your permalinks for them (Otto on Custom Post Types – wp-testers email list) however I would wonder why people use that anyway these days? The only reason I use YYYY in my URLs is that I believe there’s a date on the usefulness of these posts, and if you come back in five years, you should know how old the information is.

Another alternative is good planning. If you sit down and define your needs for your site before you build it out, and plan for the growth you desire, a lot of things become clear. Think about how many different places you’d want to go to maintain your site.

Here are some examples of sites that should not be built out as MultiSites:

To Categorize Posts

This one comes from my girl, Andrea, who reminded me of a fellow we ran into who wanted to have one site to post from, and each post would go to a special site based on the category. WordPress already has that built in! It’s called, get this, ‘categories.’ Now the user in question said he didn’t want categories because your URL shows up as /category/pemalink, and that wasn’t his desire. So I suggested Custom Post Types. /posttype/name was much better, and he could add in tags as he wanted.

When Your Site is Homogenous

Do you want your whole network to look and feel 100% the same? Don’t use MultiSite. If every single subsite is going to be exactly the same, except for content, but the content is all written the same way, you don’t need MultiSite. Replicating the theme and settings on every subsite is a pain, and you can achieve the same result with categories, tags and CPTs. You can even use a membership plugin to control who sees, and has access to, each CPT!(Role Scoper claims to do this, in fact.)

Now someone will point out that this site fails that check! If you notice, three (four, kind of) of the sites look very similar. Same general layout, same links and sidebars, but different headers. This site could have all been done as categories and CPTs, and not needed the multisite until I hit on the children sites like the one for my grandmother. But. When I built it out, I decided to put my tech posts on their own page to separate the writing. They are separate sites. What I write here is vastly different from my blog, and that’s important to me. The site has the same ‘feel’ in look alone: the context is what separates us.(And I have a plan for the photo blog.)

For One Special ‘Thing’

I’m guilty of this one. I had a site that was a blog, and I wanted to make a ‘video’ section. So I made a MultiSite! Boy was that dumb. Two admin areas, two sections for layout, and I wanted the site to still look like ‘itself.’ I caught a clue later on and converted the whole thing to Custom Post Types! Much easier to maintain! Now I have a smaller, faster, site.

Users Shouldn’t Know About Each Other (AKA Separate User Databases)

Andrew Norcross pointed this out. If you need users to be on different sites, but not aware that they’re on a network, don’t use MultiSite! Now, yes, there are ways around this, however it’s an auditing nightmare for any large company, and a security risk that you should be aware of before you start.

Curtiss Grymala points out that if you need totally separate user databases, this is a strong case against MultiSite. Be it for security or just obscurity, if the users need to be separated don’t do it. There are workarounds, but you’ll spend more time on that then updating your sites.

Hosting Small Client Sites

I don’t host my Dad’s site, Woody.com, even though I maintain it. Why? Because, as

Cristian Antohe said, he just needs a standalone WP install. Would it be easier for me to have one place to go to upgrade him? Yes and no. He’s small, he doesn’t need a lot, and he now owns his domain, his site and his email, all in one place. It costs him $7 a month, plus the number of meals he buys me when we’re in town together, and he’s master of his own domain. This is great for him, because if he fires me, he still has everything. Also, if he does something weird that spikes his traffic 500% (like last month), it doesn’t affect the rest of my sites. Factor that into your budget. Make your client own their own data.

Users Need To Embed JS Into Posts

This is not a bug, people. Only the Super Admin on a MultiSite install has the access to include iframes, javascript, and other non-oEmbed’d data into posts! You don’t want them to! If you’re running a MultiSite, you’re the big dog, and you’re responsible for limiting their actions to things that won’t take down everyone because they don’t understand what an insecure iframe hack is. Yes, there’s a plugin that will let you allow this. No, I won’t tell you what it us, because unless you’re using a 100% locked down, you approve users you know and trust with your car, site, you do not want to open this door.

If you can’t give them they access they need via shortcodes, then they need to host themselves, or you host them separately. Protect everyone on your network, and don’t give them unregulated access.

Users Need To Install Themes/Plugins

Curtiss again reminded me that MultiSite doesn’t let you let your users install themes and plugins as they want. You can, via the use of clever themes that save settings per site (like TwentyEleven) and plugins that allow you to tweak CSS (like WordPress.com Custom CSS) give them more customization, but you cannot give them access to install plugins and themes. Why? Because those things will be available to everyone on the whole Network.(There are plugins to manage plugins more granularly, and only permit some sites to use certain plugins, but again, this isn’t something everyone on your network should have access to do.) Remember, we’re sharing here!

Same Post, Every Site

I keep running into this one. “I want to have the same post pushed to every single site on my network!” I understand why people do this, I just think they’re doing it wrong. It’s not just that MultiSite is meant to be separate (aka individual) sites, it’s that you’re diluting your content. The more different places someone can go to in order to get the information you’re providing, they less impact you have because you’ve given them too many options. Decisions. Make one. Also, as Andrea reminded me, identical content in multiple places is something spammers do. Google will downgrade your site ranking if you do this.(This doesn’t impact categories, tags and archives because of the use of canonical links.)

Now, one user said he needed to do this as a business decision, because each of his (mapped) domains was a separate brand. But the separate brands had shared data. So … they’re not actually separate, but children. Me? I’d have everything link the shared data back to the master brand. McDonalds may sub-brand out happymeal.com (they did!) and make a whole separate site, but if you click on their ‘Privacy’ link, you go back to macdonalds.com! Why? Because the parent brand is where that stuff belongs.

BuddyPress Separation

This comes from Andrea again. If you need to have totally separate BuddyPress installs, use separate installs entirely. Just … y’know, you can do it other ways, but it’s not worth it.

What else?

This list could go on and on, so jump in and tell me your reasons why you’d never use MultiSite!

22 September, 2011
SSL Self Certification and WordPress
I wanted to lock a single-site WordPress install down to use SSL admin because I’m a tin-foil hat wearing nerd. Or more to the point, I detest the idea of clear-texting passwords! Most of my problem was finding directions. See, I knew I had to add define('FORCE_SSL_ADMIN', true); to my wp-config.php file, but when I did that, I got an error:

Turns out I’d never turned on SSL for my server! My problem then became that I don’t want to shell out $100 a year for SSL when it’s just me no my server, no one else. Once I determined all I wanted was to create an SSL Self Signed Certificate on my server, which has WHM, it got a lot easier!

There are drawbacks to self-signing. Firstly, every time I login on a new browser, I have to tell it ‘Yes, trust me!’ That’s annoying. If I was using this for other things, I’d have to remember to type in httpd every time, but WordPress is smart enough to redirect that for me. Also, back in the day, Chrome was an idiot about them and wouldn’t let me use them! but I use self-signed without knowing it for ages, because my host set that up for cPanel and WebMail. I’m not a business, it doesn’t bother me. If I was, I’d charge more and shell out.

All that error means is that “Hey, ipstenu.org signed this, and I don’t know who that is!” If you read further on that page, there’s a link to ‘Help me understand!’ and it explains:

In this case, the certificate has not been verified by a third party that your computer trusts.

Which is 100% true. By self signing, I’m skipping 3rd party verification and telling you to trust me. Looks scary, it’s really not if you know what you’re doing. If you’re willing to deal with this error every time you login on a new computer, then you too can SSL yourself to a little more safety!

These directions will only help you if you’re using a VPS or dedicated server. You’re going to do all the work in WebHost Manager.
1. Go to Main >> SSL/TLS >> Generate a SSL Certificate and Signing Request
2. Fill in the fields – the passwords have to be alphanumeric, and remember to use the right domain. If you use www.example.com as your default, use that. I use just example.com for all my sites so I did that.
3. Save the data to a text document.
4. Go to Main >> SSL/TLS >> Install a SSL Certificate and Setup the Domain
5. Import your certificate data (or paste in from text)
6. Select Submit
If it works, Apache will restart and you’re done! If not, you have to read the error. My problem came with the domain details:

I was able to skip steps 1-3 and just go right to ‘browse’ since, apparently, at some point I’d done them before. The problem was for my second site, it’s on my shared IP, which meant I had to put in the User of ‘nobody’ instead of the user name. Not a big deal.

After that, I was done and could log in to my site via SSL!

But wait… What about MultiSite? Well if you’re using subfolders, this is great. Subdomains, however… See the host name has got to be the domain name: halfelf.org in this case. So if I wanted to make one for all my subdomains… Owch.

Then I thought that maybe, just maybe, the computers were smart enough on their own. So I did this:

And then this:

Now, since I already had an ipstenu.org cert, I had to delete that one first. But once I did it, I was done. I turned my multi-site into something a little more secure!

And now you can too.
20 September, 2011

Show Site ID Columns in MultiSite

This is totally a use at your own risk sort of thing. I really have no plans to do anything with it, and no, you cannot sort by ID due to limitations in how the columns work in WordPress.

Installation Instructions
Make a file called show-site-ids.php, put this code in it, and upload to your mu-plugins folder.

<?php
/*
Plugin Name: Show Site ID
Plugin URI: https://halfelf.org/hacks/site-id-columns-multisite/
Description: Show Site ID in Sites Column for Multisite
Version: 1.0
Author: Mika 'Ipstenu' Epstein
Author URI: http://ipstenu.org/

        This plugin is free software; you can redistribute it and/or modify
        it under the terms of the GNU General Public License as published by
        the Free Software Foundation; either version 2 of the License, or
        (at your option) any later version.

        This plugin is distributed in the hope that it will be useful,
        but WITHOUT ANY WARRANTY; without even the implied warranty of
        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
        GNU General Public License for more details.

*/

function siteid_columns($column, $blog_id) {
        global $wpdb;
        if ( $column == 'site_id' ) {
                echo $blog_id;
        }
        return $value;
}

// Add in a column header
function site_id($columns) {
    $columns&#91;'site_id'&#93; = __('ID', 'site_id');
    return $columns;
}

        add_filter( 'wpmu_blogs_columns', 'site_id' );
        add_action('manage_sites_custom_column',  'siteid_columns', 10, 3);
        add_action('manage_blogs_custom_column',  'siteid_columns', 10, 3);
?>

14 March, 2011

Spam / Splog Wars
If you run a blog where anyone can comment, no matter what the software du jour is, you’ve had spammers. There’s really no way around it. As soon as someone comes up with a great, easy, way for you to share content and open discussion with other people, the door opens for people to use that great, easy, way to spam you.

A lot of people take spam for granted. We get junk mail, we get telemarketers, we get spam. It’s a constant of life. And spam is just like junk mail and telemarketers. They want to get your attention, they want you to click on their links, and they want your money. Some spammers link to actual products (usually sex products) and others link to sites that will infect your computer with a virus. The end result, oddly enough, is the same. They want you, and your visitors, to click on their links and somehow make a profit. The cost overhead is so low that even if just one of my visitors clicks on a link and buys something, they’ve made a huge profit. (By the way, if a post looks like spam, don’t click on their links. Only give your money to reliable companies. Research them, ask around. Be smart.)

A spammer posts spam comments or uses your site to propagate their crap. A splogger is a spam-blog. A blog that only exists to pimp the same crap. If you have an open-registration CMS site where anyone can make a blog, you will get sploggers. Some people will argue that WordPress is less secure because it gets more splogs than Joomla. I would disagree. More people use WordPress’s built in ‘anyone can make a blog!’ feature than Joomla, so it’s a better target if you’re a spammer. You’re going to get more bang for your spam-buck, so you aim for the biggest target.

No matter what type of tool you use for spam-trapping, remember that the best tool you have is your eyes, your brain, and your common sense. YOU are the number one, best defense, against spammers. Yes, this means you have to give up of your free time to maintain the site, to monitor the new blogs, to monitor the new comments and users, and stop them. While some posts can be hard to determine if their spam, if you check the email, the URLs and the context, usually you can sort them out.

Unless you have a dedicated team of people monitoring your site for trouble, it’s hard to keep up. This is where I start throwing in tools to help my site. There are three levels of defense: Server, Account and Application. I’m not linking to many tools, since a lot of this is preference. I like certain tools, other people like other tools. At the end of the day, no matter how good your tools are, the human element is required to be attentive and aware of the site. I’ve blogged before on the dangers of an unchecked multisite, and they remain true. Running a website is work. If you’re not willing to put the time in to maintain, monitor, and defend your site, something bad will happen to your site.

Server Level

Set up a good firewall. I use ConfigServer Security & Firewall, which checks against Mod Security and bans people who hit it too hard. This prevents a lot of automated spammers and also stops them, once they GET in, from being able to send out spam emails. A good firewall does wonders for other reasons too, but only if you configure it correctly. ConfigServer has a test it can run to see if your setup is good or middlin’ or poor, and I check it every time I upgrade. Oh yeah, keep current with your firewall tool, too!

Account Level

I hesitate on this one, but .htaccess can be used to ban IPs. I don’t like to do this and, generally speaking, don’t do this. If someone skirts by my firewall, I’m not going to block them at the IP level, since there are probably some legit users. Also, the firewall is automated, whereas my .htaccess I’d have to manually update. The point of a good tool is that you don’t have to fiddle-fart around manually too much! That said, there are ways you can kill spammers and sploggers via the .htaccess.

D’Arcy Norman came up with this awesome way to stop them on WordPress Multisite:
```
# BEGIN ANTISPAMBLOG REGISTRATION
RewriteEngine On
RewriteCond %{REQUEST_METHOD} POST
RewriteCond %{REQUEST_URI} .wp-signup.php*
RewriteCond %{HTTP_REFERER} !.yourdomain.tld. [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule (.*) http://someotherpage.tld/ [R=301,L]
```
Credit: D’arcy Norman.net

The part I like best is that if you change wp-signup.php to where ever it is your site has a signup page, you can make this work with just about anything. What it does is check the POST requests (which is the server request when you submit a form) for the page wp-signup.php. If those requests do not come from your domain (which if you click on the sign-up button, they must), then it sends them to http://someotherpage.tld/. I send them to a page that says they’ve been caught as a spammer, and to behave better.

If you must use an .htaccess blacklist, I would strongly suggest you follow D’Arcy’s advice and block them from accessing your registration page only. His thermonuclear option is above and beyond what I need, but I can see it being useful.

Application Level

Once you’ve set up your server and account as best you can, you have to start modifying your application. Thankfully, any modern CMS has a good plugin or extension system, and you can leverage that. Sadly, most modern CMS have the same problem of keeping up with the spammers. The tools used are pretty much the same.

Most CMS have a limited array of built-in tools. WordPress has a way to make all first-time posts require approval for example, but really when you get down to it, you want to throw in some plugins/extensions/modules that are designed to help.

Content Moderation

Blacklists are simple. Here is a list of people I don’t want to have access my site. Done. There are the usual caveats for this and the same warning applies as with .htaccess IP blocking: you may block legit users. Personally I prefer moderation lists versus delete blacklists. They put the possible spammer into a bin for me to review and approve or not. Blacklists and mod lists work best, I’ve found, for spam comments rather than splogs. I know, normally, no one on my site will be talking about viagra, but what happens if they have a question about it? The term is on my moderation list. (Funny but true story. I had the word ‘sex’ on a mod filter on another site. Suddenly people were talking about how sexy someone was, and all the posts hit my mod filter. Sometimes these terms are great to block out, but sometimes you forget how they’re really used.)

That said. There are good, reliable, blacklists. Stop Forum Spam and Project Honey Pot both are blacklists maintained by the community, and get enough information that they can be use reliably. There’s also Spamhaus, but that’s mostly email. You can use these on most applications as well.

Behavior

There’s actually a plugin called Bad Behavior, which is a great example of what I mean. Bad Behavior the app analyzes the HTTP headers, IP address, and other metadata regarding the request to determine if it is spammy or malicious. What I mean by the term is simply ‘Is the visitor coming to my site from a legit browser?’ See, spammers don’t use the normal browsers that you and I use, so if someone comes from a special method to my site, they’re probably not a good person.

Behavioral monitors learn as they go, or as they’re updated, and can be pretty effective. Sometimes people on archaic browsers (IE 6, for example) will get nailed by false positives. There’s not a whole lot I worry about with those, since any browser since 2005 is usually safe to go. There are two people who hit my sites regularly who’ve run into this problem, and once I sorted out what they were doing (Netscape Navigator 4 came out in 1998 and IE 6 came out in 2001), I told them ‘Look, the site will look like crap anyway. Upgrade.’ One guy couldn’t, the other switched to FireFox and admitted to being much happier anyway. (I don’t believe in supporting browsers pre-2005 at this point. I monitor my site stats for them, but realistically, it’s not going to happen. Upgrade, people. You’ll be happier.)

CAPTCHA

Personally I hate these. CAPTCHA is named after ‘capture’ and is a contrived acronym for “Completely Automated Public Turing test to tell Computers and Humans Apart.” It looks like this:

The idea behind CAPTCHA is that it should provide a problem easy enough for all humans to solve while, at the same time, prevent standard auto-fill software from filling out the form. Sounds great, but the problem is people have created software to read the CAPTCHA files. Personally, I love the fact that we’re making AIs smart enough to parse this stuff, but it hurts CAPTCHA because in order to defeat the AIs, they tend to become harder and harder to read for real people. Also, most CAPTCHAs are not friendly to people with limited accessibility. If you have dyslexia or glaucoma, they’re of the devil. I would never consider using one on my site unless forced to.

Human vs Computer Test

Originally CAPTCHA just meant any challenge/response to stop automated form fillers. Since it now is used, almost exclusively, to refer to those images, I’m pulling out Human Tests. A human test is when you have a question, or form, that requires thought to answer. Like ‘Who’s buried in Grant’s Tomb?’ We all know the answer is ‘Grant’ so you type that into a text field when you register or comment, and magically you have access. I’m fond of simple math questions like ‘What is 12 + 8?’ but also good are site specific questions. One on my friend’s site is about Marg Helgenberger, and they use questions about Marg (like ‘what’s the last name of her character on CSI?’).

The reverse is to trick the computer. Put a hidden checkbox on your site, that is NOT human readable, and if that box is checked, aha! Spammer! That’s a pretty cool trick if you can make it work.

Do you have tips and tricks you use?
12 October, 2010
Dig Yourself Out of a Hole – Multisite Edition
When I started my first MultiSite install, I didn’t want Blog #1 to be the main ‘dashboard’ site. The reasons why don’t matter. What does is that when you make seemingly simple changes, you have to be aware of how things work, as a whole, and be willing to take risks to fix them.

Site #1 was my test site and has since been deleted
Site #2 was a vlog which still exists
Site #3 is my ‘main’ site, the front page of it all
Site #6 is my saved Tweets
Site #7 is a documentation site
Site #8 is to save my Formspring posts

I know it’s weird. Bear with me. At first I was going to use Site #1 as an ‘all posts!’ site, like Andrea suggests you do with sitewide tags plugin, but then I realized that I wanted a splash page and then some fancy ‘Hi! Welcome!’ stuff with links to the vlog, blog, etc. Once I decided I wanted site #3 to be the ‘main’ site, I made that switch by editing two things.

First I went into Super Admin >> Options and changed my main site to #3:

Then I edited my wp-config.php file to say:
```
define('SITE_ID_CURRENT_SITE', 3);
define('BLOGID_CURRENT_SITE', '3' );
```
Now to be honest, I think that I only need one of those, but I’m totally stumped about that now. At the time, I just saw they were both set to 1 and I changed them to 3. Everything worked! Great! This was done.

Then I went to create site #4. And it didn’t show up. So I made site #5, ditto. Decided that was weird as hell, I went into phpMyAdmin and after some poking around, deleting sites and re-adding, I found the wp_blogs table and saw this:

Rationalizing that since I could see Blogs 2 and 3, and their site_id was 1, I changed it to this:

And again, things seemed to work just fine. Until I started trying to use the new iPad WordPress app. Or add anything to post to my blog. Like Formspring. Nothing worked. The blogs couldn’t be found, and third-party apps sometimes crashed. Again, I thought ‘Maybe the site_id should be 3!’ So I changed it to this:

Not only did that not work, it broke things. Quickly, I changed it back and frowned. I was obviously missing something, but what!? I started looking around for all instances of site_id and found the wp_sitemeta table! Most of the entries had site_id of 1, but some had 3.

I changed the wp_blogs table again, knowing it would break things, exported the whole wp_sitemeta table as a backup, and then ran a quick SQL search and replace, changing 1 to 3 and got this:

Now the whole site worked from front and back end, so I went to Formspring and tried to add my site. And guess what? It worked! It also magically fixed my iPad/WordPress testing woes.

So the lessons learned are “Never give up!” and “Never make changes when you don’t know what you’re doing!” Actually, no, not that second one. The lesson is to be bold with your solutions. Don’t panic and be willing to take a risk. I took backups before I started playing around, and I knew at worst, I could restore my site in 30 minutes. Because I had an escape plan that took me back to where I was, I had no fears about my changes. When you have nothing to lose, that’s when you should jump forward and try something silly!

I doubt the actual details of all this will help you, since I don’t think anyone but me was boneheaded enough to screw around like this in the first place. But seeing that someone else has seriously screwed themselves up, shot themselves in the foot, and come out feeling super smart should, I hope, encourage you to stay calm, think it through, and make a stab at something that seems right. When the wave rocks your boat, hang on and don’t be afraid to swim a bit.
20 September, 2010