ASchroder.com

Th old Ashley would never say this, maybe I’ve been working with PHP too long, but seriously, I’m going to have to side with the dynamic language crowd on this one – I think I have been spending too much time developing with Magento!

After an Eclipse upgrade a whole raft of my unit tests started failing to compile with the error: The method assertEquals(Object, Object) is ambiguous for the type. What this means is I’m passing an int and and Integer into a method that has two different signatures: assertEquals(Object, Object) and assertEquals(int, int) both of which could be called, thanks to autoboxing.
Read more…

Ok, that’s not a really good post title, because it’s actually a PHP error, nothing to do with Magento as such. You’ll only see it on certain systems when PHP is set to report warnings like this (E_STRICT). I’m bundling this into the Magento category because it happened to me when installing Magento on a reasonably simple Ubuntu 8.04. I thought it might be handy to quickly document the solution for other Ubuntu users.

The problem will look like this in Magento:

It is not safe to rely on the system's timezone settings error in Magento

Which spews out a whole lot of stuff, the most important of which is the message ‘It is not safe to rely on the system’s timezone settings’ and later the suggested timezone, in my case ‘Pacific/Auckland’:

There has been an error processing your request.
Strict Notice: date() [function.date]: It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'Pacific/Auckland' for 'NZST/12.0/no DST' instead  in /var/www/magento/app/code/core/Mage/Core/Model/Locale.php on line 498
Trace:
#0 [internal function]: mageCoreErrorHandler(2048, 'date() [storeTimeStamp('1')
#3 /var/www/magento/app/code/core/Mage/Catalog/Model/Resource/Eav/Mysql4/Product/Collection.php(318): Mage_Catalog_Model_Resource_Eav_Mysql4_Product_Collection->_joinPriceRules()
#4 /var/www/magento/app/code/core/Mage/Eav/Model/Entity/Collection/Abstract.php(779): Mage_Catalog_Model_Resource_Eav_Mysql4_Product_Collection->_beforeLoad()
#5 /var/www/magento/app/code/core/Mage/Catalog/Block/Product/List.php(151): Mage_Eav_Model_Entity_Collection_Abstract->load()
#6 /var/www/magento/app/code/core/Mage/Core/Block/Abstract.php(642): Mage_Catalog_Block_Product_List->_beforeToHtml()

The fix is in your php.ini file for Apache. You’ll need to have the permissions required to edit the php.ini file, on Ubuntu that means you’ll probably need sudo access, or root access on systems where you actually log in as root. You can edit the file using this command:

sudo vi /etc/php5/apache2/php.ini

Or if you prefer a slightly less convoluted text editor (but much less powerful):

sudo gedit /etc/php5/apache2/php.ini

The change you need to make is to find the line like this:

; Defines the default timezone used by the date functions
; date.timezone =

To this:

; Defines the default timezone used by the date functions
date.timezone = "Pacific/Auckland"

Of course you may want your timezone, not mine, in which case you should substitute "Pacific/Auckland" for you timezone!

Hopefully that helps others who encounter this problem. The tricky thing is it won’t manifest itself on the CMS homepage, so you might do an install and think everything is fine, only to find that when you finally add categories and actually view one of them, Magento breaks (well… PHP does). So be wary.

You need to run PHP 5.2.0 or newer for Magento. This is normally not a problem for MAMP but a recent reader has asked about determining which version is running on their Mac when this error does occur. I just wanted to make a quick post on checking PHP versions in MAMP, because it seems if your Mac has other versions of php installed you can end up having odd results when trying to run Magento in MAMP.

You can determine which PHP version your MAMP server is running by opening the MAMP ’start page’ and clicking the phpInfo link in the top menu. This will also tell you which php.ini file is being used.

You can also run:

 php -version

Run this in a terminal (Terminal.app), to print the PHP version that is on your PATH. You can determine which php is being run by typing:

which php

To find any php binaries on your Mac you can run the locate command in a terminal:

locate php | grep "[^\.]php$"

The pipe into grep just filters out any files that have php in the path, but are not php binaries, and also removes any files that are of the form filename.php which would otherwise turn up in the search.

You can execute any of the php binaries this command finds with the argument -version to find out what version of PHP it is. This may help you to identify any versions of PHP you have installed that you do not want anymore.

For example:

/usr/bin/php -version
/Applications/MAMP/bin/php4/bin/php -version

If anyone has any other tips for solving this or questions please post them below. Hopefully we can make sure this problem doesn’t trip anyone else up!

I have said some not very nice things about PHP on this blog, and I’m sure over time I’ll be adding more such criticisms. This time I’d like to highlight a handy little feature in PHP, one that is a great deal easier to use than it’s Java counterpart.

Shuffling the elements in an array is probably a programming exercise in every single 1st year computer science textbook, it’s easy enough to do, but because it’s been done roughly 100 million times before, it feels moronic doing it again. So it’s nice when programming languages offer it as standard language functionality. PHP does by way of the shuffle() function and Java does by Collections.shuffle() static method. Seems simple enough, except that an array is not a collection in Java. So you can’t take your int[] and shuffle the elements quite so easily.

If you have an Integer[] in Java you can just pass it into Arrays.asList(array), get the collection and shuffle it. Uh oh, I said Integer[] which sadly is not the same as an int[]! So the difference between the two means I’m going to need to convert all the elements of the int[] into a Integer[] before I can shuffle it, geez, if I have to iterate the list once to convert type, I may as well just not put them back where I found them!

So this is me admitting there is an advantage to a dynamic language. I maintain I’d still rather pay the upfront cost of a few extra lines of code here-and-there for type safety, try getting a PHP IDE to reliably autocomplete instance methods for you, when it doesn’t know the type of a variable! Perhaps I need to start using Eiffel…

I was recently asked for help on a Google Checkout problem where the Google Checkout Button on the Magento cart page was disabled with a message saying: “Not available with these items“.

I had a look at the Magento store in question and found a few clues to go on but a
Google search on the subject proved to be of little help unfortunately. The button looks like the one shown in the screenshot below:

The disabled Google Checkout button on the Magento cart/checkout screen. It looks like the normal one only greyed out.

The underlying URL for the button is:

 <img src="https://checkout.google.com/buttons/checkout.gif?merchant_id=5677186919&amp;w=180&amp;h=46&amp;style=white&amp;variant=disabled&amp;loc=en_US" alt="Fast checkout through Google" />

The big clue was the parameter on the Google Checkout button image URL on the problem store. It had variant=disabled which is generated server side, and so had to be coming from somewhere within Magento. A big fat grep over the code uncovered a variant=' string fragment in Link.php.

Read more…