Creating a test site
This is a long article, as lots of people starting out in WordPress find that many articles have ‘one liners’ that assume a level of knowledge they simply don’t possess.
So for instance saying “then copy your database to your hard drive” just produces an “uh? – what database, where is it , how do I access it and how on earth do I copy that”
So make a cup of coffee, and settle down for a tutorial !
The actual amount of work to set up a test site would take a reasonable wordpress person less than an hour, a newbie maybe 2 hours (but you can do it in stages quite easily), and the regular (maybe monthly) process is less than ½ hour, and probably much faster when you get into it. That’ll get you a test site, regular backups and prove that your backups are working all in regular process.
1. Why do I need a test site?
If you are not convinced that you need a test/development/backup site, then read my reasoning here
OK so let’s get started
2. Is this the best or only way?
This method is certainly not the only way, and may not even be the best way, but it works, and lets you understand and get used to the various elements that make up WordPress.
The downside is that you do need to get the hang of a couple of applications, and learn a quite small amount about WordPress structure. But chances are that you’d need this knowledge with any other method.
Parts of the backup and restore process may be different if you use products such as backup buddy, but you can still use these products to backup and substitute their steps in place of some steps below to restore to your test site, thus proving that these methods also work
3. Understanding WordPress structure
You website is made up of two elements, the files and the database.
The files contain WordPress itself, your themes, plugins, functions css and any media (eg pictures). The database contains all your content – pages, posts, categories, pretty well all of your settings, and lots of info about your site.
So to make a test copy of wordpress we need to copy both the files and the database.
The files are held in your website directory, which in structure looks like you own pc’s directory, with folders, sub-folders and files.
To access this area, you’ll need an “FTP client” – see below if you don’t know what one of these is.
The database is generally held elsewhere (depends on your host provider), and to access this you’ll need access to a programme called “phpmyadmin” again see below.
4. Using an FTP Client
As stated above to access your files, you’ll need an FTP client. Some host providers do with within their administration area, check with your host provider if in doubt.
Otherwise you’ll need to load a program onto your PC. Several are available, but one of the most popular is called “Filezilla”.
To learn how to download this programme and use it on your PC, the following video will help
http://www.youtube.com/watch?v=Wtqq1Mn1ltA
There are lots of other tutorials out there – just google “filezilla tutorial video”
Other FTP programmes are also available, just google “FTP client”
To get access to your web files, you’ll need three pieces of information:
- Host
- Username
- Password
Note: the FTP username and password are entirely separate from your wordpress login/wp-admin/admin details.
Your host provider will usually list this in your administration area, so just look around for FTP, and if in doubt, contact your host provider.
5. File structure
Once you have FTP access to your site, you’ll need to access the “root” (or start/top-level directory). This can be called many names such as “web” or “public”, but once you’re in the right directory, you’ll see a set of directories and files that start much like this – you may have more or less directories, and some different file names and lots more files, this is just the start of the list. You’ll definitely be in the right place when you see “wp-content” as a directory.
5.1 Wp-content
If you click into wp-content folder, you’ll see that this folder contains more folders. Amongst these will be:
a ‘themes’ folder – which contains all your available themes
a ‘plugins’ folder – which contains all your available plugins
an ‘uploads’ folder – which contains all you uploaded media/images.
You’ll also see some other folders such as “upgrade” and “languages” that you don’t need to worry about.
5.2 Wp-config
Within the top level folder is one key file called “wp-config.php” This folder contains all the key set-up information for your WordPress installation, including you database links and passwords. You may need to look at this file later to find out your database access details. For the moment just remember that this file exists.
Whilst there are other files specific to your installation, these two parts (wp-content folder and the wp-config file) are the ones you’ll need to concern yourself with.
6. Database Structure
Ok, so if the file area contains WordPress and a couple of areas that are specific to your installation, the database contains much of the info about your WordPress installation, all your posts and pages, and much other content.
To access the database you’ll need two things :
Phpmyadmin – See below for how to get phmyadmin.
Hostname, username and password – if you don’t know these, they are contained in your wp-config file. Using FTP above you can copy the wp-config file we discussed above to your PC, and using notepad or equivalent open it up.
You’ll find some lines that look like:
7. PHPmyadmin
You do not need to download any programs, you’ll access this program via your host, but how you access it varies.
Some host providers have an access area as part of their administration area, others you simply type in your website and phpmyadmin eg www.mysite.com/phpmyadmin
Once you are in you’ll see a screen looking like this
On the left hand side, the item above the information schema (in the example above _blog_www_mysite_com) is your WordPress database. It may be called many things depending on how it was set up.
Click this item and your database will open up
You’ll see a number of tables which will include (you may also have others)
As said above, you may have others – some plugins create tables.
8. Getting Started
Ok, so now you know what programmes we need to use, and some background on why we need database and files, we can start.
9. Where to create your test site.
In essence there are three options here
- In a new domain
- On your pc
- In a subdomain of your existing domain
A new domain will cost money, so unless you can’t/don’t want to use one of the other options, then I’d suggest you ignore this option.
Creating a test site on your pc is a real alternate. If you want to go that route, you’ll need to install a set of programmes that will include MySQL and php. Collectively these are known as Wamp for a windows PC or Mamp for a Mac. Wamp stands for “Windows, Apache, MySQL, and PHP” and Mamp the same but with Mac instead of Windows. If you google these terms, you’ll find the software and can download it. Google say “wamp videos” and you’ll find lots of videos on how to do this. This works perfectly well in almost all cases, and I would not want to put anyone off going down this route.
I however use a sub-domain of my site. I like this option as it means:
- that I am testing over the internet, so can catch any performance issues
- that I can get informed of upgrades needed for the test site for wordpress/plugins and themes, and upgrade these in the same way as I do for live
Most (maybe all) host providers let you have sub-domains. A sub-domain is a separate area that is referenced by adding it at the front of your domain address. So if your main domain is mysite.com then you would use either “mysite.com” or “www.mysite.com” to access these. If you create a sub-domain of say “test” then you would use “test.mysite.com” as the URL to access this site.
If you access your hosting area, you should find an option to create sub-domains. How to do this varies with host provider, so there is no set way to do this.
10. Summary of steps
Once created, you can then start to create your test site
What we’ll be doing is :
- Installing wordpress
- Copying across themes, plugins and uploads
- Copying across the database
- Changing the URL’s in the database to point to the new site
- Discouraging search engines form indexing the site
11. Install WordPress
Once you have created your site, you’ll need to install wordpress.
If your hosting provider gives you one click WordPress, install this on the sub-domain. This will create a new separate database (for some host providers it may just be that you’ll need to set up a new database).
If you have to manually install, then do whatever you did for the live site, but in you sub-domain, including setting up a new database.
If you are not allowed more than one Mysql database, you can use a different table prefix. See http://wordpress.tv/2009/02/24/run-multiple-wordpress-installations-from-a-single-mysql-database/ for more details
Once wordpress is installed, if you don’t know what database this links to, then look in WP-config file in your new installation (see 5. above for how to do this) to get the details.
Once created you’ll have a base WordPress install.
12. Copying across themes and plugins and uploads
Conveniently the wp-content folder ( see 5. above) contains all your themes, plugins and uploads, so if you copy this whole folder across to your test site, then you’ve captured all this.
You’ll use FTP to do this.
I do this via my PC, so that I have this saved locally as well as on the net. That way if your host provider goes bankrupt, you’ve still got all your files.
Alternately you can re-install themes and plugins from source, and then just copy the uploads folder between the two sites. This will ensure you have fresh copies of your plugins and themes.
Neither is a better way in my view, so take your choice.
13. Copy the Data
So now you have a testing domain with all the files and folders that you live site has, but you need to copy the data.
So do a phpmyadmin backup of your live site database to your PC – this is good practice to do each week/month in any case, and after any upgrade or serious alteration/addition to your site.
To do this, use phpmyadmin to access your live site database (see section 7 for how to do this).
Next on the left hand side you’ll see two databases, the first is your database and can be called a variety of things depending on how you host sets up the databases but the second will be called ‘information_schema’
so you may see
blog_www.mysite.com
Information schema
Click the first, and your database will be shown as a series of tables, as shown in 7 above
You’ll see an option to export, and if you click this you’ll be presented with options.
Now you can do a quick export, just click go without selecting “save on server..” or “overwrite files”, and a copy of the database will be downloaded to your PC. But this is not the recommended method as on restores it can add data rather than replace it.
Therefore I prefer to do a custom export to allow me to zip the files and improve restoration.
So click custom.
Normally you can just export all the databases as a single entity. However if you have a particularly large database, you may not be able to import in one go , so you can copy a table or group of tables at a time. However go for all as your default , as the test restore you’re doing after this stage will prove that this is all ok.
In the Output section, select a zip format if you wish to – this will speed upload which will be noticeable on larger databases. It can also allow you to overcome some file upload size limits that your host provider may set.
The in object creation options click the “drop table/view/procedure/function statement” On a restore this will delete the existing tables before restoring the new ones, ensuring a clean recovery.
Then click go, and the file will be saved to your PC. I have created a folder called “website backups” where I store these.
14. Restore the data
Having copied, we can now restore the data in our new test site. In essence we’ll just overwrite the test database with the live site’s data and then do a few simple changes.
If live and test are in the same database, then you cannot simply restore. So if both sites share a database but have different table pre-fixes (say “test” as a prefix), then a different approach is needed. Once you have saved a copy to your PC to ensure you are not reliant on your host provider, then in turn select each table. Once selected, click operations, and you’ll see the option to copy table to Amend the table name in the second line to your test database name (eg. change the live-wp-links to test-wp-links) and select the “drop table” option. This will create copy the live table to the test table. Repeat for all the tables.
Otherwise if you have different databases using phpmyadmin go into your Test database. Access the tables as before and this time click import. Browse to where you stored the files, select the backup and click go. The database should restore.
15. Change the site references
Now once restored, the test database with have the urls of your live site in the Wp-options table
If you don’t change these then as soon as you access your test site and click almost anything, you’ll be re-directed to your live site, so it is key that you change this.
In phpmyadmin for your test site, you’ll see a SQL button (third button along at the top of the page)
Click this and in the resultant box enter the following command
UPDATE wp_options SET option_value = ‘http://testing.mysite.com’ WHERE option_name IN (‘siteurl’, ‘home’)
Where testing is your subdomain and mysite your site
16. Changing image and other URL’s
Changing the references in wp-option that you just did will get the site pointing correctly, but all the references for media will still be to the live site.
So in your test site you need to change this.
There are several plugins that let you do this, but I like the velvet blues plugin – just search within plugins for it.
This gives you a tool where you can easily change all the urls in one easy move. Change the url from the live one eg http://www.mysite.com to the test one eg http://testing.mysite.com.
Do this for the options page content, excerpt, links, attachments, custom fields but not GUIDs.
17. Take out the search engines
Finally in dashboard>settings>reading change the search engine visibility to discourage search engines from indexing your test site.
GREAT now you have a backup and testing site !
18. Keeping you test site software updated
We’ll discuss performing regular backup and restores of the files and database in the next section, but you can (and should) use your test site to check out any WordPress core, theme and plugin upgrades. Do these first in your test site, and you can ensure that you are confident that they’ll work in live. So if a plugin upgrade is needed, do this in test first as an upgrade, rather than do it in live and copy across the plugin file.
19. Regular Backup and restore
You should regularly backup both your database and your upload files. I do this monthly, and before any significant changes to my live environment (such as WordPress upgrades). If your site is busy, you may want to take more frequent copies – it really depends on how much work you’d lose if you lost WordPress entirely. You don’t have to test restore every backup, but if doing monthlies, I suggest that you do – that’ll give you confidence that it all worked !
So my monthly procedure is as follows :
1. Go into ftp client and download my wp-content/uploads folder to my PC, and then copy this to the test site. (I use the procedures in 18 above to update my themes and plugins, but if you don’t and these have changed, you should also copy and restore any folders that have changed)
2. Go into phpmyadmin and export the live database using custom, zipping the file, and adding a drop table statement, saving the file in my website backups folder that I created (section 13 above). Go into phpmyadmin for the test database and restore the file (section 14 above0
3. Change the urls for the database (section 15 above)
4. Use velvet blues to change the urls for all the areas except guids (section 16 above)
5. Change the test database to discourage search engines (section 17 above). this parameter is held in the database, so each time you do a test restore it is overwritten, so needs resetting for the test database
So you test site now mirrors your live site, so any changes can be done here first.
So can you can test upgrades to themes, plugins and wordpress without affecting live site, add new plugins and play with them and alter themes without affecting live site.
You can also add css, alter functions, layouts and anything to do with your WordPress site first in the test area, and only commit to live once you are happy with the changes.
But alongside this, if you regularly backup you live site AND YOU SHOULD, you can do test restores to the test site. This means you can have confidence that your backups work, so stop the heart-thumping when that critical restores looks like it’s hanging.
This simple methodology should mean that you now upgrade with confidence, and can play with your site more boldly, doing everything in testing first, and only committing to live once you have satisfied yourself that it works !
