Category: How To

Scorched Earth Security
This post is dedicated to Matthew Freeman, who donated to help me get to WCSF. I have not forgotten coffee.

Napoleon’s invasion of Russia
There’s been a lot of kerfluffle about hacked systems again, especially that the ‘auto upgrade’ isn’t safe. I want to point out that your automatic upgrade of WP and its plugins is prefectly safe, if your system hasn’t been infected. Once you’ve been infected, however, it’s a whole different ball game. I subscribe to the salt-the-earth philosophy of cleanup, but more on that in a moment.

Odd as this may sound, I tend not to spend any time determining where the hack was. My feeling is that the longer a hack sits on my live server, the worse off I’ll be. If it starts to happen repeatedly, I may look into it more. But generally speaking, a hacked site boils down to some pretty obvious avenues of attack:
1. Insecure password on your server
2. Insecure behaviors
3. Bad plugins/themes/extensions
4. An insecure webserver
You notice that I’m leaving the apps themselves off the list? For the most part, a hugely explioted hack isn’t an app vulnerability. Most well used apps, like Drupal and WordPress, are remarkably well tested when it comes to that, and the developers are quite attentive. The weakest point in the security tripod is going to be the user. When I was exploited, you bet your ass it was 100% on my head, and no one else’s.

So when I see a web-app get hacked, my first thought is not ‘debug from whence it came’ but ‘get the file off the server — now.’ If you leave the hacked files on the server, the odds of your site going down again and again increases, so the very first thing I do is download everything. Every single file, the database, and everything that sits on that server. I back it all up on a computer, preferably one with a good security/virus scan tool, and then I get started on the real work. I’m going to come back to those files and review them, but that’s later. Right now I need to get what I have clean.

Make a list of everything on your server. Separate your ‘personal’ files from the application files. For example, in WordPress I would list my themes and plugins as the ‘application’ files, because I can easily download them from the repository. My ‘personal’ files would be the images in /wp-content/uploads and /wp-content/blogs.dir, the .htaccess file and my wp-config.php file.

Now here’s the scary bit. Every file gets deleted off the server. Yes. Every file. When it’s WordPress, I kill it all with fire except those personal files.

Then I download fresh copies from WordPress.org (and only WordPress.org) but I don’t copy them up. No, instead I change my server password, and my SQL password. If I’m having an extra neurotic day, I may make a new SQL id and use that instead. Regardless, it’s Password Changing Day. If I used that password anywhere else, it gets changed there too.

Still with my site down, I look over my .htaccess and config files with a fine toothed comb. I know what’s supposed to be there, and I know what’s not. I’ll also scan my personal files (all those image folders) for any .php or .htaccess files in there. See, nothing but files I uploaded are supposed to be in there, so if anything is, it’s bad.(If you use caching plugins, you may have other files in there, but you should already know that. Still, it’s best to turn off any caching you have while you rebuild. Change the cache constant in wp-config to off, and remove the cache folders from wp-content.) If I find anything, I delete it (though I will make a note of the time/date that file was updated, and since I have my backup, I can look at it in depth later). I’m also going to make sure permissions are right. I want things to be secure.

Finally I upload every new file back up from my fresh copies, and then make sure my site still works. It should.

It used to be that people told me I was silly for doing this. It was overkill, surely I could just change passwords and remove the infected file. Sure, that might work. The problem is these guys are getting smart. Denis uncovered a pretty cool (if evil) hack, where your updates are compromised, and basically from now on, you’re getting hacked code. With my method, you’d be ‘safe’ from that continuing.

Of course, you’re not safe from it happening again, as you could be hacked again, and this is where we have to start digging into logs and sorting out what the hack was and how it happened. And that is a different post all together.

If all of that is too much for you, and it can be, I recommend hiring Sucuri. For $90 a year, they’ll monitor your site for you. If that sounds like a lot, that’s $7.50 a month. You can spare the latte.
12 July, 2012
Art History of Plugins

This post is dedicated to Lisa Sabin Wilson, who donated to help me get to WCSF. Lisa is to documentation what I am to the forums, and encourages me to write better (though she probably didn’t know that).

Quite often people suggest that we ‘weigh’ the usefulness of plugins and themes in the WordPress repository differently. Some want to use star ratings, other popularity, and others compatibility of WordPress Versions.

Invariably, if I get roped into these discussions, I say ‘None of it maters more than the rest.’ And people always argue that their chosen method is the best. No one has ever succeeded in convincing me they’re right and, I’m pretty sure, no one ever will.

The reason I’m so sure about that is the same reason we don’t just buy cars based on the tire size, or a house based on a bathroom. It’s the reason we research and compare, study and inspect, and ask our friends. It’s because we know to look at the big picture.

Let’s look at A Sunday Afternoon on the Island of La Grande Jatte. From afar, it’s simple. A painting of people on the island. But if you walk up to the painting (it lives in Chicago, I love visiting it) you’ll see Seurat painted entirely by dots! As you step in and out, the painting changes and your perspective and understanding of the work as a whole changes. You cannot simply say ‘There is blue paint.’ and make your final decision that this painting will look nice against a blue wall. You have to consider how it will look up close, far away, and will it be better to blend or contrast. Seurat liked the contrast, which is why it has a brown border and a white frame.

The small moments, those dots, make up the whole of the piece and you have to consider everything that went into it, if you want to understand the painting. Anyone can look at if from afar and say ‘Yeah, nice.’ But when you start looking at the work, and the layers of meaning, you see things differently. With art, that’s the point. Sometimes a painting is just a painting, and sometimes a story is just a story, but more often than not, the ‘deeper meaning’ your teachers were after you to get from a story is simple: Look at the whole story. Look at how each character’s actions become a part of the whole.

This relates, directly, to understanding plugins. At heart the question people are asking is simple: How do I know which plugin is the best to use for this situation?

You can’t just take one and say ‘This is compatible with 3.4, therefore it is superior!’ I wish you could, my life would be easier. Instead, you must learn how to review plugins critically. Don’t throw your hands in the air, you don’t need to know code to do this. You do need to know what you want, and you need to read and pay attention, but at this point, if you’re still reading this blog post, you know how to do those.

The secret magic, which I talk about in WordPress Multisite 110 (Chapter 6: Security, Plugins, pg 36), is to review all components of a plugin’s information. You have to look at how all the little dots make up the whole picture — that’s why we talked about Seurat — and use those to understand how likely a plugin is to be safe to use.

Who wrote it? If I see a plugin written by someone I’m familiar with, I’m more inclined to trust their work. I already know how to get in touch with the developer if something goes wrong, and we have a rapport. Second to that is if they work on WordPress core. If they have commit access, I trust them (even Otto, who’s broken the site before). If they’re a regular contributor, it’s much the same. However this is not ‘common’ information. It’s easy to find, but it’s not something everyone knows off the top of their head. You can quickly search trac for their user name. I find it easier to limit the search by changesets, so here’s a search for wpmuguru’s credits in changesets. Yeah, looks like a trustworthy fellow!

What does their website look like? In cases where the developer doesn’t have any core contribs, move on to look at their website. Is it the generic version of WordPress with barely any content? Is it a Geocities flashback? You know crappy websites when you see them, and a crappy website for a developer warns me that they don’t use WordPress the way I do. Little to no content implies they’re not writing posts, and if they aren’t writing posts, how do they keep up with the look and feel dynamic of WordPress?

Is it well documented? Documentation is king. A plugin that is poorly documented, with poor spelling and grammar (regardless of language), and no screenshots makes me Spock the eyebrow. Not every plugin needs a screenshot, but a plugin should have the basic information included on that page. I’ve started copying my readme content into the contextual help in my plugins, for extra documentation levels. The point is, if the documentation is sparse, either the plugin is really simple, or you’re going to have a bad time of it when you have a problem. Developers, document. It will save you a lot of time.

How often is it updated? This is where we start to get weird. The simpler a plugin, the less it needs to be updated. Impostercide has barely changed since WP 2.5. I do update it about once a year, to change the versions, or add internationalization/help screens, etc. The bones of the code have not changed since 2005, and the original version still works just fine. Not every plugin should be updated every month. Now a more complicated plugin, I’d actually like to see it updated more often, with smaller changes. Don’t change it all at once, after all. Review the Changelog (if they don’t have one, it’s not well documented). See what’s being changed.

What problems have people had? Recently the Andy/Otto team made it easier to see the forum posts associated with a plugin, which means it’s easier for you to see how active a developer is with support, and how problematic the plugin is. Many of these issues are user-based (i.e. they’re not sure how to use a plugin), but sometimes they’re actually bugs. Check how many problems have people had, and if they are resolved. This example is a great sign:

What’s in the Compatibility Matrix? This is a very complicated thing, but it’s also very telling. Knowing how many people have reported a plugin works or doesn’t work, and getting an average, can help you. Sometimes you have to go back and forth, checking various plugin versions to WordPress releases, to get the whole picture, though, so it can time time to understand what’s going on.

What Else? Only now do I take a look at things like downloads, what the author says it’s compatible to, when it was last updated, and what the stars are. Why? Because unless an author has written ‘This plugin will not work on WordPress 3.4!’ in the readme, there’s a darn good chance it’s just fine and they didn’t bother to update. And that pisses off a lot of people.

Look. There’s no feasible way to force the developers to update their plugin documentation right now, and even if we did, there’s no way to assure they got it right! People make mistakes, which is why we have to learn to use our brains and think about what we want to do before we act. Yes, it’s work. As I’ve said many times, running a website is work. It’s always going to be, so at least try to work smarter.

I didn’t touch on code reviews at all, but what tips and tricks do you use when you’re collecting all the dots and evaluating a plugin for use?

9 July, 2012
Plugin Licenses, Upsells, and Add-ons
This post is dedicated to WPEngine, who donated to help me get to WCSF. While I don’t use them, I think that if you’ve outgrown WordPress.com and aren’t quite ready to host everything yourself, but you still want the plugins and themes, then you should check these guys out. They aren’t cheap, but then again, I firmly believe in paying for what’s important.

Read the comments before you comment. Otto haz the smartz.

One of the many rules of WordPress.org hosted plugins is you can’t phone home. Actually you can, and the rule really is ‘Don’t phone home without a damn good reason.’ To use Akismet as an example, it phones home with information to help verify who posted on your site, and are they a damn dirty spammer. That’s a damn good reason. But phoning home to check “Did Bob pay for a license?” is not. That’s considered abuse of the “serviceware” guideline, and essentially making an API just to make sure a license is okay isn’t okay. Now making money on your plugins is an awesome thing. But when your code is open source and anyone can see it, how do you keep people honest?

To get down to brass tacks, I’m going to take a little jounrey the wrong way, before I get to some suggestions on how you can provide ‘free’ and ‘pay’ versions of a plugin on the WordPress repository, and not cause any guideline issues.

Let’s start out with the most common way people restrict you: A license key. If you put in a plain license key check like this, it’s easy to crack:
```
if ( $license == "yes" ) { // Licensed! }
```
Okay, you say, I want to encrypt things so that I tell someone ‘your license is ipstenuisreallyneatsheismadeofturtlemeat’ but when I look at my code, it shows ‘774ffc4efce8da294dff77f35f75df98‘ instead (that’s md5(ipstenuisreallyneatsheismadeofturtlemeat) as it happens). Wait. We can’t encrpyt code. Or rather, we can’t include encrypted code in a plugin, it’s against the no-obfuscation rule. We’d want to decrypt that instead. So I give you the code string instead and run it this way instead (Just pretend that $options['license'] is a site option.):
```
if ( md5(ipstenuisreallyneatsheismadeofturtlemeat) == $options['license'] ) { // Licensed! }
```
But then I have the problem of anyone can just look and see what’s going on again. You could go the extra step like putting ipstenuisreallyneatsheismadeofturtlemeat in a file and then pull off something like this:
```
$md5file = file_get_contents("md5file.txt");
if (md5_file("test.txt") == $options['license'] )
```
Is this easily decrypted? Yes. Is this easily circumvented by editing the code and removing the if? Again, yes. In fact the only way to really do this would be to use an API on your server to check the validity of the license (which you can’t do if you want to be hosted on WordPress.org anyway – no APIs just to check licenses), and even then I can strip mine your plugin and remove all checks like that. So why bother? Because you want to make a living on your code, and that’s certainly a fair-go! But as Otto rightly says, we can’t stop piracy, so why are we trying? DRM doesn’t work, and reverse engineering hasn’t proven sustainable. Maybe we’re building the wrong mousetrap.

If we throw the code solutions out the window, because we know they won’t work, where are we left? The next most common thing I see is people offering two plugins. A free, totally open GPL one on the WordPress repository and then a version behind a pay-wall that you would ‘replace’ that free one with. For example, I have a Rickroll plugin, and let’s say I wanted to make a Rickroll Pro version that let you change the video to anything you want, just put in the YouTube URL. I would have a settings page on my free version that pretty much says “Hi, if you want to change the video, visit halfelf.org/plugins/rickroll-pro/ to download.” And now I have to code Rickroll Pro to check if Rickroll (free) is installed and active, and refuse to activate if so. Furthermore, my users have to be told to delete the free Rickroll.

You know what? That’s a pain in the butt. What if instead I coded a Rickroll Pro add-on. No, I don’t mean ‘add this file to your plugin’ but ‘Install this second plugin, which will add functionality to Rickroll.’

It’s a second plugin, yes, but now I can have Rickroll free look for Rickroll pro. Not active? The settings page (which I would keep in Rickroll free) would tell you ‘Hey, you don’t have Rickroll pro! Install it and get more things!’ or ‘Hi, you have Rickroll pro installed by not active. Don’t you know it’ll never give you up? Activate it and have fun!’

Now the code muscle becomes a question of ‘How do I ensure my dependency checks work?’ First, Scribu wrote an awesome plugin dependency plugin, and the only flaw with it, is you’d have to install a third plugin. We don’t want that here, since yet another plugin is problematic. But looking back, that code grew out of a trac ticket about handling plugin dependencies. Now there’s a nice way to check: is_plugin_active()
```
if (!is_plugin_active('rickroll/rickroll.php')) {
    // do not activate. Provide message why.
}
```
You could go to town with the checks in there. Like if the plugin isn’t active, deactivate the child and so on and so forth. I’m not going to write it all for you (though Otto wrote a lot about it for themes)

Now going back in your parent plugin, you can run the same check:
```
if (!is_plugin_active('rickroll-pro/rickroll.php')) {
    // Rickroll pro isn't active, prompt the user to buy it.
} else {
   // Include rickroll-pro/adminsettings.php so they can use it
}
```
The one last thought I had on this was how to handle pro upgrades. Since I don’t like to upgrade a plugin a lot unless I have to, I’d make it an ‘upgrade both’. In Rickroll Pro I’d set a version constant, and then in that check to see if it’s active call, reference that version. So Rickroll, after verifying Rickroll Pro is active, would come back and say ‘My current supported version of Rickroll Pro is 1.5 and the constant is set to 1.0. You should upgrade!’ Then every time I write a new version of Rickroll Pro, I’d update Rickroll to point to the new version, and when they upgrade from WP, they would get notified about Rickroll Pro needing an update too.

Probably not the most efficient or effective way about it, but the other option is a self hosted plugin update API.

Bear in mind, because of GPL, all these hoops and ladders can be circumvented. Your plugin can and will be taken away for free. Don’t fight the pirates with registration circuses, and limit the weight of your code by selling the right thing. It’s a strange idea to think that giving your code away for free will help you earn money, but at the very least, not fighting against the pirates will give you time to write better, more secure, code. And that certainly will earn you more money. Then sell your support, because that time is money.
5 July, 2012
The Anarchy of .htaccess and Multiple Domains
When you use domain mapping on a Multisite install (or anything similar, I know Drupal has this too), you run into the issue of sometimes wanting to redirect a URL just for one domain.

Over the 15 years I’ve had this site, I’ve moved my blog posts around from https://ipstenu.org/ to http://blog.ipstenu.org back to https://ipstenu.org/ and then https://ipstenu.org/blog/yyyy/mm/dd/postname to https://ipstenu.org/blog/yyyy/postname and finally to https://ipstenu.org/yyyy/postname And in those years, I’ve managed to never slaughter my SEO. Why? Becuase I know the secret magic of .htaccess. I don’t (yet) use nginx, I’m sure that will change one day, so right now my genius is limited to knowing how to do a nice regex redirect in .htaccess.

The majority of this magic comes in two lines:
```
RewriteRule ^blog/([0-9]{4})/([0-9]{2})/(.*)$ https://ipstenu.org/$1/$3 [L,R=301]
RewriteRule ^blog/(.*)$ https://ipstenu.org/$1 [L,R=301]
```
I also have this to handle the blog.ipstenu.org:
```
RewriteCond %{HTTP_HOST} ^blog\.ipstenu\.org  [NC]
RewriteRule ^(.*) https://ipstenu.org/$1 [L,R=301]
```
The RewriteCond is the neat bit that says ‘If you come here from blog.ipstenu.org, use the following rule.’ The [NC] is because domains aren’t case sensitive, and we want to CYA.

For my old setup of a single install, this was great. Today I’m using Multisite, and if I used that redirect, then any site on my network would be redirected! If you’re using subfolder Multisite, you don’t need to worry about this at all, since a redirect for ^blog/ will only impact a URL that has the first folder of /blog/. And that’s precisely why it’s a problem for Subdomains and mapped domains (of which I use both). That redirect up there would affect both https://ipstenu.org/blog/monkeys and http://photos.ipstenu.org/blog/monkeys and https://halfelf.org/blog/monkeys — and I don’t want any of that. I only want to redirect for those URLs if you’re going to ipstenu.org.

Thankfully, if you look at what I did for redirecting blog.ipstenu.org, you can easily see how to leverage that for this into two checks:
```
RewriteCond %{HTTP_HOST} ^ipstenu\.org  [NC]
RewriteRule ^blog/([0-9]{4})/([0-9]{2})/(.*)$ https://ipstenu.org/$1/$3 [L,R=301]
RewriteCond %{HTTP_HOST} ^ipstenu\.org  [NC]
RewriteRule ^blog/(.*)$ https://ipstenu.org/$1 [L,R=301]
```
Why did I duplicate the RewriteCond? Typically, you cannot use multiple RewriteRule statements following a single RewriteCond. That means for ever call I make to a domain, I can use but one rewrite rule. There are ways around that, but none of them worked well for me.

If you look at halfelf.org, however, the world gets even messier. Half-Elf is the combination of three domains. Ouch. Two can point to the same place, one needs to redirect totally differently, and then I have a category merge. Oddly that came out as only three sets.

First we can look for http://code.ipstenu.org and http://tech.ipstenu.org and redirect everything to https://halfelf.org. The trick to this is using (code|tech) in my RewriteCond, which really is one of my favorite things. That’s a built in ‘or’ right there, and if I had a hundred subdomains, I could still do that.
```
RewriteCond %{HTTP_HOST} ^(code|tech)\.ipstenu\.org [NC]
RewriteRule ^(.*) https://halfelf.org/$1 [L,R=301]
```
Next we want to redirect http://ebooks.ipstenu.org to https://halfelf.org/my-ebooks/ – notice how I don’t want to redirect it like I did for code and tech. Here, everything gets dumped back to the ebook page:
```
RewriteCond %{HTTP_HOST} ^ebooks\.ipstenu\.org [NC]
RewriteRule ^(.*) https://halfelf.org/my-ebooks/ [L,R=301]
```
Finally I want to tackle the merge of my old categories, and again this is straightforward:
```
RewriteCond %{HTTP_HOST} ^halfelf\.org [NC]
RewriteRule ^category/code/(wordpress|bbpress|buddypress)(.*)?$ https://halfelf.org/tag/wp/ [L,R=301]
```
My actual .htaccess is even crazier, since I have four domains pointing to multisite plus an add-on for my short URLs.

This should get you started on customizing redirects in .htaccess for multiple domains. What are you favorite tricks?
20 June, 2012
ZenPhoto and ColorBox
I use ZenPhoto for a gallery on a site that has a pretty hefty (gigs) gallery with many albums and subalbums. It’s too big for WordPress, in my experience, and so I picked up ZenPhoto as sort of the WP of the gallery world. Not knocking WP, it’s great for text, but sorting and organizing images are a hassle. The flip side to this is that getting straight directions on how to do anything in ZenPhoto makes me bang my head on the wall.

See, WordPress has a lot of people involved, so the forums are filled with people who’ve been there before. And these people come from a varied array of talents, so some are designers, some programers, and some users. This means the documentation, while lacking in many respects, is actually a pretty awesome display of crowd-sourcing when you compare it to other web apps. The worst part is there’s no perfect way to replicate this dynamic. ZenPhoto is still relatively young, even though it’s only a year younger than nine year old WordPress! MediaWiki (at 11) is older than both, but ‘behaves’ more like the middle child, if you really want to break your head on things.

It’s a lot to do with goals, and you can’t knock any one tool for the other. They have their places. I would never try to blog on MediaWiki, nor would I put a seriously hard-core gallery on WordPress. ZenPhoto has branched out into ZenPage, a simple CMS, but personally I’d rather see them optimize the hell out of their back end, which could use some UI love. Still, a lot of its simplicity is why I chose to use it instead of, say, Gallery or Coppermine.

But the help is still lacking, so today was a bit of a wrangling and head bashing.

What I want is, you’d think, straightforward: How do I edit the default theme of ZenPhoto to include ColorBox? If you ask this on the ZenPhoto forums, you get an understandably annoyed mod saying ‘This has been asked before.’ I feel for them, but as a mod and a user, I look at that and think ‘If people keep asking and you can’t give them a link to how to do it, something’s not right.’

The directions I found in the forums never worked, but it wasn’t long before I realized why. There were simple typos. So here’s how you can turn on ColorBox for ZenPhoto.

1. Activate the Plugin

This is a duh moment, but go Admin -> Plugins and check ColorBox. You do not need slideshow.

2. Make sure ColorBox is on for your theme

Go to Admin -> Options -> Plugins and click on ColorBox. Then find your theme and make sure that the pages you want to run ColorBox on are checked. I only wanted it to run on albums, so that’s all I checked.

3. Edit your theme

This is where everyone’s directions fell apart for me. Since I only want it on albums, I went to my default theme copy and set my image section to look like this:
```
        <div id="images">
        <?php while (next_image()): ?>
		<div class="image"><div class="imagethumb">
		<a href="<?php echo html_encode(getDefaultSizedImage());?>" rel="showcase" title="<?php echo getBareImageTitle();?>"><?php printImageThumb(getAnnotatedImageTitle()); ?></a>
		</div></div>
		<?php endwhile; ?>
```
Make special note of your classes and rel here! In specific, notice how that I have two divs for image and then imagethumb? While either one will work, I made a note of imagethumb, since it was a little more specific. Also I made a note of the rel in my image itself, in this case rel=”showcase”

Then back up before I close my head section, I added this:
```
	<script type="text/javascript">
	// 
	</script>
```
See how I’m using the showcase and the imagethumb? That’s why I needed those.

4. Customize

Everyone says ‘Read the directions!‘ but when you look at them, they’re written for people who know jQuery. I don’t. So when I don’t know what I’m doing, I make a list of what I want. By the way, yes, it irritates me when directions are ‘too techy.’ You can’t know where people are in their understanding of things, and you can’t expect everyone to be amazing at everything. I was very close to appealing to anyone who owed me a favor for help before the end of this.

No set height

That’s as easy as removing height:700 from my js.

Force colorbox to treat my cached image as an image

Just add photo:true to the js. I had to do this because my server renders the images via a php file (to redirect to cache) and this was causing funny problems. It’s a known issue, though, so one I figured out how to search for ‘ColorBox is making my images show up as gibberish!’ I found the answer.

Put a link to the full sized image

And here began my headache. If I put in this (where I used to have the height code):
```
title:function () { return "To view full size, " + "click here!".link(this.href);}
```
… then my link goes to the getDefaultSizedImage() size (which is a max width of 540px for my theme) and that isn’t what I want. I could change it to getFullImageURL(), but then colorbox loads the fullsized image, and that’s just a little silly and bad for bandwidth. I spent the next hour reading up on jQuery to understand that I really wanted to pass data through. Finally I struck about the notion that I could make a new variable in my href.
```
full=<?php echo html_encode(getFullImageURL()); ?>
```
This makes a link to the full-sized image. And then I changed this.href to $(this).attr('full')

In the end, it really wasn’t hard, but nowhere were all the pieces laid out in a way I understood. I’m happy with how it all turned out and the site now behaves like it’s 2012.
10 June, 2012
WordPress Multisite 110 – Electric Boogaloo

Introducing WordPress Multisite 110

I promised a sequel and I delivered. I hope you guys find it helpful. The sequel is out, and it’s longer than the original. Weighing in at over 80 pages, WordPress Multisite 110 has even more information about WordPress Multisite!

Why a sequel and not a second edition? There were more things to add than a few extra plugins. Branching into a little more philosophy and explanations to the whys, Multisite 110 hopes to be the second handbook you’ll need. The funny thing is most people who read my site regularly don’t need this at all. But your clients might. Imagine being able to hand that off to them saying ‘I’ve got you started, here’s how you can make it epic.’

Oh yes, with a Creative Commons release, you can pass this on to your clients as you like. I won’t stop you, just don’t sell it to them. If you want to get into the shenanigans, you can bill them for it, but not sell it. Yeah, licenses will kill us all one day. Speaking of licenses, there’s code in this one, and it’s all under GPL2 (most of it’s also on this site already).

What’s not in it? Deep diving into the database. Fixing everything… There’s no way to cover everything. This one gets into the machinations of how you make a multisite where everything looks the same, or where your admins aren’t admins at all. Favicons? Got that covered too! The White Page of Death? How to figure out what plugin you want? Man, you know I got your back! Backups, control, security, uploads… the list isn’t endless, but there’s a lot going on.

Check out WordPress Multisite 110

The post title of ‘Electric Boogaloo’ comes from a movie that came out in 1984: Breakin’ Two: Electric Boogaloo. All sequels should have that sub-title

31 May, 2012