September 21, 2020

cm-mini

Thinking Magento

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 1.9.1.0, 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:
---------------
<?php

libxml_use_internal_errors(true);
libxml_disable_entity_loader(true);

$xml = simplexml_load_file('foo');

print_r(libxml_get_errors());
var_dump($xml);

Expected result:
----------------
Array
(
)
…

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

            [file] => 
            [line] => 0
        )

)
bool(false)

B) Download Magento 1.9.1.0. 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

libxml_disable_entity_loader(false);
$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.

REFERENCES

https://bugs.php.net/bug.php?id=62577
https://bugs.php.net/bug.php?id=64938

http://framework.zend.com/issues/browse/ZF-12436
https://github.com/zendframework/zf2/pull/6200 

UPDATE:

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

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

Upload app/bootstrap.php

and replace the index.php file with the one from 1.9.2.4 (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 ####
<global>

    <events>
    </events>
</global>
##################

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

#### Correct Structure ####

<frontend>
   <events>
   </events>
</frontend>

<adminhtml>
    <events>
    </events>
</adminhtml> 

##################

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

FREE MagentoGo Migration to CE

Time is running out for store owners who are still on MagentoGO. If you need someone to handle your migration, head on over to Nimbus Hosting and start the migration before the new year. February 2015 is closer than you think.

The migration process should be fairly quick and they'll be able to move your categories, customers, orders, products and attributes and attribute sets.

For more information, checkout their website

Tell them you came from Creative Media!

 

 

Magento - Unable to communicate with the PayPal gateway

Your customer is trying to checkout with Paypal and the error they received is Unable to communicate with the PayPal gateway.

One of two things may have happened.

- Your webhosting company has applied a patch for the ShellShock Bug and forgotten to restart Apache / NginX
- Your certificate is no longer signed by one of the trusted root certificate authorities

To fix the root certificate problem you will need to have ROOT access to your server to execute the following

First, backup the old bundle:

cp /etc/pki/tls/certs/ca-bundle.crt /etc/pki/tls/certs/ca-bundle.crt.bak
Then download the new bundle:

wget -O /etc/pki/tls/certs/ca-bundle.crt http://curl.haxx.se/ca/cacert.pem

Restart Apache / NginX / PHP

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

Fatal error: Allowed memory size of XXXX bytes exhausted - Sales_Order_Collection Grid

Are you suddenly receiving the error Fatal error: Allowed memory size of XXXX bytes exhausted when viewing a grid in the magento admin, which uses sales order collection data?

Symptons: The admin grid loads correctly, however the footer does not appear to load. Right click on the page and go to view source, scroll down to the base of the source code page where the code ends you should see the Fatal Error:

The problem could be much easier than you could ever hope and caused by Mass Action and the Select All option.

When select all is enabled on an admin grid, it appears top left of the grid, next to select visible and it pre populates the javascript mass action with ALL of the row ID's and can be quite a memory strain on your server.

Find the grid.php file that is causing you problems (It may not be called grid.php if it is in a custom module) and locate the _prepareMassaction() function

In _prepareMassaction() you will need to add the following code to disable the select all button and save on server resources.

$this->getMassactionBlock()->setUseSelectAll(false);

So your code could look something like this

$this->setMassactionIdField('entity_id');
$this->getMassactionBlock()->setFormFieldName('form-name');
$this->getMassactionBlock()->setUseSelectAll(false);

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