Magento: Fatal error: spl_autoload() … line 132

So in dealing with Magento, I’ve ran across the following error:

Fatal error: spl_autoload(): Class Zend_Log_Exception could not be loaded …/lib/Zend/Log/Writer/Stream.php on line 132

We were attempting to use Memcache but each time it was enabled, the site would throw the above mentioned error on the page.  So we had it isolated to Memcache (disable Memcache in local.xml and error goes away) .  Reviewing the log files on the server (/var/log/system.log), we discovered the following:

ERR (3): Warning: ini_set(): Cannot find save handler ‘memcache’  in …app/code/core/Mage/Core/Model/Session/Abstract/Varien.php on line 56

The code was trying to use a memcache handler, but couldn’t find it.  A review of the PHPINFO() output further confirmed that memcache was not a recognized handler:


The session had a memcached handler, but not a memcache handler! 

On the server, I typed php on the command line and discovered the following:

PHP Warning:  PHP Startup: Unable to load dynamic library ‘/usr/lib64/php/modules/’ – /usr/lib64/php/modules/ cannot open shared object file:  No such file or directory in Unknown on line 0

So armed with that knowledge, I check the location to see if, indeed, the file exists.  I discovered the file does, but file does not!


So someone failed to recognize that there are two code bases for Memcache(d): 

The code appeared to be referencing the Memcache handler, but the only code base installed was the Memcached!  After discovery, the Memcache code base was installed on the servers and resolved the issues.

We were able to confirm the presence of the Memcache handler in the PHPINFO() output:


The error went away and we were able to proceed! 


Name and Location are Key!

She’s going to bark at you if you don’t treat her with respect!  That’s why it’s key to provide the proper name and proper location  for any Magento files.  Any time you see the following in Magento, assume you got your wires crossed and start rechecking everything in the path:


( ! ) Fatal error: Call to a member function load() on a non-object in C:\xampp\htdocs\MagentoE\app\code\core\Mage\Core\Model\Abstract.php on line 225
Call Stack
# Time Memory Function Location
1 0.0006 145344 {main}( ) ..\index.php:0
2 0.0041 330992 Mage::run( ) ..\index.php:87
3 0.0150 983144 Mage_Core_Model_App->run( ) ..\Mage.php:683
4 1.7253 7152144 Mage_Core_Controller_Varien_Front->dispatch( ) ..\App.php:354
5 1.7378 7894792 Mage_Core_Controller_Varien_Router_Standard->match( ) ..\Front.php:176
6 1.7412 8120632 Mage_Core_Controller_Varien_Action->dispatch( ) ..\Standard.php:250
7 1.9243 11377120 MyModule_Complexworld_IndexController->indexAction( ) ..\Action.php:419
8 1.9247 11400536 Mage_Core_Model_Abstract->load( ) ..\IndexController.php:10

In this instance My Module Class’ model was in the correct location, but the name of the class for the model didn’t match the expected name Magento was hunting for:

class MyModuel_Complexworld_Model_Resource_Eavblogpost
extends Mage_Eav_Model_Entity_Abstract


Can you spot the problem in the code above? Yeah, a simple misspelling can cause a lot of grief in this system!  This hasn’t bit me yet, but I anticipate it will the more I trudge through this mammoth system.

EAV Resource Models

In Magento, resource model classes that rely on the EAV model are required to extend from Mage_Eav_Model_Entity_Abstract. 

If you instead extend from the standard model (Mage_Core_Model_Abstract) you’ll end up with an error such as this:

Resource is not set.
#0 Abstract.php(136): Mage::throwException('Resource is not...')
#1 Abstract.php(225): Mage_Core_Model_Abstract->_getResource()
#2 Abstract.php(225): Mage_Core_Model_Abstract->load(Object(MyModule_ComplexWorld_Model_Eavblogpost), 1, NULL)
#3 IndexController.php(10): Mage_Core_Model_Abstract->load(1)
#4 Action.php(419): MyModule_Complexworld_IndexController->indexAction()
#5 Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch('index')
#6 Front.php(176): Mage_Core_Controller_Varien_Router_Standard->match(Object(Mage_Core_Controller_Request_Http))
#7 App.php(354): Mage_Core_Controller_Varien_Front->dispatch()
#8 Mage.php(683): Mage_Core_Model_App->run(Array)
#9 index.php(87): Mage::run('', 'store')
#10 {main}

Here is the code that generated this error:


class MyModule_Complexworld_Model_Resource_Eavblogpost

extends Mage_Core_Model_Abstract

//This should be Mage_Eav_Model_Entity_Abstract



Setting Developer Mode in Magento outputs Errors to screen


I updated the <VirtualHost> element in my Apache configuration file (apache/conf/extra/httpd-vhosts.conf) to include the environment variable “MAGE_IS_DEVELOPER_MODE”:

<VirtualHost *:80>
    documentroot "c:/xampp/htdocs/magento"

By doing this, I can see any error that may have occurred during process of request.  This was done as a result of following the Magento For Developers: Part 5 – Magento Models and ORM Basics, which led me to the Wiki article Configure Magento error page, and a StackOverflow article discussing how to set up the environment variable.

As stated in the Wiki article, Magento handles outputs this way to eliminate the need of changing the index.php file for a production, staging or development server.

On the XAMPP War-Path…

Pulling my head out of the Windows stack for a while, not that ASP.NET doesn’t work for me – it does; I’m simply tasked to support another stack.  A world somewhat foreign to me.  The world of Apache, MySQL, and PHP.  Not sure what the X and P surrounding the AMP stand for if that’s any indication to how new I am at this.

So I downloaded XAMPP and installed it on my Windows 7 64bit OS.  I didn’t run anything as a service because I didn’t want to add additional processes to my start-up routine.  So I tried to fire up the Apache service from the XAMPP Control panel (v.3.0.12) and it starts and immediately shuts down.  I have my suspicions that it may be conflicting with my IIS utilizing port 80.  So I step into the config file (httpd.conf) and change the port and now I’m up and running it appears.


If you are a XAMPP guru or even a PHP guru, let me know as I’m about to perform the equivalent of swimming across the English Channel and would like a personal floatation device to keep me bouyed in this endeavor.

MVC 3, EF Code First and SQL CE: Putting it all together

If I don’t write about this incident, I’ll inevitably repeat it.  So here we go:

SQL CE database was not getting created when using using Entity Framework’s Code First paradigm within an MVC application.

Initial error stated:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)

However, the Inner Exception specified:

ProviderIncompatibleException: The provider did not return a ProviderManifestToken string.

Essentially, what I was lacking was a Connection String to tell Entity Framework where to create the Database.

I used the following code in the root-level Web.config file to remedy the error:

<add name="SalesQuoteDB" connectionString="Data Source=|DataDirectory|SalesQuote.sdf" providerName="System.Data.SqlServerCe.4.0"/>

Now all seems well with the world.

Import/Export Data: Position Matters!

Just ran a test to determine why my data wasn’t showing up after importing elements into an Orchard site.  Ran a comparison from the data that was built manually into the site, and the data that was imported:  I discovered the only difference in the data for the Content Types was the Common_IdentityPartRecord.Id field was different (swapped) for some content items.  I went back to my import package (xml file) and rearranged the content so that the order flowed logically (ContentType Parent created first, then ContentType Child, then Widget instead of ContentType Child, then Parent then Widget like the Export Feature ordered them) and presto!  The data for my control is now rendering!

No explanation as of yet why this is the case.  This cost me some considerable time to troubleshoot and I wanted to post this to assist anyone trying to figure out why their data from using the import feature is imported, but your site still may not work as expected.

When control was built manually and it works the Common_IdentityPartRecord table looked like this:


When imported, table looks like: