How to Duplicate/Mirror a Store on the Same Server/Account

[zcnb]

Introduction

In my attempt to devise a store update methodology, with minimal disruption to the live store, I came to the conclusion that a mandatory part (of that methodology) would be to duplicate the Zen Cart top level directory (usually 'store' or 'shop') – in the same server, same account.

I quickly realized that this store duplication requires not only a simple single step recursive directory copy but rather needs to be accompanied by database duplication and some configuration files fixups.

Realizing that I am not the first to need something like this, I searched for a step-by-step tutorial on duplicating/mirroring a store within the same server, same account. I found three excellent articles that seemed to be very close to what I was looking for (and certainly relevant):

I have installed Zen Cart to a directory. How do I rename or move that directory?

Is it possible to create/build a complete Zen-Cart setup on a test server and then install on a live server?

How can I do a database-backup with phpMyAdmin?

Still, since I knew that this process was going to be repeated many times in the course of the store's lifetime, I needed a HowTo that is somewhat more detailed, to be used as a checklist or at least as a recipe.

In addition, I needed more specific description of how to perform certain steps in a shared hosting account, which is understandably restricted. For example, generally stating “duplicate the databaes using phpMyAdmin” simply doesn't work in a typical shared hosting account. This step must be performed using other tools, such as cPanel.

Thus, I created this mini HowTo (or Checklist). You are welcome to comment, correct, add, improve, etc. - until we have an article that is good enough for posting in Zen Cart's tutorials section.

Before going ahead with the actual checklist, please note the following clarification: This checklist is for duplicating a store on the same server, same account - and is specific to a Linux based shared hosting account with SSH/SFTP access.

For simplicy sake, it is assumed that Zen Cart's top level directory (under ~/public_html or htdocs) original name is 'store'.

The actual steps will follow in the next message in this thread.

[zcnb]

OK - here are the steps, in HTML format, packed into a ZIP file - only 2.4KB in size.

Enjoy!
Daniel

[paulmd]

Hello, I'm new here ... just joined today because I wanted to ask how to do more or less this very thing!

I have had a single ZC store for a while, and I'm starting a new operation for different products aimed at different customers, so I thought the easiest way would be to duplicate the existing store and edit the copy to make a similar new one, ending up with two completely independent stores.

BUT, I'm using UK2 for everything and they only allow a single MySql database per domain, so I'm struggling.

Any ideas?

Thanks

[zcnb]

Any ideas?

It's not a Zen Cart issue but rather a web host one: You have to purchase a hosting package that allows you more than one MySQL database.

[misty]

Also possible to install zencart on your own home computer
using WAMPP or XAMP

[brenda1970]

ZCNB thanks for your great HOWTO. I tried it and it works well as advertised

However, as advertised it's not very practical for me. Why? because of 2 problems:

Problem 1: if I duplicate `store` to `test` I can test everything except for THE MOST IMPORTANT THING: PAYMENTS! I can't test PAYPAL because for PAYPAL to work I need to enter into it the exact full URL of the store. So, if I configure PAYPAL for www.zencart.com/store, I can't test www.zencart.com/test.

Do you have a solution for that?

Problem 1: Your HOWTO is practical only if site is DOWN FOR MAINTENANCE from the moment you START to COPY the DATABASE until FINISHED TESTING. The reason? if you intend to make `test` the live shop after all CHANGES and TESTING, you must not allow any customer transaction, otherwise the live `test` will be MISSING transactions that were done during the time you did CHANGES and TESTING. Changes and testing can take HOURS. Nobody can accept online store going DOWN for HOURS....

Do you have a solution for that?

Other than that, KUDOS for sharing this with us.

[kuroi]

Neither of these "problems" are difficult to overcome. Those of us who do this professionally face them every time we do an upgrade.

For the first, create a sandbox account at Paypal and use that for testing. Switch to the live address only when you have completed you main testing. You want then to pass a live transaction just to be sure that you have accurately entered to live Paypal account details.

For the second, take a backup of your database and load it into the new site - ensuring that you drop the old tables. Do your testing and when you're satisfied that everything is OK and ready to go live, take a fresh backup and use the same method to load the up-to-date information.

[brenda1970]

KUROI, I have a problem with both of your solutions:

Solution 1: I already have sandbox account at PAYPAL and I already used it for testing. I even tested with the LIVE PAYPAL account. The problem is ONCE I switch to the other URL (`test` instead of `store`), I need to change only that tiny detail at PAYPAL but even though it's tiny I still need to test it. I can't test it while the store is live. It must be down.

Solution 2: If I take a backup of my live database and load it into the test site - ensuring that I drop the old tables - I LOOSE ALL THE NEW CHANGES that I added to the new site, which was the reason for the test site to begin with. Do you see the CHICKEN and THE EGG situation here?

[brenda1970]

Update: What I am basically saying is that there must be a way to test THE REAL THING, not a copy, not a backup.

Also ideally it would be better to test the real thing WITHOUT having the store go DOWN FOR MAINTENANCE because some tests could take HOURS.

Since there are so many OPERATIONAL ZEN CART stores out there I can't believe there isn't alreay a solution BUILT-IN ZEN CART for that.

[kuroi]

It sounds as thoughb you are setting three fundamentally incompatible objectives:

1. hours of testing on a live system
2. no customer access until testing is complete
3. no interruption to customer access

You hve to release one of these constraints, or there cannot be a solution.

We typically allow some interruption of customer access to the site, but minimise it and ensure that it happens at a time when visitor numbers are likely to be at their lowest.

This is the normal approach. As a Paypal customer you will no doubt receive occasional emails from them giving you notice that they will be unable unable to process transactions for (typically) an hour, several days ahead when their systems will be taken offline for maintenance.

We normally do a ton of testing on a system that is as close to the live system as we can get, including using live customer and order data, though we do run a script to change the customer email addresses, just as a precaution.

By the time we come to go live we are very confident that everything will work, so we're only checking that it has, which is quite a short process. For that period we screen the site about to go live from customers by putting up an html file explaining that the site is being upgraded and will be back within the next few minutes and inviting them to be the first to see the new site.

Our approach to data conversion varies from project-to-project reflecting factors specific to the data being transferred or upgraded for each project and in particular the types of changes that may be made to the database. The easy ones are those where the customer and order data isn't changing, so we only need to move more recent copies of those tables across and there's no conversion.

If the shape of the customer or order tables needs custom amendments then we may choose to import the new tables and apply SQL scripts to change their shape (very quick) or in more complex cases have an external (usually spreadsheet-based) process for reshaping the data and then upload the results. In the later case we don't just test the outcome, but also the process.

Since the approach taken varies according to the specifics of the project, it's difficult to see how this could be built in to Zen Cart.