Category: How To

Breaking Up Multisite
This is by no means the be-all and end-all of how to break up a Multisite. These are, however, methods I’ve used to move Multisites around into brand new places. As always, if you have another method, feel free to explain in the comments, and link back to your own tutorials!

You see, Multisite is great at some things, but breaking up is crazy hard to do. If you want to just disable multisite, it’s not too bad, four steps, and the hardest is to delete the right tables. And if you want to move a whole multisite, it’s not terrible either.

But. What happens when you want to move only one site on the network?

Usually I see this happen when someone is developing a site for someone else, and thinks it’ll be ‘easier’ to do it on their Multisite. After all, the site will be ‘visible’ but clearly a development site, and remote clients can take a look all they want. The minority of people I see doing this for just themselves, knowing the site won’t ever need to be on a Multisite, but taking the ‘easy’ way out. And to them I suggest developing locally, as domain.dev, and then a blanket search/replace on ‘domain.dev’ for ‘domain.com’ when you’re ready to move. Then there is a small group of people who have a multisite installed on localhost for development, which … no. Don’t. It’s localhost. Spin up a new instance of WordPress.

And still, while I lament the shortsighted nature of these things, there are clear-cut use-cases for this that people just can’t predict. Like the day you wake up and realize that Ennis and Jack can stay on brokebackblog.com, but maybe you should move the Hulk.(Ang Lee directed both movies.) Now you have a dilemma. Do you rebrand brokebackblog.com as angleefilms.com? Maybe you just domain map brokebackblog.com/hulk to hulksmashblog.com or maybe, maybe, you don’t want to run the Hulk blogs at all, but your friend Eric does. Certainly there are always options to splitting up a Multisite, yet for the sake of this post, you have decided that Eric (who has bought hulksmashblog.com) should have the whole site, all the posts and users, and you don’t want it on your server at all!

Now what?

Uber Easy: Export and Import

This is straightforward. Install your new stand-alone WordPress instance, export the posts from brokebackblog.com/hulk, import them into hulksmashblog.com, customize the theme and plugins, done. If you don’t have a lot of users, this is the best bet. Yes, you’ll lose a lot of time resetting all the plugins and theme configs, but you probably had to do some of this anyway. All your comments come with, all your images too, so it’s going to be straightforward.

A couple more things to keep in mind. User passwords will need to be reset, which is trivial in my experience, and a good idea anyway if you want to enforce good passwords. Many new themes are getting great at allowing you to export theme settings, so that may ease the pain as well. The plugin settings really are the biggest hassle to me, but in the long run, I’ve found that having to reset them isn’t horrible since the new home usually is a little different from the old one.

Finally, you’ll probably need to search/replace your posts to compensate for the new image location. I prefer Velvet Blues Update URLs, but sometimes I use .htaccess to redirect instead. If you’re moving from an older Multisite, your images will all point to /files/, but newer ones are in /wp-content/uploads/sites/#/ instead. Of course, wp-cli make it even easier, and I use it all the time when moving people at work.
```
$ wp search-replace brokebackblog.com/hulk hulksmashblog.com
```
That’s right now my favorite command. It updated everything, with serialization handled safely, and I was done. If I can’t use that, I’ll grab the interconnectit search/replace tool (not just for WordPress) and run that instead, but for me, I install WP-CLI pretty much everywhere now. It’s just so easy!

Ugly Complex: Database Dancing

When you’ve got a more complex situation, like a heavily customized and themed site, with lots of users and content, then you may have to do this the hard way. As before, make your new stand-alone instance of WordPress. Copy down all the plugins and the theme from your multisite, same as before. Instead of importing the content via an XML file, though, we’re going to import the following database tables as well as all the media images. Remember, no import, no media import, so you must SFTP them all over.

Then the DB Tables you need are as follows:
```
wp_x_*
wp_user
wp_usermeta
```
This means you need to know your site number (not too hard, you know how to make them show up, right?), but don’t think it stops here! Now you have to rename tables. There are two directions to go. One is to rename all the wp_x_ tables to wp_, and the other is to rename the other two tables to wp_x_user and wp_x_usermeta instead.

Either way you get to fuss even more. And don’t forget what I talked about in Recovering Your Cape: If your tables are named wp_x_ then you MUST have a field called wp_x_user_roles in wp_x_options, or no one will have any permissions at all. This almost makes it easier to think “Well I should just add in _x right?” You’d think, but then you’re stuck with this funny prefix you have to account for in your wp-config.php file, and you also have to consider what if hulksmashblog.com later wants to make itself a multisite. Be nice to the next guy. I would rename the tables, and then run a search/replace for wp_x_ and wp_ using wp-cli or that script.

Now you’re still not done though. You actually moved over all of your users. That means you have a bunch that don’t have any posts. Go to the /users.php screen and sort by number of posts. Nuke everyone who doesn’t have any posts. Of course… what if they had comments and you want to keep that? Sadly that’s not listed. The comments table isn’t tied in to the users table in a easy to calculate way. But remember, deleting a user won’t delete the comment.

Finally, remember you changed the domain name? Do that again, like you did with an import export.

To The Pain: Moving Your Main Site

Ow. Ow. Okay, Jake, here’s where we get messy. There are just too many options to consider, so let’s look at them briefly.

First, if you want to keep the main site at its current location (domain etc), then you want to actually move all the other sites and then disable multisite.

However, if you want to keep the domain as a multisite and give the main site it’s own, new, home, you’ll want to switch out the main site for a subsite (detailed in WordPress Multisite 110 – around page 80), and then move it per one of the other ways… except remember the site number stays as ‘1’ which is to say ‘none’ so you’ll be moving wp_* and only the ones for the site, not the network (which you can’t delete unless you feel like breaking everything).

Finally, and this one boggles my mind, you want to keep the multisite, and all the sites, but separately. You can see there’s no quick fix for this. Move ’em all manually, and have a beer when you’re done, cause it ain’t fast.

Worse….

There’s more? Just a little bit. Keep in mind that any network settings won’t copy over, so W3TC and WordPress SEO, just to name two popular plugins, have network wide settings. Those don’t magically come with, you’ll have to re-build all of that. With W3TC, you should be able to export the settings, but maybe not. Other plugins too may prove problematic. What about BuddyPress? That would pretty much have to be a table-copy over. At least bbPress should be easier, as it’s all CPTs.

Obviously the more layers you get into with this, the messier it gets. Me? I try to do the age old export/import whenever possible.
27 August, 2013
WordPress Media Library: Show ID
While this is considerably less of an issue with the new Media Uploader, and how it inserts your gallery code, this used to be a hassle. The old [gallery] code would just be that, a short tag, and if included all images attached to a post. So if you wanted it to exclude some images, you had to figure out their IDs, or remove them from the post.

I used to have to show people how to do this all the time. Hover over the image, note the URL, bleh bleah bleaaaaaaaaah.

So what if the images showed the IDs? Hey! You can do that with this function!
```
function column_id($columns) {
    $columns['colID'] = __('ID');
    return $columns;
}
add_filter( 'manage_media_columns', 'column_id' );
function column_id_row($columnName, $columnID){
    if($columnName == 'colID'){
       echo $columnID;
    }
}
add_filter( 'manage_media_custom_column', 'column_id_row', 10, 2 );
```
And there you go. I don’t actually use this anymore, but it was sitting in my scrapbook of functions.

If you’re wondering about the right way to handle galleries today, the gallery editor lets you configure what images are and aren’t in it through a GUI, so you don’t need to mess with this. Just click on the gallery to edit it, remove the images you don’t want, add the new ones, and off you go. About the only thing it doesn’t do is let me select how I want the images to like (URL, file, or none), and I still don’t have the option to link to an external URL. Ah well.
26 August, 2013
How To Duplicate Content
I’ve talked about this before. 100% duplication of content on multiple sites is bad. So why am I going to tell you how to do it? And better, why am I going to tell you how to do it without Multisite? Because as a proof-of-concept, it was interesting.

The rest of this post tells you how to do something I don’t advocate, nor will I support. If you have a better way, or improvements, please leave comments. Otherwise, you’re on your own when you do this. I will not help you do it in any way, shape, or form.

Honestly, I still think this is a pretty silly idea. Duplicating content is a terrible user experience, and I still flat-out decline to accept any work for doing this. Sharing content is one thing, but 100% duplication of sites makes no sense at all to me. Yoast also says it’s a bad idea. But, if you really are totally 100% dedicated to do this, and you absolutely are going to, damn the torpedos, then you should do this in the least computationally expensive way possible. And that would be a single install.

Now all that said, this means you’ll need to do a lot of monkey-work, so why do I call this ‘easier’? In many ways, easy is relative and this will be hard, complicated, and may I stress, entirely unnecessary. You’re going the hard way around for something that good planning and a solid understanding of the Internet totally negates. Remember the absolute rule of the Internet: Use one URL per page and never change that URL. (With all rules, there are exceptions, of course.)

The way to make all this work, without Multisite, is by tricking your domain a little. There’s a neat trick with parking (or mirroring, depends on your host) domains, that lets you keep the other domain URL in your browser’s address bar. That’s what I do with this site, actually, halfelf.org is parked on top ipstenu.org. And with a park, the URL always stays as halfelf.org. Hey look! Two URLs, one site! Multisite has secret sauce to know “Someone’s coming to HalfElf, send ’em to site #2.” But on a single site, all my links would still be ipstenu.org and not halfelf.org.

Now how do you use this to duplicate content? You use relative URLs.

So here’s a real example. I have twofer.elftest.net set up to mirror plugins.elftest.net (which will give you a coming soon page, it’s just where I like to blow things up for tests).

In the beginning of this post, when I linked to my old post about Duplication Dilution, the URL was https://halfelf.org/2012/duplication-dillution/ and that is what we call an absolute URL. Because I’m mapping domains, I can leave those in without worry, but if I wasn’t, I’d change that URL to /2012/duplication-dillution/ instead. Right away this makes my URLs entirely relative, no domain name included, and I’m off to the races.

This doesn’t solve everything, though. See, WordPress really wants to use absolute URLs. There are plugins like root relative URLs, and those will help a lot. None of them back-ports your existing posts, though, so for that it’s nothing for it but to search/replace the DB and change your post content.(ONLY change your post content. Do not change GUIDs!) I really like those plugins because now for a new post, when I add a link and chose to link to existing content, it happily works:

And when I add an image, it too smartly handles as I want it to:

That’s the easy part of all this, though. Now you have to disable canonical URLs, so that you don’t end up with even more of the dread duplicate content penalty in WordPress.
```
remove_action('wp_head', 'rel_canonical');
```
This also stops WP from redirecting things like http://plugins.elftest.net/?p=1 as well, however, so keep that in mind. Of course, that’s what you wanted. But they don’t address the problem of your source code. If I view source on twofer.elftest.net, it still showed plugins.elftest.net, and that would be a problem for images and themes. You’ll need to toss in this to your wp-config.php, which will dynamically change your URL to be whatever URL I’m visiting from, so that changes automatically. Awesome.
```
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('DOMAIN_CURRENT_SITE', $_SERVER['HTTP_HOST']);
```
Now I want to tell WordPress that wp-content is not in URL/wp-content/ so let’s just put this in and make it relative too!
```
define('WP_CONTENT_URL', '/wp-content');
```
I’m still going to have to search and replace my old post content (I used Velvet Blues for this):

But that didn’t address the problem of the source code. 90% of WP now thinks it’s all on twofer, which is what I wanted, but look at XMLRPC:

And even better, when I try to log in via twofer, it still says I’m going to plugins. Oh and it doesn’t pass through cookies, so really, I never log in to Twofer. Realistically? This isn’t a problem. I’m always going to use plugins.elftest for all this when I log in on the backend, and since the convenience of all this was meant for the front end, and it’s just pingbacks. And why is that? Honestly, I don’t know. I have a guess that since, at WordPress’ heart, the site is always plugins, the absolute URL there has to be what it is, but in so far as all that goes, I think it meets the needs of why most people want to do this.

Conclusions? You can do this. If you wanted to, you can hardcode the theme so the domain you visit the site with will dynamically change the header image, or widgets, or anything else you want. PHP is pretty cool that way and WordPress is too. But I would never do it, except as an experiment to see what I could do it at all.
31 July, 2013
Recovering Your Cape
One of the odder “hacks” out there is one where the person, once they get in, de-frocks your Super Admin on a Multisite. This isn’t always a hack, sometimes it’s just a simple mistake.

To quote my friend Jen Mylo:
1. People give away admin rights like logo-encrusted keychains at a car show and then the new admins abuse the power.
2. Someone who has admin rights deservedly but doesn’t know code makes a mistake.
[…]

Some people make bad decisions about who to give admin roles.
There’s an extra level of problems with making everyone and their pet monkey a super-admin on Multisite. You may think it’s a great thing, because now someone else can add new users, install plugins, edit themes and plugins, and of course, use iframes and PHP and such in widgets.

We run a Multisite at work, and they let me ‘secure it up’ recently. The first thing I did was demote pretty much everyone except five of us to ‘Editor.’ I told them all that I’d done this, and if they found something they couldn’t do, tell me, and I’d fix it. At this point, I’ve changed only three people to Admin, and dropped even more to ‘Author.’ Why? Because they don’t need to have high levels of access to do what they need to do! The admins on the site can tweak theme settings, play with widgets, and add ‘existing users.’ Everyone else? They just write content. Heck, most of them don’t even need to be Editors, but we gave them that level so they could help us copy-edit other posts. Two people complained “I need Super Admin access!” and I gave them my best Enda: NO CAPES.

Limit your admins, and there is less of a chance someone will accidentally remove access from the wrong person.

So now that that’s out of the way, how do you get it back?

Normally, reinstating an admin account is pretty easy. You go in via mySQL, pop open the wp_usermeta table, find your ID, and toss this in for meta_value for wp_capabilities: a:1:{s:13:"administrator";b:1;} That won’t restore all the roles, if you happen to be using Role Scoper, or some other management tool, but if you’ve got that, you can do anything. If you’re using WP-CLI, wp user update 1 --role=administrator (assuming you’re user ID 1).

There’s a sidebar/caveat to this. Sometimes this doesn’t work, and it happens if you change your DB prefix. So normally you have the prefix wp_ and the table wp_options. In that table you have a option named wp_user_roles and everything works. But then you make a new site, and you pick a different DB prefix, maybe you heard it was more secure, or maybe you wanted both tables in the same DB. Either way, now you have wp_wdssrr_options instead, and when you copy over your old options content, no one can log in. It’s because you have to rename that option to wp_wdssrr_user_roles

I just had a site with this problem last week.

On the other hand, getting back Super Admin access is less straightforward, but by no means is it impossible.
1. Go into wp_sitemeta and look for site_admins.
2. In there you will see something like this: a:1:{i:0;s:7:"Ipstenu";}
3. If your userID is ‘superman’ then it would be a:1:{i:0;s:8:"superman";}
Capitalization and stringlength matter. Add one user, and use that to correctly restore power to the others.

Can you do this via WP-CLI? Yes, if you’re on the latest versions. Kind of. You can get a list of super admins via wp network-meta get 1 site_admins and in theory wp network-meta update 1 site_admins USERNAME would work except that the data is serialized. I opened a ticket with WP-CLI, and it’s a ‘plugin territory’ issue right now, so I’ll have to see if I can code it myself.
25 June, 2013

Shortcode: MLB.TV

I like baseball, I like the Indians. I like embedding content. Why MLB.tv likes to make their stuff not easily embeddable is beyond me. I think [mlbtv id=28142247] is way easier to deal with if I’m using the visual editor. I grabbed the default sizes from their settings.

<?php 
// MLB.TV Shortcode - Better code by Konstantin Kovshenin
// &#91;mlbtv id="###" width="480" height="270"&#93;
function mlbtv_shortcode( $attr, $content = '' ) {
    $attr = shortcode_atts( array(
        'id' => null,
        'width' => 400,
        'height' => 224,
    ), $attr );
 
    $attr = array_map( 'absint', $attr );
    $url = add_query_arg( array(
        'content_id' => $attr['id'],
        'width' => $attr['width'],
        'height' => $attr['height'],
        'property' => 'mlb',
    ), 'http://wapc.mlb.com/shared/video/embed/embed.html' );
 
    return sprintf( '<iframe src="%s" width="%d" height="%d" frameborder="0">Your browser does not support iframes.</iframe>', esc_url( $url ), $attr['width'], $attr['height'] );
}
add_shortcode( 'mlbtv', 'mlbtv_shortcode' );

[mlbtv id=28142247]

Looks just fine.

23 June, 2013

Migrating to DreamPress
I should start with the note: You do not need to do this. We’re finishing up the last bells and whistles on a script that will handle all this for you if you have a One-Click-Install, but if you really just can’t wait or had a manual install, here’s what you’ll need to do. Keep in mind, there will be about an hour where your hosting will ‘vanish.’ In the words of Ford Prefect, don’t panic.

Again, you don’t have to do this. We will have a magic button soon enough. That’s why this isn’t going up on the Wiki, it’s really not going to be (long term) useful except to people who love experimentation.

We have a magic button!

But if you still want to do it manually, read on.

So you saw the news about DreamPress and read our bragging post about it? You got super super excited and then bummed, because the magic button isn’t done yet? Well… Okay, you can migrate manually (I did it for this site yesterday), but you need to know shell. You can do all this with FTP, but it’ll take way longer.

If you just want to make a new domain, read DreamHost Wiki: DreamPress, and you’re good to go! Otherwise, pull the hat down snugly, because here we go!

1. Remove Hosting

Yes, I know. It’s scary. By removing hosting you will turn your site to DNS only. This is OKAY. Your files and your DB will remain exactly where they are. The Remove button is right under ‘Fully Hosted / User : elftest‘ so just click that.

See? Now it’s DNS only.

2. Add DreamPress hosting

Go to https://panel.dreamhost.com/index.cgi?tree=domain.wordpress& and add a new site.

You should see a happy green box telling you that it will take 15-30 minutes to provision you the site. Sorry about the wait time, but we’re actually building you the server stuff on the fly. It’s special.

While you’re waiting, let’s get some things done.

3. Export the old DB

Everything is perfectly safe and sound, so just go ahead and do that. Save it locally to your computer.

Go to https://panel.dreamhost.com/index.cgi?tree=goodies.mysql& and log in to your SQL database. The directions are the same as our normal Backup MySQL ones, so just go and do that.

If you’re Command Line savvy, you can do this via WP-CLI.
```
ssh oldaccount@oldserver.dreamhost.com
cd example.com
wp db export
```
That will reply with “Success: Exported to example_com.sql”

By the way, you’ll need to have the server name (not your domain name) in order to SSH in, as we’ve already pointed your domain to DreamPress. It’ll be something like ps10000 which makes your SSH ps10000.dreamhost.com. You can leave the SQL file there, we’ll pick it up later on in the show.

As soon as you get that email saying “Yay! DreamPress for you!” we’ll ignore the email’s directions and skip on to…

4. Get the new credentials for both SQL and SFTP.

On the DreamPress page, you’ll see your new site info.

You’ll be able to find the new passwords at the usual locations. In the case of the user account (which will be something like wp_kxezav), you’ll want to set it to something you know. While you’re in there, change the account type to “Shell account – allows SFTP/FTP plus ssh access.” I personally also check to disallow FTP, for security. I also like to rename the account something like ‘ElfTest – DP’ so I know this account is for ElfTest on DreamPress.

By the way, you may wonder “Why can’t I have one ID for all my domains on DreamPress?” and the answer is twofold. First, we’re charging you per site. Yes, site. Secondly, security. If one account gets hacked, the others are safe. This is a good thing!

5. SSH into your new account

It’ll be ssh wp_kxezav@ps1121212.dreamhostps.com or such and this will dump you into not the domain, but the folder above it. This is important! You need to be in the example.com folder in order to do anything. Notice also how the domain is suddenly dreamhostps.com and not just dreamhost.com? Also important.

By the way, if you’re going to be using a lot of SSH, you should set up passwordless SSH access. It’s perfectly safe (in fact, safer than entering a password), and has to be set up per computer but .. how many of us use more than one computer? Hush, geeks.

6. Super power time! Let’s copy everything over!

Actually, let’s delete everything first. Yes, I know what I just said. There are reasons. This is just faster. I’m super lazy, so I first opened up wp-config.php and copied the SQL data for the NEW database.
```
// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'example_com');

/** MySQL database username */
define('DB_USER', 'examplecom1');

/** MySQL database password */
define('DB_PASSWORD', 'likeaflaninthecupboard');

/** MySQL hostname */
define('DB_HOST', 'mysql-1.example.com');
```
Obviously changed for my protection. You’d never publicize your passwords. Right? RIGHT? Good. I saved this to a text file on my laptop for the time being. Now let’s delete:
```
ssh newuser@ps1121212.dreamhostps.com
cd example.com
rm -rf *
```
This wipes out everything in my domain’s folder. Make 100% absolute sure you got the right folder! Once you’ve done it, let’s copy things over!
```
scp -r olduser@oldserver.dreamhost.com:example.com/ .
```
SCP is ‘Secure Copy’, and is a fancy pants Unix Command. I’m fond of it. You’ll notice that I said to use ‘oldserver.dreamhost.com’ and not ‘example.com’ and this is because we’ve already pointed your domain to DreamPress. Zoing! When you do this, you’ll be prompted for a password.

Then you’ll get a mile of stuff like this:
```
wp-config.php                                                  100% 3583     3.5KB/s   00:01
xmlrpc.php                                                     100% 2719     2.7KB/s   00:00
readme.html                                                    100% 9177     9.0KB/s   00:00
admin-bar-sprite.png                                           100% 2470     2.4KB/s   00:00
```
This is SCP copying everything over, safe and sound.

7. Change your Database Stuff

There are two parts here. First you want to copy that DB stuff you saved before into the wp-config.php file, replacing the configuration you had there before. Second you want to import that backed up database into the new DB.

You can do this via phpMyAdmin if you want, but if you’re using wp-cli (and you should, it’s awesome), you can do this:
```
wp db import example_com.sql
```
Whaaaaat? How did that work? Remember when you exported on the old setup and then SCP’d the files over? Guess who came with! That’s right, you slipped your DB over nice and fast, and boom goes the dynamite, you’re in.

8. Have a beer!

I always end things with a celebratory something. Your URLs didn’t change, so you’ve got nothing to worry about. Once you’re sure everything’s good, go ahead and delete the old user ID as long as you are 100% certain you’re not still using it!!! Remember, a lot of us use the same IDs for multiple domains.
4 June, 2013