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.


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

Magento Configurable Option UpdateFor a project I had to figure out how to update options of a configurable product in the Magento Cart.

Considering the code from the famous Inchoo post from 2009 does not work anymore in Magento 1.8+ and I managed to get it working I decided to document the function for my fellow Magento developers out there on the interwebs. The code from the Inchoo post does change a few parts of the quote item but misses a few vital parts like changing the SKU. So on the frontend you might think it has properly changed the product, it will even show up fine in your cart, but once you checkout it will still use the old product! Turns out there’s a cart function called updateItem which can not only change the quantity but also the selected option of configurable.

Hope you’re all happy with this one, it took one of our developers more than 2 weeks to not get it working and I managed it in a day, once again. Mind you, a day is still frustratingly long for me, hence the post because everyone should be able to save that amount of time while working in a project..

The function I wrote to update options of a configurable product in the Magento Cart

To update the flavor of a configurable project we currently use a url like this:

Some explanation of the various variables you’re supposed to pass to the function:

  • $superAttributeId is the id of the attribute, in our case flavor which has id 175.
  • $childId is the id of the selected option of the attribute
  • $itemId is the id of the item in the cart
  • $productId is the id of the actual product, in this case the configurable
  • $refresh: if set will force the current page to refresh after updating the cart (handy for cart page since you want to not only refresh the ajax cart but also the whole cart page)

I cleaned up the code while writing the post so an error might have slipped in during the process, if you find anything wrong with it please don’t hesitate to comment and I will fix the code

These days it’s very uncommon for websites to user usernames and most sites just use the user’s email address.

Laravel has many, many very handy packages we can use to quickly get up and running and save us countless hours when developing a website but sometimes they do not do exactly what we want. In this case I relied on a package called Confide by Zizaco, commonly referred to as Zizaco/Confide. It started off pretty great with me having user creation, login, password reminders etc all working within 30 minutes. However, Zizaco/Confide heavily relies on the existance of a username for creating users and logging in. To get around this you will have to extend Zizaco\Confide\UserValidator and override $rules and also extend Zizaco\Confide\EloquentRepository and override the function getUserByEmailOrUsername.

To do this you can create a file in app/controllers with two classes in it and modify app/start/local.php to re-bind the Confide classes to your new ones so the original classes get overridden.



UPDATE: Had to override the function validateIsUnique as well which required me to “use Zizaco\Confide\ConfideUserInterface;” to get it to work. Code fragment updated to reflect the new situation.

If you ever experience the error ERR_INCOMPLETE_CHUNKED_ENCODING in WordPress (you should be able to find this in your Nginx error log) then you should check the following things:

  • Nginx and PHP-FPM should both be run as the same user
  • The directory /var/lib/nginx and all underlying directories should be chowned to that user

I my case Nginx and PHP-FPM were both running as Apache, but the directory /var/lib/nginx was owned by nginx:root. This meant the dir has to be chowned to apache:apache to fix the problem:

Don’t forget to restart nginx & php-fpm to be on the safe side.

laravelSo I am developing an invoicing system in Laravel and ran into the problem that I couldn’t figure out how to pass validation errors to the master template in Laravel. Normally you can only Redirect::to()->withErrors($validator); and I wasn’t trying to Redirect but output them straight to the View. After having read a few silly solutions which involved View::make()->with(‘errors’, $errors); and then writing a whole new foreach loop in the view instead of the template. That is clearly not an efficient solution since I would mean copy/pasting code from the template to the view.

Doing the following does not work:

So I figured out you can share a variable across all currently loaded views/templates.

Here’s the piece of code that works for me now:

So I get the validator messages and store those in a variable $messages. I then “share” that variable as $errors across all views and my template picks it up in the following piece of code:

In case you are searching for why you can still get a 504 gateway timeout when you have already increased max_execution_time in php.ini: try adding this to your fastcgi_params file:

UPDATE: Turns out this was also happening when we were running an Nginx + HHVM server. Of course I went searching for a max_execution_time value but as far as I could tell HHVM doesn’t have that and it turned out to be this nginx timeout once again.