So there’s basically two ways to instantiate a Magento block. The one that should work everywhere is:

And then there’s the one which you can use in a controller which extends, for example, Mage_Core_Controller_Front_Action

vultr-logoSo I changed from DigitalOcean to VULTR hosting and decided to go ahead and switch from CentOS 7 to Ubuntu 15.04. I also changed to HHVM since that was not possible on CentOS 7 unless I compiled it manually which I couldn’t be bothered to do. An upgrade to Nginx 1.9.* made it possible to use HTTP/2 instead of SPDY, so I am basically totally up to date when it comes to the latest technologies.
Wordpress was also upgraded to 4.4.

I must say I’m very happy with VULTR, I did some compilation benchmarks using OpenBenchmarking, the results can be found here:,1508186-SNEK-SNEKVPS64

If you want to sign up to VULTR please use my affiliate link:

I was trying to install the Afterpay module for Magento and ran into the following problem:

I read various topics mentioning a lack of MySQL tmp dir space, but since the tmp dir was on the root partition of the server that wouldn’t be the problem. Then I read about InnoDB corruption and someone listed a tiny little script which uses innochecksum to check the tables. This fixed my problem quickly and efficiently so I decided to log it here.

Turns out there is a slight undocumented change in the latest PATCH SUPEE-6788 which caused problems for almost all of our Magento clients: the password reset link that got mailed to customers directed them to a page with no form to actually reset the password.

Turns out a change was made to customer.xml which causes this if you have copied over customer.xml to your own store views. customer_account_resetpassword was renamed to customer_account_changeforgotten and the block type was also changed.

The exact changed are outlined here:



I expected compiling of PHP 7 to be more difficult considering it was still an RC1 release and Ubuntu Vivid is not an LTS release. However, it turns out compilation of PHP 7 actually requires more new packages so it was easier than on 14.04 Utopic.
From what I could tell you only need to have two packages installed: build-essential and libxml2-dev. I might have already had extra packages which were required because this is a fully setup desktop for development, so it already includes nginx & hhvm.

The steps to follow are pretty slim and should hopefully be sufficient for most:

And that should do it.

A client mentioned that he kept having to reindex the Product Flat Data but the notification in the admin section never went away. While trying to reindex from command line I was greeted with the following error:

Turns out this problem was caused by products which were deleted but still existed in the product flat data table.
To find these products you can run this query:

In this case it was nearly 80 products! To fix it you can just delete them with this query:

So we have a project which has two different database connections. After having read on the web for a bit I didn’t run into the ideal solution to inserting into a table which was not in the default database. It turned out to be pretty simple though:

So we stumbled onto this problem with a new customer who was using a module called Techtwo_Mailplus. When trying to make a rest connection HHVM would cause the following exception to be thrown: Invalid chunk size “” unable to read chunked body. This did not happen with their old server which ran bog standard PHP DSO. Now, I was not looking forward to debugging it because it’s a complex module and the error eventually ended up in Zend_Rest_Client after tracing it through 4 other files and multiple functions in those files. However, I stumbled onto this post which gave me the solution:

To fix the Techtwo_Mailplus module I edited app/code/community/Techtwo/Mailplus/Helper/Rest.php and around line 160 you will find:

This is the spot where you can add the fix from the Zend post. So just add it to the end of this part so it looks like this:

I don’t have time to figure out exactly why this happening but forcing HTTP version 1.0 seems to “walk a different path” in Zend Framework and doesn’t hit the part that causes the error.

During an import I managed to get the order wrong of the selectable attributes of some Magento Configurable products. So I had to change the sort order of the Magento configurable attributes. It took me a little while to figure out how to fix this but it as pretty easy actually. You can find the function below which will loop over all configurables and set a new position value if there are more than 1 attributes. It does not seem to matter if position is greater than the amount of attributes or if it skips a number.