Name-tag-admin-1000
So here’s a little snippet which lets you Add Magento admin programatically. This comes in VERY handy if your client doesn’t give you the admin login to their website (in time). I’m impatient and don’t want to have to go through the hassle of sending mails which will get bounced around a few people before reaching the appropriate person who can give me an account.

This was stolen from some other place on the web, who probably stole it from somewhere else again 🙂

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:
http://openbenchmarking.org/result/1512022-SNEK-VULTR2G18,1508186-SNEK-SNEKVPS64

If you want to sign up to VULTR please use my affiliate link:
http://www.vultr.com/?ref=6862103

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:

customer_account_changeforgotten

php7

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.