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.

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:


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).

After importing lots of data into Magento I had problems reindexing. I had no experience with fixing indexing errors Magento before and digging through the EAV structure in MySQL is not something you look forward to. Turns out there was a pretty easy fix for this which basically makes sure that all the tables are actually linking to an existing product. If there is a link to a product that doesn’t exist (anymore) for some reason you can expect to see errors like:

It’s as easy as running the following SQL commands:

Original post where I found this:

Moved logo-centos-7distro again because I somehow managed to break MariaDB on Ubuntu.. So instead I’m back to Percona on CentOS, which I upgraded to v7 now. CentOS 7 WordPress with Percona and Redis! Mind you I am not running HHVM anymore so the site will be slower. Turns out there’s a memory leak when it comes to Crayon, the syntax highlighting plugin I use. I have to look for a nice caching solution, preferably using Redis..

UPDATE: Found my redis solution! https://github.com/BenjaminAdams/wp-redis-cache
Without being logged in the blog loads in 13ms now, that’s even faster than varnish 🙂

UPDATE: Turns out I was overloading my VPS and the dreaded OOM killer struck and killed Percona. So I’ve upgraded to a 2GB VPS and I’ve added DataDog monitoring to Nginx, Percona and Redis just to see what’s going on. Here’s an example of my dashboard at DataDog. It’s a bit of a build it yourself NewRelic and free up to 5 hosts!



You can quickly delete all Magento products using this collection of queries.
UPDATE: Added removal of reviews & ratings!

This works for me under

Thank you Marius for this one! Something went wrong during an import and this saved a lengthy slow fix function which would take at least a whole day to run.