Last Updated on December 3, 2019 by Christopher G Mendla
We had a client who wants some database changes and associated programming. He sells fairly big ticket items but isn’t doing a lot of volume at this point. On the other hand, he really could not afford to be down for any length of time.
We decided to purchase another domain and shared hosting account. If the stuff hits the fan with his primary host, we should be able to switch the dns pointers for his main domain name and reload the latest data from the daily backups he is supposed to be doing (that is another story for a later time kids…)
So, we purchased a domain name. No big deal. The next step was to get an economy hosting package from Westhost.com We’ve had a lot of luck with their hosting and especially their support.
The steps to get things set up on the new host were
- Do an FTP download of the oscommerce code since it is heavily customized.
- Set up PHP in the new hosting panel
- PUT A robots.txt file in the root of the new hosting. You do NOT want the search engines to see duplicate content.
- Go into Cpanel for the old host and download the databases. (Note we downloaded everything from the SQL backup, not the oscommerce database backup)
- The old site was set up with a subdomain. I had to re-create this on the new site.
- I uploaded all of the oscommerce code to the appropriate folders
- I then used phpmyadmin to import the sql database.
- Now things started to get a little hairy. There are a couple of config.php files where the sql connect data is stored in oscommerce. The problem was that on the old site, a user we created would work. On the new site, we had to connect as root. I’m not happy about that but it was the only way to get it to work. Connecting via Putty and ssh confirmed that root was the only user that would connect.
- I made sure that the admin folder AND the store was behind an ID and password. We do NOT want people looking at this site. it is only for development at this point.
- I had to go into the php.ini file in etc and set global variables on.
- Once things were running I got a zend optimizer error. The folks at westhost went way above and beyond in trying to find a solution. It turned out that there we had to find all of the php.ini files and set them to the right version of zend. We were still getting an error.
- The thing that finally wrapped it up was that I installed ecellerator (It think that is the right spelling). That seemed to resolve all the issues with zend.
Now, we have a fully working store and admin section where we can try out code. The robots.txt should prevent dupe content issues. Also, the password protection should keep the spiders out and also prevent customers from purchasing from the dummy store.
Now, the disaster recovery plan is this
- We need to keep a current copy of the database and catalog. This means that we need to run the backup tool in oscommerce and also should be backing up AND downloading the sql database from the old site. Just to repeat, backing up is not enough, you need to be religious in downloading the backups to a local machine.
- In the event of a failure, we would (1) remove the robots.txt from the alternate host, (2) Upload the database backups (3) Point the DNS for the main domain from the old host to the alternate host. (4) Say a LOT of prayers or sacrifice many small animals at midnight.
The moral here is that, had the hosting company crashed, we would have been down for at least a week or more. Having a development site that is set up as an emergency host is probably worth the effort for a lot of small oscommerce sites.