Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

Updated for Magento 2! No Frills Magento Layout is the only Magento
front end book you'll ever need. Get your copy
today!

For the tech savvy single store owner, managing product attributes isn’t that big a deal. They go to the admin console, use the UI to create an attribute, and add it to an attribute set. Over the course of the morning, day, or week they go back to the attribute and tweak it until everything works right.

For the agency developer things are a little trickier. Unless you’re with a shop that’s a thinly veiled recruiting/resale firm, you’re going to be working within a team based development process. That always includes working first on a development/staging server, and then moving your work over to a live server.

If you’re a developer creating a module/extension for redistribution there’s an even greater challenge. In an agency environment you can work around a broken deployment process by fiddling with a site after you’ve pushed all your code live. With an extension, after your user installs things it’s up to them to smooth out any wrinkles. Too many wrinkles, and they’re going to find another solution.

Magento Migrations

This is where Magento’s setup resource scripts come in handy. Similar to migrations in other frameworks, a setup resource allows you to write scripts that adjust Magento’s database/attribute store automatically, without any user intervention.

At least, that’s the theory, and for general entity setup the theory plays out in practice. However, with EAV attributes it’s another story. As you’re developing a new feature in Magento (or teaching yourself the attribute system), you often end up constantly adjusting your attribute as your understanding of the problem changes.

If you start with a migration script, this means each time you make an adjustment you need to subtly change your migration script. Conversely, if you start by configuring an attribute using the UI, when it comes time to launch you need to slog through the UI and database to extract the information needed write your migration script.

Either case introduces friction to the development process, friction that prevents you from getting into flow. Friction that makes many developers dread using attributes in their projects.

Tedious Busy Work

Of course, when I say most developers I mean most developers named Alan Storm. I find writing product attribute migration scripts tedious, error prone, and frustrating. In large part it’s because the format of the attribute array

isn’t officially documented anywhere, and is different from the data properties of a the “proper” attribute objects used by the Magento UI. These are small, trivial differences (global vs. is_global), but they add up. It’s particularly tedious when testing your migration scripts means a full database restore to the point prior to the migration running or having the confidence to selectively remove the attribute information from the various tables its definition is spread across. There’s also the problem of the various EAV attribute types each having their own setup resource classes. Using the wrong class won’t fail, but a number of your attribute properties will be discarded and you’ll end up creating an attribute that isn’t quite the type Magento wants.

None of this is hard, but this sort of friction is mind numbing and where a developer’s soul goes to die.

Tedious Busy Work is for Computers

Fortunately, in the mid-20th century human beings created something to deal with tedious and error prone busy work. It’s called a computer. The PHP script below is the start to a solution

As I mentioned, this script is a start. Right now it only works with catalog_product entities, has no option for adding the attribute to a group, only uses the values key for option values, (which only inserts (doesn’t update) new values), and only does so for the admin/default store view. Also, the code itself looks like it was banged out on a Saturday night after a trip to the pub. Myriad areas for improvement.

This is where you come in. I’ve dropped the script on Pulse Storm’s public github account. Fork it, fix it, hack it to pieces. Beyond helping out the Magento development community, this is a great way to familiarize yourself with the structure of Magento’s attributes.