June 04, 2020


Thinking Magento

Magento 2 - The Elephant We Try To Ignore

To this day, we still can't get our heads around the choice to develop an entirely different, more complicated version of Magento and we have been trying to keep an open mind.

But it's there, this great big elephant standing just a few feet away from us, telling us that we should either jump on or be trampled on.

We've been onboard with Magento since the very very early days of 07 / 08.

The great versions stand out to me as the stable ones (Once you tweaked them),, & 

From 1.3 to 1.4 it was a great leap and caused many headaches as the database structure for sales orders took on a whole new structure. As a live database took 8 hours to very very slowly migrate all the sales data into the new 1.4 tables.

On a personal level, these migrations took their toll, until you find the corner stone versions of Magento that you're happy with and then everyone in the client list gets an update to that rock of a version.

The learning curve is much much much much smaller these days for Magento 1. A mistake can be fixed pretty quickly and it's only the patches that sometimes cause the headaches, but for the most part they are stable.


Magento 2, we're not prepared to go in on the ground level this time around. We're not as young as we once were and the overheads are much much greater, we now have families and we're still not convinced it's what's needed to survive.

A lot of opinion pieces we've read are all about scaring people into jumping to Magento 2, the security is what you'll see written down regularly.
But these people don't seem to understand it was the community that helped develop and bug find Magento 1 into the fine piece it is today. It is regular human beings who are out there bug finding and figuring out patches. That doesn't just end when there is a community behind you. (Some of that community did get lost in the archives of the old forum)

We say that Magento 1 shouldn't just roll over and play dead. An MS Excel / Word or Photoshop user is never forced to give up their skill base because the program has been redeveloped so that they can no longer use it and must find alternative software. (Some will say, apples / pears), but is it? You can class yourself as an experienced photoshop user and quickly perform bread and butter jobs to financially keep you going. But now, as Magento Developers we are told it's either do or die. Is that what is left of the community?

As for the elephant, perhaps it will change course before it tramples us to death.

-- forum member elfling --

Magento Enterprise - Full Page Cache & Messages / Notices

Just a quick one about Magento Enterprise Full Page Cache.

Recently I noticed that the Enterprise PageCache wasn't hole punching notifications to the customer, so it would just reload the page without displaying the notice. But if the customer went on to do something else, such as a search, then the notice would appear. "This product is not available in the requested quantities"

So taking a look at the theme, I had a quick look to check for the issue.

In the catalog/view.phtml on the product page, is the following to get the message block

<div id="messages_product_view"><?php echo $this->getMessagesBlock()->getGroupedHtml() ?></div>

and after checking through a more recent version of Enterprises theme files I notice a difference and updated it to the following

<div id="messages_product_view"><?php echo $this->getMessagesBlock()->setEscapeMessageFlag(true)->toHtml() ?></div>

Now messages are displayed to the customer without being cached.

Update Product URL's Programmatically with 301 redirect

Recently I needed to update the URL's of existing products, without losing the 301 redirects. There are ways of course of doing this with extensions and uploading CSV's to extensions, however I decided to take a different route and update the URL's programmatically. 

Created a PHP file and placed it in root, in this case we can call it URL_UPDATER.php and added the following code. Set the ID's that you would like update to avoid overloading your database. Job don.


require_once 'app/Mage.php';
/*Set store to be admin so that you the URL change affects global*/

/*Build collection of products*/
$collection = Mage::getResourceModel('catalog/product_collection');

/*Set the product ID range of products you would like to adjust 7157 - 7357*/
$collection->addFieldToFilter('entity_id', array('gt' => 7156));
$collection->addFieldToFilter('entity_id', array('lt' => 7358));

foreach($collection as $id) {

/*Get the ID of the product to load*/
$load = $id['entity_id'];

/*Load the product*/
$_product = Mage::getModel('catalog/product')->load($load);

/*New URL based on product name*/
$new_url = Mage::getModel('catalog/product_url')->formatUrlKey($_product->getName());

// save rewrites history for old to new url redirect
$_product->setData('save_rewrites_history', true);

// set new url

// set new url path

// save the product


Daylight Savings and Magento - date_default_timezone_set problem

A strange situation I've noticed can happen if you directly use date_default_timezone_set anywhere in your PHP code.

I had this set in an Observer.php file that was activated by cron.php / cron.sh.

Once this script was activated it changed the behaviour of the cronjob timestamps.

A job that started at 9am would finish not at 9AM, but finish at 10AM.

I then noticed that in using date_default_timezone_set in s script to look for products that were on sale, it again was changing timestamps in the database.

Finally I noticed that order date/time were sometimes in the future and sometimes not. This again came about due to date_default_timezone_set  was being used against shipping methods and when those methods would be available.

Removing date_default_timezone_set removed this timezone problems and there was no need for any work around to get Magento to work with BST.

However, you still need perform a datetime lookup in your code, which means you can do one of a few things.

Either you can use the following to check date and time for BST/GMT stores

date('Y-m-d H:i:s', Mage::getModel('core/date')->Timestamp());
date('H', Mage::getModel('core/date')->Timestamp());

Or you could use something a bit more complex, however does the job as well.

$tz = new DateTimeZone(Mage::getStoreConfig('general/locale/timezone')); 
$theTime = time();$transition = $tz->getTransitions($theTime, $theTime); 
$i = $transition[0]['offset'];
date("Y-m-d", time() + $i);

Warning: simplexml_load_string(): Entity: line parser error : StartTag: invalid element name

So you've enabled your Magento cache and your var/log/system.log file is starting to fill up with entries. This is because it's just built a cache of your config.xml, system.xml & adminhtml.xml files and there is an error in one of them.

StartTag: invalid element name - This is often simple because the xml element starts with a number, but could be a symbol etc

Can we be sure it's a configuration .xml file? Yep, because of the following error lib/Varien/Simplexml/Config.php

Navigate via SSH to your app directory and run

find . -type f -name "*.xml" -exec xmllint --noout {} \;

This will validate your xml files and find the bad one... hopefully.

Unfortunately Magento throws a spanner into the works that you should also be aware of  the table CORE_CONFIG_DATA in your database. Magento takes the path value of each entry and converts it to an XML. So in your core_config_data table, you may see postcode/license and Magento will convert this to <postcode><license>

However if an old module corrupted or was badly formed when it was saved, you may find something with a path like 2DSoR0swfgww77YzlyE0EsGDiyjUIE4G, which would create an XML value of <2DSoR0swfgww77YzlyE0EsGDiyjUIE4G>, which is invalid anyway but also doesn't pertain to a modules configuration.

Delete this entry from your core_config_data table and you will be steam rolling along again

Page 1 of 9