However the copy procces of  Magento shop has following main steps

• duplication of database schema
• duplication of core sources
• duplication of downloader sources

Database

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:

• log_url
• log_url_info
• log_visitor
• log_visitor_info

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:

• downloader dir
• any content of dirs inside of var but .htacces file.
• media/tmp dir

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:

Update: The described way to handle downloader sometimes causes problems by doing upgrade. Especially pear.ini shold be treatet carefully. Check also a workaround proposed by Enno Julian.

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

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!

Be Sociable, Share!

• 

It differs from other “Related posts”-plug-ins, which are based on automatic content analysis. What ever the content analysis algorithms are and how ever the configuration options used,  resulting related post lists are mostly just a bullsh$%.  That’s is understandably, then these plug-ins have same problem like search engines and other content analysis tools . In the reality of our age (It is 2009 A.D.) – computers cannnot understand any semantic of human written articles.

So what is the solution for an good Related Post Plugin? Of cause simple to do it manually!

You say it much work?  No!, with Micrkid’s Related posts Plugin, which  provides very comfortable AJAX driven interface, it becomes fun! It’s becomes so easy and quick as providing tags. You decide what is related to the actual post by creating meaningful related post list.  Try it out!

Be Sociable, Share!

• 

DIGG Effect

Eric Enge has wrote very good article about succes on digg. Some of details he presents my be not true at the moment, because DIGG evolves and changes internal algorithms. However some facts are really interesting.

As he says, stories that where able to reach the digg home page receive an average of 129 links, and more than 10,000 visitors in an hour. Some stories have brought even more than 1,000 links and 100,000 visitors. This shows how important DIGG is and why there are so many legend and so much attention from SEOs. So it has happened many times that stories which have made the home page, have brought the server of the story site can’t handle the traffic load. This is well known phenomena is known as the “Digg Effect”.

Of cause the quality of this kind of visitors is “bad”. Don’t expect that they will by your products and click Ads. Do not expect big growth in comments, DIGG users often comment regarding a site on digg itself instead of on the dugg website. Digg users comes to see only that what they would inspect in the story description on DIGG itself.

I don’t wanna be a Digger

So after reading several articles about how to success on DIGG i realized that it would take very very very much time. So as every body know time is money, but moreover time is life! In my opinion the truly success on DIGG starting from null will deserve much to much time in comparison to the revenue.
Personally I don’t have much time and will not spend it to fullish site like DIGG, voting for silly topics of US tanagers So at the moment and I think also in the future will not spend much time on DIGG or other communities.

I mean isn’t it better to spend time to create wonderful content? It would give you personal much more satisfaction than any DIGG effect. But however good content have in any case good chance to achieve one DIGG effect after another!
So by by DIGG, may others vote for my content, I will not spend my life for Digging

P.S. It doesn’t mean i will not continue submitting my articles to it

Be Sociable, Share!

•