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

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.

Sorry for the delay. Copying the checklist that I prepared, while preserving formatting, proved to be incredibly tedious and time consuming...

I tried posting the HowTo in an attached PDF file but it is 115KB and exceeds the 48KB attachment limit.

I then tried attaching it as DOC file, but it is 82KB, still exceeds the 19.5 KB limit.

I then tried attaching it as HTML file (only 15KB) but then discovered that HTML files are not accepted as attachments.

So, I will try to find another way to post the actual steps.

Stay tuned...

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

Enjoy!
Daniel

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

paulmd:

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.

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

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

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 https://www.zencart.com/store, I can't test https://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.

:cheers:

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.

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? :frusty:

:cheers:

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.

:cheers:

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 accessYou 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.

Brenda, thanks for your comments. If you noticed, I actually cautioned in my HowTo's footnotes about it being not the entire methodology for store update with minimal disruption to the live store. This is just the skeleton of part of that methodology.

kuroi is right about setting three fundamentally incompatible objectives. In Zen Cart's current state, there is no way to update a store and test it before being available to the customer while always being available to the customer.

What I can suggest to you is the following 3 Phase approach (using this HowTo to implement parts of Phase 1 and 3):

1. Duplicate store while "frozen"
2. Apply changes to duplicate store - and test them thoroughly!
3. Re-Apply changes to original store
   The last step requires that you document precisely each step in phase 2, so that the changes can be re-applied with minimal chance for errors. Also, it requires that during that time, site visitors don't see Zen Cart's "Down for Maintenance" page but rather your own index.html (or index.php) that is independent of the Zen Cart system.

HTH,
Daniel

zcnb:

kuroi is right about setting three fundamentally incompatible objectives. In Zen Cart's current state, there is no way to update a store and test it before being available to the customer while always being available to the customer.Though I don't see this as a Zen Cart restriction, more a fundamental feature of the current space time continuum paradigm that we currently inhabit. When we learn to bend, fold, rewind or otherwise adapt time more conveniently to our needs, this restriction will disappear, and not just in Zen Cart.
:unsure:

Not sure if this was addressed so I will make mention of it.

Any 'test' dir. should always be Password protected. This will provent SE bots from indexing it and unauthorized access of any kind. Using Apache Authentication or a stand-alone password script would suffice.

kuroi:

Though I don't see this as a Zen Cart restriction, more a fundamental feature of the current space time continuum paradigm that we currently inhabit. When we learn to bend, fold, rewind or otherwise adapt time more conveniently to our needs, this restriction will disappear, and not just in Zen Cart.
:unsure:
kuroi, I totally agree with you.

However, there may be partial solutions to the "update" problem. The reason I put "update" in double quotes is because we don't necessarily have to look at "update" as an "all or nothing" proposition. Some updates are simpler than others, requiring basic and very short testing, perhaps without any down time at all.

For example, adding a new downloadable product to an online store that carries only downloadable products:

The process of adding a downloadable product is simple. But it is manual and thus error prone. If I don't want disappointed customers who expect a new product to be available for download immediately after payment, I must positively verify that the newly added download works 100%. That is, test it before being seen by a prospective customer.

Currently Zen Cart supports only complete site shutdown, so making certain products visible only to the store admin is not possible. It would be nice if Zen Cart supported such "partial down for maintenance". That's what I meant by "Zen Cart's current state".

Unless this feature is already available in Zen Cart and I am not aware of it? :unsure:

Regards,
Daniel

Currently Zen Cart supports only complete site shutdown, so making certain products visible only to the store admin is not possible. It would be nice if Zen Cart supported such "partial down for maintenance". That's what I meant by "Zen Cart's current state".
Are you not familiar with how to 'hide' a Category or Product?

On the applicable page within 'Categories/Products' you see this on the right-hand side:

Quantity - Status - Sort << under Status is usually a Green icon

Click on the Green icon which turns it to Red because the Category or Product is now disabled/hidden. This allows you to work on it without it being seen by others.

Website Rob:

Any 'test' dir. should always be Password protected. This will provent SE bots from indexing it and unauthorized access of any kind. Using Apache Authentication or a stand-alone password script would suffice.
Indeed, I overlooked this point and thank you for pointing this out.

I don't know whether the fact that www.<yourdomain>.com always redirects (301) to www.<yourdomain>.com/store will do the trick, i.e. hiding www.<yourdomain>.com/teststore from the SE bots.

Can you elaborate on your ideas of Apache Authentication or a stand-alone password script?

Many free Password scripts are available and can found using your favourite SE.

My preference though is to use Apache Authentication as most Hosting Control Panels provide this feature; called Web Protect in cPanel and similar wording in other panels.

Website Rob:

Are you not familiar with how to 'hide' a Category or Product?
Yes, I am familiar with this feature and indeed it allows me (as site/store admin) to work on it without it being seen by others.

However, it doesn't allow me to go through an actual simulation of a live purchase as a test customer.

The only way currently known to me to simulate a live purchase as a test customer, without others seeing it, is by "Down for Maintenance" for all except for my own IP address.

Not sure what the hang-up is with the 'live' purchase testing?

For testing a new downloadable product you need only to use 'Check/Money Order' to complete the sale and test the download. If it works that way it should work with any other payment method as well.