April 05, 2020


Thinking Magento

Magento Patch SUPEE-6285: What Developers Need to Know

Magento Patch SUPEE-6285 is one of those patches you are going to hate.

The problem you are going to face is tracking down any module that extends Mage_Adminhtml_Controller_Action

Now a formal check has been put in place in the form of protected function _isAllowed() 

The check affects admin users who have restrictived roles. The moment a role becomes restricted the extra check comes into play.

Going to an admin menu that results in Access Denied is frustrating, but solvable.

You will need to go to your controllers directory and in Controller.php that extends Mage_Adminhtml_Controller_Action will need to have protected function _isAllowed() added in which a check to see if the session allows for access.

It's not always straight forward. Checking the session against access to the modules configuration page isn't normal practice. You normally don't want employees fiddling with the configuration of the module, so my advice is to check the session against the top of the menu tree.

For example you have a main menu for your module which has 6 sub / children menus. Set your allowed action to check the main menu only.

protected function _isAllowed()
return Mage::getSingleton('admin/session')->isAllowed('pathto/acl_mainmenu');

Placing this into your Controller.php will then give access back to those who are suffering from Access Denied for that module.

Need to find your acl mainmenu path. This will be either in adminhtml.xml or config.xml in your etc directory for the module. 

<trackingimport translate="title" module="trackingimport">

This translates to the following to add into your Controller.php

return Mage::getSingleton('admin/session')->isAllowed('sales/trackingimport');

-------------------- THEME UPDATES ------------------


If you have any themes that overwrite these files, you will need to patch them as well. These files are vulnerable to unescaped HTML injection attacks.

Magento - My Cron Is Running, But No Cron Schedule

So you've just finished off your Magento installation and you're trying to get the cronjob to queue up so that they can run, however nothing is being populated in your cron_schedule table.

As long as you've not updated the cron configuration in System > Configuration > System your generation ahead is for every 20 minutes and this is produced every 15 minutes.

This should mean running http://www.yourdomain.com/cron.php will populate cron_schedule in your database. In the cases that this doesn't happen, it's time to check your cache directory.

var/cache needs to be writeable

If it is writeable, try deleting it's contents and running http://www.yourdomain.com/cron.php again and seeing if it populates cron_schedule in your database.

In the instance that it works briefly, but either stops generating or only generates half of the schedule, then it's time to look at your permissions.

Check to see which user is creating the files in var/cache

It maybe that your PHP or PHP-FPM is configured to use the wrong user. It could be using apache/apache as the initial file user/group.

Magento Downloader - Insufficient Permissions Using FTP to update Magento Connect

You've set your downloader directory in Magento to use FTP to update files in your Magento installation. You can confirm that your username, password and root are correct in the settings, but still receiving the error "Please check for sufficient ftp write file permissions", then you may want to check a few things.


Check to see if those directories and files are writeable.

Try and run Magento Connect again.

If this saved you hours of work or saved you from a headache, feel free to buy us a beer.

Magento Suddenly Redirects To Installation Wizard

Redirecting to the Magento Installation Wizard is down to local.xml not being load correctly or even at all. If local.xml doesn't exist or isn't readable or contains errors, it will more than likely redirect you to the installation wizard, under the impression there is no existing installation.

Although this error to do with Soap has been patched in Magento, it's not always practical to upgrade to the most recent version, so I'm going to break down the error and what's going on.

In you var/report directory you will probably start seeing a huge increase in files with the following error "Front controller reached 100 router match iterations"

If your magento installation of years is suddenly redirecting to the Magento Installation Wizard and you can't get your site back without doing a php restart.

This problem is evident in php 5.3 - 5.5 and is caused by simplexml_load_string() and Zend.

The source of the problem is normally from a problem with Soap. Everytime the Soap URL is called on an installation that has external entity loading turned off by default (As it should be).

This triggers libxml_disable_entity_loader(true) and the local.xml file is no longer readable, so it redirects the customer to Magento Installation Wizard, because it doesn't detect that there is a valid install.

Things to do.

A) Test out your installation to see if you are vulnerable to this problem. Create the following file and run it in your browser.

Test script:


$xml = simplexml_load_file('foo');


Expected result:

Actual result:
    [0] => LibXMLError Object
            [level] => 1
            [code] => 1549
            [column] => 0
            [message] => failed to load external entity "foo"

            [file] => 
            [line] => 0


B) Download Magento Navigate to lib/Zend/Xml and lib/Zend/Soap

Upload lib/Zend/Xml to your server (This is a new directory, no overwritting required)
Upload lib/Zend/Soap/Server.php to your server (Overwrite the existing file)

C) (As a precaution) On your live server, download Mage.php in /app directory

Find public static function isInstalled 

Look for 
$localConfig = simplexml_load_file($localConfigFile);

Change it to the following

$localConfig = simplexml_load_file($localConfigFile); 

If this saved you hours of work or saved you from a headache, feel free to buy us a beer.





Installing patch SUPEE 6788 on a pre store causes this error for you. What to do you ask?

Download (No, I'm not going to say install it)

Upload app/bootstrap.php

and replace the index.php file with the one from (unless you've customised index.php) If you've customised it, add load app/bootstrap.php in index.php

All fixed... So what do you do now with all the money you've saved (beer buying time, see link above ;)

Mage registry key already exists when firing events

You will receive Mage registry key already exists when firing events error if <events> is inside <global>

#### This is no good ####


Move it to either <frontend><events> or <adminhtml><events> outside of the <global> tag to fix.

#### Correct Structure ####




If this saved you hours of work or saved you from a headache, feel free to buy us a beer.