Magento – Configuring Multiple Store Views
A conceptual non-technical overview of this article first appears in the Conetix Blog here – https://conetix.com.au/blog/magento-implementing-multiple-store-views/
Domain Names – Setup
The technical setup to demonstrate our 3 language store example described in the previous Blog article (see above link) requires that we have a number of sub-domains configured on a local workstation first and then configured in the web server so that the web server can route the domain name requested to the appropriate virtual web site configuration. Basically when we enter a domain name in our browser, the Browser application will lookup the name locally first and if not defined go to a DNS server to get the IP. When we configure it locally we speed the process up significantly and have a lot of power to perform testing prior to production release of our web site.
Lets configure a domain called test-mg-conf.com on our workstation, if you are lucky enough to have a Linux workstation then you can configure the required entries in the /etc/hosts file, on windows you need to edit c:/windows/system32/drivers/etc/hosts
I added the following entries to my hosts file, the IP is the server I have defined on my test network, so you need to know the IP address of your web server:
Apache Web Server Configuration
In our configuration, the web server configuration file is located at /etc/httpd/conf/httpd.conf (we have used a default install of Apache Web Server) we suggest that you include a line at the bottom of the httpd.conf file to Include additional configuration files. Here is what we enabled and/or added to our httpd.conf file:
First we turned on name virtual hosting directive in the httpd.conf file so that it would recognize the additional configuration files (removing the has uncomments the line):
Then we add an additional line to the END of the httpd.conf file:
Next we needed to create the vhosts.d directory as it is not present by default, we created it using the bash shell command:
Inside the /etc/httpd/vhosts.d directory, we created a text file for each domain/sub-domain we are going to host. The individual virtual host file contains the path to the web application (in this case Magento), the domain name entry and two environment variables. The file format is very specific, using the domain names declared above the files we create are:
-rw-r–r– 1 root root 309 May 26 14:46 vhost-http-admin.test-mg-config.com.conf
-rw-r–r– 1 root root 304 May 26 15:28 vhost-http-us.test-mg-config.com.conf
-rw-r–r– 1 root root 304 May 26 15:29 vhost-http-en.test-mg-config.com.conf
-rw-r–r– 1 root root 304 May 26 15:29 vhost-http-nz.test-mg-config.com.conf
-rw-r–r– 1 root root 314 May 26 14:43 vhost-http-test-mg-config.com.conf
-rw-r–r– 1 root root 335 May 26 14:42 vhost-http-www.test-mg-config.com.conf
You will notice a file called vhost-http-admin.test-mg-conf.com.conf, this is defined as the main administration entry point for this Magento instance during setup, if you have a lot of sub-domains or your business structure has many diversified arms then this might be an ideal way to manage the stores. You can add other sites to the configuration and as the business changes over the years the “Admin” site as the main entry point for administration will still be the way to administer the Magento stores.
Magento Environment Variables
The key to invoking a store view is to tell Magento via an environment variable, fortunately this can be done very easily inside a virtual host file using the “MAGE_RUN_CODE” and “MAGE_RUN_TYPE” variables. The contents of vhost-http-en.test-mg-conf.com.conf are as follows:
SetEnv MAGE_RUN_CODE encode
SetEnv MAGE_RUN_TYPE store
The files for the NZ and US sites are the same but the ServerName changes accordingly as does the MAGE_RUN_CODE from “en” code to “nz” code and “us” code accordingly. You can use anything as the CODE… even “fred”, “barney” and “wilma”, but try to be logical and consistent in your naming scheme as these need to be defined in Magento later.
The virtual host file for www.test-mg-conf.com file is a little different to the others, in the blog we mentioned redirecting to a site without the “www” sub-domain portion. The file contains the following to redirect to the preferred entry point:
# www.test-mg-config.com <VirtualHost *:80> ServerAdmin DocumentRoot /var/www/magento <Directory /var/www/magento> AllowOverride All </Directory> ServerName www.test-mg-conf.com Options +FollowSymLinks RewriteEngine on RewriteRule (.*) http://test-mg-conf.com/ [R=301,L] </VirtualHost>
While the virtual host file for test-mg-conf.com has the following configured:
# test-mg-config.com # Main entry point # <VirtualHost *:80> ServerAdmin DocumentRoot /var/www/magento <Directory /var/www/magento> AllowOverride All </Directory> ServerName test-mg-conf.com SetEnv MAGE_RUN_CODE mainentry SetEnv MAGE_RUN_TYPE store </VirtualHost>
With the virtual host files in place the web server httpd daemon will need a “reload” to re-read the configuration files. You may even need to restart it. The command to run is:
service httpd reload
If any errors are display then you will need to follow up on them, if the errors relate to domain name issues then this is not serious as we are implementing changes with no production DNS changes yet implemented.
Once the DNS entries are created and in effect, Magento can be configured to support multiple stores. Magento provides a configuration page to do this under Configuration -> Manage Stores.
To configure the stores, you can create a new admin store using the “Create Store” button, then create the store views, finally add in a new website and create the store and store view for the main entry. The best way to configure the store view name is to use the URL as the name rather than “usa store”. The “Store” name is used to tie the view to a catalog, the “WebSite” becomes a parent place holder to tie it all together.
Magento provides a great deal of flexibility here so there are numerous other ways to code this other than the way shown, but logically a website with multiple views should be configured this way.
This image is the completed store configuration, we named the store view using the relevant sub-domain name and as shown, the associated store code is configured to the view.
Per store configuration is essential for our example to work, we need to configure the applicable currencies that are relevant to each store and the countries that are applicable. We also need to configure the base URL for each store and the a range of other settings like page titles, home pages in the CMS to name a few.
The important first step is to go into the Configuration -> System tab and select the store from the “Current Configuration Scope”, all changes will now apply to this store.
In this example, we selected the “US” store. Next we need to change the base URL and to do this we need to uncheck the “Use Website” checkbox, this makes the configuration local to the store.
Configuring Currency Support
Despite having stores configured in different currencies, nothing seams to happen until you set a currency rate. Under the “SYSTEM” tab there is a tool to configure the Currency rates. See System -> Manage Currency -> Rates
You will need to select “Import” each time you wish to set a new currency rate, suggested frequency is weekly or you could be costing yourself money.
The testing process requires the DNS name of each store and the IP address of the web server to be added to the hosts file of the workstation. When a request is made in the browser for one of the store names, it will be re-directed to the web server. The web server will automatically match the host name to the httpd virtual host configuration and render the store. If configured correctly, the currency should display appropriately and products enabled for that store should be viewable.
Where to from here?
Supporting multiple stores is easy to configure and should not present any long term maintenance issues. The next logical step is to implement custom templates for each store, these can be configured into a package and seasonal variations can be implemented as needed. Part 1 of this series explains templated and what is required to customize the look and feel of your Magento store.
To enable the site to go live, your DNS servers will need “A” records added for each sub-domain. Once configured it may take up to 72 hours to propagate through the Internet, but in most cases it will take effect quickly if the entries are new and hence not cached anywhere yet.
If you are going to get serious about getting your hands dirty inside Magento then you need to read two guides.
The first is the “Magento Users Guide” available from the Magento Commerce Web Site. The guide explains various aspects of setting up your store.
The second is the “Magento Designers Guide”. The design guide explains the concepts of theme construction reasonably well, but you may need to look at a few template files to see how it is all rendered in a working system!