Magento or Mag-er-pain-in-the-ento

Any way you look at them, whether from a design standpoint or a development standpoint, shopping cart platforms suck.

I recently implemented one of the newer entries into the shopping cart market, Magento, on a low-budget client project. I had done my forum research prior to digging into the platform to get an idea what I was in for. In the end, I found that Magento’s reputation among designers is well deserved.

Magento is billed as the “designers” cart solution. Supposedly, Varien, designed their “robust e-commerce software application to be simple to customize.” Depending on your perspective, or rather your need for control over the platforms you utilize for your projects, this statement is somewhat true or utter hogwash.

First of all, I approached this project from a designers perspective. I am not a code-monkey and I chose 16toads’s CMS, Expression Engine, because it is, in fact, architected in a manner that permits my feeble mind to grasp it’s core templating. Oddly enough, the Magento web site is supposedly built using EE, so one would think Varien would take a few cues from EllisLab. Not so.

Here’s what I found and please keep in mind, this isn’t a technical discussion.

As long as your web site is built in a manner that it can be adapted to “fit” into the rigid templating system of Magento, skinning the cart to look like your site is not a terrible experience. It’s not easy, but tolerable when you figure out how to add a custom theme, locate the CSS files, and understand basically how their convoluted file structure is organized. Why didn’t I dive in and mess with the templates? I don’t know PHP and XML from Swahili and Magento makes heavy use of both in it’s templates.

I was lucky that the design of this site was a perfect fit for Magento’s basic structure. In other words, I had a basic header with logo, a horizontal navigation bar, a big content area, and a footer.

The “customization” was limited to changing the background, adding a logo, adjusting the header area, adding a couple image buttons to the main nav, color changes, and adding a couple blocks (modules) to the Home page. Nothing was done to adjust the base templates. All of the Magento templates require making changes to at least two files: a .php file and a .phtml file. The .phtml files are generally where layout changes are made.

Skinning
The basic CSS adjustments were fairly straightforward, just find the element and tweak. CSS docs are located in skin>>frontend>>(yourdirectory)>>(yourtheme)>>css>>allCSSfiles. I had to add a few CSS attributes to make everything work, but all in all this part of the process went smoothly. Even so, skinning the cart took about two days.

The fun part began when I needed to add a couple image buttons to the main navigation bar in order to improve usability. The navigation file is located in design>>frontend>>(yourdirectory)>>(yourtheme)>>template>>catalog>>navigation>>top.html. Follow that? This is pretty much how deep every single file you will ever need to find is buried. And, they are all located in different places. Even this wasn’t too much trouble, just a lot of digging and re-uploading the CSS file(s) once the code was adjusted.

Layout Adjustments
Onward ... templating. It took me a little while to wrap my head around the concept of “blocks” and how to implement them. The whole idea behind Magento is that is it “easy” to customize.  Well, it sort of is ... as long as you do one of two things. (1) Don’t try to hack their templates or (2) hire a whiz-bang programmer to handle the job. I didn’t have the latter option.

Magento gives users the option of selecting from a number different content layouts (the area below the header and above the footer) - Empty, 1 column, 2 column left bar, 2 column right bar, or 3 column (left and right bars). The important thing to understand with each of these choices is that the area you have to “customize” is the column area, not the bars, or the header, or the footer. The areas designated as “bars” are where the cart modules and callouts are automatically placed by Magento.

Once you have selected your layout. You can add your custom content in the CMS tab in the “Content” field under “General Information”.  Varien calls this “content management”, but it requires knowing HTML in order to “customize”. In other words, your clients won’t be able to update the “customizations”.

It is important to understand that elements placed in the CMS Pages or Static Blocks are independent of the cart layouts (templates) unless you add the necessary code snippets. I wasn’t able to find any archive of available code snippets.

The Home Page
The Home Page is not auto-populated with ANY information, products, or even pictures of gnomes. After you go through the process of creating Categories, Attributes, adding products, and selecting the correct display criteria in the System settings, you will find a blank Home Page when you test your work. WTF?

This is point when Magento gets really frustrating.

First of all, there is no clue in the Design Guide explaining how to get products to appear on the home page. I referred to the Demo Site to see how the Home Page was configured. It is set in the CMS Page configuration as a 2 column format with a right bar. What I found was somewhat astonishing ... the Home page (found under  the CMS tab) was completely hand-coded. The Demo sample content wasn’t tied into the Cart at all. The side bar was, but the content was not. Now, imagine the fun it will be explaining to my client that they will not be able to easily swap out the home page graphics ...

After digging through the forums, I found the basic code snippet required to display content on the Home page:

{{block type="catalog/product_new" name="home.catalog.product.new" alias="product_homepage" template="catalog/product/new.phtml"}}.

This worked, but not quite what I was hoping for.

Eventually, I found a relatively simple method of adding a “featured products” module to the home page that required adding an attribute, a .php document, and a phtml document. I also added a “brands” module to the home page that displayed the content of another custom attribute. I had to wade through implementing a few solutions for each problem before finding two that actually worked.

So, at this stage, I had successfully added two new modules to the Demo code of the home page. Now, I thought, how the hell do I change the five “ad” blocks? On the demo page, there are two ad blocks that appear in the left column, two that appear in the content column, and one that appears in the right column. The “shoes”, “camera”, “sale”, “shipping”, and “back to school” blocks.

All of these images are hard-coded into the page. If you choose the 3 column layout (and, don’t use the Demo as a sample), the “back to school” and “dog” graphics are automatically added to the left and right columns. In order to remove or change them, you have to locate their code references in two separate files or comment out code in a third (catalog.xml). For reference, the side “ads” are referred to in Magento parlance as “callouts”.

I succeeded in adjusting the templates to create block elements out of the “right callout” and “left callout”. This allows an admin to adjust the code for each graphic / space in the CMS >> Blocks tab rather than having to dig through multiple folders, templates, and code. Or, by FTPing a new image. Keep in mind, that knowledge of html is still required for these changes.

And, that is the rub
In order to swap or remove any of these images, it requires revising code in multiple template files, manually uploading a new image, or making html changes to “custom” blocks.

The Home Page content area is, for all intents, a free-standing entity. You will note that even if you choose to use the most “automated” layout, 3 columns, the content area must be hand-coded.

The whole concept of Blocks is flawed. For example, it is relatively simple to add or remove a block, such as the Sony Ericsson ad, that appears above the products on the Demo Cell Phone page as long as that block is attached to a Category. Which is the boast behind Magento’s “ease of customization” claim. With the caveats, that it only applies to categories and works well if you don’t mess with the underlying page structure. So, if hand-coding is still required for the most important sales page on an eCommerce site, the Home Page, what’s the point of being able to swap blocks easily on the internal pages?

To clarify, the navigation bar is constructed from Categories, therefore each nav link (category) connects to a Category Page. The Home Page is a CMS page and is NOT linked in any way to categories, nor for that matter are any “pages” you create in the CMS >> Pages tab. Static Blocks don’t apply to CMS pages.

Important Configuration Note:
Do NOT delete the “Default Categories” root category when you begin adding your own categories. ALL new categories MUST be added as children of the Default Category or “root” category. If you delete this and have to start from scratch, you can find instructions in the forums how to rebuild the category structure and enable the correct settings in the System section. It’s a pain and I recommend simply not deleting the “root” category to begin with.

Note: The “root” category can be renamed. The sole purpose of a “root” category is to provide separation between multiple “stores”.

Conclusion
For designers, Magento does not fulfill the “built for designers” claim. It’s a good system. It’s one-page checkout is really nice and developers may swoon at it’s back-end.  But, Magento is a designer’s black hole.  At least, it was for the shirt I lost implementing this shopping cart platform.

Long long story short. Magento is, indeed, robust. Probably more robust than most businesses will ever need. It is a server hog. And, it is easy to customize ... as long as you don’t change the templates and your client doesn’t ever have a need to swap out Home Page graphics.

I wasn’t reduced to tears ... but ... geez ... and, I still have to hook up a payment gateway.