
I just imported a ton of products for new website that I’m working on, and it turns out that the client misnamed a bunch of images, causing Magento to ignore the image import for those ones. I don’t want to scour through the website and the CSV (and the client wouldn’t want to pay us to do that either), so I figured if I could just come up with a list of SKUs for products missing an image, I could hand it off to them so they could correct everything.
This isn’t foolproof, but it does the job. This query will give you a list of SKUs where there is no record in the database for that product’s ‘image’ attribute (the main large product image).
SELECT `sku` FROM `catalog_product_entity` AS a LEFT JOIN `catalog_product_entity_varchar` AS b ON a.entity_id = b.entity_id AND b.attribute_id = 74 WHERE b.entity_id IS NULL
June 29th, 2010 in
Magento,
MySQL |
No Comments

When building custom modules for Magento, one of the most common needs is to override Magento’s core files, most commonly Blocks, Models, Resources, and Controllers. And, by the way, when I say “override”, that is also synonymous with “rewrite” or “extend”.
I wanted to write this up for my own reference, but I hope this ends up helping you to. At the time of writing this, all of these methods have been tested on 1.4.0. This post assumes you to have familiarity with writing Magento modules. And remember, you only need to include functions in your file that you are modifying. Leave all untouched functions out of your file.
Also, the reason I haven’t included much for examples of the actual block/model code is that 90% of getting a rewrite to work correctly is just getting your config.xml correct. It matters way less of where you put your files in your module (though it’s good to keep it organized and clean).
Overriding Core Blocks
One of the more simple and straight-forward things to override in Magento. Let’s say that you want to override the following class: Mage_Catalog_Block_Product_View.
The first step is to copy the file into your own module’s Block folder. It can be anywhere you want within that folder, it really doesn’t matter. But, for organizational purposes, it’s always best, in my opinion, to keep a similar folder/file structure as Magento does. In this case, I would put this file in My/Module/Block/Catalog/Product/View.php. Of course, you’ll need to rename the class, and have it extend Mage_Catalog_Block_Product_View.
Here is how the ‘blocks’ tag in your config.xml should look:
<blocks>
<my_module>
<class>My_Module_Block</class>
</my_module>
<catalog>
<rewrite>
<product_view>My_Module_Block_Catalog_Product_View</product_view>
</rewrite>
</catalog>
</blocks>
As you can see, we’ve got the rewrite xml inside of the ‘catalog’ tag. This refers to app/code/core/Mage/Catalog/. Then the ‘rewrite’ tag tells Magento that we are going to override a block (since we are within the ‘blocks’ tag) under Mage/Catalog/. The ‘product_view’ tag points to Mage/Catalog/Block/Product/View.php, and within that tag is the name of the class that we are using to override the core block.
As another example, if you wanted to override Mage/Catalog/Block/Product/View/Type/Simple.php, the tag under ‘rewrite’ would be ‘product_view_type_simple’.
Overriding Core Models
Overriding models (but not resource models, which are anything declared in config.xml as ‘resourceModel’, which are typically files within a Mysql4 directory) is basically the same as blocks (above). So, I will give an example, but leave out much of the explanation.
Lets say that I want to modify the model for the items on an order invoice (Mage_Sales_Model_Order_Invoice_Item). I will copy that file to My/Module/Model/Sales/Order/Invoice/Item.php, rename the class, and extend Mage_Sales_Model_Order_Invoice_Item.
The config.xml ‘models’ will look something like this:
<models>
<my_module>
<class>My_Module_Model</class>
</my_module>
<sales>
<rewrite>
<order_invoice_item>My_Module_Block_Sales_Order_Invoice_Item</order_invoice_item>
</rewrite>
</sales>
</models>
Overriding Core Resource Models
I found out the hard way once, and wasted a couple hours, that resource models have a different way of overriding them. All of the concepts are the same, with the exception of the syntax in your config.xml file. A resource model is typically going to be models that reside within a ‘Mysql4′ folder. The resource model folder is typically defined in the config.xml file using the tag ‘resourceModel’.
I was putting together a dependent filter module, and I needed to override this class: Mage_Catalog_Model_Resource_Eav_Mysql4_Attribute. Just as the above examples, I created this file: My/Module/Model/Catalog/Resource/Eav/Mysql4/Attribute.php, renamed the class, and extended Mage_Catalog_Model_Resource_Eav_Mysql4_Attribute.
As I said above, the xml syntax changes for resource models. Instead of defining just the ‘catalog’ tag right before the ‘rewrite’, you actually have to define all the way down to the mysql4 folder. Here is an example for the above model:
<models>
<my_module>
<class>My_Module_Model</class>
</my_module>
<catalog_resource_eav_mysql4>
<rewrite>
<attribute>My_Module_Model_Catalog_Resource_Eav_Mysql4_Attribute</attribute>
</rewrite>
</catalog_resource_eav_mysql4>
</models>
Overriding Core Controllers
I have seen numerous methods on how to do this, but the method I will describe seems to be the current ‘standard’.
Lets say that I need to override the adminhtml attribute controller: Mage_Adminhtml_Catalog_Product_AttributeController. First thing is to create the controller in your module. I would put mine in My/Module/controllers/Catalog/Product/AtttributeController.php. An important key to note here is that with controllers, Magento does not autoload them like it does with blocks and models. So, we’ll need to include the file of the controller that we want to override. Here is an example of how my controller would look:
<?php
include_once("Mage/Adminhtml/controllers/Catalog/Product/AttributeController.php");
class My_Module_Catalog_Product_AttributeController extends Mage_Adminhtml_Catalog_Product_AttributeController
{
...
The config.xml file is key now. Unlike models and blocks, you don’t need to define exactly which/where controller you are needing to override. You just need to define whether it is an ‘admin’ or ‘frontend’ controller, which module has the controller(s) you are overriding, and which module you are overriding it with (your own, obviously).
Here is the example for the above controller:
<config>
<admin>
<routers>
<adminhtml>
<args>
<modules>
<My_Module before="Mage_Adminhtml">My_Module</My_Module>
</modules>
</args>
</adminhtml>
</routers>
</admin>
</config>
Please feel free to ask questions or provide feedback on this post. If there are any errors or better ways to do any of this, please let me know.
June 24th, 2010 in
Magento |
2 Comments

I am open and looking for a few freelance projects, developing Magento modules. If you are in need for a module to be custom-built, or for an existing module to be modified, hire me!
I have had direct experience in order exporting, custom attributes for almost anything, custom database tables/models, custom sort orders, custom order status functionality, and authorize.net payment gateway modification. I am not interested in building new payment gateway modules, or heavy integration with external software.
Please fill out the form below with your inquiry if you are interested in getting a quote or in exploring the idea of hiring me for a freelance project.
June 10th, 2010 in
Magento |
No Comments

One of the most valuable tools that I have found in Magento module development is to actually just look at Magento’s code. It seems obvious, but at least for me (for a while), it wasn’t. Every directory that you see inside of app/code/core/Mage/ is just a Magento module built in the same format that you would build your own in app/code/local/yourstuff/.
I look at core code constantly. If I need to figure out how to do a certain type of configuration option in my module, I just look at the etc/system.xml files. If I need to add a new order attribute, I check out Sales/Model/Mysql4/Setup.php and emulate the file structure and method needed in that file to setup my own custom order attribute (making sure to properly configure config.xml as well). The list goes on and on.
Just by having an installation and access to all the core files, you really have most of the examples that you would need to help you in writing your own module. Just follow what they do, their same folder structures and everything, and you’ll be well on your way to writing a better quality module.
June 2nd, 2010 in
Magento |
1 Comment

I was dumping a database today to put onto a different server. I am currently running 5.1.45 locally, and the server I am moving to has 5.0.58. When trying to import the database to the new server, I was getting the following error:
ERROR 1064 (42000) at line 576: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'USING BTREE,
KEY `FK_ATTRIBUTE_VARCHAR_ENTITY` (`entity_id`),
KEY `FK_CATALO' at line 9
After doing some checking around, I found that the problem was the ‘USING BTREE’. Mysql 5.0 and lower doesn’t seem to understand what that is about and will fail. The solution: Just remove ‘USING BTREE’, and you’ll be good to go.
It sounds like versions after mine (5.1.45) have fixed this and omit the ‘USING BTREE’ from the dumps.
June 1st, 2010 in
MySQL |
1 Comment