Okay this is a bad habit

I'm a bit of a fly-by-the-seat-of-the-pants gal. :blush:

I tend to do my work in the wee hours :blink: since everyone is asleep and I can focus better. My time is limited so I don't, ah, do it correctly.

In other words, I don't tend to do backups and I work on my live shop. :lookaroun

Sorry, but I do. So, for those of you that play by the rules, you do what? You have a sandbox shop/database which is a dup of your live shop/database and you what? Try it there and then go back and do the whole darned install again? So it takes double the time?

I was just gonna go do my usual and I came to that warning I always ignore and decided to consider doing this correctly. You'll be happy to know I just did my backups. :blush:

I know that other people have different approaches, but here's how we do it at Kuroi ...

Firstly we use the "Backup MySQL Database" mod. Whenever we need a copy database, we can just copy it from the admin/backup folder on the live site to the same folder on the test site and restore it. It's just so easy, and takes literally seconds.

Then we manage the code that we are changing by keeping separate all the scripts that we have changed (or are changing). We do this by storing them in dedicated folders on our development machines already in the folder structure that reflects Zen Cart's over-ride system. Then we have our FTP program set up with two connections one to the test site and one to the live site, with both pointing to the same folder with the segregated files on our development machines.

We make any changes needed on the small number of files held on our development machines, downloading more down from the test site if we need to. When we want to see them in action, we upload them to the test machine and test them in a browser. When we're happy with them, we switch the connection to the live site and upload them to there instead. Easy.

I can't remember the last time I needed to rebuild a test site from scratch. We do this only for completely new developments where we want a clean start. If we make a mistake during development we can either delete the over-ride file on which we're working from the test site and start again without the need to recreate it form scratch, or, if it's one of the files not yet covered by the over-ride system, we can pull a copy of the unchanged file down from the live site.

This segregation of files has the additional benefit that it is easy to zip them up and store them for re-use later, or for submission to this site as mods.

We use Dreamweaver most of the time to achieve this. But we also use FileZilla in this way, especially when we have a large amount to be uploaded. It's free and it works extremely well.

Very nicely explained. I am feeling the risk of danger - some of my installs have gone badly - so I am going to go ahead and so something like this. I don't have Dreamweaver or anything like that.
Ellen

sobebabies:

Sorry, but I do. So, for those of you that play by the rules, you do what? You have a sandbox shop/database which is a dup of your live shop/database and you what? Try it there and then go back and do the whole darned install again? So it takes double the time?

I use a test site which is a duplicate of the live site. Any changes are made on the test site first and all the normal checks are made. Once I'm happy that the changes won't break the live site I back everything up and then do the changes on the live site. I keep a written log of all changes that are made to the live site, what was changed and when. I also split test all changes before they are fully adopted, 50% of customers see the changes, 50% see the original. I do this so I can measure what effect the changes will have on conversion rate. Split testing normally runs for about two weeks and then the changes are either adopted or dropped.

Regards,
Christian.