Patrick Ward words, code, and music

Magento Development Environment

Each time I have to work with Magento, I take a few minutes to set up the development environment. These steps ease some of the pain when Magento doesn’t work the way you expect it to and you have to dig down into troubleshooting mode.

Turn On Developer Mode

Magento has an IsDeveloperMode flag that overrides Magento’s default handling of errors. In normal mode, Magento will handle exceptions by logging the exception to a report under /var/report and then redirect the browser to a page that display’s the report id. This is great if you’re in production, but when you’re actively developing an extension or working on a site, you need immediate access to the error that ocurred.

Thankfully, the index.php file within the Magento root let’s you turn Developer Mode on. When active, Developer Mode tells Magento to skip the report writing and display the exception directly to the browser.

However, in the most recent version of Magento (v1.7.x at the time of this article), Magento also comments out the PHP directive display_errors and lists it separate from the server flag that turns developer mode on.

So, I modify index.php to include the display_errors directive if the MAGE_IS_DEVELOPER_MODE server flag has been set:

ini_set('display_errors', 1);

Then, I modify .htaccess to enable/disable developer mode via the MAGE_IS_DEVELOPER_MODE flag:


Turn on Logging

Magento has some built-in logging available through the Mage::log function. However, you must turn logging on from within the admin panel before logging will work.

To turn logging on within the admin panel:

Configuration -->
Developer -->
Log Settings -->
Enabled = Yes

Now, you can log messages to var/log/system.log:


Or, to a custom log file of your own (e.g. var/log/custom.log):

Mage::log($foo, null, 'custom.log');

Notes on Debugging

While we’re discussing development modes, it’s useful to note that there are some additional debugging functions available while you’re developing.

Most notably, the Zend_Debug::dump function is avilable, which can be used instead of var_dump or print_r to print objects to the screen:

Zend_Debug::dump($var, $label = null, $echo = true);

You should also be aware of the Varien_Object::debug and Varien_Object::getData methods, which can be used to present an object as a string or retrieve data from the object respectively. Used in cooperation with the Zend_Debug::dump function, they can be quite powerful:

Zend_Debug::dump($var->getData(), $label = null, $echo = true);

Using Amazon S3 for Static Files on a Custom Subdomain

I’ve moved this blog over to Jekyll and decided to take advantage of Github Pages for hosting. Previously, I used my own static generator, Willow, and hosted it on Linode, but it didn’t seem worthwhile to spend the money on Linode for the simple, and infrequent posts I was making. In addition, I found the workflow of pushing changes to Github and having Github Pages automatically regenerate the website to be quite nice.

However, I didn’t want to host larger files and projects, such as my games, in the site’s git repository. It would have been redundant and take up too much storage space.

So, I created a new Amazon S3 bucket to host media files for this site that shouldn’t be in the main blog’s repo.

The process was rather simple:

Note: this will only work with a subdomain. To create an S3 website using a root domain (e.g., you will need to host your DNS with Amazon’s Route 53 service. That’s a topic for another day.

  • Log in the AWS Management Console
  • Create a new bucket with the same name as the subdomain (e.g. a bucket named for the domain
  • Next, you’ll need to add permission for anonymous users to read the contents of that bucket.
  • Select the bucket you created.
  • Select the Properties tab at the top right.
  • Select Permissions in the available properties.
  • Click the Add bucket policy button and in the policy editory add the following code (replacing with your own subdomain).
"Version": "2008-10-17",
"Statement": [
"Sid": "AllowPublicAccess",
"Effect": "Allow",
"Principal": {
"AWS": "*"
"Action": "s3:GetObject",
"Resource": "*"

A few notes about this:

The Sid is an arbitrary identifier that you make up. Name it something meaningful related to the policy statements. The Principal here indicates you are allowing acces to all of the AWS objects in the bucket. The Action indicates you’re allowing GetObject (or read) access.

  • Next, you’ll need to enable the S3 website feature
  • Click on the Static Website Hosting tab under the Properties area.
  • Select Enable website hosting and add the index and error document names that Amazon’s S3 service will use when browsers hit to the root of your new subdomain hosted at S3.
  • Finally, you’ll need to make a CNAME entry at your DNS provider and point your subdomain to the Endpoint url that is listed under the Static Website Hosting tab.

Once your DNS resolves and you’ve uploaded your files, you should be able to view your subdomain, now hosted on Amazon S3.

Sharing Folders and Adding VirtualBox Guest Additions to Ubuntu on Mac OS X

I decided to try out VirtualBox and run some instances of Ubuntu while I work on a client Magento site. However, I had some difficulty understanding how to share a folder within the Mac environment.

I was tripped up while locating the “VBoxGuestAdditions.iso” file. I couldn’t find it anywhere! Until, I realized that it resided within the application package of the “VirtualBox” application under the “/Applications” folder.

Specifically, it’s located in /Applications/VirtualBox/Contents/MacOS/VBoxGuestAdditions.iso

However, that location is not accessible from within the open dialog box that VBox provides while adding a CD to the CDRom drive (i.e. you can’t choose “Show Package Contents” to get inside the applcation folder). So, I copied the iso file over to the Desktop as a temporary stopgap. Once, I had that figured out, adding the “Guest Additions” and sharing the folder was fairly simple.

  • Open the “Settings –> Storage” for the VM you’re setting Guest Additions up for.
  • Select the empty CDROM IDE controller
  • Add the “VBoxGuestAdditions.iso” on the desktop to the CDROM
  • Mount the cdrom from within the Ubuntu guest VM:
mount /dev/cdrom /mnt
  • From within the guest VM run the additions script for the Linux environment:
cd /mnt
sudo ./
  • Reboot the guest OS
sudo reboot
  • Add your user and any other users that will need access (e.g. www-data) to the vboxsf group:
usermod -a -G vboxsf <username>
usermod -a -G vboxsf www-data
  • Back in VirtualBox on the host (my Mac in this case):
    1. Open “Settings –> Shared Folders” for the guest VM
    2. Add the host folder you want to share (giving it a shared name for the VM)
    3. Make sure to check both “Auto-mount” and “Make Permanent” to ensure the shared folder is available between sessions
    4. Logout of the guest OS or reboot
  • The shared folders on a Linux system (such as my Ubuntu VM) are available in the /media folder when mounted and are prepended with sf_ by default.

For example, I named my share “magento-1.7” in the VBox shared folders settings.

Therefore, the share on the Ubuntu guest OS was available in /media/sf_magento-1.7

How to Choose a Wordpress Theme

I thought I would write down the basic guidelines I use when choosing a Wordpress theme. While this blog doesn’t currently use Wordpress, I’ve installed, created, fixed, and adjusted numerous Wordpress themes over the years. So, these are guidelines built on experience.

My primary concerns are:

  1. Upgradability
  2. Security
  3. Long term impacts on the blog

There are thousands up thousands of beautiful Wordpress themes out there. But, don’t let the bling dazzle you. Choosing a theme or a design without considering the fundamentals of how Wordpress works can get you into trouble down the road. I’m speaking as someone who has run into those nightmare situations in the past, but who has also been successful in avoiding them because of these simple rules.

So, without further ado, these are the minimal requirements I look for when choosing a theme.

Design focused, not feature focused.

Does the theme promise everything but the kitchen sink? If yes, then avoid it! I see too many themes, especially on sites like Themeforest, that offer a plethora of features and custom admin panels. It sounds enticing, but these should be red alerts, not selling points. Don’t base a decision on how the theme looks, base it on both “how it looks” and “how it’s made”.

A theme should be focused on it’s design, it should be simple in terms of it’s overall features and not try to sell you on being an all-in-one shop for your blog’s needs. Why? Because features are what plugins are for. Themes based on features can be a problem when you want to change that theme down the road. And there is ALWAYS a theme change at some point in the future. Always. Many feature-filled themes are using non-standard tables, extra fields, and/or customized areas that aren’t going to be available in other themes. That means, if your blog is using these features regularly, when you do change the theme, you lose all that work (possibly years worth of snippets, pictures, and adjustments). It’s not worth it.

However, if you choose a theme that is designed focused and then supplement that theme with plugins that have the feature you’re looking for, your blog has a certain amount of future-proofing that can be carried forward from one theme to the next. You win every time when you’re choosing a design and layout focused theme that uses the standard Wordpress features to begin with.

Themes with too many features can be problems when upgrading Wordpress as well, as they tend to take liberties with the standards of a Wordpress install and can turn into real headaches during normal maintenance of the blog.

Wordpress Standards

Nobody wants to be boxed into some stodgy set of standards, but the truth is those standards are there because they’ve been battle tested for years. If you’re choosing a theme that doesn’t at least claim to be based on Wordpress standards, you’re opening yourself up to upgrade issues, security issues, and possible breakage issues in the future.

Wordpress blogs are always being upgraded, your themes should be too. A standards based theme works well with these upgrades and anticipates updates to both Wordpress and the theme itself.

If you’re not regularly updating your Wordpress install with the latest security updates, you’re asking for trouble. Wordpress is a favorite amongst the script kiddies out there, who troll the net looking for unpatched Wordpress installs.

So, if your theme is not able to handle upgrades because it uses some non-standard method or feature, then you’ve just boxed yourself into a bigger nightmare than the stodgy standards box could ever be.

Child Themes

Themes are never exactly what you want them to be. That’s fine, that’s why Wordpress themes are configurable. Wordpress even offers the ability to edit CSS and templates inside Wordpress. Just, don’t do it.

A decent theme is going to be updated over time by the original developer. That’s a good thing. You want that. The problem is, if you’ve made adjustments to that theme, the next time you update the original theme for bug fixes, security issues, etc. then you’ll lose all of your hard work. And believe me, themes can have security issues just as much as Wordpress itself can.

So, when choosing a theme, I always look for one that supports the “Child Theme” pattern. Wordpress itself recommends that you use child themes, because child themes let you fully modify the original theme without touching any of the original stylesheets or code. I can even check my child theme work into a source control system, like git, outside of the original theme. It’s wonderful.

If you’re choosing a theme that doesn’t support child themes, and you have to make changes to that theme at some point (which happens more often than you think), then you’re going to start running into issues when that theme updates.


Which brings me to my next point. Whenever I choose I theme, I look at the developer carefully. Are they updating their themes regularly? Have they been tested against the latest version of Wordpress? If not, then avoid them like the plague. Themes that aren’t updated regularly can be serious issues down the road. If the developer isn’t supporting them, then you’re responsible for making bug fixes, security updates, compatibility updates, etc. And if you’re going that far, you might as well make the theme yourself!

Some developers even offer automated updates (like the automated Wordpress updates), which can be a nice bonus and ensure that you’re theme can always be kept up to date.


Finally, as an option, I try to use themes that are fully GPL compliant. This is the same license that Wordpress is based off of and one that, in theory, all Wordpress themes should be based off of. Many premium/paid-for themes are GPL compliant.

The advantages of a GPL compliant theme are that:

  1. I can go through the styles, template code, etc. and make changes and fixes (in a child theme) if I want to. I can even base a new, custom theme off of that code as long as I maintain the GPL license and give proper credit where it’s due.
  2. The license let’s me use it on multiple sites
  3. The license allows me to carry-forward the good work of all those Wordpress developers before me
  4. Most, but not all, of the themes that I’ve found that aren’t GPL compliant, tend to forget all of the minimal requirements I’ve made above.

Some of the most advanced and largest Theme frameworks out there are GPL based, and that just adds to the continued goodwill of the community.

So, I implore you to consider these guidelines when making theme choices. They aren’t the final word on themes, but they can have significant impact on the safety, health, and extensibility of your Wordpress blog.