Tag: multisite

WIRED Doesn’t Use Multisite

At WCSF this year, WIRED engineer Kathleen Vignos talked about moving WIRED from 35ish blogs to one blog.

They didn’t use multisite at any point along the way.

Now part of this was that back in 2008, when they started, the concept of multisite wasn’t really there. But that left them in a strange world with 35 separate blogs, separate installs, and an psychotic update system that was headachy and roundabout and involved 35 separate sites. But you could understand why they didn’t in the past, since there wasn’t a way to do it back then, but it brings up the question today.

Why not multisite now?

That was my question after her talk, and I promise you angels sang from the heavens when she said that multisite was intended for siloing data, and she needed to share data between ‘subjects.’ So for them, to have categories and just post articles in the appropriate ones (yes, plural) was exactly what they needed.

I have been saying this for a few years now. Multisite is great, except when it’s not, and there are reasons to use it and reasons to not. WIRED properly looked at their sites and said “We need to share data, Multisite may not be the best.” They also said “We need to make it easier to add users to a site, so maybe not Multisite.” Every single reason they picked to not use Multisite was 100% exactly the right one.

Multisite is simply not what you want if you need to share data between sites and you’re on a big site. Had WIRED used Multisite, they would have been miserable and have to write not just plugins to migrate the data, but ones to join the tables and display data in an ongoing way. What a pain.

Kathleen talked about the hurdles of merging the sites, and the tools they invented in order to make their Pangea happen. They had to worry about logical things, like keeping User A out of a category, and made use of plugins like Restrict Categories to do just that. Custom fields in the author profiles were use to assign a ‘default beat,’ and they made extra roles to allow people to manage the sites. They used template files to make various categories look different, which is often the main pain point.

By doing this, they were allowed to share and segregate data in an efficient and effective way.

WIRED wins my hat-tip for the best talk at WCSF about Multisite, simply by not using it.

You can see the slides here:

WordCamp SF 2014 – WIRED Migration Project from kvignos

And the video here:

[wpvideo n4wrIVIU]

10 November, 2014
Mapped Domains And Google Search
The other day I was surprised to learn that Google still looks for tech.ipstenu.org

Kind of.

If you go search for it, Google still believes that URL is a real thing: https://www.google.nl/search?q=site:tech.ipstenu.org

Some of those URLs were made long after I mapped the domain, by the way. And yes, of course I have a 301 redirect for the subdomain.
```
<If "%{HTTP_HOST} == 'code.ipstenu.org' || %{HTTP_HOST} == 'tech.ipstenu.org' ">
    RedirectMatch 301 (.*) https://halfelf.org$1
</If>
```
What’s going on here? Strictly speaking, Google’s right and stupid. The URLs are correct, but Google should be honoring the 301 redirect. Because it’s not, you have to tell it not to trawl your subdomains and use a robots.txt file, just for your mapped subdomains.

First we’ll need to make a special robots.txt file, like robots-mapped.txt, and put the following in it:
```
User-agent: *
Disallow: /

User-agent: Googlebot
Noindex: /
```
This tells Google to sod off. Then you need to specify when to use this special file, and that brings us to the lands of options. Since .htaccess is a top-down file, that is it reads from the top of the file down, you can get away with this:
```
RewriteCond %{HTTP_HOST} = (code|tech).ipstenu.org
RewriteRule ^robots\.txt$ /robots-mapped.txt [L]
```
Just have that above any redirect rules for other things. But what if, like me, you’ve got Apache 2.4?
```
<If "%{HTTP_HOST} == 'code.ipstenu.org' || %{HTTP_HOST} == 'tech.ipstenu.org' ">
    RedirectMatch 301 ^/robots\.txt /robots-mapped.txt
    RedirectMatch 301 (.*) https://halfelf.org$1
</If>
```
Of course, that sends tech.ipstenu.org/robots.txt to https://halfelf.org/robots-mapped.txt which is scary but still works, so don’t panic.

Another way to do it would be to have a massive rewrite for all my subomains:
```
# All Mapped
<If "%{HTTP_HOST} == 'code.ipstenu.org' || %{HTTP_HOST} == 'tech.ipstenu.org' || %{HTTP_HOST} == 'photos.ipstenu.org' ">
    RedirectMatch 301 ^/robots\.txt /robots-mapped.txt
</If>
```
I will note, it should be possible to have (code|tech).example.com work in there, instead of all those OR statements, but I’ve yet to sort that out (corrections welcome in the comments!).

The last step is to fight with Google Webmaster Tools. Add your subdomains and you should get this on the robots.txt checker:

If you don’t, don’t panic. Go to the Fetch as Google page and tell it to fetch robots.txt. That will force it to recache. Once you have it right, ask Google to remove the URL from their index, and in a few days it’ll sort out.

It’s very annoying and I don’t know why the 301 isn’t honored there, but oh well. At least I can make it work.
15 September, 2014
Network Rules

I love Multisite. I don’t think people use it ‘right’ but I love it. So I’ve started to make my own rules about Multisite and how to use it properly.

Only One SuperAdmin

There should be only one SuperAdmin, and you should never use that account to post. This will limit what you can do on any given day, and you’ll need a second account to mess with network settings, but this is a good thing. While WordPress lacks a sudo feature (yes, I know there are plugins), having only one SuperAdmin and locking that account tight and keeping the keys to yourself limits people’s ability to be mean to you and brute force. Extra points if you name the account something random.

Restrict Access

Only give people access to what they need. This means you limit their plugins to what they have to have, ditto themes, and you don’t let them argue they need the unicorn.

You knew I’d pull that one out, right?

Be mean and say no. Don’t let someone be an admin of a hundred sites if they only need to be admin of one. Don’t let them be members of sites they don’t need to write on. Remember, Multisite makes you a pseudo-subscriber so a user will be able to read and comment on all sites on your network. They only need to be a legit member if there’s a real reason, like it’s a locked site.

Don’t Network Activate Things

Perhaps this is better said as follows: Only network activate things that must be network activated.

Is it ‘easier’ to network activate W3TC and configure it for your network? Sure! Should you? Probably. But what about Jetpack? Does everyone need it? Do they all need the tool for GUI comments when not all the sites even use comments? Be judicious and cautious when you network activate plugins.

Test All The Things

Vet your plugins and themes before you install them. Test your upgrades on a non-production site. I cannot stress this enough. Test, test, test, test! Test! Just … test okay?

What are your rules?

I asked on Twitter and Tim Moore said he turns off the plugin menus for subsites. You can do this very easily by going to Network Admin -> Settings -> Network Settings and uncheck the plugins box for “Enable administration menus.” I do sort of wish we had more things there, like disable themes and so on, but seeing as you can more granularly control themes anyway it doesn’t matter that much.

5 September, 2014
He Ain’t Heavy, He’s My Website
I get asked this a lot from a more technical perspective.

All the myriad reasons you have to use, or not use, Multisite aside, the question that is often wondered and confused over is the one where we’re trying to balance out ease of support vs cost. You see, a lot of the time, people consider multisite because they’re on a webhost who only allows one domain for your site. You may be able to use add-on domains but they also may be limited, and the easiest way to run a hundred sites on one hosting plan is multisite.

I have to remind everyone here, I would never, ever, in the history of ever even remotely consider running Multisite on anything less than a VPS. Yes. I said it. Keep in mind when I run a Multisite I’m always doing it to run a network of heavy duty sites. If I was just running a tiny private network, my goals would be different. But more than that, I keep in mind the realizations of the limitations of shared hosting. Shared hosted is tiny. Multisite is big. Match ’em up and you’ll be happier.

What does this have to do with the heft of a network? Well if I have 100 separate sites and 100 sites on a multisite network, what’s the real, practical difference?
- 100 separate logins vs 1 login on 100 sites
- 100 separate sites to update vs 1 site
That’s pretty much it. Yes, there are a dozen of little things (like it’s easier to restrict access to a single site) that come into play here, but when you start looking at the server itself, the practical differences when it comes to things like disk space, memory usage, process utilization, and emails, there is no negligible differentiation on your site’s performance.

Yeah, 100 separate sites and 100 sites on a network will run pretty much the same on the same server, assuming the exact same level of traffic and use of plugins. That’s a pretty big assumption most of the time but in this one case, it’s safe. We’re trying to compare apples and apples, with only one difference: Multisite or Not.

Of course, there are specific situations where a multisite will cause more damage to a server than a single site, especially if you’re doing a lot of cross-content manipulation (like including the RSS from one site into the sidebar of another). But it all really depends on if you have a lot of traffic. Yes, one Multisite blog getting hammered will hurt the others on the network, but it shouldn’t cause a significant CPU spike any more than two separate really massive single sites would on the same server.

And there is one place where Multisite very much would do more work on the server than Single Site, and that’s with ms-files.php. That old magic that made your image URLs to be domain.com/files/2014/09/image.job. The way that worked was to pass images via .htaccess through the ms-files.php page and then generate the image. Yes, that caused more load. It’s part of why we don’t do it anymore, and why I suggest never trying that again.

It’s funny, though. I’ve seen one host say that Multisite will use less by way of PHP processes because it’s one install, while another said it would use more because ‘Multisite’, and a third said there’s no difference.

Obviously I don’t think there’s a difference.
3 September, 2014
Marrying Multisite
While there’s really no practical difference, server usage wise, between 100 separate sites and a multisite with 100 sites, a lot of us prefer to use Multisite for a variety of reasons. And today, assuming you have thought long and hard about those reasons, let’s talk about how to take 100 sites and fold them into one multisite. And yes, this will suck. If you read about how to break up a multisite, you may already have an inkling of the pain you’re about to embark on.

Make A Temporary Site

The first thing that makes it hard is that you have to keep your existing site up and running while you import it, no matter how you chose to import. So regardless of if you’re moving subdomains or subfolders, you need to make a temporary site. I like to keep the site names similar, and the same length because it’s easier for me. So if I’m moving a site with the slug ‘donnanoble’ then I’m going to make the new site on my network named ‘donnanobl1‘

There’s a practical reason for this. When I’m all done with everything, I can do a search/replace with any tool to change it back to ‘donnanoble’ and I don’t have to use a tool like the interconnectit Search/Replace DB script that has serialization safe super powers. If you use WP-CLI, the built in wp search-replace tool has this already, and I’d be using that personally. The point is that you will be renaming everything at the end to the original name eventually.

Bring in the Content

I personally do this via the WordPress Import/Export feature.

Now look, I know you can port over the tables and rename them but … I wouldn’t. Why? The users. The tables for the users have to be pulled over with the right user meta, and you would have to marry the wp_users and wp_usermeta tables in a way that no user ID was duplicated. Frankly, I don’t think it’s really possible to do that well. If I had to, I would actually manually create the new users on my Multisite and make a note of that new ID. Oh and of course the user names can’t both be admin. You can’t have two Doctors at once. Well. You can. And I’m sure they all use the same username, but you’re using WordPress and not a TARDIS, so if two users have the same username, then either they’re going to be the same user or you’re going to have to make one a new account.

There are number of you thinking about how many people use ‘admin’ as their username, and yes, that’s exactly what I’m talking about. But if we’re lucky and doctor11 and doctor10 used different login IDs on their sites, then you’re just going to need to copy over the one line in wp_users for that:

See how he has an ID of 10? That has to match all of these:

They don’t match right now, do they? Nope. The Doctor has an ID of 10, but the snippet I took from his site was for a user ID of 2, so I have to edit everything in wp_usermeta. Next, I have to rename my tables for wp_posts, wp_postmeta, etc etc over to wp_x_posts and so on, to make them match the new site ID. Oh and don’t forget wp_user_roles! You have to fix that for your new site ID too! And then reattribute all your posts!

You see this slope and how it’s getting really slippery really fast? That’s why I won’t do it. It’s certainly possible, but it’s neither simple nor easy nor safe. Importing and exporting via WP’s built in tools has only two downsides as I see it:
1. Your users have to make new passwords
2. You have to reconfigure your theme and plugin settings
That first one doesn’t bother me. The second one doesn’t either, since not all the plugins and themes work the same way on Multisite, so I probably want to take the time to do it all cleanly anyway. That does mean that I can’t automate things, but at the same time, I’m not particularly sure I want to. Taking each site one at a time will take longer, but it will let me be careful and test everything every step of the way.

Either way, once you have the site content in place, and your site settings look and feel how you want them to, it’s time to do a flip.

Flip The Sites

Take your original site, donnanoble, and rename it. If it’s a subdomain, turn off whatever weirdness you did in your panel to map the subdomain. For most types of server panels, having both named subdomains and a wildcard can live happily together, because the ‘real’ subdomain will supersede the wildcard. If not, you’ll need to change that subdomain to point to the location of your main install of WordPress. So if you’re in /public_html/donnanoble/ then that becomes /public_html/ on it’s own.

Either way, you have this real folder on your server called donnanoble and that needs to be renamed to anything else. At this point, I tend to use donnanoble-disabled because it is. Also it’s not supposed to work anymore.

Once you’ve broken donnanoble, it’s time to go into your network admin, go to the sites page, and edit the donnanobl1 site. Rename that to donnanoble, and check the box to change both home and site URL. Oh, and remember I mentioned search and replace before? Run that now. Change donnanobl1 to donnanoble all over the whole database.

I told you it wasn’t super easy

If you’re like me, you now have a bit of a headache, thinking about doing this 100 times. It’s one of those things that should conceivably be easier than it is, but right now WordPress really only has a way to export content and not settings (which is pretty much why we have such nightmares segregating content and code).

It may be plausible to use tools like BackupBuddy to import, but you still will find yourself at a tense moment when you have to flip the real and temporary sites around.
29 August, 2014
Customize Network Toolbars
This came up in the WordPress Support Forums. If you use Multisite, the WordPress toolbar (at the top of your site when logged in) has a special item called “My Sites” which shows all the sites of which you are an administrator. This is great and works as a quick jump to get to a different site really fast. It has problems, though, in that if you make a network with a bunch of sites named the same thing, it’s hard to tell which site you’re on.

Now I know what you’re thinking! “Mika!” You say. “Mika, come on, no one has 100 sites with the same name unless they’re doing what you say is a terrible idea, and duplicating sites!!”

Au contraire, mon frère. There are a few totally understandable reasons why this might happen. Fairly recently I was helping a school sort out Multisite, and they wanted a site for each classroom (easy) and the names of the sites would all be the same: Super Cool School – Class Frog

And their ‘My Sites’ list was all the same.

As you can see, WordPress wisely puts a practical limit on the title length, which makes sense. Now when I was faced with this problem, I remembered something that had come up in the forums, where someone wanted the ‘language’ of the site to show up in the site list, so his sites would be showing as “SiteName (en)” and so on. Since he was using the site path (en, de, etc) as the site’s slug, it was easy for him to come up with this, once I (accidentally) pointed him the right way:
```
&lt;?php
/*
Plugin Name: Show Site Path
Description: Show Site Path in My Sites Menu
*/

function helf_customize_my_sites( $wp_admin_bar ) {

    $mysites = $wp_admin_bar-&gt;user-&gt;{'blogs'};

    foreach($mysites as $site) {
      $site-&gt;blogname .= ' (' . $site-&gt;path . ')';
    }
}

add_action('admin_bar_menu', 'helf_customize_my_sites');
```
I say it was an accident because I did read the question wrong, but it actually gave me the answer to my schools. They too used the classroom name as the site path, so for them I changed one line:
```
    foreach($mysites as $site) {
      $site-&gt;blogname = '$site-&gt;path';
    }
```
That was it. Now the sites showed up the way they wanted.
20 August, 2014