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: http://framework.zend.com/issues/browse/ZF-741

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.

I saw this error today while updating a shop to Magento while trying to re-index from the commandline using the indexer.php, turns out it was as easy to solve as just flushing the cache. In our case a redis-cli flushall but always make sure Magento didn’t spontaniously create a var/cache dir or even a dir in /tmp/, it likes to do that if your config is not rock solid.


Another version of Magento ( was released and this one promises some welcome fixes!

As always here’s a download link off my VPS which should be faster than the official download location:
md5sum: 79ca01aa9736a402e68ec34361222b96 magento-

The full release notes can be found here:

The most notable changes/fixes for me are:

  • Magento Community Edition 1.9.1 works with MySQL 5.6 and PHP 5.5
  • Improved product save performance with a large number of rule-based product relations.
  • Catalog price rule expiration dates are observed.
  • Improved indexing performance.
  • The Update on Save option works properly (reindexing is not required).