Archives For PHP

Trials and tribulations of coding with PHP, sometimes I like it sometimes I hate it. In either case I’ll post my experiences here.

This article will give an overview of Magento extension clashes (sometimes called conflicts) and then run through a few ways you can find them in your installation.

I get asked at least once a week a question like ‘What is a Magento Extension Clash‘ or ‘How Do I Find Extensions that Conflict‘. So, if you’re reading this, you probably just asked me, and I probably just sent you a link to here. That was a bit meta-blog, sorry about that. On with the article.

What is a Clash?

Magento extensions can override core functionality using what’s called a class rewrite. That’s when your extensions configuration file tells the core of Magento to use your custom PHP class, instead of the core one. Typically the custom class will sub-class the core one, and only override the methods that need to be changed. Here’s an example of that, firstly showing a snippet of rewrite xml for a core model:

<!-- ... snip config.xml ... -->
        <models>
            <core>
                <rewrite>
                    <email>Aschroder_Email_Model_Email</email>
                </rewrite>
            </core>
        </models>
<!-- ... snip config.xml ... -->

And then the corresponding class, notice it overrides the core version:

 
class Aschroder_Email_Model_Email extends Mage_Core_Model_Email {
 
// only add methods here that override the ones we want to change in Mage_Core_Model_Email
 
}

So that’d all be well and good if everyone only installed my email extension in their Magento store, but they don’t. They install PDF email attachments, email emoticons, email monkeys and god knows what else. So the rewrite that my extension needs to work, may very well not happen, because another extension rewrites the same class.

The same sorts of things can happen all over Magento, and typically the bigger and more complex and extension is, the more rewrites it will need, and the bigger the surface area for conflicts and clashes.

You might be thinking: “Gosh, it’d be great if Magento Connect ran some sort of rudimentry test for compatibility before installing extensions willy-nilly in Magento Stores” and if you are, that means you’re one of the Good Guys™.
Continue Reading…

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 https://raw.github.com/mxcl/homebrew/go)"

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.

This is just a quick post that shows you how to edit or disable the checkout fields in Woothemes WordPress shopping cart Woocommerce. It may make all the Magento developers jealous to see how nearly trivial it is – but I couldn’t see a good blog post explaining it, so here goes.

Disabling and Editing Checkout

To use the WordPress API, I made a simple little plugin that listens for the filter event and then makes some changes to the arrays.

The anatomy of a plugin is really just a class definition, in the constructor you listen for events and bind them to functions of that class. In those functions, you do the real grunt work. In this case, that’s where I weed out disabled fields, and swap in my edited field definitions.

Hopefully the way the code is laid out makes the actual editing/disabling is performed self-evident. To see the full range of available fields and options, please see the underlying array declaration in the core file woocommerce/classes/checkout.class.php.

My class looks like this:
Continue Reading…

If you are reading this, you are an unwitting participant in my latest experiment: clustering my blog on Amazon EC2 – thanks! You will be connecting to my blog on one of several Amazon EC2 micro instances, cobbled together in a quick and dirty solution that was more knee-jerk reaction to some downtime, than well thought out project.

This post serves as a chance for me to test if the cluster works, and a summary of the architecture I have set up using several EC2 micro instances and WordPress. It’s a quick and dirty little WordPress cluster using spot-request micro instances at $0.007/hour – how fun!
Continue Reading…