I've just installed a plugin and now magento isn't working anymore. Firstly i thought this was due to the plugin but even after disabling/removing the plugin the problem persists.

Magento backend is working just fine, the problem is solely on the frontend which just shows a blank page. Error from the log:

include(): Failed opening 'Mage.php' for inclusion (include_path='/var/www/magento/app/code/local:/var/www/magento/app/code/community:/var/www/magento/app/code/core:/var/www/magento/lib:.:/usr/share/php:/usr/share/pear') in /var/www/magento/lib/Varien/Autoload.php on line 93

Now mage.php is located in /var/www/magento/app so i get the error message but adding this directory to the include path raises other errors. Mage.php is also included in index.php so i was wondering why is it included throughout the autoloader anyways?

Furthermore i tried reseting file/folder permissions to 644/755 but still no results. I'm running version

Afterwards PHP tries to look for the Mage class in the functions.php file which also fails.

[Wed Apr 09 20:46:23 2014] [error] [client] PHP Warning:  include(Mage.php): failed to open stream: No such file or directory in /var/www/magento/lib/Varien/Autoload.php on line 93
[Wed Apr 09 20:46:23 2014] [error] [client] PHP Warning:  include(): Failed opening 'Mage.php' for inclusion (include_path='/var/www/magento/app/code/local:/var/www/magento/app/code/community:/var/www/magento/app/code/core:/var/www/magento/lib:.:/usr/share/php:/usr/share/pear') in /var/www/magento/lib/Varien/Autoload.php on line 93
[Wed Apr 09 20:46:23 2014] [error] [client] PHP Fatal error:  Class 'Mage' not found in /var/www/magento/app/code/core/Mage/Core/functions.php on line 244   

Hope anyone can help, thanks.

  • What extension did you install? – Sander Mangel Apr 9 '14 at 19:10
  • 3
    Let me guess: AITOC. – Fabian Blechschmidt Apr 9 '14 at 20:42
  • @FabianBlechschmidt wish I could give 2 upvotes for that comment. Couple of extension builders extend the autoloader with their own. They're one of them as far as I can remember – Sander Mangel Apr 10 '14 at 11:35
  • sander, is it good process to create own autoloader?? – Amit Bera Apr 10 '14 at 18:45
  • @AmitBera - If your extension overwrites core files, then no, it's not good process. The entire Magento framework is designed to help avoid modifying core files. – Axel Apr 12 '14 at 0:49

It seems like the plugin either wrote over your Mage.php or it messed up the include_path. Disabling a plugin (extension) is often not enough. You need to remove it completely. What was the extension that you installed? How did you disable it? Do you have your Magento site in GIT so that you can do a fresh git checkout?

  • 1
    Unfortunately i don't have this site in GIT since i've just set it up. Well definitely do this the next time. Mage.php doesn't seem to be corrupted, any ideas how to reset the include paths? – chrisblomm Apr 9 '14 at 20:13
  • Just copy the files over the old way with FTP if you don't have it in GIT. Also disable all custom extensions to make sure these don't mess up anything. But I'm quite sure you have a "missing file" problem and that can only be cured by copying over core files. – Sven Jun 18 '14 at 14:54

Here's your diagnostic path:

  • tar -tf extension-package.tar.gz |grep 'app/code/core [1]
  • if that yields results, then restore those files from backup
  • if it doesn't, check shell/compiler.php to see if compilation is enabled and recompile or disable.
  • The include references 'Mage.php', even though the include is always called as 'app/Mage.php'. So find out, where there's a called for (require|include).*(?<!app/)Mage.php.

The fact that it's called as Mage.php actually makes me believe it's the compiler.

[1] Use bsdtar if it came in a zip to save you some headaches.


OK, had a closer look. The error is caused by the error handler using a call to Mage::getIsDeveloperMode(). This is safe, cause normally it is app/code/core/Mage/Core/Model/App.php that sets up the error handler in line 366 and at that point index.php has already setup the Mage class using require_once $mageFilename; and Mage::run() pulls in the Mage_Core_Model_App that sets up the error handler. So there should never be an spl_autoload() for the Mage class as the class is defined literally 2 lines after the autoloader is created. Several things come to mind about how this is possible:

  1. You mangled $mageFileName in index.php and it's now pointing to something that does something similar to app/Mage.php, but generates an error after it sets up the error handler and before it defines the Mage class. In this case: reset $mageFileName back to $mageFilename = MAGENTO_ROOT . '/app/Mage.php';
  2. You have some code that is loaded in index.php, that manually sets up the error handler and then generates an error.
  3. Somehow, the Mage class gets unregistered (I don't think it's possible to unload a class definition, but let's go with it) when Mage::run() calls Mage_Core_Model_App::run() => baseInit() => _initEnvironment -> setErrorHandler().
  4. Something I can't think of, since I'm already reaching with 3) :)

This patch should help diagnose:

diff --git a/lib/Varien/Autoload.php b/lib/Varien/Autoload.php
index bc11b67..d442bf4 100644
--- a/lib/Varien/Autoload.php
+++ b/lib/Varien/Autoload.php
@@ -88,6 +88,8 @@ class Varien_Autoload
         } else {
             $classFile = str_replace(' ', DIRECTORY_SEPARATOR, ucwords(str_repl
+  if( $classFile == 'Mage' )
+     throw new Exception('Mage should not be autoloaded.');
         $classFile.= '.php';
         //echo $classFile;die();
         return include $classFile;

Usage: (cd /var/www/magento && patch -p1 < /tmp/theabovecodeinafile.diff)

  • Thanks for the diagnostics but did not managed to find it. Apparently it has something to do with other things i did on the server yesterday. I've replaced all the files with the original magento 1.8.1 files and the problems are still there so it might have something to do with rights? All files are chowned by www-data and chmod settings are 755 on folders and 644 on files. – chrisblomm Apr 10 '14 at 17:48

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.