marramgrass

References

• Overview: How Multiple Websites & Stores Work
• MultiStore and Multiple Domains problem – /app/Mage.php was not found
• How To Setup Multiple Magento Stores
• Magento for Designers: Multi-Store Functionality

Notes

• This assumes a standard LAMP setup. In our case, Ubuntu 10.04 LTS, Apache 2, MySQL 5 and PHP 5.3.
• It’s necessary to create some symlinks on the filesystem, so you’ll need access to do that. You don’t really want to be trying to run Magento
  on a shared host anyway, so this shouldn’t be a problem.
• The stores are on different domains, although the principles are the same if it’s a subdomain, subfolder or other configuration.

Magento is powerful and flexible, but not terribly well documented, so figuring out the best way to accomplish something can take some digging
and some experimentation. I needed to set up two stores to run off the same Magento installation as two catalogues (one a subset of the other)
from the same retailer.

There are two broad approaches:

• A single VirtualHost with aliases for the various domains, with logic added to the root index.php to decide which store to load.
• A VirtualHost for each domain, linked to one core Magento installation.

I took the multiple VirtualHosts approach, as it seemed a little more logical to me (a matter of taste, really). It has the advantage of each
domain having its own .htaccess, which might be handy if you’re doing other things alongside Magento.

When running multiple stores from one Magento instance, they all share the same back office and catalogue. Once you set up a second website,
store or view then anywhere they need to differentiate the option appears to use the default config or to apply a site- store- or view-specific
setting. This means that themes and extensions for the various stores all live together.

A side note: websites, stores and views

You’ll need to decide whether your new store is a whole new website or a new store of the same website. Broadly
speaking, from the point of view of what the customer sees:

• Websites are separate entities
• Stores are distinct but share customer accounts and shopping carts
• Views may be the same store in a different language or layout

Although that’s pretty configurable. Websites can be set to share customer accounts, for example. And, again, they’ll all share the same admin and
catalogue.

In this case, we went for two distinct websites.

The method

1. Create a new root category for your new website. You can put a full category tree under it and add products to the categories.

2. In the control panel, go to System > Manage Shops and create a new website, then shop for that website and view for that shop. Take note of the
   code you assign to the website – you’ll need it later. Assign your newly-created root category to the new store.

3. Create a new VirtualHost for the new website. Note that the Magento files will need to be accessible to PHP from this VirtualHost,
   so pay attention to any restrictions on your server.

4. In the new VirtualHost block, you need to set two environmental variables:
   
   SetEnv MAGE_RUN_CODE "your_new_website_code"

SetEnv MAGE_RUN_TYPE "website"
   
   If doing this in the VirtualHost is a problem, your server configuration may allow you to do it in the .htaccess file below.

5. Copy index.php from the document root of the existing site to the document root of the new site. Find and modify the following variables to point
   to the files in the Magento installation:
   • $compilerConfig
   • $mageFilename

6. Copy .htaccess from the existing document root to that of the new site. Check it for any hostname-specific rules that have been added, and
   modify them as necessary.

7. Create symlinks of the following folders in the existing site’s document root to the same locations in the new site’s document root:
   • app
   • errors
   • includes
   • js
   • lib
   • media
   • skin
   • var

   For example, ln -s /path/to/existing/document/root/app /path/to/new/document/root/app.

8. In the control panel, go to System > Configuration > Web, select hte new website from the dropdown in the top-left corner, uncheck
   Use Default by the Unsecure and Secure Base URLs, then correct the URLs set to those of your new website.

9. Reindex everything.

10. Optionally set the theme for the new site under System > Configuration > Design.

11. Job done.

If, after doing this, the home page of the new website is showing a default Magento 404, then check that the code for the new website
is set exactly the same in the control panel and in the server environment variable. A typo in the control panel setting lost me 45 minutes.
That was frustrating.

Also note that as we’ve edited a core file or two (index.php and maybe .htaccess), keep an eye on them if you upgrade your Magento instance.

If the title of this post doesn’t mean anything to you, you’re pretty safe to skip it.

Like many others, I’ve been using Subversion for source code management and version control. I have mostly been happy, but over the weekend I’d had enough of some of the foibles by which Subversion shows its age. After playing about with it for a while, I decided to move to Mercurial.

Distributed VCS is all the rage right now. All the cool kids seem to be using Git, but Mercurial appealed to me more. There are other options, as well.

Migrating from Subversion to Mercurial should be easy. Mercurial includes the hg convert extension, which takes your Subversion repository and converts it to Mercurial while maintaining all your branches and tags as well — if you can get it to work. I tried for an afternoon and couldn’t get it to fire. (I was working with a remote repository. You may have better luck working locally.)

I decided to try hgsvn, which I installed from MacPorts as py25-hgsvn. It aims to allow you to use Mercurial to manage a repository and then push and pull from a Subversion repository. I didn’t take it that far, though if you try it please let me know how it works. I was mainly interested in making the switch completely, which I managed reasonably well.

Before we go through the process, here’s one thing to bear in mind: if your Subversion repository contains tags and branches, these will appear in your new mercurial repository as directories containing a bunch more source code, with the whole directory structure making up one big working copy. This makes sense if you think about it, as branching and tagging in Subversion is nothing more than making copies of your files and promising yourself (and your collaborators) that you’ll treat them a certain way.

Because of this, I found that this will work best if you select a certain branch (maybe your trunk, maybe not) and convert it only. So this process will work best for you if you’re working on your trunk, or only want to bring over one branch with its revision history.

With that in mind, here’s what you do. (I’m on Mac OS X, but this should follow for most *nix-type systems. On Windows, it may well be a bit different.)

Set up the conversion using, for example

$ hgimportsvn http://yourrepo.com/trunk/

In this example, the new Mercurial repository will be in a folder called ‘trunk’, so you may want to rename it by

$ mv trunk MyProject

Move into that directory and grab the contents of the repository with

$ cd MyProject
$ hgpullsvn

At this point, you will be able to run this as a Mercurial repository without any trouble. However, there is a little cleanup we can do to make everything neater.

First, because hgsvn is designed to allow Mercurial and Subversion to coexist, but that’s not what we want, you can get rid of the .svn cruft and the file that tells Mercurial to ignore that cruft, using

$ find . -name .svn | xargs rm -frv
$ find . -name .hgignore | xargs rm -frv

(By the by, if you’re planning to pipe find into rm, especially with the -f switch, it’s best to run the find first to check you’re only going to delete what you want to, and only then run it with the pipe in place. Man, am I glad I checked it first!)

Second, if you run

$ hg branches

You’ll see that your main branch is currently called ‘trunk’ instead of ‘default’ — which is what a new mercurial repository would have. You can correct this by running

$ hg branch default

By now, you’ll have made a few changes to the contents of your working copy, so commit them with

$ hg commit -m “Cleaning up after migration to Mercurial”

And that’s that. It’s easy when you know how.

(I found useful clarification on a little of the cleanup from samhart.com.)