Archives For PHP

In my previous post I weighed up the benefits and limitations of Amazon’s Elastic Beanstalk hosting environment for Magento and took a very vague look at the costs. In this post I will run through the actual setup of a very basic Magento install ‘in the cloud‘ and the process of deploying changes. The goal for this initial setup is to keep everything bone stock as possible, we want minimal maintenance effort and an automated environment.

If we have some time at the end, we’ll do some stress testing of the platform to see how it handles customers. Benchmarks will have to wait, stay tuned.

The Tools

For this tutorial we’ll be working in a linux environment. I used a small EC2 server with the AWS default Linux AMI as the setup box, it’s nice and fast being on the same network as the Beanstalk platform. Make sure you have the following installed.

  • AWS EB tools, and the getting started guide
  • git, sudo yum install git
  • ruby, sudo yum install ruby
  • python 2.7, sudo yum install python27 – this one is a bit of a pain on the AWS default Linux AMI, you’ll need to hack in explicit use of the 2.7 binary in the AWS scripts. Or, heaven forbid, set it up properly and compile from source…

Once you have those in place, you should be ready to get Magento and the Beanstalk environment setup.
Continue Reading…

I’ve been a long time MAMP user, but I recently upgraded my laptop and decided to do a fresh install of everything, and a ground up re-configuration of all my dev environments (a fair bit of mucking about with PHP, Ruby, Java, Python and trying Go).

After a short while researching it became clear the best tool for the job would be Homebrew – it gives you much more control of the environment than MAMP, without the Macports heartache.

In this post I’ll run through using Homebrew on OSX Mountain Lion for a Mysql+PHP CGI setup – I’ll document adding a webserver to this stack in a later post, my immediate need is for a PHP CGI environment.

Setup Homebrew

Before you do any of this, go grab Xcode from the App Store. Hope you’re not on a 3G internet connection, it’s a 1.6GB install! Go grab a coffee while you wait. After that’s installed you’re also going to need to go to Xcode > Preferences and install the command-line tools, another 100+ MB install.

The Homebrew install from their own site is just:

ruby -e "$(curl -fsSL"

Setup PHP

Homebrew uses the tap command to import more sources for install scripts. See what they did there? I use the homebrew-php project, seems awesome – loads of support, docs and info on the project page, all going to plan you’ll just need these two commands below.

brew tap josegonzalez/homebrew-php
brew tap homebrew/dupes

You can review all the options with the brew options php54 command, if you want mysql and CGI, use the command below that I used.

brew install --with-mysql --with-cgi php54

It’ll run through a bunch of downloading/compiling steps but the end result should be that you get the following test output:

/usr/local/bin/php-cgi --version
PHP 5.4.12 (cgi-fcgi) (built: Mar 19 2013 14:39:37)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies

Setup MySQL

It’s super easy, watch.

brew install mysql

Then just follow the instructions that get blurted out during the Homebrew install of mysql.

Slight catch is, if your OSX is anything like mine you’ll need to run this first:

mkdir -p /usr/local/var/mysql
unset TMPDIR
mysql_install_db --verbose --user=`whoami` --basedir="$(brew --prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

I also got this warning:
WARNING: Found existing config file /usr/local/opt/mysql/my.cnf on the system. which you can safely fix with:

#backup existing
mv /usr/local/opt/mysql/my.cnf /usr/local/opt/mysql/my.cnf.old
#move new
mv /usr/local/opt/mysql/my-new.cnf /usr/local/opt/mysql/my.cnf

There’s also a lot of good advice for securing your mysql install blurted out during the install process, ignore it at your peril. Test your handiwork by checking you can access the mysql commandline prompt:

mysql -uroot
# or, with the password you set. You set one, right?
mysql -uroot -p

Other Notes

I noticed that the Homebrew installed PHP didn’t seem to support $_ENV in scripts, instead the $_SERVER array seems to be used – the Macports PHP with CGI support did seem to work with $_ENV. It might be a subtle version difference, I’m actually not sure, and decided not to spend time trying to figure it out. Just update scripts that depend on $_ENV, to use $_SERVER. If someone knows what’s behind this, please share.

So, that should be it, PHP with CGI support and MySQL installed and ready to rock. If I missed anything let me know.

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.
Continue Reading…

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

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() []: 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
#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 (, 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!