Error / maintenance page - custom theme implementation failure

Question

So I followed, the magento error report and maintenance page instructions on how to customize the error / maintenance page `503.phtml', but it still displays and uses the default!

I created the custom theme errors/MyTheme copied css and images folders. Also copied 404.phtml, 503.phtml, page.phtml and report.phtml to errors/MyTheme from errors/default.

Now I have:
errors/MyTheme/css
errors/MyTheme/images
errors/MyTheme/404.phtml
errors/MyTheme/503.phtml
errors/MyTheme/page.phtml
errors/MyTheme/report.phtml

The errors/local.xml file looks as follow:

<?xml version="1.0" encoding="UTF-8"?>   
 <config>   
   <skin>MyTheme</skin>   
   <report>   
    <action>email</action>
    <subject>Store Debug Information</subject>
    <email_address>[email protected]</email_address>
    <trash>leave</trash>
   </report>
</config>

File Permission inside of Default folder:

File Permission inside MyTheme folder:

File Permission inside error/ folder:

No matter what I do it does not use contents of MyTheme! Any ideas?

Answer 1

It all looks correct. Maybe check file permissions on copied files. If Magento can't find custom error them it fall back to default one.

Answer 2

The problem you have is that in your httpd.conf the DocumentRoot location is set to a wrong location.

errors/processor.php uses ugly/bad code:

protected function _getIndexDir()
{
    $documentRoot = '';
    if (!empty($_SERVER['DOCUMENT_ROOT'])) {
        $documentRoot = rtrim($_SERVER['DOCUMENT_ROOT'],'/');
    }
    return dirname($documentRoot . $this->_scriptName) . '/';
}

$_SERVER['DOCUMENT_ROOT'] should not be used to get the webroot.

Correctly set your DocumentRoot location in httpd.conf and the fallback to default will not happen. Funny thing is "default" is correctly resolved to the right webroot because it does not use the server variable DOCUMENT_ROOT. I dont know why they resolved the webroot in two different ways. One of them is obviously bad.

Answer 3

I saw an example that used the Admin to construct a Maintenance page however I thought if it's using the Database to store settings then how does that work if your update includes the Database...? That doesn't seem right to me.

Wouldn't any true maintenance page be completely non-reliant upon the environment that the system you're updating relies upon - Even PHP? I guess if you want to take that even further, maybe it should reside on a completely different server, maybe your in-house development server. Then you point a DNS sub, 'maintenance.yourURL', at your IP address.

This would be obviously slower - They do have services that do this type of stuff. You can Google it - Don't want to sound like I'm spamming this forum :)

Answer 4

Check your capitalization On Linux servers 'MyTheme' and 'mytheme' or 'Default' and 'default' aren't the same.