Archives For April 2013

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 ... -->
<!-- ... 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…

In this post I’m going to introduce Amazon’s Elastic Beanstalk PHP environment as a platform for Magento. In particular I’ll cover the mechanics and economics of hosting Magento, along with it’s benefits and limitations as a platform. The goal here is to create an auto-pilot environment providing high availability and scalability.

But first, the background. With World Wide Access, we’ve always run our own EC2 instances, ELBs, database servers and memcached. We scale up the instance sizes or counts manually when required. When we started using AWS (in 2008) Elastic Beanstalk was not yet on the scene so we had no choice but to do it that way. But now we do have a choice and, thanks to some downtime in the last week, I’m prompted to gather some thoughts on a migration to a fully auto-pilot set-up. This post is my notes on Elastic Beanstalk and Magento with git for deployment. I’ll add a more detailed setup guide and some benchmarks in a future post – this one will be a bit more abstract, so go make yourself a cuppa.

About the Amazon’s Elastic Beanstalk

Beanstalk brings together various parts of Amazon’s infrastructure: AWS servers, scaling, load balancing and high availability, to give your applications an automated environment to run in with flexible server sizes and instance counts that make growing easy. You can do all the things Elastic Beanstalk does, by combining the separate parts yourself, but this is much easier, trust me.
Continue Reading…