Vhosting offers an alternative by allowing multiple sites to be hosted on your single vCluster IP address. You can then use independent WordPress installs on each of these sites, decentralising a network and allowing you to manage each site manually.

We already have a guide for “vhosting” and “multiple domains on your vCluster“, but you can follow the instructions here as well to setup multiple WordPress installs on vhosts.

Creating vhosts

To create a vhost you need to connect to your vCluster using SSH or FTP. In this article I will be using a visual FTP client, FileZilla, to visualise the process. If you do not know how to connect to your vCluster using an FTP client or by SSH, have a look at “setting up an FTP client“, or “connecting with SSH“.

Once you have connected to your vCluster navigate to:

/sites/fubra-customer/vhosts

Replace the fubra-customer with your own Passport Group, and vCluster name. Alternatively double click on the directories in FileZilla to find the vhosts folder visually.

Inside the vhosts folder you you can now create directories for each of the sites you wish to host on your vCluster. There is a very strict naming convention that you must follow in order for vhosting to work successfully.

The directory you create must have the exact same name as the domain name you wish to point here. For example, I have purchased the domain name joegardiner.co.uk, so in the vhosts folder I will create a directory named joegardiner.co.uk. Note, you will never need to add www to the front of the directory name.

Now open your newly created vhost directory (joegardiner.co.uk), and inside this directory create a new directory named http. This directory will be the root directory for this vhost, similar to the http directory two levels higher in your main vCluster directory tree.

Inside the newly created http directory you can install any php application you want, including WordPress. You can create as many vhosts as you want in this manner, but if you’re installing multiple WordPress’, it is very important you follow the next few steps.

Database table prefix

You vCluster is created with a single database, this means that multiple WordPress installs using this database may clash by trying to access the same tables, leading to instability. The solution is to change the table prefix each WordPress uses when you install it. Changing the prefix will allow you to easily see which set of tables applies to each vhost.

During the WordPress installation it is necessary to edit the “wp-config.php” file to add database information. If you unsure how to install WordPress have a look at this guide, “Install WordPress on your vCluster“.

While editing the wp-config file you can also add a table prefix. Open up your wp-config file in a text editor and scroll down, near the bottom of the file. Find this block of code:

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'wp_';

The ‘wp_’; line is what you need to change to alter the table prefix. The table prefix must be made up of letters and numbers and underscores, and you can add anything you like between the single quotes, but I would recommend using a prefix that applies to your domain.

In my case my vhost is named joegardiner.co.uk, so I shall edit my prefix to read ‘joegard_’;. After editing this line the previous block of code should now look like…

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each a unique
 * prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'joegard_';

Once you have made the changes to the wp-config.php file you can save and exit your text editor and continue installing WordPress in the usual manner.

Pointing your domain

Now that WordPress is installed you need to point your domain name at your vCluster. Due to our clever Apache configuration, all you need to do is point each domain name for all of your vhosts at the single vCluster IP and the correct vhost will always be loaded, provided the directory naming rule was followed, and vhost directories exactly match domain names.

Every domain name registrant will use a different control panel for managing a domain name’s DNS settings, I registered my domain with LivetoDot, so the following screenshot will be of their control panel.

First of all you need to head to the CatN Control Panel for your vCluster and take a look at the main settings page. Take a note of vCluster IP address as you will need this in a minute. Next head to your domain registrants site and login to the control panel. You will be editing the (A) Address record of your domain name which will be under DNS settings.

You want to overwrite or add records for “www” and an empty field. Have a look at the screenshot below for help.

Once you save these two records, it may take up to 24 hours to update a .co.uk domain name so be patient! Once the (A) record is updated, navigating to your domain name in your web browser, in my case www.joegardiner.co.uk, will load the files from the joegardiner.co.uk vhost directory we created earlier.

You can follow the previous procedure as many times as you want for as many independent WordPress installs as you require. The benefit is that you can manage installs separately without the confusion caused by a centralised user, theme and plugin management system. On the down side you may have to repeat configuration across each WordPress manually instead of being able to activate plugins across the network.

Fortunately your vCluster happily supports both methods, so whichever process you prefer for setting up your WordPress network, it will be fully compatible with our php optimised hosting platform.

Yesterday we suffered a major RAID card failure on a database server, unfortunately we didn’t have the spares in place, resulting in a fix taking much more time than it should have and prolonged downtime. The server has been rebuilding the majority of the evening and is concluding now. The time it takes to repair an array of the size we host is measured in 24hour periods, not single hours, so waiting for this rebuild is not a viable restoration method.

If we experience RAID failures we need to have a plan for immediate recovery, but unfortunately our current graceful failure plan was not successful due to the catastrophic failure of the RAID controller, which left the entire RAID in an inconsistent state.

The recovery procedure

After the failure we looked at backups and restoring to a spare server as a possible solution. There were a couple of delays to a backup restoration. Currently all of our backups are remote, not a major delay but it did slow things down a little, another problem was not having a predetermined method of rapidly recovering backups.

Currently we have restored to our most recent backup in order to resume normal service, but unfortunately this backup was from Saturday morning (28th) between 06:30 a.m. and 07:12 a.m, 48 hours behind, clearly our planned nightly backup had failed.

As we alternate between running full and incremental backups, occasionally our system schedules a large number of full backups, resulting in a backlog of backups. The hardware failure we suffered coincided with a scheduled backup meaning we were half way through the process when the hardware failed, unfortunately the failed database server backup had not run at the point of failure.

Future Redundancy

In order to prevent a failure of similar magnitude in the future we are currently reviewing our recovery procedure and will be investing in five levels of redundancy for the future:

• RAID on all servers
• Master/Slave replication, allowing us to switch the Slave to Master in the case of a failure.
• Having an on site cold spare database server will provide a full set of spares in the case of a Master and/or Slave failure.
• On site daily backups (using a dedicated server in our Data Centre for rapid restores if Master/Slave replication fails).
• Off site daily backups using Amazon EC2/S2

Once the new hardware and backup solutions are in place we will have fast replications for the vast majority of potential issues. If both of our servers fail, we will have a spare server on site. If we do have to resort to archived backup, we will have more current and on site backups available instead of just off site as we currently do.

Finally, InnoDB backups did not work successfully, and we are currently reviewing this and will update here shortly.

Let me offer my sincere apologies to all our vCluster customers, and assure you that we take any major failures extremely seriously, and that we are working rapidly to prevent any failures of this magnitude occurring again. If you continue to experience problems please email support@catn.com, and remember to follow us on Twitter for further updates.

Summary

The key points from the rest of this report follow:

Migration – We migrated dft.gov.uk from it’s current management system to WordPress to illustrate the ease of the process and that the site can be moved to an open source, free management system for very little cost. We had no access to any site files but used a small script to crawl the sites content and images.

Hosting – The copied site is now hosted on our php platform vCluster and was developed on the same platform it is now hosted on.

Expenditure – The migration and hosting process resulted in costs to us of £5000. This small investment could save up to £64,800 per month, £777,600 per annum, and this is for a single Government site.

You can view the result of the migration and our sample site running on WordPress here: DFT sample site.

My aim is to illustrate the ease of the process and to show the reduction in expenditure that can be achieved by using an open source hosting platform and a low cost language to write and maintain, like php. I chose DFT as it had one of the worst value for money “cost per request” rates in my Government value for money report.

To put the cost per request for DFT into context, the next highest cost per request is communities.gov.uk:

As you can see, DFT is almost four times as expensive per request than communities.

The site dft.gov.uk can be considered a “static” web site. This means that content is not dynamically generated, and that there are no complex application on the dft.gov.uk. the DFT site is purely informational and contains static content for this purpose.

Migration process

By Iain Cambridge

The sample site is now being hosted on a Fubra development vCluster, on the CatN platform. We migrated 4 levels deep giving a good overview of the sites categories without scraping the entire sites data which would be very time consuming for a sample case study. After extensive testing of the site, we have achieved full functionality in WordPress (4 levels deep), and have achieved excellent site performance with no extra configuration of the CatN platform required.

You can view the result of the migration and our sample site running on WordPress here: DFT sample site.

How much?

It is difficult to give a precise figure for the required expenditure for hosting dft.gov.uk on a CatN vCluster, as we have no access to site analytics. However, I have compared the percentage of global page views with other sites hosted by CatN on the Alexa Web Information site, to give a suggestion of the price range DFT may fit into, and I have page impressions and total site visitors data from the COI Report on Progress 2009/10.

Note: There are some questions over the accuracy of Alexa traffic data, particularly with sites heavily dependent on social media that will receive spikes for certain articles effecting similar site rankings. I am not fully dependent on Alexa statistics, but am just using them as a guide to fit dft.gov.uk into a realistic price range as an indicator of the cost of hosting on the CatN platform.

The sites I am comparing are not heavily dependant on social media, and are not tiny sites whose scale is difficult for Alexa to manage. All of these sites receive consistent traffic at the levels expressed in the following graphs, and do not use the Alexa toolbar to manipulate Alexa rankings.

Have a look at my blog post Alexa Accuracy, or an Alexa blog about site rankings: What’s going on with my Alexa rank?

Alexa and Analytics

Adding Site 2 as a comparison to dft.gov.uk reveals that it is gaining a higher pageviews rank in Alexa, in fact at some points on the graph, four times as many. As I have access to analytic data for Site 2 a more accurate comparison can be made

The analytic data agrees with Alexa’s ranking, showing Site 2 to be approximately four times the size of dft.gov.uk in terms of traffic and global reach. Although it would be possible to scale down Site 2‘s hosting expenditure for an indication of the required spend for DFT on our platform, comparison with similarly sized sites will increase the accuracy of the estimate.

Site 3 and Site 4 are given a similar rank by Alexa to DFT, so are worth considering in more detail. The similarities in rank may be reflected in traffic patterns, allowing a clearer indication of the required expenditure for hosting DFT on a vCluster.

The analytic data shows that dft.gov.uk can be considered a similar size in terms of traffic to Site 3 and larger than Site 4, so a fair estimate should be similar to Site 3 and approximately a quarter the size of Site 2, a pessimistic estimation would be around half the size of Site 2.

COI pricing comparison

From the COI Reporting on Progress 2009/10 I have the following site data for dft.gov.uk:

From the traffic data of Site 2, 3 and 4 in my previous comparison, I can compare hosting expenditure across the sample with the spend disclosed by the COI report for an indication of the expenditure required for hosting DFT on a vCluster.

In comparison to sites of a similar size in terms of traffic, particularly Site 3 and Site 4, DFT seems to have an enormously inflated monthly hosting expenditure. I have visualised this below with a following graph displaying page visits.

Hosting expenditure (June 2010) for sample sites

Site visits (June 2010) for sample sites

There is no clear correlation between site visitors and hosting expenditure when comparing any of the sample sites to dft.gov.uk. Site 2 with 3.5 times more visitors has a hosting expenditure almost 30 times smaller per month. This is an annual difference of £782,460, provided DFT is ported to a php CMS such as WordPress. Presuming that dft.gov.uk did achieve the same traffic levels as Site 2 and was spending approximately £3,000 per month using a vCluster, DFT could expect to make savings of up to 96.6%.

Estimate

It is difficult to give a precise estimate, there are clear indication from my analysis of the price bracket DFT should fit into if hosted on a CatN vCluster:

• Using the sample comparison sites as a pricing guide
• Taking into account the requirements of the dft.gov.uk website’s static content
• Inputting traffic data from the COI report to the vCluster Platform Hour Calculator

Please note that the estimate is precisely that, and does not include any development costs required for migrating dft.gov.uk to an open source php CMS.

Comparison guide

Platform Hour estimate

Taking the Platform Hour charge of £1,696 and adding the package charge for vCluster Ultimate of £100, all that remains is Data Transfer charges if usage exceeds allowance.

The average page size from 10 sample pages of dft.gov.uk is 287kb. Multiplying average page size with monthly page views allows a data transfer estimate to be made.

As the vCluster Ultimate package allows 500GB of data transfer before usage charges are incurred, from the above estimate dft.gov.uk would incur no data transfer charges as 418GB are being used. Therefore the only usage charges from this estimate are for Platform Hours. The total charge based on these figures would be £1,796 (Platform Hours + vCluster Ultimate subscription).

The estimate of £1,796 fits within the comparison sites range of £240 to £2,295, and is similar to the average of the range. As the top end of the range, Site 2, has traffic levels 6 times higher than dft.gov.uk and is charged £2,295, I would feel confident that DFT would be very unlikely to be charged more than £4,000 per month for being hosted on a platform such as the CatN vCluster. In fact £4,000 is a pessimistic estimate based on the analysis in this report.

Even if dft.gov.uk did achieve monthly bills near £4,000, it would still be receiving a saving of 94% per month from the current £67,500 expenditure, and this is based on the worst case scenario for DFT hosting expenditure.

Can the government afford to ignore the potential savings of moving to an open source, cloud hosting platform? In a period of savings and public service cuts, surely web hosting expenditure should be reviewed when such large savings seem possible.

You can view the result of the migration and our sample site running on WordPress here: DFT sample site. Don’t believe it’s WordPress? Add “wp-admin” to the site url for the WordPress login screen.

Alexa is widely used, especially when attempting to value a website for a potential sale. Some Webmasters focus on improving their Alexa ranking over improving their content in the pursuit of valuing their site higher. This seems like a waste of effort to me, but this practice does take place, but then you already knew that! With this behaviour taking place, and discrepancies when comparing Alexa rankings with analytic services such as Google’s, some concerns over Alexa’s accuracy have been raised.

The tracking tool that users download, tracking their activity for Alexa allows Alexa to show the proportion of a web sites global traffic rank, reach and page views in relation to all the other sites Alexa has data about. What Alexa does not do, is give precise numbers for any of it’s site detail categories.

Long Tail

A recent blog on the Alexa site “What’s Going On With My Alexa Rank?” offered an explanation for some dramatic change in Alexa rank that some smaller sites have experienced. The Long Tail represents how a tiny change in value can dramatically change a sites position on the curve (rank) dependent on it’s starting position.

A site at the top of the curve will see very minor changes in position even when visitor numbers change by the thousands, as the density of sites at this level is low. From the middle to the lowest point of the curve is the highest density of web sites from the 200 million reported by Netcraft in their July 2010 Survey. A small change in visitor numbers, maybe a spike of 5000, will dramatically effect a sites relative rank when 10 million other sites share similar traffic stats, thus leading to a dramatic change of an Alexa ranking.

Google Analytics

To gauge the accuracy of Google analytics before comparing to Alexa I carried out a number of comparisons between analytics data and our own web monitoring with awstats. Across the three sample sites below I found consistent correlation with plus or minus 5,000 page views on average for each day in the trailing three month range.

A comparison

I wanted to compare large sites we host with Alexa rankings to test the accuracy for myself, unfortunately I can’t give any names!

Large site #1

Over three months Alexa is pretty accurate in tracking traffic patterns for my first sample site. Even the spike is fairly represented, and the time frame the spike takes place over is correct.

Large site #2

Alexa does represent traffic patterns over the course of a week but the accuracy is certainly less than Site #1, and the time frame is inconsistent.

Large site #3

This is the weakest correlation of the three graphs, with only a suggestion of this site’s traffic patterns. The spikes from Alexa for global reach do not seem to follow any spikes in page views on the actual site.

The numbers

As I have access to analytics data for numerous large sites on our cluster I can attempt to calculate the real number of site visitors 0.001% of global traffic in Alexa. Adding to my two example sites with Alexa graphs I will use three more large sites hosted on CatN vClusters. Before attempting to calculate the real visitor value of an Alexa percentage it is important to check the consistency across a sample of data for each site.

From these sample sites, there are obvious changes in consistency. For sample Site 1 on July 12th there were 220,403 page views giving an Alexa global page views of 0.0008%, but on July 26th 40,000 more page views (266,596) results in Alexa giving a lower percentage of global page views, 0.00058.

Continuing to sample Site 2, on July 12th 59,628 resulted in 0.0002% of global page views and two weeks later 10,000 more page views (72,821) gave a lower Alexa percentage, 0.0001%.

Finally in sample Site 5‘s data July 12th and July 26th data is consistent with a difference of 6,332 page views (60,716 – 54,384) giving the same Alexa percentage in both cases 0.0001%. However, on August 6th the site page views drops to 49529, approximately 5,000 less page views, but the Alexa percentage halves to 0.00005%, not a relative representation of the change in page views.

Sites gaining an Alexa rank of approximately 0.0001% have a wide range of traffic figures suggesting that the Long Tail effect is apparent in this range of sites which must be densely populated. The lowest traffic I have recorded within the 0.0001% range is Site 3 with 27,290 page views and the highest is Site 2 with 72,821 page views. With a difference of almost 50,000 page views the Alexa ranking for sites of this size must be densely populated with large change in ranks from relatively small changes in page views.

However, sites with page views within this range (27,290 to 72,821 page views) do not have corresponding Alexa global page views percentages. Site 4 on August 6th fits within the 0.0001% range from Google analytic page view data (27,893 page views), but Alexa gave a global page views percentage of 0.0003%, 0.0002% higher, revealing clear inaccuracies in Alexa ranking. Due to these inaccuracies I feel it is impossible to attempt to calculate the real world value in page views of a reach of 0.0001% from Alexa.

Users

I wanted to find out how many Internet users actually have the Alexa Toolbar installed, as this could explain varying ranks from Alexa, and the demographic of user’s would clearly effect the amount of data Alexa is gathering about certain sites.

To do this we searched our web server logs for occurrences of the “Alexa Toolbar” user-agent string, and variations of. An example user agent string containing the target words would look like this:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.0.04506; Alexa Toolbar)

I cannot disclose actual website request numbers or a websites name, however from sample sites receiving requests over a period of time from 1 million to 10 million, an average 0.019% of those requests came from users with the Alexa toolbar installed.

The sample sites demographic is wide ranging from niche technical sites to property and employment sites giving a wide range of sample demographic data. Another point to note is that from these sample sites, the highest percentage of requests from Alexa users was 0.026%, still a very low percentage, suggesting this level of Alexa requests is applicable across other web sites.

Is it possible for Alexa to give accurate rankings and percentage of global page views for a website, considering many sites are being visited by a tiny number of users that actually have the Alexa toolbar installed? Clearly Alexa cannot be relied on for accurate ranking information for critical site analysis, and perhaps should only be used as a rough guide, especially for smaller sites subject to the long tail effect. What are your experiences of Alexa’s accuracy? How far do you trust it?

Here we will be discussing the best MySQL practices you can use not only to keep your database running smoothly and quickly but also to keep it user friendly.

10 – Use sensible field names

Have you ever started on a project and designed the database using ambiguous field names like ‘x’ or ‘uft’ or other silly abbreviations, then it comes to writing a query and you wonder to yourself “What the heck did I call the field for First Names?”. Well this is possibly one of the worst things you can do to hurt the usability of a database. Instead simply call a field ‘FirstName’ or ‘Address1′ and save yourself all the hassle later of looking it up. Save time, name fields by what they contain.

9 – Don’t use ‘SELECT *’

Let’s create a scenario, you have a login form on your website and to check if the details are correct you query the database. This database could contain loads of fields that are totally unnecessary for this certain query like address or phone number. You would only need the username, password and possibly email to check the user input against. So why grab all that unneeded data and use up resources when its totally avoidable. Instead of structuring a query like

SELECT * FROM Users WHERE Username = 'bob'
AND Password = 'password'

Change it so that it only takes what it needs.

SELECT Username AND Password FROM Users WHERE Uesrname = 'bob'
AND Password = 'password'

As you can see from that, it will only get the two fields that you need, reducing the time it takes to run the query. Good for your database server and good for the end user.

8 – Limit queries where possible

Another time and resource saver here. When you know your query will only return one result, is there any point in continuing to search the database after it has been found? That’s what’s happening if you don’t limit, it will search the entire database even after it has found the record you are looking for. A login query will only ever return one result, so let’s add it into the query to stop searching when that result is found.

SELECT FirstName FROM Users WHERE Username = 'bob'
AND Password = 'password' LIMIT 1

Et voila, the query will be ended when the record is found, another time benefit to the end user.

7 – Create an ID field

When you are creating your database, implement an ID field. Make this one of the INT types, primary key and auto increment. This way, every single record will have a unique integer as the identifier, which is much cleaner and faster than a VARCHAR. A VARCHAR as the primary key is much slower than an INT due to processing time, which is why it is not recommended.

6 – Static tables are best

First, do you know what a static table is? Clue’s in the name. A table is considered static when all of the column types have a fixed length. Examples of fixed length types are INT, DATE and DOUBLE, but the ones that are not static (dynamic) are VARCHAR, TEXT and BLOB so these are best avoided. Although a table is only static when all of the columns are fixed length so if you have one VARCHAR then a table instantly stops being static.

5 – Split large queries

If you have any maintenance scripts you run on your database which deletes or inserts a large amount of rows (more than about 1000) then you are better off splitting them up. MySQL works most efficiently when queries finish sooner, so if you split a large delete query into multiple smaller ones, you are less likely to lock up your database. This can be done simply by using LIMIT 1000 at the end of the query. To automate running all of the queries, a PHP infinite loop can be used.

while (1) {
	mysql_query("DELETE From Comments WHERE PostedDate <= '2010-01-01'
		LIMIT 1000");
	if (mysql_affected_rows() == 0) {
		break;
	}
}

The if statement checks if anything was actually deleted, and if it wasn’t then it breaks out of the loop, ending the script. Very simple to do, and can save your database from bringing down your website.

4 – Use smaller columns where possible

In a database, size is everything. A large data size can often cause a bottleneck in your database server, so the best solution to this? Use types that are smaller in size. If you can get away with using SMALLINT or even TINYINT instead of the regular INT then go for it! When large amounts of rows are created, it will make all the difference.

There is a whole document on the MySQL Docs website that explains the sizes and storage uses of the various types and from that we can see that INT uses 4 bytes, where as SMALLINT uses only 2 and TINYINT uses only 1 byte. The space saving opportunities are endless!

3 – Use an index key where necessary

This is possibly one of the best things you can do to decrease the times needed to search a table. Any field that is regularly going to be searched should have an index on it. There is absolutely no reason not to! One query is all that it takes.

ALTER TABLE Users ADD INDEX ('firstName')

And that’s it. The column firstName now has an index on it that will drastically increase the performance of searching by it.

2 – Change the default username and password

If you have a database server like mine, then the default username and password is ‘root’. This is incredibly insecure, and needs to be changed. Again, it can be solved by two simple MySQL queries. First to change the username.

RENAME USER root TO new_username

That changes the username to whatever you specify and this next one will set your password.

SET PASSWORD FOR 'username'@'hostname' = PASSWORD('newpass')

Make sure you update any connection settings in any of your scripts after changing the username and password.

1 – Don’t give users the ability to inject MySQL

The number one rule of MySQL is don’t trust the users. If you have a database incorporated into a PHP script which inserts data, for example a registration form then it is possible for a user to inject SQL. It’s a bit complicated to explain, but there is a handy .pdf over at dev.mysql.com that goes through it in epic detail. All you really need to know is how to defend yourself against it.

The easiest way is to simply sanitise any data that is received from the user. Let’s consider this:

$name = $_POST['name'];
$query = "INSERT INTO Users (name) VALUES ('".$name."')";
mysql_query($query);

Currently the name variable is whatever the user inserts and that could contain SQL to delete all tables. Not good. So we sanitise the string to make that impossible. Here is the new code with the sanitation.

$name = filter_var($_POST['name'], FILTER_SANITIZE_STRING);
$query = "INSERT INTO Users (name) VALUES ('".$name."')";
mysql_query($query);

Notice the change on the first line? Good. That’s SQL injection safeguarded against.

I hope you have learnt from this post, and use at least some of these practices. Any questions? Leave a comment and I will reply.

Your CatN vCluster makes an ideal platform for running a WordPress blog farm. If you’re looking for unlimited domains (including vanity domains!) from a single WordPress installation, this guide will get you up and running in no time.

Note: This guide only applies to WordPress version 3.0 and above.

This guide is dependant on you installing WordPress in your root directory, not in a subdomain.
e.g. install WordPress in your www/sites/fubra-customer/http folder

Getting Started

Unzip your downloaded WordPress install to a folder on your desktop.

Open the newly unzipped WordPress folder, locate the file called “wp-config-sample.php”, and rename it to “wp-config.php”.

Open the newly named “wp-config.php” in you text editor and locate the MySQL Settings section.

You need to open your vCluster setting page to retrieve your database information which is available on the CatN Control Panel: https://passport.fubra.com/site/cat/login/.

After the ‘DB_NAME’ field, enter your username exactly as it appears in the Database Settings page, as this is the same as your database name.

After the ‘DB_USER’ field, enter your username.

After the ‘DB_PASSWORD’ field, enter your Database password. Note: This is different to your Access password, and can be changed in the Database Settings screen.

After the ‘DB_HOST’ field, enter the server name in the Database Settings screen. eg. xserve1.dc.fubra.net.

You can ignore the two remaining fields, (‘DB_CHARSET’ & ‘DB_COLLATE’).

The multi-site rule

Scroll to the bottom of the wp-config file, and just after define(‘WP_DEBUG’, false); add the rule “define(‘WP_ALLOW_MULTISITE’, true);“. This is a very important step, and you must make sure that it matches exactly the text in this guide.

I have also added comments above this rule, just to help me review this file quickly at a later date. You do not have to do this, but it is good practice to comment any code.

Once you have added the multi-site rule you can save and close the completed “wp-config.php”, making sure you click ‘Yes’ when FileZilla prompts you to re-upload the file to the server. There may be a delay of a few seconds before this prompt appears so be patient, it’s very important!.

Uploading

To upload WordPress files to the root directory of your vCluster follow the FTP upload guide.

To upload WordPress files to a sub-domain on your vCluster follow the vHosting guide.

Installing WordPress

Now you can install WordPress in the usual manner. If you are unsure how to do this have a look at the guide, “Installing WordPress on your vCluster“

Multi-site in the Admin panel

Head to your WordPress install URL and login to the admin panel by adding “/wp-admin” to the end of your site URL. Use the left navigation side panel and select Tools. Under this option you should see a new link called Network, select it now.

In the Network panel, choose to setup your multiple sites on Sub-domains or Sub-directories.

CatN vCluster is configured to allow wildcards to be directed to the correct vHost, so fully supports either options. I recommend Sub-domains as this allows you to take advantage of the unlimited free domains on your vCluster account. Finally enter your network title and you email address. When all this information has been entered, click install.

Editing your WordPress install

In the following screen you will be presented with a lot of information. Take your time to read through it and familiarise yourself with the steps we are about to follow.

Let’s get started…

1. Create a blogs.dir directory: I’m going to create this directory using an FTP client with a user interface such as FileZilla. FTP to your vCluster and navigate to your WordPress installation directory, if you don’t know how to FTP to your vCluster read this guide: “FTP Upload“. In my case this is the “http” folder as my WordPress is installed in the root directory.

Following the Admin panel instructions, I want to navigate to “/sites/fubra-customer/http/wp-content”. Inside this directory create the new directory named blogs.dir. FileZilla should create this directory with the correct permissions, but you can right click on blogs.dir and select Permissions to ensure the web server can write to the directory.

2. Edit the wp-config.php file: In the same FTP navigation panel navigate to the root directory of your WordPress install, and locate the wp-config.php file. As I said earlier, my WordPress install is in my “http” folder -> /sites/fubra-customer/http.

As I am using FileZilla I can edit the file on the web server. Right click on the wp-config.php and select View/Edit. This opens up my text editor and allows me to copy and pase the code from my WordPress Admin panel.

Following the WordPress admin panel instructions, copy the code under Step 2 and paste above the line near the bottom of the wp-config file reading: /* That’s all, stop editing! Happy blogging. */.

As you can see this code fits nicely below my “Enable multi-site” comment! One thing remains to do in the wp-config.php file. This is very important, make sure you delete the line we added at the start of the process: define(‘WP_ALLOW_MULTISITE’, true);. Once this line is deleted, you can save and close the wp-config.php file, making sure FileZilla commits the changes to the server.

3. Edit the .htaccess file: Again, using FileZilla make sure you are in the root directory of your WordPress install. In my case the file path is /sites/fubra-customer/http to my WordPress root directory. Before we locate or create the .htaccess file, make sure that hidden files are viewable in FileZilla. To do this select Server from the top menu bar (MacOSX), and make sure Force showing hidden files is checked.

Now have a look in the root of your WordPress install for an .htaccess file. It is unlikely that one will be here, to create a new file, open a text editor. Copy and paste the code from Step 3 on the WordPress dashboard into your text editor and save it as htaccess.txt. Make sure you save it as plain text, ending in .txt, and we will change the file extension on the server after the upload.

Now upload this file to the WordPress root directory by dragging it into the FileZilla server panel. Once the file is uploaded, right click and select rename. Make sure the file is now called, .htaccess. Make sure you delete any file extensions and the file is named exactly as shown.

If you already had an .htaccess file in your root directory you can edit the contents. Right click on it and select View/Edit to open the file in your text editor. Now select the code from Step 3 on the WordPress dashboard and override all the contents of this file, leaving only the copied code. Now save this file and ensure it updates to the Web server.

.craccess

The final bit of file editing, that is not explained in the WordPress dashboard, which is local to the CatN vCluster is in the .craccess file. Those of you paying attention will have noticed a .craccess file above your .htaccess file. We need to edit this file slightly in order to make sure content is being served correctly.

Note: If you are unsure about .htaccess or .craccess have a look at this guide: “.craccess and .htaccess”

Right click on your .craccess file and select View/Edit to edit the contents. Your .craccess file contents need to be overwritten with the following. Make sure you replace the (highlighted in red) Private IP with your own, available in settings page of your vCluster in the CatN Control Panel: https://passport.fubra.com/site/cat/login/.

Now all our file editing is complete you can click the Log In link at the bottom of the Network panel in the WordPress Dashboard to re-login and finish the Network creation.

Super Admin

After you log back in to the WordPress dashboard you will be able to see a new Super Admin tab in the left side bar.

This panel allows you to administer your WordPress install across multiple sites by adding users and domains etc.

The exact function of each Super Admin option is explained in detail on the WordPress Codex: http://codex.wordpress.org/Super_Admin_Menu.

Domain Mapping

Now that multi-site is installed and your Network has been created you can create multiple sites, and direct the domain names you have purchased to each site. To test domain mapping create a test site before you attempt to map domains to a working site!

Create a test site

In your WordPress dashboard, have a look at the Super Admin panel and select Sites. This will take you to the Sites admin panel, enabling you to create a new site in your Network.

In the Site Address box enter “test1“. This will add the test1 sub domain to your WordPress domain. Make sure you dont put any spaces in this box.

In the Site Title box enter “Test 1“. Don’t worry about the boring name, this is only a test site, and you can delete it later.

In the Admin Email box enter your administrator email address.

When this information has been entered, click Add Site to complete the process.

You will now be directed to your sites overview panel where you will be able to view your newly created site. At this point grab a pen and paper and take note of the sites ID number, this will be important later. In my case the test1 sites ID is 3

Installing WordPress MU Domain Mapping plugin

Now you need to install this plugin to add the Domains, and Domain Mapping functionality to your Super Admin panel. First thing first, download the plugin from the WordPress Plugin Directory.

This plugin is a little different to others, you don’t simply copy the plugin folder to your wp-content/plugins folder on the web server, it has precise installation instructions you must make sure you follow correctly.

Step 1:Extract the downloaded plugin file to your desktop and open the extracted folder. Inside you will see these files…

Step 2: Go back to your FileZilla window and navigate to the wp-content folder. On my vCluster the directory path is: /sites/fubra-customer/http/wp-content. Drag the sunrise.php file from the extracted plugin folder to the wp-content folder you have found in FileZilla.

Step 3: Now to copy the second file to your WordPress install. Head back to your extracted plugin folder and find the file named domain_mapping.php. Now switch back to Filezilla and navigate to the plugins folder inside the wp-content directory. My file path is: /sites/fubra-customer/http/wp-content/plugins.

Drag the domain_mapping.php file to the WordPress plugins directory to complete the upload. Provided you have not installed any other plugins the directory should look like this:

Step 4: Time to edit the wp-config file again! In case you don’t remember where it is, head back to your WordPress install root in FileZilla, in my case /sites/fubra-customer/http. Scroll down and find the wp-config.php file, right click on it and select View/edit.

Your text editor will open up allowing you to make changes to the file. Add the following text just below the Multi-site text we added earlier.

Note: The text between forward slashes, Enable domain mapping plugin, is a comment to help reviewing this file at a later date. You do not need to add it, but I recommend commenting wherever possible, it will make your life easier in the long run!

Make sure you save and close the wp-config.php file after making changes and that you click ‘Yes’ to the FileZilla prompt about re-uploading the file. This is very important!

Dashboard configuration

Now that the plugin has ben uploaded, head to your WordPress dashboard, but make sure you are in the dashboard for the original WordPress site, not the test site we just created. This is very important as many changes are local to the site dashboard you make changes in, for example you can activate a plugin in one site and it will remain deactivated in another! To change between sites look for the Dashboard tab in the left sidebar and select My Sites.

You can now switch between dashboards using this control panel by selecting the “Dashboard” sub-nav under the site name.

Make sure you are in the original sites dashboard, in my case the site named “Customer”, or the name you gave your site during the WordPress installation process. Have a look down the left sidebar and find the Plugins tab. Select Plugins under the Plugins tab to display a list of the currently available plugins to this WordPress install.

Click Activate under the WordPress MU Domain Mapping plugin to activate the plugin and enable Doamin Mapping functionality in your Super Admin panel. Now if you look over the left sidebar under the Super Admin tab, two new options have been added, Domain Mapping, and Domains.

Click the Domains link to take you through to the Domain mapping panel. Now, do you remember taking down the Site ID number when you created the test1 site? If you have forgotten it or didn’t write it down you can click the Sites button in the Super Admin panel to find it again. If you have your Site ID to hand type it in the Site ID text box.

In the Domain text box enter the domain name you have purchased, e.g. joegardiner.co.uk that you want to direct visitors to the test site we created. You can leave the Primary box ticked.

Now all this information has been entered you can click save.

Pointing your domain

Now that WordPress has been configured to direct my domain, joegardiner.co.uk to the test1 site, I need to change my domain settings to point at my vCluster and the WordPress install. The following instructions may vary depending on who you bought your domain from, but the principle is the same.

Head over to the CatN control panel, https://passport.fubra.com/site/cat/login/, and find the Settings page for your vCluster. If you have difficulties take a look at the Quick Start Guide. On the settings page for your vCluster you can find your Public IP address. Mine is: 87.124.84.82, take a note of yours and copy and paste it from the Settings page to a text file.

Now head over to the company you bought your domain name from. I bought mine from LivetoDot, so will be using their control panel in the next few steps. The exact process may differ but the records we’re changing are the same with any domain name provider.

You need to find the DNS settings for you domain name, and within the DNS settings there should be an Address (A) records panel…

In the Address (A) Settings panel, past you Public IP address from the CatN control panel into the www hostname IP address text box, and the empty hostname text box if there is one. This will direct traffic to my vCluster IP for joegardiner.co.uk and www.joegardiner.co.uk.

It may take a few minutes for you Address (A) record to update so be patient, and after a while try typing your domain name, e.g. joegardiner.co.uk into your web browser to see where it takes you.

As you can see from my last screen, the domain joegardiner.co.uk is successfully directing to my main WordPress installs IP address which is then mapping the domain to my test1 Multi-site! Success!

This process can be repeated as many times as you want by simply creating a site, remembering its ID and mapping a domain name to the site ID. Then you just point your domain names Address (A) record at your vCluster IP for successful domain mapping.

If you run into any difficulties following this guide, please comment and I’ll do my best to help you!

Firstly, make sure you have an external domain and a CatN vCluster. An external domain is one you have registered seperately like a .co.uk address or a .com one. For example…

www.olliearmstrong.co.uk

…is an external domain. There are many places to register one of these domains and a Google search will reveal multiple registrars that you may use. You will probably want to choose the cheapest one that offers the best service and value for money, and for that I can recommend:

livetodot.com

Visit them and buy a domain if you don’t already own one. This will also be the registrar I will provide screenshots for.

Getting the Required Settings

You need to be able to tell the domain where to actually point to, so you need the address of your vCluster. This can be found in the settings page. So, login to the vCluster Control Panel and look on the settings page. You can click any of the images on this post to show the full size image.

What we need from this page is the Public IP Address. This address is the IP address that the domain registrar can use to point to your vCluster. So, go ahead and copy or save the Public IP and we will use it later.

Setting up DNS Records

Domain registrars use something called DNS Records to track where to point the domain to. It is the more advanced version of Nameservers. We need to set something called the A Record. But this may be different for your registrar, so I will show you how to do it using the one I use, but it should be pretty obvious where the options are for yours.

You need to log into the Control Panel of your domain registrar, there will probably be a link on the homepage of the registrar or it will have been emailed to you. Now, find your way to the settings of your registered domain. For Livetodot, you need to click My Domains and then click on the domain.

Then choose something similar to Nameservers or DNS or Advanced DNS. Here I click DNS and it brings me to this page.

On here there should be an option to set different types of records and a load of other stuff we don’t need. We are only interested in the A Record. So click on the link for ‘Address (A) Record’, and that takes us to a page with a few boxes.

On the page it will probably ask for a hostname – and as you can see, on Livetodot it has multiple hostnames. We are only interested in the first one (the blank one) and the IP Address of the first one. This is where we put in the Public IP we copied earlier. Once that’s done you can click save changes and it will update the DNS settings.

Often it can take up to 48 hours to update them, but mine was instantaneous.  When it has finished updating you will then be able to access your vCluster at this new registered domain instead of the one that we give you!

Any problems trying to do this? Leave a comment and I will try and help.

I decided to put together a list of questions to help you analyse exactly the service a cloud provider can offer you, to help your move to a cloud platform go as smoothly as possible.

1. Which languages does their platform support?

This may seem like an obvious one, but dig a little deeper. You need to know if your app will run on a providers system, and in some cases even when a platform claims to run any php application for example, certain configurations, such as database, may prevent this from being the case.

Ask your provider for specific app compatibility before you sign up, and if they are unsure ask them to install the app to test it for you.

2. What access options do they offer?

This is particularly important for developers. Every cloud host will offer you FTP access, as there are few better ways for transferring your website files to their platform, however additional access options like SSH may be important for your application and team, so it’s well worth checking this in advance, as not all cloud providers allow ssh access.

3. Where is their data centre located?

It is important to know exactly where your website will be hosted as this will effect the performance for international users. When considering location it is also important to investigate the cloud providers connectivity so any geographic factors can be balanced by high speed back haul, peering and connections to internet exchanges.

Having said this, if a cloud provider has multiple data centre locations and allows you to specify your location, or host in multiple locations, this is less of an issue.

4. Does their billing system suit the cloud platform?

Cloud hosting supports a utility model that allows billing for consumed resources to occur. This is a large benefit to using a cloud platform, as I wrote about in How do large website benefit from Cloud provisioning? and Benefits of Cloud Hosting.

If the potential provider is not offering a pay for resources billing system and is only offering packages, they are not allowing you to benefit from the utility model of a cloud platform and it may be worth looking elsewhere for a company who can fully utilise, and provide, the key benefits of a cloud platform.

5. Do they offer a backup service?

Providing backups is not a vital feature for choosing a cloud provider and of course, it depends on your requirements. However, when using applications like WordPress that store data for blog posts in a database, a hosting provider backup service can be the simplest solution for protecting your web sites content.

Plenty of hosts offer free or competitively priced backup services, so if backups are important for your project and you dont want to manage them yourself, there’s no need to pay huge amounts for the added extra.

6. What levels of support are available with a hosting package?

Support is always an important issue when choosing a web host, especially when moving from one host to another. Numerous small configuration settings that are incompatible between platforms can be a nightmare to sort out without a capable support rep to ease the process.

Having said that, it’s worth doing a bit of research into public opinion about a cloud providers support record, just to to avoid any nightmares that are all to frequently reported online. Even if you don’t think you’ll need support, it is reassuring to know a good service is available for a new, possibly unfamiliar platform, especially if it’s included in the price.

7. How easily does their platform scale?

One of the main motivations for moving to a cloud platform has to be the possible scalability. You can have a read about cloud scalability in my previous article Large web sites can benefit from Cloud provisiong. If scalability is indeed your reason for moving to cloud, you’re going to want to scale your project easily with minimal or ideally no configuration.

This is a reasonably technical question to ask a potential cloud provider but is well worth investigating to avoid continuous adjustments to your service to cope with spikes, or reduce resources to save money during quiet periods. Ideally you want a platform that scales instantly without any interaction from you or your engineers.

If scalability is not an issue for you, then perhaps a cloud provider is not applicable for your project…

8. Is their database hosting powerful enough for your app?

Web development is evolving and applications requiring databases are becoming more and more common. The availability and quality of a database is high on any developers list and should be thoroughly investigated before signing up to a cloud provider. As well as the standard database service offered, it is worth taking note of any “add on” database services.

This style of cloud custom package building is offered by the more developer oriented cloud providers and should be understood before purchasing cloud hosting.

If you can think of any more that aren’t included comment away and I’ll add the best ones!

For large websites arguably the two most important benefits are scalability and cost, and in a cloud environment they are closely linked. The nature of a cloud platform allows resources to be allocated and removed as a sites demand scales, which is reflected in the expenditure required from the business as quantities of resources are consumed. As resource use drops the hosting expenditure required follows suit, offering scalability from performance to billing.

Over provisioning

Any website considered “large” being developed and launched will already have a considerable audience in place, due to other forms of media promotion such as printed advertisements employed by the company. This present audience will often lead to high traffic and demand after the launch with a slow reduction in traffic until the traffic becomes consistent. The nature of the site will also have an impact on traffic, with a news update or forum post generating traffic spikes, and on a large site this is likely to be considerable.

The difficulty faced by system administrators planning a large company’s web site infrastructure, is providing resources required to handle these spikes and high initial traffic. The expenditure for a new hosting project is often high as servers must be acquired to give the infrastructure capacity to meet demand, and consultancy and setup costs also play a role in a high expenditure.

Problems occur when launch traffic levels decrease and a more consistent pattern of site visitors starts to emerge. Apart from content or externally influenced spikes, large capacity has been purchased and is not being fully utilised but must still be maintained to cope with spikes, resulting in an inefficient infrastructure expenditure during periods of standard traffic. For any business to be successful, ongoing wasted infrastructure expenditure should be addressed and avoided. This is where the benefits of a cloud platform are most applicable.

Cloud provisioning

A cloud platform allows users to avoid the high expenditure required to build an infrastructure from scratch by renting a portion of the platform from the provider. This reduces the initial high expenditure required and the staffing costs for providing the service. However, the greatest benefit for a large web site in the cloud is the utility computing model offered by cloud hosting providers.

The utility model allows resources to be provided as a service, and for clients to pay for only the resources they use (commonly on top of a small initial base package). This model instantly removes the issue of over provisioning, provided the cloud providers infrastructure is correctly configured and has extra capacity to meet the rise (and fall) in a sites traffic. Any resources for meeting traffic spikes are rented temporarily so as traffic decreases again the hosting expenditure reduces proportionally. The capital expenditure required for hardware, software and engineering services is massively reduced, with a smaller upfront payment required, improving a companies cash flow.

Aside from cost, performance for a sites users will be consistent with a cloud provider managing their capacity. For a company  managing their own hosting, as a site nears capacity performance will decrease until capacity is increased, incurring more costs! In a cloud system, a large web site will benefit from seamless capacity and performance increases as more nodes are added to the cloud platform requiring no engineering from the customer or extra expenditure (apart from usage). This instant capacity scaling allows a cloud platform to meet traffic demands with no negative impact on performance, improving the user experience on the website.

Finally…

Clearly a strong motivation for moving to a cloud platform for a business will be the massively reduced costs of infrastructure and management, as well as the scalable nature of the utility billing ensuring hosting expenditure is efficient for the business model. It is important for site performance to be considered as a large benefit also, a cloud platforms scalability provides consistent performance under any load.

If you’re thinking of moving to a Cloud hosting provider, have a look at the Cloud Provider Check List before making your decision!

When you sign up we create a personal account and give you the option to create a business account as well. When you first login to the CatN Control Panel you will be in the context of your personal account. If your service subscription is associated with you business account then you will need to switch to this account in oder to view your CatN services.

You can switch accounts in the Control Panel using the drop down menu in the top right hand corner, next to the logout link.