2

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)

enter image description here

  1. 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:

enter image description here

  • Seeing a similar issue after applying all the latest security patches (SUPEE-6788 specifically). Only way I can fix it is by clearing out sessions & cache. Have updated all extensions for support for SUPEE-6788 now hoping to see resolve. Anyone else experiencing this? Specifically the admin screen as seen above, and the home page CMS error. – Moose Nov 17 '15 at 20:39
  • are you using any extensions by Extendware? – Moose Nov 17 '15 at 20:58
  • Do you have error logging turned on? Are there errors in your var/log folder you can copy into your question here? – MagentoMac Nov 17 '15 at 21:15
  • The error needed will be in your system.log file, I remember having a similar issue with 1 of my stores a while back, although I can't be 100% sure it's the same problem you have. – MagentoMac Nov 17 '15 at 21:17
  • If you have DB backups, try the below DB query: SET FOREIGN_KEY_CHECKS=0; UPDATE core_store SET store_id = 0 WHERE code='admin'; UPDATE core_store_group SET group_id = 0 WHERE name='Default'; UPDATE core_website SET website_id = 0 WHERE code='admin'; UPDATE customer_group SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN'; SET FOREIGN_KEY_CHECKS=1; – MagentoMac Nov 17 '15 at 21:18
3
+50

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.

3

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);
2

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!
  • 1
    Damnit @moose I'm the author and I never get to post this :) On some versions of Magento this error causes the "no 404 CMS page configured" error which you are seeing. If this has only started happening since applying SUPEE6788 then I'd definitely recommend applying this patch. – Luke Rodgers Nov 19 '15 at 15:31
  • @LukeRodgers, sorry man not trying to take credit at all, just providing the answer for the community. Would really prefer if you could write one up & I will gladly delete my own :) Excellent work by the way! You saved me a LOAD of time, blood sweat & tears. – Moose Nov 20 '15 at 7:45
  • Don't sweat it man. I had no idea that SUPEE 6788 caused all this trouble as my instances already have my config patch in place hahaha. :) config corruption can happen in vanilla magento, but is often exasperated by custom code. I'm just never quick enough off the mark to post the answer myself. – Luke Rodgers Nov 20 '15 at 7:52
  • I'm sure some people are yet to uncover it due to the nature of the trigger itself. There's a 50 point bounty waiting for you if you provide an answer here. – Moose Nov 20 '15 at 7:58
  • Let us continue this discussion in chat. – Moose Nov 20 '15 at 8:03
1

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.

  • Is your site working with this "fix"? Can you access the backend? – Yiorgos Moschovitis Nov 18 '15 at 15:27
  • I have to say that it's working fine now. There is no installer coming up due to the is_installed option and the "getCode() on boolean" error is also gone now. Still, I can't figure out what was going on with the views. After cleaning all caches, disabling them and disabling the compiling feature of magento, there aren't any problems either. But this all can't be a permanent solution. – sleepless Nov 18 '15 at 16:57
  • 1. Are you using any extensions by Extendware? (Specifically Minify JS/CSS) and 2. Have you installed SUPEE-6788. (If yes, did these issues only pop up after the installation of the security patch?) – Moose Nov 19 '15 at 5:51
  • Hi, no I'm not using any extensions by Extendware and I have to negate you second question too. I asked this question before the SUPEE-6788 came out. Sorry I'm not able to help you with that. – sleepless Nov 19 '15 at 13:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.