- T-SQL functions to convert Strings to Tables
- Batch Process to rename multiple files using Windows DOS
- SSIS Multiple Lookups in one
- mysqldump: Got error: 2049: Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled) when trying to connect
- AHK Countdown Tooltip
Last Updated on Friday, 15 February 2013
More for others than for myself, but this article is for those who do not have development/test environments of their Joomla website.
I have been doing this for years and still come across clients who have the one version of their website. They experiment on their customer-facing website and in most cases, they are paying for a hosting package which would allow them to have several copies of their website.
In my job, it is important that we have a development environment for the website/application developers, a quality assurance environment for our clients to test these, and then a live/production environment that will be released for public use. This allows for a good test bed and stable releases, error and hopefully risk-free.
Here's one method I used based on the services available to my client:
- Copy all files of your main website to another folder.
- Setup an FTP account to the new folder created in the previous step.
- Copy the database of your main site to another database.
- Setup a database user account that can access the new database created in the previous step.
- Modify the configuration.php file in the root of the TEST site to reflect the usernames/passwords created in the previous steps.
- $sitename - I would suffix this with "TEST" so as to quickly distinguish this from your main website.
- $db, $user and $password - these are the database and login credentials.
- $ftp_user and $ftp_pass are the ftp credentials.
- $log_path and $tmp_path should also be updated.
- $robots - set this to 'noindex, nofollow' (we don't want google to index our test site).
- Disable new user registration in the TEST version of the site (User Manager > Options)
Do NOT create TEST as a subfolder of LIVE (this will complicate backups to no end).
Do NOT overwrite/remove the TEST configuration.php file.
Do NOT enable users access till the last step.
My Standard Setup
- LIVE - the public facing version of your site
- QA - for clients who need to test enhancements that you've developed. (referred to with the customers as TEST).
- BACKUP - an exact copy of LIVE (preferably from a daily refresh - and inaccessible to non-administrator users)
- DEV1 - a copy of LIVE and for developers to play with.
- DEV2 - a copy of LIVE for another team of developers to play with.
Refresh TEST using only web-based tools
- Web-Based File Manager (eg. cPanel File Manager)
- Web-Based Database Manager (eg. phpMyAdmin)
- Compress/backup LIVE files to ZIP file.
- Export LIVE database to SQL file. (Export > Custom > Save output to file)
- Except for configuration.php, delete all files in TEST folder.
- Drop all tables in TEST database.
- Copy all files from LIVE to TEST (Do not overwrite configuration.php !!!)
- Copy database from LIVE to TEST (Operations > Copy to... > untick "Create Database")
- Done! and you have all the necessary backups for a restore point.
Don't forget the .htaccess file for Search-Engine Friendly (SEF) website addresses as a lot of web-based file managers cannot see hidden files!
» Compress your LIVE files into a ZIP and extract to TEST to copy over any hidden files. You only have to do this on the first refresh. For further refreshes, you can simply select all files in LIVE (except for configuration.php) and copy these to TEST using the web-based file manager.
Above & Beyond
Creating subdomains allows your developers to simply change the http://www.mysite.com to your development environments, eg. http://dev1.mysite.com, http://dev2.mysite.com, http://qa1.mysite.com. When working with a FTP client this also helps as all you are usually changing is a folder name in order to quickly point to LIVE or TEST. Confirm with each person aware of this setup and involved in the development, that they understand the risk of "accidental" changes and the concept of working on TEST before applying changes to LIVE (-> Schedule a daily backup of LIVE - NO EXCUSES!).