Magento completely broken: Call to a member function getCode() on boolean & There was no 404 CMS page configured or found

Question

Suddenly (without any changes or updates) our magento installation seems to be completely broken.

Every day we're now getting some of this errors:

1. There was no 404 CMS page configured or found when accessing /index.
2. The magento installer suddenly shows up when accessing /index
3. No template is showing up (as shown in the picture)

4. Strange redirects. When everything seems to work (no 404 cms error, no template issues) and I try to visit a product I sometimes get redirected to the home page.

Well, what I did so far is:

1. flushed cache folder, flushed session folder
2. truncated table core_url_rewrite

It seemed to work. After reindexing (core_url_rewrite) everything seemed broken again so I truncated again. With empty core_url_rewrite it looked all okay. But the next day it was broken again.

Well and today it's the same again but today it's also the first time where flushing cache, sessions and core_url_rewrite doesn't work anymore.

Oh and this is showing up in our nginx error log:

[error] 11773#11773: *242799 FastCGI sent in stderr: "PHP message: PHP Fatal error: Call to a member function getCode() on boolean in /htdocs/seg_posorder/stage/app/code/core/Mage/Customer/Model/Session.php on line 71" while reading response header from upstream, client: 217.24.X.X, server: www.example.com, request: "GET /index.php/customer/account/login/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock:", host: "www.example.com", referrer: "example.com"

But our stores also seem okay:

Answer 1

After chatting with @moose I've decided to post this as an answer myself. Thanks to Nexcess for pointing @moose to my write up, and thus feeding my insatiable lust for stars on my github repository.

There is a core magento configuration cache bug which causes a "No 404 CMS Page configured" error or - in other instances - a "100 router match iteration" error. The error goes away when you flush the cache, but usually re-appears after some time.

https://github.com/convenient/magento-ce-ee-config-corruption-bug

(Edit: Further changes can be added to prevent config corruption: https://github.com/convenient/magento-ce-ee-config-corruption-bug#update-2-further-improvements)

Replication

Check out my repository above.

It has a file 100-router-script.php which should help replicate the error for you by running it in the root of your website.

The Patch

Magento have released a patch (SUPEE-4755) based on my write up.

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

This patch is the exact same as my fix which gives it some validity.

This patch isn't publicly listed anywhere because Magento don't do that for anything but security patches for some reason. I know the patch file says EE_1.13.1.0, but I tested it on community edition 1.9 and it applied fine.

You can grab a copy of the patch here: https://github.com/convenient/magento-ce-ee-config-corruption-bug/blob/master/PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

And for historical reasons or in case my github account ever gets deleted

/**
* Initialization of core configuration
*
* @return Mage_Core_Model_Config
*/
public function init($options=array())
{
    $this->setCacheChecksum(null);
    $this->_cacheLoadedSections = array();
    $this->setOptions($options);
    $this->loadBase();

    $cacheLoad = $this->loadModulesCache();
    if ($cacheLoad) {
        return $this;
    }
    //100 Router Fix Start
    $this->_useCache = false;
    //100 Router Fix End
    $this->loadModules();
    $this->loadDb();
    $this->saveCache();
    return $this;
}

If this doesn't fix your Magento instance

This patch file will solve all reasonably vanilla magento instances (anything that reinitialises the configuration cache using the defined init or reinit methods).

If you have any code which calls the loadDb function - like n98-magerun - then you're likely to have a bad time and should probably consider refactoring your code to call reinit or init on Mage_Core_Model_Config.

If you still have trouble, I recommend you read my write up and

1. Implement the logic mentioned in the Debugging the Issue section.
2. Wait for some log data to appear.
3. Contact me!

A theory on why supee 6788 makes the error worse

I've just posted this in the chat room and thought I'd pop it here for posterity.

Something to remember is that magento has ALWAYS had this bug in it's background. and that supee 6788 has just made it something that is more likely to happen

I just had a look at the supee 6788 patch for EE1.14 This is my working theory.

Mage_Core_Controller_Varien_Router_Admin was patched to override the addModule function

Now, I can't quite recall the order in which things occur during the mage request initialisation But this modification now adds two calls to Mage::getConfig()->getNode() on each single request, quite early on in the flow. If there is an object cache param failure with useCache during either of these two calls, then it could potentially trigger an incomplete configuration being written to the cache (getNode can trigger a reinit, as it tries to load values from the cache, and on a failed load, it will reinit the entire config cache and re-save it via the reinit() function)

So perhaps just adding these two extra getNodes on to a very early part of the request, when the full configuration may not be loaded could have caused this error to happen Either way I wouldn't sweat a full understanding of the issue. It'd be a lot of work for not a lot of gain, and looking into Mage_Core_Model_Config::loadDb (with a focus on what effect the useCache flag may have on it) could drive a man insane.

Answer 2

Of the problems you describe, only point 2 is particularly familiar, but for what it's worth this is how we resolved it in our case:

There's a bug in PHP's libxml library - I think it's this one - which means that sometimes Magento fails to load some of its own configuration files. You may find it was some low-level update (PHP or one of the libraries it relies upon) that brought the problem out in the open.

Try adding this line to index.php, right near the start (I put it just after the PHP version check):

libxml_disable_entity_loader(false);

Answer 3

Nexcess (Magento Platinum Hosting Partner) pointed me to the solution on GitHub (Big kudos to Luke Rodgers, the author of the patch)

Magento Bug - Corrupted Config Cache

PATCH_SUPEE-4755_EE_1.13.1.0_v1.sh

This patch is the exact same as my fix which gives it some validity.

This patch isn't publicly listed anywhere because Magento don't do that for anything but security patches for some reason. I know the patch file says EE_1.13.1.0, but I tested it on community edition 1.9 and it applied fine.

This page gives you a full explanation AND the ability to reproduce the error by running the 100-router-script.php from your root directory (this replicated the issue for me, first-try).

The Fix:

/**
* Initialization of core configuration
*
* @return Mage_Core_Model_Config
*/
public function init($options=array())
{
    $this->setCacheChecksum(null);
    $this->_cacheLoadedSections = array();
    $this->setOptions($options);
    $this->loadBase();

    $cacheLoad = $this->loadModulesCache();
    if ($cacheLoad) {
        return $this;
    }
    //100 Router Fix Start
    $this->_useCache = false;
    //100 Router Fix End
    $this->loadModules();
    $this->loadDb();
    $this->saveCache();
    return $this;
}

It goes on to say:

It would be naive of me to believe that this will completely solve the issue for everyones Magento setup. If it does not work for you then I recommend you

• Implement the logic mentioned in the Debugging the Issue section.
• Wait for some log data to appear.
• Contact me!

Answer 4

Since I haven't got any answer for a long time (and our shop is in production for a customer) I needed to come up with my own solution. I'll share it, maybe it can help to find the problem:

In my index.php I changed:

/* Store or website code */
$mageRunCode = isset($_SERVER['MAGE_RUN_CODE']) ? $_SERVER['MAGE_RUN_CODE'] : '';

/* Run store or run website */
$mageRunType = isset($_SERVER['MAGE_RUN_TYPE']) ? $_SERVER['MAGE_RUN_TYPE'] : 'store';

Mage::run($mageRunCode, $mageRunType);

To:

$mageRunCode = 'default';
$mageRunType = 'store';

Mage::app()->setCurrentStore(1);
Mage::run($mageRunCode, $mageRunType, array('is_installed' => true));

This is hardcoded and only working because we just have one store. But still, it seems to work now.