Magento Dev Environment on Windows 7

In this post, I’m going to walk through how our development team configured our development environment on a Windows OS for Magento.  The impetus for this was to support an out sourced site running Magento in a LAMP environment; keeping in mind the need for continued support of current projects on the Windows stack.  Thus we’ve moved to using XAMPP on Windows to support a company site on Linux.  Fun right!?

We decided to go with the XAMPP Package to install Apache, MySQL and PHP.  The version may be unimportant, but XAMPP 3.1.0 Beta 6 was used at the time of this writing.  When finished with our environment, we had three sites we could hit from our development machines:

  1. The XAMPP Startup/Splash page on the root (Example:
  2. A fresh Installation of Magento at a subdomain (Example:
  3. A copy of the company site (running Magento) configured at a subdomain (Example:

The following is a list of downloads we found useful for setting up the development environment:

  1. XAMPP (the platform)
  2. NetBeans IDE (the development tool)
  3. XDebug (debugger for PHP)
  4. WinSCP (used to move files off Linux server on to development machine)
  5. Git (Distributed Version Control System)
  6. 7-zip (used to unzip compressed database and folders from Linux environment)
  7. MySQL WorkBench (MySQL GUI for development)

Below is a general outline of steps taken to establish these three sites on our development machines:

  1. Using a Zip Package of XAMPP
  2. We Kicked off the setup_xampp.bat file after storing the folder structure in the desired location
  3. Configured Port to use 100 instead of 80 (optional) due to IIS using port 80 (under install-path\xampp\apache\conf\httpd.conf)
  4. Added new domain names in the Hosts file (c:\windows\system32\drivers\etc\hosts)
  5. Configured Virtual Hosts File (install-path\xampp\apache\conf\extra\httpd-vhosts.conf)
    1. Referenced domain names from the Hosts file
    2. Added MAGE_IS_DEVELOPER_MODE “1” to Each Virtual Host configured
    3. Each Virtual Host referenced a folder under the default install-path\xampp\htdocs\ path using the DocumentRoot attribute

      Sample vhost file

      Sample vhost file

  6. Launch/Restart Apache and MySQL services under XAMPP control panel  (install-path\xampp\xampp-control.exe)
    1. open default website based on configured domain and port and confirm “XAMPP For Windows” site opens
    2. Local XAMPP Site Complete
  7. Obtained Copy of Magento Enterprise Edition (Community will suffice)
    1. Copied Magento folder structure under the install-path\xampp\htdocs\ path
    2. Created a new database for Magento using mysql (or MySql Workbench)
    3. Site opened with installation page for Magento.
    4. Began Installation
    5. Magento Out of the Box Development Site Complete
  8. Obtained Copy of Company Site (developed on Magento)
    1. Used WinSCP to retrieve a copy of Company Site from Linux servers (or pull from Git repository)
    2. Retrieved a copy of the database as well (using MySqlDump)
    3. Retrieve a copy of the media folder as well
    4. Create database schema for the new database in mysql (or MySql Workbench)
    5. Imported SQL file into new database
    6. Confirm app/code/etc/local.xml exists and configured accordingly
    7. Change domain name in core_data_config table to reflect development URL
    8. Run Site
    9. Company Magento Site Complete

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.