Managing Risks With Web Hosting

We’ve had some clients recently who’ve been burned by other web designers and their hosts. At first we wondered how… our own uptime so far this year, removing planned outages, has been 99.966% – ie, we had three hours downtime on a Sunday morning due to a routing problem at our hosts.

It’s unusual to have even that much downtime, but it can happen. Machines can break, drives fail, and availability isn’t always easy to guarantee.

But if it’s happening a lot, or you run a mission critical website, then this can be a major issue. Imagine spending £200k on a national advertising campaign, and the day it goes live the web server’s having a nap. The developers are on an office day out, and the hosts put you on hold when you call.

In web hosting there’s an awful lot of people making false economies – they run major companies on cheap, consumer level hosting that costs perhaps £15 a month… or less! This may be fine if the site isn’t generally that busy, but any spike in traffic and the machine won’t have the resources to keep the site going. Not only that, but because you’re sharing a box with possibly thousands of other websites, the poor server may well be over-stuffed and overworked anyway.

There’s a few steps to consider when dealing with this:

1. Properly assess risks. If you could lose £100,000 of business when your website fails, it’s obviously wise to spend more than a few hundred pounds a year on it. But there’s no point spending £10k a month on a site that generates very little trade, just for the sake of avoiding ten minutes of downtime.
2. Make sure what goes on the server is only ever fully tested code written by people you can trust. Our own web consultancy, Interconnect IT goes to great lengths to make sure the code supplied is reliable.
3. Consider bringing in house code-reviews and creating your own testing requirements.
4. Load test your server with the predicted maximum level of traffic. If you don’t, how do you know its adequate? And you can’t predict the load just on raw visitor numbers either – some websites are much more demanding on server resources than others.
5. Make sure the site is suitably protected from attacks by hackers and even malevolent rivals.

Ultimately any website is a reflection of your business – if it’s cheap and unreliable, it’ll say that to your potential clients.

Hello from Liverpool

Let’s just start the introduction – this blog is run by James Whitehead, Scott Appleton and Dave Coveney. The idea being to have a separate blog about our life in the world of web business, from our perspective here in our wee office in Liverpool.

We’ll cover the various tribulations, problems and issues that we’ve grown to enjoy or at least tolerate in this line of business.

In our day jobs we both work at a Liverpool Web Consultancy, creating websites, WordPress trickery, running the occasional course, and generally building this business up. It’s still early days, but we’re broadly optimistic.

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. 😀

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";}');