How to set up multiple Magento 2 websites / stores with Nginx?

September 21, 2016  |  1 Comments  |  by Raj (MagePsycho)  |  Magento 2, Nginx

Magento is so flexible that one instance of it can have multiple websites/stores with different languages, domain names, categories etc.
You can configure the websites, stores, and store views in the Magento Admin. You use the MAGE_RUN_TYPE and MAGE_RUN_CODE variables in entry point scripts(index.php), .htaccess or Nginx configuration files(depending upon the web server you are using) to start the Magento application using these websites or store views.


The code (i.e. MAGE_RUN_CODE and MAGE_RUN_TYPE) checks two environmental variables


and use them to start Magento with the right website/store which can be defined in Manage Stores section in Admin.

The value of MAGE_RUN_TYPE determines if MAGE_RUN_CODE should be considered the code of a website or a store.

  • If MAGE_RUN_TYPE = ‘website’ is used, MAGE_RUN_CODE should be the code of the website and default store for this website will be loaded in the frontend.
  • If MAGE_RUN_TYPE = ‘store’ is used, MAGE_RUN_CODE should be the code of any store view and that particular store will be loaded in the frontend.

Nginx Configuration Settings

As mentioned before, there are many ways to configure the MAGE_RUN_TYPE and MAGE_RUN_CODE environment variables. But setting environment variables using web servers would be the best way as it doesn’t involve any core code edits.
Since I am using MEMP Stack, I will be sharing on how to configure Nginx for multi-website/store environment.

Case 1: One Website, Multiple Store Views

For example, we have

  • (store code: mystore_en)
  • (store code: mystore_de)
  • (store code: mystore_es)

Step 1. Edit your Nginx virtual host configuration file as

File: Usually located under /etc/nginx/sites-available/ or /usr/local/etc/nginx/sites-available/ or other depending upon the OS type.

map $http_host $MAGE_RUN_CODE { mystore_en; mystore_de; mystore_es;
server {
    listen 80;
    set $MAGE_ROOT /path/to/your/magento2;
    set $MAGE_MODE default;
    include /path/to/your/magento2/nginx.conf.sample;

Here you can see how the Nginx map block is used to set MAGE_RUN_CODE as per host. And server_name directive includes all the available domains.

Step 2. Send MAGE_RUN_CODE and MAGE_RUN_TYPE variables to the php-fpm server
File: include path from above, example: path/to/your/magento2/nginx.conf.sample

# PHP entry point for main application
location ~ (index|get|static|report|404|503)\.php$ {
    try_files $uri =404;
    fastcgi_pass   fastcgi_backend;
    fastcgi_buffers 1024 4k;

    fastcgi_param  PHP_FLAG  "session.auto_start=off \n suhosin.session.cryptua=off";
    fastcgi_param  PHP_VALUE "memory_limit=768M \n max_execution_time=600";
    fastcgi_read_timeout 600s;
    fastcgi_connect_timeout 600s;
    #add here - start
    fastcgi_param  MAGE_RUN_TYPE store;
    fastcgi_param  MAGE_RUN_CODE $MAGE_RUN_CODE;

    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;

Here Nginx fastcgi_param‘s MAGE_RUN_TYPE & MAGE_RUN_CODE will create the enviroment varilables for PHP, so that the script can access the values via


Case 2: Multiple Website, Multiple Store views

For example, we have

  • (website code: mystore1)
    • (store code: mystore1_en)
    • (store code: mystore1_de)
    • (store code: mystore1_es)
  • (website code: mystore2)
    • (store code: mystore2_en)
    • (store code: mystore2_de)
    • (store code: mystore2_es)

In order to configure for this case, you can use the similar settings as for Case 1. The only difference will be the store code values for Nginx map block and domain names for server_name directive.


If you are unsure about which value(website or store) should you use for MAGE_RUN_TYPE, go for the store value and use the corresponding store code for MAGE_RUN_CODE

Hope this helps you in configuring the Nginx for multi-store/website. In the case of any issues with the multi-store setup, please do comment below.

Sandbox script for quick testing in Magento2

September 14, 2016  |  No Comments  |  by Raj (MagePsycho)  |  Linux, Mac OS-X, Magento 2

What’s your approach for quick & dirty testing in Magento2?

  • Creating a test module with a controller and executing it from browser to see the output?
  • Creating a Console module and executing via CLI?

Obviously, above two approaches takes time.

Rather I would create a simple script (a single file) and put it somewhere in /[path-to-magento2]/pub/sandbox.php

 * @author Raj KB<>
 * @website
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
require __DIR__ . '/../app/bootstrap.php';
$bootstrap = \Magento\Framework\App\Bootstrap::create(BP, $_SERVER);
$obj = $bootstrap->getObjectManager();
$state = $obj->get('Magento\Framework\App\State');

// Your quick and dirty code goes here...
$quote = $obj->get('Magento\Checkout\Model\Session')->getQuote()->load(1);

Now you can easily test by pointing to URL

But wait, this won’t work in the case when you are using Nginx + PHP-FPM server.
The reason you can explore from the Nginx conf file: [path/to/magento2]/nginx.conf.sample

# PHP entry point for main application
location ~ (index|get|static|report|404|503)\.php$ {
    try_files $uri =404;
    fastcgi_pass   fastcgi_backend;
    fastcgi_buffers 1024 4k;

    fastcgi_param  PHP_FLAG  "session.auto_start=off \n suhosin.session.cryptua=off";
    fastcgi_param  PHP_VALUE "memory_limit=768M \n max_execution_time=600";
    fastcgi_read_timeout 600s;
    fastcgi_connect_timeout 600s;

    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include        fastcgi_params;

As you can see only PHP files: index.php, get.php, static.php, report.php, 404.php & 503.php files are parsed by the PHP-FPM.

In order to include your sandbox.php in the whitelist, just edit the line of Nginx conf file:

location ~ (index|get|static|report|404|503)\.php$ {


location ~ (index|get|static|report|404|503|sandbox)\.php$ {

And don’t forget to reload or restart your Nginx server depending upon your Operating System.

sudo service nginx reload
sudo service nginx restart


sudo nginx -s reload
sudo nginx -s stop && sudo nginx

What’s your approach for quick & dirty testing in Magento2? Please do comment below.

Magento 2: How the quantity_and_stock_status attribute value is populated in product object?

August 6, 2016  |  No Comments  |  by Raj (MagePsycho)  |  Magento 2

Well, a new product attribute that you may notice in Magento2 is quantity_and_stock_status.

SELECT * FROM eav_attribute WHERE attribute_code = 'quantity_and_stock_status';

Query Result:
quantity_and_stock_status attribute info

If you load a product object as:

$product = $this->_productRepository->getById($productId);

You will see the value of quantity_and_stock_status as an array of is_in_stock and qty.
You must be thinking from where the heck it came from? These values are supposed to be in the stock item object.

Let’s dig it out.
Try to load any product:

$product = $this->_productRepository->getById($productId);

Inspect the value of following using X-Debug


You will notice that the value of quantity_and_stock_status is 1 initially (i.e. the default value).
Once the product is loaded, afterLoad() method of attribute’s backend_model: Magento\Catalog\Model\Product\Attribute\Backend\Stock is executed.

# Class: \Magento\Catalog\Model\Product\Attribute\Backend\Stock
 * Set inventory data to custom attribute
 * @param Product $object
 * @return $this
public function afterLoad($object)
    $stockItem = $this->stockRegistry->getStockItem($object->getId(), $object->getStore()->getWebsiteId());
        ['is_in_stock' => $stockItem->getIsInStock(), 'qty' => $stockItem->getQty()]
    return parent::afterLoad($object);

From above you can see clearly that is_in_stock and qty value are being fed by the $stockItem object.
And hence scalar value becomes an array.
Now it’s no more mystery, right? Cool.

Now let’s comment on – “Why has Magento2 team introduced quantity_and_stock_status attribute?”

Configure your Bash Shell for Magento 2 CLI Commands

June 29, 2016  |  No Comments  |  by Raj (MagePsycho)  |  Mac OS-X, Magento 2

One of the major improvement in Magento 2 is the introduction of CLI commands based on Symfony Console Component.

CLI commands can perform multiple tasks. Some of them are:

  • Installing Magento (and related tasks such as creating or updating the database schema, creating the deployment configuration, and so on)
  • Clearing the cache
  • Managing indexes, including reindexing
  • Creating translation dictionaries and translation packages
  • Generating non-existent classes such as factories and interceptors for plug-ins, generating the dependency injection configuration for the object manager.
  • Deploying static view files
  • Creating CSS from LESS
  • Providing “plug in” capability for third party developers

To invoke the CLI command:

php /path/to/your/magento2/bin/magento group:[subject:]action

To list all the available console commands:

php /path/to/your/magento2/bin/magento --list

which will output similar to:
Magento2 CLI Commands

In this article, we will discuss on how to configure bash shell for Magento 2 CLI to increase your productivity.

Bash Configuration Tips for Magento 2 Console

1. Install Bash Completion

Refer to our previous article – Install Bash Completion for Mac OS-X, which shows how to enable the completion feature for shell commands just by pressing [TAB]

2. Create useful bash aliases

Alias for bin/magento: mage2
Edit your ~/.bash_profile and add the following code:

alias mage2 = "./bin/magento"

Now instead of using:

php bin/magento [options]

You can simply use:

mage2 [options]

(Must be run from root of Magento2 path)

Alias for enabling module: mage2-module-enable
In order to enable module in Magento2, you have to run following series of command:

php bin/magento module:enable Vendor1_Module1 VendorN_ModuleN --clear-static-content
php bin/magento setup:upgrade

To simplify this process, you can simply add the alias as:

mage2ModuleEnable() {
	mage2 module:enable "$@" --clear-static-content && mage2 setup:upgrade
alias mage2-module-enable="mage2ModuleEnable"

Now you can simply enable the module(s) by running:

mage2-module-enable Vendor1_Module1 Vendor2_Module2

These are just a few examples. You can add similarly if needed.

Isn’t that a smarter way of executing CLI command?
Note: Don’t forget to reload the bash after adding aliases:

source ~/.bash_profile

3. Install Magento2 Bash Completion

Some of the cool dudes in Magento community are really doing amazing work. One of such work is magento2-bash-completion plugin.

In order to install this magento2-bash-completion, proceed as follow.
Download plugin to bash-completion hook folder

curl -o /usr/local/etc/bash_completion.d/magento2-bash-completion

Reload the shell

source /usr/local/etc/bash_completion.d/magento2-bash-completion

Time for Magic
Just write few letters of command and press [TAB], you will see as per the following gif:
Magento2 Bash Completion
(Image Source:

Do you have any useful tips on executing Magento2 CLI commands? Please do share in the comment.
(We will keep on updating this post with more cool bash tips for Magento 2 CLI, so keep your eye on it.)

Install & Configure Varnish Cache for Magento 2

May 19, 2016  |  13 Comments  |  by Raj (MagePsycho)  |  Linux, Magento 2

The performance of a website is always the key factor for the higher conversion rate. Fortunately, Magento 2 (both CE & EE) comes by default with the support for FPC (Full Page Caching), Varnish & Redis to make your store fly.
In this tutorial we will be discussing brief info about Varnish, it’s installation and configuration so bear with me.


Magento 2 supports Varnish versions 3.0.5 or later or any Varnish 4.x version.
And Magento team strongly recommends using Varnish in production as the built-in full-page caching (to either the file system or database) is much slower than Varnish, and Varnish is designed to accelerate HTTP traffic.

Varnish Cache is an open source web application accelerator (also referred to as an HTTP accelerator or caching HTTP reverse proxy). Varnish stores (or caches) files or fragments of files in memory; this enables Varnish to reduce the response time and network bandwidth consumption on future, equivalent requests. Unlike web servers like Apache and Nginx, Varnish was designed for use exclusively with the HTTP protocol.


We have carried out the Varnish installation in the following enviroment:

  • Ubuntu – 14.04 LTS
  • Nginx – 1.9.6
  • MySQL – 5.6.28
  • PHP – 5.6.20 (but PHP 7 is recommended)
  • Magento EE – 2.0.5


Run the following series of command as a root user (sudo su).

apt-get install apt-transport-https
curl | apt-key add -
echo "deb trusty varnish-4.1" \
     >> /etc/apt/sources.list.d/varnish-cache.list
apt-get update
apt-get install varnish

If everything goes right you should be able to see the Varnish version with:

varnishd -V


Once Varnish is installed, you need to configure it and your web server(Nginx in our case).

Configure your Web Server(Nginx)

Configure your web server to listen on a port (say: 8080) other than the default port 80 because Varnish responds directly to incoming HTTP requests, not the web server.
For this add the ‘listen’ directive in ‘server’ block as:

server {
    listen 8080 default_server;

to default nginx configuration file (generally located at /path/to/nginx/sites-enabled/default)

Configure Varnish Configuration

1. Modify Varnish System Configuration

vim /etc/default/varnish

And edit the file to have similar code:


# Maximum number of open files (for ulimit -n)

# Maximum locked memory size (for ulimit -l)
# Used for locking the shared memory log in memory.  If you increase log size,
# you need to increase this number as well

DAEMON_OPTS="-a :80 \
             -T localhost:6082 \
             -p http_resp_hdr_len=64000 \
             -f /etc/varnish/default.vcl \
             -S /etc/varnish/secret \
             -s malloc,256m"

2. Modify default.vcl
Make a backup of default one.

cp /etc/varnish/default.vcl /etc/varnish/default.vcl.bak
vim /etc/varnish/default.vcl

And edit the lines under ‘backend default’:

# Default backend definition. Set this to point to your content server.
backend default {
.host = "";
.port = "8080";


  • .host – fully qualified host name or IP address and listen port of the Varnish backend or origin server; that is, the server providing the content Varnish will accelerate. Typically, this is your web server.
  • .port – the web server’s listen port (8080 in this example)

Note:This is the minimal configuration. You need to use the configuration which you get from Magento 2’s Varnish Export (Ref – #3).

3. Configure Magento to use Varnish
Instead of manually editing default.vcl, Magneto 2 comes up with an export option for it.
First enable the Full Page Cache to use Varnish (Go to Admin > Stores > Configuration > Advanced > System > Full Page Cache), you will see as:
Save the settings and hit the Export VCL button (Varnish 3 or 4 as per your Varnish Version).
And use this default.vcl to replace the file in /etc/varnish/default.vcl

Finally, restart the Varnish & Nginx

service nginx restart
service varnish restart


I assume You have followed all the above steps (Installation & Configuration). Now lets check if Varnish cache server is taking into account for HTTP response or not.

Check if Varnish is listening to port 80
Run the following command:

netstat -tulpn | grep varnishd


Verify contents in var/cache, var/page_cache folder is not regenerated
Since FPC is configured to serve the content from Varnish, once cleared, cache folders (var/cache, var/page_cache) should always be empty .

Verify the HTTP response headers
Load your Magento 2 Frontend and check the response from browser console, you will see similar as shown in the below screenshot:

Or you can simply use CLI as:

curl -I

And You will see some similar Varnish keywords.

Voila, you’re done. Let your store fly!
Please do comment or contact us if you have any issues regarding Varnish + Magento2 Installation & Configuration.