Nicolas Demers

In hindsight I probably should have tested the method I blogged about recently, just to make sure it works.

Because it doesn’t.

Oh, the EAV attribute is created all right. But it’s useless, because as I learned since then, orders do not read from the EAV tables since Magento 1.4 (released end of 2010, maybe). They use a flat table ({sales_flat_order}) along with a bunch of other flat tables (order items, quotes, invoices…).

What to do? There are a couple of options. I could add a field to that flat table. Easy to do with an install script, something like:

$installer->run("ALTER TABLE ADD my_custom_field VARCHAR(500);");

Problem is, according to one poster on Stack Overflow, that’s probably not upgrade safe. Plan B would be to create a separate table, keyed on Order ID. Easy enough to do, and my first plan was to write the to the custom as the info is copied from the quote to the order, in Mage_Sales_Model_Convert_Quote::toOrder().

But that doesn’t look possible, because the Order ID isn’t set yet. Seems crazy, I know, but I tried to read

$order->getIncrementId() //I know that one's set
$order->getId() //Nope
$order->getOrderId() //Not that either
$order->getEntityId() //Because the order table's primary key field is entity_id

So I could use increment_id (not exactly sure what that field is good for, except for displaying to customers)… but then I decided to just key the custom table on quote_id. No need to worry about writing to the order, I just extend the order model like so:

class Npd_Myextension_Model_Sales_Order extends Mage_Sales_Model_Order
{
    public function getCustomField() {
    	$quote = Mage::getSingleton('sales/quote');
	$quote->load($this->getQuoteId());
   	return $quote->getCustomField();
    }
}

Which works, because orders always keep a reference to their source quote. Likewise, invoices keep a reference to their source order.

So there you go, and I’m making progress. Progress against a massive headwind, mind you. Again, I whine: why the hell is Magento making things so hard for developers?

PS: about the order ID, am I just kind of dim, or is it actually not set at that point? If it is, what getter function should my code be using? The fact that I’m even asking “what getter function should I be using?” shows either Magento or myself needs serious help…

I’m currently working on a little Magento side project. The learning curve is still steep, and still frustrating. A key part of it involves creating custom fields on orders.

Better Magento developers than me have already gone this route, so I didn’t need to reinvent the wheel. Alan Storm’s excellent post on setup resources was a huge help. I’ll just note a couple of things: first, the actual setup class name could in fact be anything, it doesn’t have to follow the Company_Module_Model_Mysql4_Setup pattern. All you need is to place it in the location in your directory that corresponds to the class name (as with all Magento classes).

Second, it bears repeating: the installer script will only run if the version stored in the core_resource table is different from the version being installed. To run the installer multiple times, simply delete the appropriate record from core_resource, then clear the cache (if it’s enabled) and refresh any page. Having only written one other extension with an installer script in my career, I’d forgotten that particular bit.

Third, and this also bears repeating: damn, but Magento is not friendly to developers. Usual Magento bitching aside (convoluted config.xml, overcomplex extension class/directory structure), why is it making developers do extra work, like writing:

$installer = $this;
$installer->startSetup();
...
$installer->endSetup();

…in every installer script? It’s just a little thing, you say? Maybe, but it’s one of many unnecessary little things, one more little annoyance for experienced developers, one more thing novice devs need to remember, making the learning curve just a little bit steeper.

So that’s general instructions for the installer. Now, how do I specifically add this custom field? I got my answer from the first post on this page. The logic goes like this:

$setup = new Mage_Eav_Model_Entity_Setup('core_setup');
$setup->addAttribute('order', 'newfield', array(
    'position'             => 1,
    'type'              => 'text',
    'label'                => 'Your New Field',
    'global'            => 1,
    'visible'           => 1,
    'required'          => 0,
    'user_defined'      => 1,
    'searchable'        => 0,
    'filterable'        => 0,
    'comparable'        => 0,
    'visible_on_front'  => 1,
    'visible_in_advanced_search' => 0,
    'unique'            => 0,
    'is_configurable'   => 0,
    'position'          => 1,
));            

Pretty self-explanatory, right? Note, though, one thing that tripped me up before I found the above link: the first argument of addAttribute() is a string, not an integer. I’d expected to have to enter the entity_type_id corresponding to orders (5, in my system), but no, it looks like it needs the entity_type_code (‘order’). Weird, and against my common sense.

So there you go, now you know how add custom fields to orders.

PS: here’s some more Magento bitching. This whole EAV scheme, what exactly is it good for? Because frankly, so far it’s given me nothing but headaches. It makes the db bloated and slow, makes looking up data extremely time-consuming, and does not make my life as a developer easier. Like, at all. Other e-commerce platforms (*coughUbercartcough*) use simpler and saner systems that are just as flexible, if not more so.

PPS: While playing around with this extension, I discovered some weird / amusing behaviour related to installing & uninstalling extensions. Since this has nothing to do with custom attributes or installer scripts per se, I’m saving it for another post.