How to make an ExpressionEngine test site for module and plugin testing

If you currently are or planning to do module and/or plugin development work for ExpressionEngine you really should have a dedicated private test installation of EE that you can work with. While you could use your public installation it’s not a good idea. Do you really want to have your public blog throwing out errors or completely being wiped out because of a bug in the module or plugin you were working on?

This tutorial will walk you through step by step on how to setup a test installation. The ultimate goal being that once you follow these steps you’ll have a clean install of EE that you can test your modules or plugins with. The benefit of following this guide is that at any time you can do a complete rollback to the fresh installation in just seconds. Should you accidentally blow up your database or mangle the configuration all you’ll have to do is run a simple command line script and bingo it’s just like new again!

A few things to point out before we begin. First off, this should work fine for any *nix OS but I am using FreeBSD for my server. Second, you will need command line access to your server. IE you’ll need to use telnet, ssh, or be working locally. Third, this does need to be a clean, private install. The install you do should be completely separate from anything else including the use of MySQL databases and server directories. Fourth, I’m using my real world setup as the example in the tutorial just to help make it clearer. You should change the names and directories where appropriate to match your setup.

Step 1: Installing EE There really is no need to explain this. Just do a normal fresh install of EE. Create a new database and use a new directory structure separate from anything else. I created a new MySQL database and user account called “ee_test_site”. I installed EE in a separate folder “/home/abarber/public_html/ee_test_site” too. Just copy the EE image, system and user_guide folders into this new folder. IE “home/abarber/public_html/ee_test_site/images”.

Step 2: Configure and Setup the EE test site Just go through and setup the test site. Set all the admin configurations, build the templates, create a few sample members, create a few sample entries, etc. Basically, you want to have the site setup just how you want it to look and act every time you do a rollback.

This is the most crucial step! You need to have everything exactly as you want it. We’ll be making a backup of the entire installation and the rollback will totally wipe out everything and reset it to how it is from the backup.

If for example you forget to set template cacheing on but really do want it on. Every time you do a rollback you’ll have to go in and turn on template cacheing because the backup had it off!

So take a few extra minutes to thoroughly check every single thing. Yes even the directory contents. If there are files you do or do not want in the backup manage them now. It’ll make life much easier later.

Step 3: Create backup directory Someplace you should make a directory to hold and run the rollback from. I prefer to make a folder called “rollback” in my home directory. “/home/abarber/rollback”

Step 4: Make the MySQL backup We’re going to use mysqldump program to create the backup.

At the command prompt type: mysqldump -u ee_test_site -p[enter password] –add-drop-table –databases ee_test_site > /home/abarber/rollback/ee_test_site.sql

Step 5: Make the EE installation backup We’re just going to make a simple tar gziped file with the contents of the website folder. That means the actual EE files, images, etc. Remember what I said above? This is your last chance to make any changes to the files in the backup!

At the command prompt type: tar cvzf /home/abarber/rollback/ee_test_site.tar.gz /home/abarber/public_html/ee_test_site

Step 6: Create the rollback script I call it “rollback.sh” and place it in the “/home/abarber/backups/rollback” directory.

– copy below –

/usr/bin/sh

echo Rolling back EE Test Site blog…

echo Reloading database defaults into MySQL… mysqladmin -u ee_test_site -p[enter password] -f drop ee_test_site mysql -u ee_test_site -p[enter password] < /home/abarber/rollback_data/ee_test_site.sql

echo Reloading EE installation… rm -rf /usr/home/abarber/public_html/ee_test_site cd / tar xfz /home/abarber/rollback/ee_test_site.tar.gz

echo Resetting file and folder permissions… chmod 777 /home/abarber/public_html/ee_test_site/images/captchas chmod 777 /home/abarber/public_html/ee_test_site/images/uploads chmod 777 /home/abarber/public_html/ee_test_site/system/cache chmod 666 /home/abarber/public_html/ee_test_site/system/config.php chmod 666 /home/abarber/public_html/ee_test_site/system/config_bak.php chmod 666 /home/abarber/public_html/ee_test_site/path.php

echo Rollback finished! echo – copy above –

Note - Remember to chmod the “rollback.sh” script to give it execution permission.

Step 7: Test the rollback script Make a few changes in the control panel such as delete a few entries or delete a template or change a category name.

Now go to the rollback directory and type “./rollback.sh” at the prompt. Check the control panel again. The missing entries and changed categories should be back. If not we have a problem and need to figure out what we did wrong.

Now lets try something a bit more crazy. Just go in and start randomly deleting files until the website no longer works. Oh no! The site is ruined. Wait lets use the mighty rollback again! Sit back and watch in amazement as the backups are reloaded and your site is saved.

So what’s the point of all this you might ask? Software development is a science. When you’re working on a module or plugin it’s nice to always have a fresh clean install to do your tests. That way whenever you make changes to your software you can rollback the system and have identical test parameters. This helps to keep bugs from cropping up that are not a result of your software but the test environment being changed from a previous test.

This you may realize comes in very handy for module development since modules make changes to several database tables and probably create their own. That way you don’t get errors or bugs showing up because you have already installed 3-4 different versions of the module before. When you’re working on that module you know you have a fresh clean install every time you start testing it. It’ll make it just that much easier to debug!

I hope people find this useful. I’ll admit it’s probably not the clearest written tutorial but you should get the idea of how to set this up. I’m using it and it works great. I can screw around with the test site to my hearts content then just run the rollback script and it’s back to normal in 30 seconds.