Till's blog

Moving a store from one server to another server, you're bound to have small issues. While 99% of the configuration is stored in app/etc/local, there are other bits and pieces that are more spread out. For example, I noticed that there's no central 'Are all file permissions OK?' screen in Magento Commerce and at times the system is pretty secretive when it comes to error messages.

For example, after moving a store from a linux to a BSD (essentially a different WWW user id), Magento Connect just died with "Error: Please check for sufficient write file permissions".

Of course it did not disclose what exactly it failed in the process. Anyhow — debugging in downloader/Maged/Controller.php (Maged_Controller::isWritable()), here's a list of files and directories that need to be made writable so Magento Connect gets to work:

/path/to/your/magento-install

/path/to/your/magento-install/downloader

/path/to/your/magento-install/downloader/config.ini

/path/to/your/magento-install/downloader/pearlib/config.ini

/path/to/your/magento-install/downloader/pearlib/pear.ini

/path/to/your/magento-install/downloader/pearlib/php

Who knows — maybe the secrecy is for security reasons or whatever. In the end the list above is incredibly helpful, when you realized that the linked entry from the knowledge base is missing half of them and/or does not list the relevant parts for Magento Connect there. :D

Multiple stores is probably the killer feature of the Magento Commerce store. It enables the needy to manage multiple stores through a single interface. Your very own mall in a box.

It's also a management/deployment nightmaredream come true. A single piece of software powering multiple websites.

This small HowTo requires a working installation of Magento (tested with Magento Commerce v1.3), multiple stores setup already, an understanding of your (web)server, some shell-fu and probably root access.

I won't go into creating virtual hosts, and if you're stuck with CPanel, Plesk or similar, this may work as well but I can't help you very much.

Making it work

Magento is complex and so on, but let's disregard the caveats for now and figure out how to make it run.

This setup is one of the things that took me a good while to research, so I'm sharing this so it jump starts others. I remember I had a wiki or knowledge base entry over at Magento bookmarked, but that one seemed to have vanished.

My file system layout is as follows:

/web/customer/magento/1.3/

/web/customer/magento/1.0/

/web/customer/example.org/htdocs

/web/customer/example.net/htdocs

Now, let's say you have a store setup for example.org and one setup for example.net, then place an index.php with the following contents in each htdocs directory:

<?php
require_once '/web/customer/magento/1.3/app/Mage.php';
Mage::run('STORE-CODE', 'store');

The STORE-CODE is hidden in your Magento Commerce Admin. Go to System > Configuration and then click on the designated Store View.

Last, but not least — add the following symbolic links inside both htdocs directories:

ln -s ../../magento/1.3/app/ ./app
ln -s ../../magento/1.3/downloader ./downloader
ln -s ../../magento/1.3/js/ ./js
ln -s ../../magento/1.3/media/ ./media
ln -s ../../magento/1.3/skin/ ./skin
ln -s ../../magento/1.3/var/ ./var

Of course you may need to adjust the paths around, but aside from that, it's all straight forward.

And that is all!

Update: Updated instructions for symlinking (added downloader).

Yesterday, I started upgrading a test server to Apache 2.2 and PHP 5.2.9 and ran into this is a problem, which then bugged me for a good day. So here's the run down:

My test.php:

<?php
ob_start();
system('file -i -b /path/file.txt');
$contents = ob_get_contents();
ob_end_clean();
var_dump(headers_sent($file, $line), $file, $line);

My test2.php:

<?php
$contents = shell_exec('file -i -b /path/file.txt');
$contents = trim($contents);
var_dump(headers_sent($file, $line), $file, $line);

test.php claims that headers were send, while test2.php shows the expected behavior. The difference is not only system() vs. shell_exec(). But the ob_start(). Apparently headers_sent() returns true right after system() was called. We've used output buffering to trap whatever came back from system and this works on PHP 5.2.6 and 5.2.8, but not on 5.2.9.

Since I was after the response of the shell call, using shell_exec() is what should have been used to begin with — still. This is pretty weird.

Update: I've opened #47973 - Yay, bug fixed!

I swore myself to only post meaningful stuff to this blog, so basically, no rants, ever. But!

The discussion revolving around Twitter and Rails (versus Scala) did remind me of something: If you've doing PHP for a while and know people who are programming not in PHP, you probably heard it all before. PHP guys (and girls) are being look down on and mocked by people of other programming and scripting languages. And that is despite ...

1. ... the overall acceptance and distribution of the language
2. ... the millions of free lines of code in open source projects and other code repositories
3. ... the countless great examples of PHP in the enterprise
4. and the amazingly short time to market when you develop with PHP

Those are a few good things to say about this fine language called PHP. Unfortunately they are never taken into consideration when you bash people who use it.

Instead you tell them about the short comings of several pieces of software such as phpBB, Mambo/Joomla and Wordpress who have had a lot of issues in the past but never the less are more popular than virtually any of their open source counterparts in the other languages.

Now, because a lot of Ruby people have a strong dis-like for PHP, you may think they deserve this. I don't think they, or Ruby, do.

I am perplexed how Alex Payne handles the current Scala/Ruby shoot out over at Twitter.

• I'm amazed that someone with his experience and knowledge oversees the obvious short comings of several people who worked on the Twitter code base over the past years.

• I'm amazed that he oversees all the crap they implemented.

• I'm amazed that he oversees how they were and still are suffering from the most classic NIH.

And all to blame it on the language — Ruby.

Anyway, there may be plenty to argue about Ruby (or maybe just Rails). But blaming the language because of the inability of a developer (or multiple) is not the way to do it. It just makes you look very ignorant.

I sure hope Scala lives up to Alex' expectations, but if it doesn't — just blame it on Scala!