How to duplicate magento installation

duplmagentoIn this article I explain how to create a copy of running Magento online shop . One of purposes of having duplicates  is e.g.  the need of developing or test environment. Test are very inmportant in magento. Many people do official Magento upgrades on productive environments and suffer form it.   You don’t need to do so, use always test environment first! However the copy procces of  Magento shop has following main steps

Databasepohpadmin

First, let me say say, that it is good idea to not install two Magento instances to the same database. Magento in  version 1.1.8 s has 198 database tables. Most of them are of type  InnoDB and they are  related with each other by checked foreign key constraints. That is background information. So new database for every  Magento instance save you from having headaches  and this not only because having just two magento installation i one DB leads too approx. 400 tables in one database but more to avoid possible problems or side effects with constraints and Co. (e.g. ) .  ;) . The easiest way to export the database is to use phpMyAdmin. Go to export dialog of original database, select “zipped” option, select tabbles, let other options on their defaults (See screen 1) and get zipped download. Switch to new database and  upload the downloaded  there in the import dialog. Sound as a piece of cake, but sometimes the import of the SQL files will not work. I have already seen many different exceptions bu trying. Beginning with “SQL Syntax..” and ending with “constraint violation…”.  In my opinion the purpose of problems is size of some tables and therefore of whole backup. There are few MyISAM tables that are full with (useless) log data. And the amount of this data makes problems to the import routine. Don’t export them first at time! they don’t have any constraint to other tables so you can import them on second or third turn. Alternative  you can export only the DDL-Statement of this table not the data itself. Here are tables you can  omit in first step:
tables
Don’t forget to change configured URL of origin shop to the  URLs of new shop in the table core_config_data. You can also use Search-Tool of phpMyAdmin and identify every record where old URL is used – but outside of core_config_data table  they are not so important and could be changed later in the Shop interface.

Core Sources

That is most easiest part. Just copy the source of magento to the new location, but don’t copy the following: If you use another DB for new Magento installation don’t forget to change DB setting in app/etc/local.xml file. Var directory hold any temporary content like sessions, caches and error-logs. Downloader is used by Magento connect module, before copy must do some preparations.

Magento Downloader

Warning! do not copy unchanged downloader to new location on the same server it may break your origin magento installation! Now I got your attention ;) The problem is that downloder stores serverpath in many many configuration files. And if you don’t change the serverpath  and  starts updates on  new shop copy, you will update the origin shop and not the new copy of it! The server path of origin magento shop is stored in many many files in the downloader directory, you can’t change all of them manually. But you can do it automatically. If you have SSH access to your web-space  following command will help you:

//shows all files with OLD_PATH element

find  . -type f -exec grep -q "OLD_PATH" '{}' \; -print

//Replaces OLD_PATH string in all occurrences in every file to NEW_PATH

find . -type f -print | xargs sed -i -e ’s/OLD_PATH/NEW_PATH/g’

If you have only ftp access, then you can use [Alt+F7]-search in Total Commander. Then open each file with Notepad++ and then use “Search and Replace” functionality of Notepad++ on each file. Whole replacement willtake you max. 5 minutes.
totalcommander
After replacing old path you can upload downloader to the new instance of Magento. Now everything including “Magento Connect” should work properly and independent form each othen on thow instances. The last thing my be useful   is to clear all caches in admin back-end of new instance. Good luck! ;)

Open Question

This article describes how to double the Magento instance once. The next question which i didn’t answered for me yet is how to make permanent  mirroring of data from production environment to the test installation. Maybe someone has cool ideas?

Disclaimer

Please consider that I can’t guarantee that everything described here will work in your environment as it worked for me. Please use this tutorial as incitement and adopt my methods to your own situation. Be sure that you don’t peril origin Magento installation or other data. Do regular backup befor you begin!
Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • BlinkList
  • MisterWong.DE
  • Slashdot
  • StumbleUpon
  • Technorati
  • NewsVine
  • Reddit
  • Yigg
  • HackerNews
  • LinkedIn
  • Webnews.de
  • Yahoo! Buzz

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.

Comments

Nice post. I’m a little disappointed to see it here and not on TechPHP.net. Still I hop you just post there too.

Thanks;)
Hmmm yes indeed It was not a topic tech.php before. Will see.

Thanks for this post. You cover the issue I had been having regarding the upgrade of the store. When I went through the updating process on my staging store, it disabled the existing store.

Thanks ;)

hey, thank you very much for posting this… exactly the information I have been looking for. Nice one.

As a matter of interest, I am using magento for the first time. I have sed other shops before… there is a lot of fuss at themeoment about the stability of magento etc. Waht is your take on it?

Thanks

Ana

Could you be more precisely what do you mean about stability?

There could be stability problem in early versions and there are still some bugs in Reports and also import/export functionality.

Magento requires relative much resources. So I had some performance problems on the entry-level hosting. That performance problems have lead to some stability issues as i thing.

Further stability problems could arise on upgrading Magento through Magento Connect. I had several problems there. One have to be (always) careful on update. DO BACKUPS. Don’t upgrade productive system first.

Hi shuron

I guess what I mean by stability is that the damn thing actually works. I keep reading about bugs here, bugs there. But, I have no idea how these ‘bugs’ are going to impact me.

I have one more step before I finally commit to magento, I have a working shop with about 1,000 products… it has to go up to 5,000 then I have to go through grouping the products by hand. If magento bugs out after that, it is one hell of a lot of work down the toilet.

Which version of magento is the best one to use do you think. Currently I have 1.3.0 … is it worth upgrading to 1.3.1 or should I even consider going back a version.

There seems to be so much ‘chatter’ going on that it is hard to know which way to turn. In the end the one who is going to loose is me, the client is not going to pay me twice if I have to change to another shop.

What do you recommend?

thanks

ana

Very helpful article, thanks.

Missing a final ‘ on the sed substitition. Small thing, but it tripped me up for a minute.

Simon

@mach hare

In every case you should first try your update on a test system. Current article describes how to create such a test instance.
Magento version 1.3.0 is pretty new. I still have my exercises on Magento in a version 1.1.8 – which is pretty old meanwhile. So I’m not really able to help you with the decision about 1.3.1.
Here are
release notes for 1.3.1

It seems there are not only minor bug-fixing but some greater changes also. Look carefully though the list, if you not really need that stuff may be it is OK to not upgrade yet.

On the other side keeping system up to date is never a bad thing.
However try on test instance first. ;) Testing and doing backups prevents disasters ;)

@Simon thanks!

Actually I did a fresh installation and used 3 domains, magento.com for default store (otherwise, when I changed the Unsecured URL admin collapsed) and 2 domains for the solution you are suggesting and it worked fine.Right now I’m trying to realize how to copy data stores or how to upload magento data sample into store1_en for instance.

Hi

I migrated to 1.3.1 last week. It works much more quickly (on the back end) than 1.3.0, I get the impression that 1.3.0 was a bit of a dog, hence the chatter about magento being so buggy, most of the bugs on the back end ironically appeared to be due to some poorly written CSS. Seems to be working very smoothly now. Even managed to migrate my categories over from 1.3.0 to a clean install of 1.3.1

One tip I offer to anyone starting fresh with Magento, is to use the downloader install, it means that updates can be done using Magento Connect, otherwise you have to do it by hand, which can be painful, and for me has lead to completely corrupted stores.

Happily I am at the beginning of building this store, the first using magento so other than my crisis of confidence using 1.3.0, I have tested Magento 1.3.1 dataflow, MySQL migrations, magentoconnect, language packs and payment gateways. All working completely bug free.

So in a nut shell, I recommend 1.3.1 as the best release so far of magento, and at all costs avoid 1.3.0.

Thanks for your help and support Shuron, this page has been very helpful =8~)

I’ve used the duplicate process described here, and it seemed to have worked well, but we’ve sinced discovered a couple of issues.

I’m thinking some of the code didn’t copy properly, or became corrupt, etc. I’ve recopied (just the folders recommended) but have same issue, wondering if anyone has any hints.

Here’s what we’re experiencing:

- the checkout dies when moving past the billing info field, whether logged in or not, after hitting the next either for ship to this address or ship to another address the ajax spinner appears, then goes away, but nothing else happens. We can’t move on from that point

- can’t get into magento connect. Just get a blank screen.

We’re running 1.3.0. The source site from which I duplicated it works just fine.

Any idea?

Thanks.

simon

Just to clarify, we can enter our login details for magento connect, but then are redirected to the home page of the site. If I hit the back button I get a blank page.

hmph. Just replaced all of the code with a fresh install, imported in my db, and still an issue. It’s in the db I guess.

arghh!

I forgot we need: class=”col-right side-col” and changed it about the same time.

Hey Simon, did you solve your problem?
Was it a duplication related problem?

Not related to the duplication at all.

We modified some of the html right after the duplication. It was a minor change and I’d forgotten about it. In the process we broke the right column class: “col-right side-col”, which breaks the 1-page checkout.

Not sure why the checkout would be reliant on that class, but putting it back resolved the issue.

Simon

A useful guide on Magento installation. I liked your tip about installing a test version so that not to spoiling productive environment. Should save a lot of hassle.
Thanks,

Andy

My situation is slightly different.

I have a live website (currently ver. 1.3.1) with categories, attributes, clients etc etc… that has gone through a bunch of updates and extension installs etc… now for some reason the admin is breaking and things are not working smoothly so I decided to install a new clear ver 1.3.2.1 in my local PC, and bring in only the DATA from the live website to the new local install so I can be sure that the DB is fresh, clean and working with the new version.

But I really don’t want to do everything manually from scratch…
My question: how would you go about transferring only data from the live ver 1.3.1 into local PC ver 1.3.2.1 using the fresh DB install.

Thanks!

Hmm.. I would probably do the following:
1) copy actual dbschema with msqldump or as described above to the local database.
2) Then copy Magneto files to the local maschine. Then I would override them with fresh Magento 1.3.2.1 data. Leaving your installed extensions and correct app/etc/ files (of course adopted to you local db setting)
3) Go to the local web page of the magento and do upgrade/installation steps.

This should preserve all the data and setting. At least these, which are stored in the database but upgrading ith schema to the 1.3.2.1 version.

Do this not on production System first :)
I can’t give you any warranty of success :)
Good luck. Tell us your experience.

Thank you for your interest and help!

Here is what I did and the result with a problem:

- Export live website’s DB structure and data excluding tables ‘logo_url’ ‘log_url_info’ ‘log_visitor’ and ‘log_visitor_info’
- Exported only the structure of the above mentioned tables
- Installed 1.3.2.1 on my local PC
- Created a new DB ‘my_newDB’ on my local PC
- Imported the DB backup (from the live website to the PC webstie) including the structure for the four tables above
- Changed the ‘secure’ and ‘unsecure’ path URLs in table ‘core_config_data’ (to ‘http://localhost/magento/’)
- Edited app/etc/local.xml on my local PC to point to the new DB ‘my_newDB’
- All other files are from the clean install other than the second website ‘/intl’ folder and some other custom folders
- Cleared var/cache and var/sessions

RESULT:

- Frontend seems to work well with all categories, products, websites, store views etc on local PC – Now version 1.3.2.1
- PROBLEM: Admin login page loads without any CSS or images and most importantly, when I login I get a ‘Loop Redirection’ error (see attached image).

This is the problem I was having with the live version after trying to upgrade to version 1.3.2.1 from 1.3.1 which is why I decided to make a clean install (besides to be able to have a production server).
In the live server, in order to fix this I had to restore a previous install of the FILES only and it would log me in correctly but if I did ANY extension installation or import tablerates.csv the admin would break again.

I’m guessing this is a bug in version 1.3.2.1 and I don’t know how to go on from here (I tried clearing the cookies and setting 644 permission on ‘js/index.php’ as suggested in some forum threads and still the same problem. I lost 3 days on this! and the problem is still there!!!!!!!)

A detail: My Magento is setup like this:

WEBSITE 1
- Spanish
- English

WEBSITE 2
- Spanish
- English

Any help would be GREATLY appreciated!!!
Thanks!

David

Have you adapted your .htaccess file? Check it.
It local machine an windows system?

Please give Image link. Or further information about redirection. I guess there is Redirection configuration problem.

Have you also changed your “web/unsecure/base_url” & Co in the core_config_data table?

After the duplication (which worked well otherwise), I can’t seem to get to magento connect – I enter my login & password, then get forward to a “whoops” page. If I back up, I’ve got a blank page. Anyone seen that?

Thank you

Simon

I have the same problem with magento connect. It does not seem to like a hand install rather than a magento connect install. I hope there is a work aroud for this, any suggestion very welcome, as migrating a store from a dev server to a production server and then not being able to upgrade using connect will become most upsetting in the future…. help Shuron … only you can save us =8¬)

I remember that I had this problem too in the 1.1.8 or some of above versions. I don’t know the solution or can’t remember.
I would check cache first.

However if you want to update your Magento test Copy you can overwrite all the magento installation files. As described on Magento wiki

  1. Backup your database
  2. Backup all the code you modified yourself, and don’t forget to keep the original installation archive
  3. Take care of saving the media directory that contains all the uploaded product/category images
  4. Create a backup copy of app/etc/local.xml file
  5. Download a new installation archive or run SVN update if you checked it out from the Magento repository
  6. Extract and upload all the files it contains to your server
  7. Delete var/cache and var/session directories
  8. Point your browser to any Magento page
  9. Database upgrades should happen automatically
  10. .You are done!


THERE IS NO WARRANY. SO PLEASE DON’T DO IT IN YOUR PRODUCTION ENVIRONMENT OR DATABESE FIRST

After this procedure your Magento Connect will not show any installed features. On one of my installation it helped to upgrade with “magento-core/Mage_All_Latest”. It restored all the information, o course in latest upgraded version.

Hi Shuron,

any answer please to the blank Magento connect page please? I am really stuck on this… I have created life instance, put data in there and now realized that I am unable to install any new plug-ins which is quite late. Please help, thanks.

Which version? I never had blanc Magento connect Page, so i don’t really know how it comes to and how to fix it. I had my problems with Magento connect but never blanc page.

Have you done new installation or have you copied your installation as described here??

Hi!

I’m having an issue when trying to import the db:
“#1452 – Cannot add or update a child row: a foreign key constraint fails (`magento_test/#sql-775c_a15f`, CONSTRAINT `FK_CATALOG_CATEGORY_EMTITY_INT_STORE` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCADE)”.
I tried all what you guys wrote, but I still have this issue… does anyone have an idea?
thanks,
Erwan

Thanks for this article. I followed your suggestion about changing paths in the downloader files using search and replace. However when I log into Magento Connect Manager, none of the extensions are listed now. What have I done wrong?

Hi, Erw.
Try to put something like this before your SQL

SET @OLD_FOREIGN_KEY_CHECKS=@@
FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=’NO_AUTO_VALUE_ON_ZERO’

this switches Foreign contraint check off.

And that ant the End.
SET SQL_MODE=IFNULL(@OLD_SQL_MODE,”)
2.SET FOREIGN_KEY_CHECKS=IFNULL(@OLD_FOREIGN_KEY_CHECKS,0)

It makes it on again.

But do not on in Production, can lead to problems

Hi, Vicky. Which Magento version?
I had this issue ones but I don’t know anymore what i did to fix it. Just can’t remember:(

Anyway I have new experiences how to copy Magento instances so my plan is to rewrite this article. I’ll try to find time for it in next days, I promise.

Hi Shuron, I’m currently on 1.2.1.2.

Thanks for your help!
I tried to put the SQL snipet Shuron, but it didn’t work!
Then I found this and it worked fine!!
SET FOREIGN_KEY_CHECKS=0;
// SQL
SET FOREIGN_KEY_CHECKS=1;

Btw, great blog!
Thanks,
Erwan

I would love to see your new article about how to copy Magento. Will you be able to publish it soon?

Thank you, shuron.

It’s a little disheartening for me, as a new Magento user to see that there’s not an automated process for building a test or staging or development platform. One would think this is a pretty key function of an e-commerce platform (and especially one that’s open-source!)

But that’s just me whining. Thank you for saving me a great deal of work. And I hope I can return the favor by automating it in a script, and post it somewhere.

Tom

Well, your process worked beautifully. Thanks.

However… it seems that there are many hundreds (maybe thousands) of references to fully qualified domain names (FQDN) in the data itself. And they are in any number of different forms — “http://mySite.com”, “http://mysite.com”, “http://www.mysite.com” and then the ones for https, and ones with or without the trailing slash.

So … I am getting up to speed with an organization that has little technical experience, so am wondering — shouldn’t it be the case that all URLs should be relative references? Is there some macro that pulls on the correct secure or unsecure URL from the core data table?

Any ideas about where I can look (source code or otherwise) to help me understand how things should have been done would be greatly appreciated!

Tom

Hi Vicky, did you solve your issue ? I’m having the same problem and didn’t find the solution yet …

I encountered the magento connect error that people have been seeing and I found that the easiest thing for me to do was remove the pear.ini file inside downloader/pearlib

For some reason hand editing that file corrupts the ini file.
The system seems to work without it and extensions install to the new installation directory instead of constantly trying to use the old directories.

Thank you Lee. Indeet i’ve noticed it too. I think, i should write new version of thins article, with new experiences.

Just sharing our thoughts on Magento Installation requirements in localhost

_http_://magento.novosoftwares.com/magento-installation/magento-installation-requirements/

Kind Regards,

Team Novo

Pierre – No, I’ve not solved my issue yet.

Nice information and good comments for magento installation, Thank you for sharing.

Problem with the connection problems in the downloader result from the simple string exchange in pear.ini. The configuration is stored in a serialized array. If the old path and the new path don’t have the same length, the serialized structure breaks, as the length of the strings is also encoded in the structure.

Therefore the above mentioned command only works if the old path and the new path have exactly the same length.

If this is not the case you have to read in the configuration inside php unserialize the structure, change the configuration and rewrite the file with the new serialized string.

That makes sense!
Thank you Gerhard for that hint!

Leave a comment

(required)

(required)