MU

WordPress 3.0 Multisite With Multiple Domains Setup

WordPress 3.0 multisites lets you easily publish multiple sites, on multiple domains, within one installation.  This is a time-saving option for those of us who need to manage multiple separate domains running WordPress, but it does take a little knowledge and file access to set up, and at the moment isn’t for anyone who doesn’t consider themselves technically proficient.

You will need to be able to modify your vhosts file in order to do this, but once done you will have a very flexible and powerful server.

This article is written for 3.0 alpha, as of the current build on 19th March 2010.

Multi sites mode

  1. Install Wordpress 3.0 and install as a normal Wordpress.
  2. Add define(’WP_ALLOW_MULTISITE’, true); near the top of wp-config.php
  3. Log into the admin go to the tools/Nertwork menu.
  4. If it asks you to deactivate all plug-ins do so otherwise go straight ahead and set up multi sites as sub-domains and fill in the other details as needed as needed.
  5. Make a note of the changes needed to wp-config.php and .htaccess and make the changes.
  6. You should now be in multi-site mode.

Adding a new domain

  1. Now we’re in multisite mode login as admin go to super admin/sites
  2. Add a new site – the address can be anything you like just make it unique and make it something you can remember so we can find it easier in the db.
  3. Make sure your domain is pointing at the server if not do so and wait for it to propagate.
  4. Add Vhost alias to the root domain. So if in the Vhost file you have ServerName mywordpres3root.com you would add ServerAlias mynewwordpress.com beneath it.  Alternatively, you can use a wildcard here, but in our implementations there are good reasons why we prefer to specify the host aliases.
  5. Open up the db for editing and add a new row to wp_site table
    1. site_id, domain and path.
      1. i.      site_id, will be a new unique id, remember it
      2. ii.      domain, should be set to the new domain name added above.
      3. iii.      path should be /
  6. Change the row in wp_blogs that matches your new site and make a note of the blog_id.
    1. Change site_id to the new site_id created above.
    2. Change domain to our new domain name.
  7. Open up wp_[blog_id]_options table.
    1. Change siteurl to the new domain name.
    2. Change home to match the new domain name.
    3. Change the fileupload_url to match the new domain.
  8. Your new site should now be ready, you’ll need to go in and set all the options for the domain now. If you wanted a clone of the root sites options you could copy all the rows in wp_sitemeta with a site_id matching the site you wanted to clone and just change the site_id to the new site.

The instructions above are obviously given without any guarantee – use at your own risk, especially if converting your site from single site to multisites.  If you have any feedback or better approaches then do let us know in the comments below.

Wordpress 3.0 with multiple domains.
Multi sites mode
1.
Install Wordpress 3.0 and install as a normal Wordpress.
2.
Add define(’WP_ALLOW_MULTISITE’, true); near the top of wp-config.php
3.
Log into the admin go to the tools/Nertwork menu.
4.
If it asks you to deactivate all plug-ins do so otherwise go straight ahead and set up
multi sites as sub-domains and fill in the other details as needed as needed.
5. Make a note of the changes needed to wp-config.php and .htaccess and make the
changes.
6. You should now be in multi-site mode.
Adding a new domain
1. Now we’re in multisite mode login as admin go to super admin/sites
2. Add a new site the address can be anything you like just make it unique and make it
something you can remember so we can find it easier in the db.
3. Make sure your domain is pointing at the server if not do so and wait for it to
replicate.
4. Add Vhost alias to the root domain. So if in the Vhost file you have ServerName
mywordpres3root.com you would add ServerAlias mynewwordpress.com beneath it.
5. Open up the db for editing and add a new row to wp_site table
a. site_id, domain and path.
i. site_id, will be a new unique id, remember it
ii.domain, should be set to the new domain name added above.
iii.
path should be /
6. Change the row in wp_blogs that matches your new site and make a note of the
blog_id.
a. Change site_id to the new site_id created above.
b. Change domain to our new domain name.
7. Open up wp_[blog_id]_options table.
a. Change siteurl to the new domain name.
b. Change home to match the new domain name.
c. Change the fileupload_url to match the new domain.
8. Your new site should now be ready, you’ll need to go in and set all the options for
the domain now. If you wanted a clone of the root sites options you’d could copy all
the rows in wp_sitemeta with a site_id matching the site you wanted to clone and just
change the site_id to the new site.
Categorised as: Wordpress

Migrating a WordPress/WPMU/BuddyPress Website

Migrating a WordPress site can be something of a scary challenge, but we do it a lot, and we’ve become used to it. There are many good reasons to move a site – for example, you might set one up in a subfolder, and decide to move WP to the root. Or perhaps you’ve built a site on localhost and now need to put it on a live server.

If you do it incorrectly, you stand to lose all your widget settings, some file links and so on. This wasn’t a problem with ‘classic WP’ years ago, but these days there are many many paths stored away in the database, in various forms, and catching them all can be somewhat tricky.

Here I show you the steps we take moving a localhost site to a live domain. We’re using WPMU which is running the BuddyPress plugin suite.

The Local Install

media_1254926142419.png

Here’s our site on our localhost. As you can see, it’s pretty basic, but everything’s there that needs to be there – we know all elements of the install works, and now we want to pop it onto a live server. In this lesson, we’re going to use FileZilla and ftp the files across from our local install.

Copying the Files

media_1254926439240.png

On the left you can see we’ve navigated to our local filesystem for this install. On the right, we’re connected to the server. There are already files there, because we have an old install running. You should delete all the files and replace them with the new ones in this case, but if you are replacing a site do make sure you have a copy of everything. Merging sites is much harder than migrating – and way beyond the scope of this tutorial.

So – select and drag all the files from one side, to the other.

Moving the Database

media_1254927088021.png

Our preferred tool for administering databases is mySQL Administrator. A free tool that really simplifies a lot of DB Admin tasks. Use this to take a backup of your database. You’ll need to create a new backup project.

1. Click Backup
2. Create New Project
3. Select the Schema you’ve been using
4. Click to move it across, selecting ALL tables (unless you have multiple installs in one database, in which case, just the tables for the install you’re interested in)
5. Give it a name
6. Save Project
7. Execute the Backup

Backup Done

media_1254927164402.png

You should now have a backup.

Because the server we’re using doesn’t allow connections on Port 3306, we’re going to use phpMyAdmin there. This is no problem at all, but if you were using mySQL administrator you could use the restore tools there. If you’re doing this kind of project you should really know how to use these tools anyway – I’m only explaining these steps for completeness sake and showing you a migration I’m doing myself that’s likely to be typical.

Editing the SQL

media_1254927350304.png

A database backup is done simply as a big set of SQL statements that you can run. If you’re migrating to a different database you’ll need to edit the CREATE and USE statement to tell it which database to use.

Be very careful with this database dump by the way – database dumps are a very easy way for hackers to get into your system and find out lots of information you’d rather not give away.

Importing The Database

media_1254927962875.png

Now you need to Import the Database. We’re using phpMyAdmin for this. If you have any tables there already, it’s probably best to drop them. All of them. Like I say, if you’re merging you’re going to need more help than this guide can provide.

1. Click on the Import tab
2. Select your file (if it’s bigger than your sever’s upload limit then you’ll have to speak to your admin guys about how to do this.
3. Press the Go button!

Once the import has run successfully you should see a message saying something like "Import has been successfully finished, 95 queries executed." – and it can be an awful lot more than 95 queries! It can also take quite some time. If you need to handle large datasets it’s far easier to use the mySQL Administrator tools – phpMyAdmin can get clunky.

Visit the Site

media_1254928211787.png

If you try to visit the new uploaded site at the moment you’ll get a Fatal Error because all sorts of things are confused.

You need to change the wp-config.php file.

Changing wp-config.php DB Settings

media_1254928518189.png

Change 1, 2, and 3 to match your server’s database settings.

Change 4 to the appropriate path. Most installs are in the root directory, so that would mean $base = ‘/’;

Change 5 to the domain name in use.

Change 6 from ‘/buddypress.11/’ (or whatever your local path is) to the new path, like in 4, so in most cases that will be ‘/’ also.

Search & Replace on the Database

media_1272277924659.png

You now need to run a search and replace on the database – including all incidences of code within serialised PHP strings. There is an excellent and free utility written by Interconnect IT, called the Safe Search and Replace Tool.

I can’t emphasise enough that it’s important to handle serialised PHP correctly. If you don’t, then settings will go missing, fields will get corrupted, and your site runs a severe chance of not working on the new location. It’s a pain, but it’s important.

So, download the program, place it in your blog’s root folder and then run it by visiting the appropriate URL.

If you’re getting confused at this point, perhaps you shouldn’t run the program. Just saying, because it can cause plenty of damage!

Running the Script

media_1254930511307.png

Simply visit http://www.example.com/searchreplacedb.php in your browser to fire off the script. This will run. If you experience a time-out, or too much output, you may need to go into the script and remove any echos that are slowing it down. I’ll probably comment this out in due course anyway, but for diagnostics purposes I’ve left it. Once run, you should see something like the above at the bottom. Even a very large search and replace should only take a few seconds.

Some Tweaks

Check that you can navigate your site in its new location.

You may have to modify .htaccess to fix paths, and you may need to check your uploads folder for media. But that’s it. All should be good.

Extra Steps for WordPress MU

media_1254930620452.png

If you’re using WordPress Single User, then that’s it. You’re all done!

But in this example, we’re running BuddyPress on WordPress MU, and that means one extra step. In phpMyAdmin you need to open up (1) wp_blogs, (2) click the browse tab, and (3) click the edit tab for each row. If you have a lot, you may wish to run another searchreplacedb.php against the database, looking for localhost.localdomain and buddypress.11 and swapping them appropriately.

Categorised as: Wordpress

WordPress in News & Media Presentation

This is the presentation given by David Coveney at WordCamp UK 2009 in Cardiff. It covers the advantages, problems and implementations of WordPress as used by the News & Media sectors.

If you need to view the slide notes (primarily for me, to be honest, but you may see some points that got cut during the presentation) you’ll have to visit the Slideshare site.

Categorised as: Wordpress

Restricting WPMU sign-up.

Restricting the ability to sign up to new wpmu blogs is unfortunate but necessary to get away from all the spam bloggers out there. They make life hell for everyone.

This simplest means of hindering their progress is a plug-in that checks to see the login status of the person trying to create a new blog.
<?php
add_action("signup_header","ICITAreYouAllowed");
function ICITAreYouAllowed() {
if (!is_site_admin()) {
header("location: http://{$_SERVER["HTTP_HOST"]}");
} else {
return;
}
}
?>

Something like the above dropped into the mu-plugins folder would make it hard, if not impossible, to create blogs unless you where a site administrator. Nice for locked down sites but not very useful for sites that want to be open. You could change the “is_site_admin” to a check for logged on user with “user_level_0″ access. This would add an extra step to the sign-up process and would require that the user provide a few more details before they can move on to the process of creating a blog. This would eliminate the scripted bot blog creation but would not stop the manually created spam blogs.
That leaves us with a problem. Either lock it all down and the admin has to do it manually upon request or leave it open and be forever fighting fires.

As a result of the above I’m going to create a plug-in that gives you the following

  1. Drop down menu to choose the minimum account level to allow blog creation. i.e. level_0 to level_10 or “site admin”
  2. Option to choose to give users blog create access once they have X number of moderated comments on the site. This may also help get people posting comments to other blogs. Of course it could also lead to people posting youtube-esque comments just to get to the magic number.
  3. As part of the last one I may also introduce a comment voting system (different plug-in) and only trigger when a certain quality has been reached.
  4. Add an option that states you should have been a member of the site for at least X amount of time before you can create accounts. Couple that with the post count and it should make it a lot easier to spot and block the spammers.
  5. Will have to include the option to have the settings available for each site on the one mu install. So blog creation on each site can be controlled on a site by site basis.
  6. An option to pick up the wp-login form from a kind of page template in the plug-in folder or the theme folder. Would allow you to style it uniquely for each of your themes.

WARNING: These are my personal notes and there is no time frame for this. I can see this turning from the simple code above to something quite large. :D

Categorised as: Wordpress

Steps for installing WP Mu as domain manager

The following is the basic procedure for installing Wordpress mu with more than one domain name so that you only need one install to control several domains. I’m creating this document to help me see all the steps I’ve take so that I never have to figure it out from cold again and to help me with the writing of a plug-in that will allow me to do this via a very simple interface.

  1. Install mu on your domain {e.g. yourdomain.com} and ensure that wildcard domains are processed by mu. Entering [ramdom].yourdomain.com should take you to a prompt to create a blog of [ramdom].yourdomain.com unless it already exists that is.
  2. Park the new domain {e.g. newdomain.com} using your servers management back end. This will be different on each hosting provider and may not even be available so if it is not obvious you’ll need to contact your provider.
  3. Create a new blog {e.g. newdomain.yourdomain.com} and test it.
  4. Get into a position where you can edit the db.
  5. Run SELECT * FROM wp_blogs WHERE 1and look for the blog you just created and make a note of its blog_id.
  6. Edit the domain cell. Will currently be set to newdomain.yourdomin.com and we want to change it to newdomain.com. If we assume the blog_id is 9 the following command would do. UPDATE wp_blogs SET domain="newdomain.com" WHERE blog_id =9 LIMIT 1
  7. We now need to edit the other references to the sub-domain and point them to the real domain name. If you run the following you will find 3 references back to http://newdomain.yourdomain.com change them to http://newdomain.com/ and be sure to keep anything that comes after the domain name. i.e. /files/. Again we assume the blog_is is 9 SELECT * FROM wp_9_options WHERE option_value LIKE "http://%"
  8. Your site should almost work at this point. Give it a test, you should find it all looks as you expected until you try to login to the backend. That is what we’ll fix next.
  9. We need to add a new site to the wp_site table so that we can use the backend admin. INSERT INTO wp_site (id,domain,path) VALUES ("9","newdomain.com","/");We can use the blog_id as the value for id if it has not been used before, if it has been used then just pick a number that’s not been used and make a note of it. The value of domain should be that of the new domain {e.g. newdomain.com} and the value of path should normally be “/”.
  10. We now need to go back to the wp_blogs table SELECT * FROM wp_blogs blog_id = 9 and edit the site_id to be that of the id we set up in step 9. So that would be UPDATE wp_blogs SET site_id=9 WHERE blog_id =9 LIMIT 1. Change the site_id to that which you previously chose if it is not the same as the blog_id. I like to keep them the same to aid my admin but there is no technical need to do so.
  11. Site meta needs to be configured to allow administrators to change the site settings. This command will set the user called admin as site_admin if site_id == 9 INSERT INTO wp_sitemeta (site_id,meta_key,meta_value) VALUES ('9','site_admins','a:1:{i:0;s:5:"admin";}');If you need to change the admin name to something else, say “administrator”, you will have to change the s:5 to match the size of the new word. In the case of “administrator” it would be set to 13.
  12. To enable site plugins the following is needed. INSERT INTO wp_sitemeta (site_id,meta_key,meta_value) VALUES ('9','menu_items','a:1:{s:7:"plugins";s:1:"1";}');
Categorised as: Wordpress