FFS, running a Magento (1.x) subdirectory storeview on NGINX

I’m writing this for all good and holy, as other Mage developers will recognize. Setting up NGINX configuration for a multistore installation can be a massive pain in the unpleasants. After another night of sighing, moaning and clicking through pages and pages of Google search results, I found something that works.

Now obviously this is not “the best way” to go, but documentation on Magento and NGINX is very, very scarce, there are many articles out there with incorrect, incomplete, fuzzy or just plain wrong information. I know if you’re reading this, you have seen those articles yourself, trying to puzzle a working solution out of all possibilities, but coming up short every time.

SO. Here it is, for the future of mankind: How to properly set up a second storeview/website on a NGINX server. I won’t go over the setup of the new website/storeview in the Magento admin, because that is very straightforward and the same on both Apache and NGINX servers, so there’s plenty of documentation for that. And yes, of all possibilities mine relies on creating a subdirectory, copying the index.php and creating symlinks. If that doesn’t bother you, please read on.

Creating the subdirectory
In your magento root (i.e.) /usr/share/nginx/html, create a new folder with the name you’d want. So in example if your store is called “storetwo” create a directory as /usr/share/nginx/html/storetwo

Copy the index.php file
Copy the index.php file from the root to the newly created subfolder and add this befcre the last line Mage::run($mageRunCode, $mageRunType)
$mageRunCode = 'storetwocode'; // replace this with the actual storecode you set up in the admin
$mageRunType = 'website'; // can be store or website, depending what you want and need

Create the symlinks
Because you’re copying the index.php file to the subfolder, you’re kind of fooling the system into thinking there is a second installation being run there, but in fact it just uses the same system. To keep the paths correct, we create symbolic links to (or aliasses) to point to the correct files. Connect via SSH and run these commands.
cd /usr/share/nginx/html/storetwo/
ln -s /usr/share/nginx/html/app/ app
ln -s /usr/share/nginx/html/errors/ errors
ln -s /usr/share/nginx/html/includes/ includes
ln -s /usr/share/nginx/html/js/ js
ln -s /usr/share/nginx/html/lib/ lib
ln -s /usr/share/nginx/html/media/ media
ln -s /usr/share/nginx/html/skin/ skin
ln -s /usr/share/nginx/html/var/ var

Other sources say you can just symlink the entire root at once, others again say that you should symlink all folders. In my experience, just these are enough. Be sure to edit the paths to the correct ones in your situation.

And now, the ‘thing’
You see, the ‘thing’ is, that at this point you can browse to yourdomain.com/storetwo and you’ll see your second storeview or website. Congratulations! But clicking anything will result in a 404. This is because the Zend framework is a dick to rewrites, and all those people saying “ooh, just copy over the .htaccess file too” never heard of NGINX.
Try it, and if all is well, you’ll get 404 pages all around. Now see if those pages do work if you add index.php between them; so mydomain.com/storetwo/about-us would be mydomain.com/storetwo/index.php/about-us. My guess is that that’ll work/

You could disable store-rewrites in the backend and you’d be done, but you’d be stuck with that index.php in all the urls which is, well, just stupid and I’m pretty sure bad for SEO.

So it’s time to edit the NGINX configuration!

And now, the REAL thing
Edit your sites config, in my case it was just the default /etc/nginx/sites-available/default. My editor of choice is nano, so I typed
sudo nano /etc/nginx/sites-available/default
Somewhere in there you should find a block starting like location ~ \.php$ { . Underneath that block, add a new one like this:

location /storetwo {
rewrite ^/storetwo(.*)$ /storetwo/index.php last;

And restart NGINX with sudo service nginx restart. And now check out your second store again. Bam!
..And now go shame yourself, because that was pretty straightforward nonetheless. But hey, us webdevelopers aren’t serverops. I know serverops who can’t even do a vertical-align right in CSS. Ha.