**Debugging is a bit of an art, but something that can easily be mastered by following a simple regiment.**

Follow each point until you finally reach a solution.

---

#Enable PHP Errors

This is key to most issues. For security or other reasons, PHP error display could likely be disabled by default by your PHP configuration.

You can enable errors with a more permanent solution, or something merely more temporary.

##Permanent solution

**For Apache/mod_php users**

In your document root `.htaccess` file - just drop this at the top.

    php_flag display_startup_errors on
    php_flag display_errors on
    php_flag html_errors on
    php_flag  log_errors on
    php_value error_log  /home/path/public_html/var/log/system.log

**For Nginx/fastcgi users**

In your Nginx virtualhost configuration, in either the final `location .php {` directive, or in the `fastcgi_params` file (if you have one specified)

    fastcgi_param PHP_VALUE  display_startup_errors=on;
    fastcgi_param PHP_VALUE  display_errors=on;
    fastcgi_param PHP_VALUE  html_errors=on;
    fastcgi_param PHP_VALUE  log_errors=on;
    fastcgi_param PHP_VALUE  error_log=/home/path/public_html/var/log/system.log;

##Temporary/Universal solution

**For any platform**

Edit the Magento bootstrap `index.php` in your document root and uncomment the following line:

    #ini_set('display_errors', 1);

---

#Enable Developer Mode

When you've had an error and suddenly hit the "Error Report" page, and been given a seemingly useless error string like `1184257287824` - you've got a few options.

##Permanent solution

**For Apache/mod_php users**

In your document root `.htaccess` file - just drop this at the top.

    SetEnv MAGE_IS_DEVELOPER_MODE true

**For Nginx/fastcgi users**

In your Nginx virtualhost configuration, in either the final `location .php {` directive, or in the `fastcgi_params` file (if you have one specified)

    fastcgi_param MAGE_IS_DEVELOPER_MODE true;

##Temporary/Universal solution

Edit the Magento bootstrap `index.php` in your document root and either make the `if` statement always true, or enabled for your specific IP.

    if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || true) {
      Mage::setIsDeveloperMode(true);
    }

or

    if (isset($_SERVER['MAGE_IS_DEVELOPER_MODE']) || $_SERVER['REMOTE_ADDR'] == 'my.ip.add.ress') {
      Mage::setIsDeveloperMode(true);
    }

---

#Revert theme to default

Its possible that either your theme or package is responsible for this issue. Reverting back to a vanilla Magento theme is a quick way to find out. 

**This comes with the caveat that some modules may be dependant on certain theme features*

Rather than change anything via the admin, it is much simpler to merely rename the offending directories.

**Via SSH**

    mv ./app/design/frontend/myBrokenTheme{,.tmp}
    mv ./skin/frontend/myBrokenTheme{,.tmp}

Or via your FTP client, traverse and rename your package to something else. eg. `myBrokenTheme.tmp`

##If this resolves your issue

Then you need to dig a bit deeper as to what part of the template is problematic. So restore your package and attempt the following, testing between each.

Essentially, the process is to gradually enable directories as you traverse down the file tree - until you can find the offending file.

 1. Rename the layout directory to `.tmp`
 2. Rename the template directory to `.tmp`

Then if either yields a fix, rename all files within the layout directory to `.tmp` - (for the SSH users `ls | xargs -I {} mv {} {}.tmp` or `rename 's/^/.tmp/' *`) 

Then gradually enable each file 1 by 1 until resolved.

##If this doesn't resolve your issue

There is potential that your `base/default` or `enterprise/default` directories have become contaminated - and are best replaced with a known clean version. 

You can do this by downloading a clean build of Magento and replacing your directories as necessary. Via SSH you can do this:

    cd /home/path/public_html/
    mkdir clean_mage
    cd clean_mage
    MAGENTO_VERSION=1.7.0.0
    wget -O magento.tgz  http://www.magentocommerce.com/downloads/assets/$MAGENTO_VERSION/magento-$MAGENTO_VERSION.tar.gz
    tar xvfz magento.tgz
    cd /home/path/public_html/app/design/frontend
    mv base{,.tmp}
    cp -par /home/path/public_html/clean_mage/magento/app/design/frontend/base .
    cd /home/path/public_html/skin/frontend
    mv base{,.tmp}
    cp -par /home/path/public_html/clean_mage/magento/skin/frontend/base .

You can also take the opportunity to `diff` the two directories if you want to verify any changes.

    diff -r base base.tmp

NB. This method will cause more errors during the process, as module dependency dictates the existence of specific files. *Unfortunately, its par for the course.*

---

#Disable local modules

By default, Magento defines the PHP include path to load classes in the following order

    Local > Community > Core

> If a file is in Local - load it and do no more.  
> If a file is in community - load it and do no more.  
> If a file can't be found anywhere else - load it from the core.  

Again, rather than disable modules via the Magento admin. It is more practical to do this at a file-level. 

Typically, to disable a module the "proper" way, you would edit the respective `./app/etc/modules/MyModule.xml` file and set `<active>false</active>` - however, this doesn't actually prevent a class from loading.

If another class extends a given class in a module (ignoring any Magento dependency declarations), it will still be loaded - regardless of whether the extension is disabled or not. 

So again, the best means to disable an extension is to rename the directory.

###Begin by disabling local

Just rename the directory via FTP, or use the following SSH command

    mv ./app/code/local{,.tmp}

###Then disable community

    mv ./app/code/community{,.tmp}

##If the issue is resolved from either

Then it is a case of understanding which module in particular the error stemmed from. As with the example given above for the package diagnosis, the same process applies.

So restore the X directory and attempt the following, testing between each.

Essentially, the process is to gradually enable directories (modules) one-by-one until the error re-occurs

 1. Rename all the modules in the directory to `.tmp` (for the SSH users `ls | xargs -I {} mv {} {}.tmp` or `rename 's/^/.tmp/' *`)
 2. Gradually enable each module one-by-one, by removing `.tmp` from the file name

##If the issue is not resolved

Then it is possible the core itself is contaminated. The main Magento PHP core consists of

> ./app/code/core  
> ./lib

So again, rename these directories and copy in a clean variant. Assuming you already downloaded a clean version of Magento as above, via SSH, you can do this:

    cd /home/path/public_html/app/code
    mv core{,.tmp}
    cp -par /home/path/public_html/clean_mage/magento/app/code/core .

Then if the issue still isn't resolved, replace the `lib` directory too

    cd /home/path/public_html
    mv lib{,.tmp}
    cp -par /home/path/public_html/clean_mage/magento/lib .

At this point, your Magento store will be nothing more than a vanilla installation with a modified database.

Some models are actually still stored in the database (Eg. order increment) - so at this point, it becomes a case of manually making those edits. So far, all the steps above have been reversible with no lasting damage. But if we were in import a clean Magento database too - it could prove reversible (short of restoring a backup).

---

#Seek help from a professional

The above tasks are easy complete, even by amateurs, but beyond this point; if you are still experiencing problems - we would suggest seeking professional help.

The guide above serves to get you on your way to identifying an error; not to fixing the resultant error - but is the standard debug procedure at [Sonassi][1].

---

Content willingly sourced from [www.sonassi.com/knowledge-base/magento-debug-process/][2]

  [1]: http://www.sonassi.com/
  [2]: http://www.sonassi.com/knowledge-base/magento-debug-process/