For some reason, I always tend to run into this problem and I forgot the solution I previously implemented. Sometimes, you Magento site will have custom product attributes that you’d like to be viewable from the cart/checkout areas. For performance reasons, the product available to the order/quote doesn’t contain all of the attributes.

Instead of querying the product new to retrieve the attributes, you can instead define what attributes you’d like to be loaded during the cart/checkout process within the a config.xml file. The structure will be as follows:

<sales>
<quote>
<item>
<product_attributes>

<your_attribute_1/>
<your_attribute_2/>

</product_attributes>
</item>
<quote>
<sales>

Maybe this will save some others time as well…

If you search the net for how to add new custom attributes to categories, you’ll find many sites that define the steps in manual SQL inserts. The issue I found was that most of these sites are specific to Magento versions previous to 1.4/Enterprise 1.9 and leave out a crucial step. Also, I find it to be bad practice to manually insert rows into your Magento database because it makes it hard to deploy across environments.

The general approach to create custom category attributes is the following 3 SQL inserts:

INSERT INTO `eav_attribute` (
				`attribute_id` ,
				`entity_type_id` ,
				`attribute_code` ,
				`attribute_model` ,
				`backend_model` ,
				`backend_type` ,
				`backend_table` ,
				`frontend_model` ,
				`frontend_input` ,
				`frontend_label` ,
				`frontend_class` ,
				`source_model` ,
				`is_required` ,
				`is_user_defined` ,
				`default_value` ,
				`is_unique` ,
				`note`
	)
	VALUES (
			NULL ,  '3',  'header_image', NULL ,  'catalog/category_attribute_backend_image',  'varchar', NULL , NULL ,  'image',  'Header Image', NULL , NULL ,  '0',  '0', NULL ,  '0',  ''
	);

	SET @attribute_id = LAST_INSERT_ID();

	INSERT INTO `eav_entity_attribute` (
				`entity_attribute_id` ,
				`entity_type_id` ,
				`attribute_set_id` ,
				`attribute_group_id` ,
				`attribute_id` ,
				`sort_order`
	)
	VALUES (
		NULL ,  '3',  '3',  '3',  @attribute_id,  '30'
	);

	INSERT INTO `catalog_eav_attribute` (
				`attribute_id` ,
				`frontend_input_renderer` ,
				`is_global` ,
				`is_visible` ,
				`is_searchable` ,
				`is_filterable` ,
				`is_comparable` ,
				`is_visible_on_front` ,
				`is_html_allowed_on_front` ,
				`is_used_for_price_rules` ,
				`is_filterable_in_search` ,
				`used_in_product_listing` ,
				`used_for_sort_by` ,
				`is_configurable` ,
				`apply_to` ,
				`is_visible_in_advanced_search` ,
				`position` ,
				`is_wysiwyg_enabled`
	)
	VALUES (
		@attribute_id, NULL ,  '1',  '1',  '0',  '0',  '0',  '0',  '0',  '0',  '0',  '0',  '0',  '1',  '',  '0',  '',  '0'
	);

The above code is specific to one of my Magento installs, which in this case I’m creating a custom image attribute. You can create any sort of attribute by identifying a similar attribute and copying most of the columns.

Now, this alone will give you your custom attribute, and if you only have one environment, this may be sufficient. Most projects, however, have development, test, and production environments, and if you manually insert SQL, it can be hard to ensure data consistency.

For this reason, its good practice to create a custom module where you can create a sql setup script that will automatically run and insert your desired columns. For my project, I created a module called Brim_Catalog with the following folder hierarchy:

-app
– code
– local
– Brim
– Catalog
– etc (create a config.xml file here)
– sql
– brim_catalog_setup (create a mysql-install-0.1.0.php here)

Now, in your config.xml, create the following resource declaration:

<resources>
            <brim_catalog_setup>
                <setup>
                    <module>Brim_Catalog</module>
                </setup>
                <connection>
                    <use>core_setup</use>
                </connection>
            </brim_catalog_setup>
        </resources>

Finally, you can define your SQL in the mysql-install-0.1.0.php file as such:

startSetup();

// create a new category attribute 'header_image' to display as the header on category landing pages
$installer->run("
	INSERT INTO `eav_attribute` (
				`attribute_id` ,
				`entity_type_id` ,
				`attribute_code` ,
				`attribute_model` ,
				`backend_model` ,
				`backend_type` ,
				`backend_table` ,
				`frontend_model` ,
				`frontend_input` ,
				`frontend_label` ,
				`frontend_class` ,
				`source_model` ,
				`is_required` ,
				`is_user_defined` ,
				`default_value` ,
				`is_unique` ,
				`note`
	)
	VALUES (
			NULL ,  '3',  'header_image', NULL ,  'catalog/category_attribute_backend_image',  'varchar', NULL , NULL ,  'image',  'Header Image', NULL , NULL ,  '0',  '0', NULL ,  '0',  ''
	);

	SET @attribute_id = LAST_INSERT_ID();

	INSERT INTO `eav_entity_attribute` (
				`entity_attribute_id` ,
				`entity_type_id` ,
				`attribute_set_id` ,
				`attribute_group_id` ,
				`attribute_id` ,
				`sort_order`
	)
	VALUES (
		NULL ,  '3',  '3',  '3',  @attribute_id,  '30'
	);

	INSERT INTO `catalog_eav_attribute` (
				`attribute_id` ,
				`frontend_input_renderer` ,
				`is_global` ,
				`is_visible` ,
				`is_searchable` ,
				`is_filterable` ,
				`is_comparable` ,
				`is_visible_on_front` ,
				`is_html_allowed_on_front` ,
				`is_used_for_price_rules` ,
				`is_filterable_in_search` ,
				`used_in_product_listing` ,
				`used_for_sort_by` ,
				`is_configurable` ,
				`apply_to` ,
				`is_visible_in_advanced_search` ,
				`position` ,
				`is_wysiwyg_enabled`
	)
	VALUES (
		@attribute_id, NULL ,  '1',  '1',  '0',  '0',  '0',  '0',  '0',  '0',  '0',  '0',  '0',  '1',  '',  '0',  '',  '0'
	);
");

$installer->endSetup();

That’s all there is to it. Now, every environment that you deploy your code to will be guaranteed to have the same custom category attributes.

If you have every done this:


$_product = Mage::getModel('catalog/product')->load(__PRODUCT_ID__);
$manufacturer = $_product->getManufacturer();


You’ll know that you get the manufacturer’s id instead of it’s name. Which may or may not be what you would have expected. But the product model provides a nice helper method for getting an attributes value, in case it was not what you were expecting. Below is the code to get a product’s manufacturer name instead of it’s ID.


$_product = Mage::getModel('catalog/product')->load(__PRODUCT_ID__);
$manufacturer = $_product->getAttributeText('manufacturer');


In previous versions of Magento, the approach I would take to get a product’s parent product would be the following:


$parentIdArray = $product->loadParentProductIds()->getData('parent_product_ids');
$parent = Mage::getModel('catalog/product')->load($parentIdArray['0']);


In the latest version of Magento, Mage_Catalog_Model_Resource_Eav_Mysql4_Product::getParentProductIds() has been removed. Its odd though because line 1338 of Mage_Catalog_Model_Product still references this missing method. So, if you use the above code to retrieve a product’s parent product, then it will blow up with a missing method exception.

For the time being, my fix is just to copy the Mage_Catalog_Model_Resource_Eav_Mysql4_Product class into my local code folder and add the method back in. The code for this method is the following:


public function getParentProductIds($object)
{
$childId = $object->getId();

With the above method added back in, my original code works. I’d like to know if there is a new suggested approach to get a product’s parent, but for the time being, this is what I’ll fall back to.

We currently have a post explaining how to associated simple products that have required options to a parent grouped product (link), but another product configuration that many people ask about is associating configurable products within a grouped product. This association allows a Magento store to more intuitively display their products on a single page, rather than forcing the user to navigate to multiple configurable product pages.

There are quite a few steps to get this working correctly, but since we’ve implemented this for a few clients, we’ve bundled the code into a module that you can download here: groupedconfigurable.

Here, I’ll list the basic steps to get this working, and you can download the code and modify to your liking.

Step 1: Allow the Association

By default, Magento wont allow you to link a configurable product from a grouped product. If you check config.xml in the module we wrote, we updated the allowable product types for a grouped product.

Step 2. Add our product.js File to your layout

Since the configurable product, by default, is a page-centric configuration, we had to write a new javascript class to handle having multiple configurable products on a single page. In your grouped product layout handle, add the brim/product.js file.

Step 3. Check for a configurable product, and use our new configurable template

In the grouped.phtml file, while it is iterating through the associated products, check if the product is configurable. If it is, use our Helper class to echo out the configurable template. This would look something like: (this is basically pseudo code)

if($_item->getTypeId() == Mage_Catalog_Model_Product_Type::TYPE_CONFIGURABLE):

echo Mage::helper('groupedconfigured')->getAssociatedConfigurableProductHtml($this, $_item) ;

else:

// default to original behavior

Within the method getAssociatedConfigurableProductHtml, it will create a block using the configurable template we’ve provided.

Another thing to mention is that since Magento by default has a single form for adding products to cart, you’ll want to remove the form declaration from the grouped.phtml file, and instead, just use the forms that are provided by our template.

To show the module in work, I added configurable products to the “recently viewed” template on the right-hand side of a base magento install. You can see it here:

The screen shown above isn’t pretty (I didn’t style anything), but as you can see, you can display a configurable product anywhere in your store using a convenient helper method. We’ve provided the code necessary in this post, but if anyone has specific customization questions or needs any help, send us an email through our site’s contact form or comment below.

– UPDATE –

Jason (see comments below) pointed out a flaw in my config.xml file and the lack of some required overrides. I’ve updated my module, and the link above is the latest version.

– Update (8/5/11) –

We have packaged this blog post up into an easy to install Magento extension available in our new Magento Extension Store. The new extension is now called Grouped Options.

Cufon is a really great javascript-based font replacement library, which aims to be a sIFR replacement. In an attempt to make it easier for a Magento storefront to take advantage of its functionality, we have written a module that allows you to upload the fonts you’d like to use on your website and easily replace any text or component using a single method.

Once you’ve installed the module (link at the end of this post), you’ll first want to upload the fonts you’d like to use on your site. In your admin panel, navigate to Catalog->Brim Fonts.

Here, you can upload the fonts you’ll be using on your site given a name and the font file.

Now that you’ve created your font, you can replace any text in your templates. Simply use the helper method “replace” as such:

echo Mage::helper('brim_fonts')->replace('.product-name h1', 'Chalkduster')

Given the above code, Cufon will now replace your h1 product name text with the Chalkduster font:

Installation of this module can be a bit tricky, but we’re happy to help out with any installations. You’ll start by installing the Brim/Fonts module into your app/code/local directory.

Next, place the cufon php lib under your root/lib folder. Likewise, place the cufon js files under root/js.

Once this has been done, you have all the code necessary to enable the module. You’ll want to create a Brim_Fonts.xml file in your app/etc/modules directory just like any other module to make it active.

The only configuration for this module is specifying the location of the fontforge executable. Cufon sits on top of fontforge, so you need to have it installed on your server in order for it generate your fonts from your .ttf files. You can install fontforge from here : http://fontforge.sourceforge.net/. Once this is installed, you need to update your app/code/local/Brim/Fonts/etc/config.xml to know where the location of your fontforge resides. As you can see in the file by default, the location of my fontforge is /usr/local/bin/fontforge.

Again, we’re happy to help with any installations, so let us know if you have any questions.

– EDIT [1/6/11] –

Oguz (see comments section) noticed something I missed and was kind enough to email me. I forgot to include that you’ll need to add the cufon js to any page you’d like to replace fonts. In your layout handle, you can do something like this:

<action method="addJs"><script>cufon.js</script></action>

Thanks Oguz!

For most users, the “recently viewed products” should be ordered based on the last product viewed. Previous versions of Magento had defects filed describing the recently viewed products were being ordered by the index ID, but this has apparently been resolved in the latest versions. The forum post here describes the defect: http://www.magentocommerce.com/boards/viewthread/9752/ .

Well, when helping a recent client, he was running on Enterprise version 1.9, and he was still having the ordering issue. I took a look, and it appears that if the “recently viewed products” widget is on anything but a product view page, the ordering will still not work.

The solution that I implemented was to “rewrite” the Mage_Reports_Model_Mysql4_Product_Index_Viewed_Collection class and override it’s setAddedAtOrder() method. The setAddedAtOrder() method adds the added_ad column as the sort order column ONLY if the index table has been joined to the query. This only occurs on the product view page. The overridden method should look as such:

public function setAddedAtOrder($dir = 'desc')
{
    $this->_joinIdxTable();

    $this->getSelect()->order('added_at '.$dir);

    return $this;
}

This ensures that every time we attempt to set the order, it will join the index table appropriately.

The telephone field on the Magento address is a required field. You’d think that removing this constraint would be as easy as removing the required-entry class so that the client-side javascript validation doesn’t require it, but its not that simple.

Removing the telephone as a required field on any Magento customer address requires 3 changes:

1. As noted above, remove the ‘required-entry’ class from the telephone HTML input

2. Go to your admin panel, and navigate to “Customers->Attributes->Manage Customer Address Attributes” and select the ‘telephone’ attribute. Update the “Values Required” selection to “No”.

3. Since Magento has server-side validation on this field as well, you’ll need to override the Mage_Customer_Model_Address class. Just as you would do any override, create a local module or copy this file into your local folder directory. The only method you need to override is the validate() method. It should look like this (Magento 1.4/Enterprise 1.9):

public function validate()
	{
		$errors = array();
		$helper = Mage::helper('customer');
		$this->implodeStreetAddress();
		if (!Zend_Validate::is($this->getFirstname(), 'NotEmpty')) {
			$errors[] = $helper->__('Please enter the first name.');
		}

		if (!Zend_Validate::is($this->getLastname(), 'NotEmpty')) {
			$errors[] = $helper->__('Please enter the last name.');
		}

		if (!Zend_Validate::is($this->getStreet(1), 'NotEmpty')) {
			$errors[] = $helper->__('Please enter the street.');
		}

		if (!Zend_Validate::is($this->getCity(), 'NotEmpty')) {
			$errors[] = $helper->__('Please enter the city.');
		}

		//		if (!Zend_Validate::is($this->getTelephone(), 'NotEmpty')) {
		//			$errors[] = $helper->__('Please enter the telephone number.');
		//		}

		$_havingOptionalZip = Mage::helper('directory')->getCountriesWithOptionalZip();
		if (!in_array($this->getCountryId(), $_havingOptionalZip) && !Zend_Validate::is($this->getPostcode(), 'NotEmpty')) {
			$errors[] = $helper->__('Please enter the zip/postal code.');
		}

		if (!Zend_Validate::is($this->getCountryId(), 'NotEmpty')) {
			$errors[] = $helper->__('Please enter the country.');
		}

		if ($this->getCountryModel()->getRegionCollection()->getSize()
		&& !Zend_Validate::is($this->getRegionId(), 'NotEmpty')) {
			$errors[] = $helper->__('Please enter the state/province.');
		}

		if (empty($errors) || $this->getShouldIgnoreValidation()) {
			return true;
		}
		return $errors;
	}

With these three pieces in place, you’ll now be able to remove the telephone from the form (or just make it optional) without Magento throwing a fit.

Let me know if anyone would like additional clarification on this…

Very recently, the need arose for us to send out a new, template based email from a custom Magneto module.  A Google search yielded surprising lack of information for this task. Therefore, we documented the process we took to get our module to send out an email based on a template.

Here’s the process…

1.       Create the HTML Template – The email template directory is located in app/locale/en_US/template/email  . The key here is that the {{var sample}} is the syntax for adding variables to the email template. If you need more samples you can take a look some of the sample templates there.

sampleEmail.html

<style type=”text/css”> body { color:#2f2f2f; font:11px/1.35em Verdana, Arial, Helvetica, sans-serif; } </style>

<div style=”font:11px/1.35em Verdana, Arial, Helvetica, sans-serif;”>

<p>Today’s product of the day is {{var sample}}.  Please visit our store for more details</p>

</div>

2.       Create XML definitions and references to the HTML Template – The sendTransactional method allows you to pass an integer for the id if you’ve added the template via the admin console and would like to use the core_email_template table. However it’s considered best practice to follow the process we’ve laid out and create your template separately and configure them via XML.

Add your Template definitions to your modules config.xml between the <Global> tags

<template>

<email>

<sample_email translate=“label” module=“sample”>

<label>Sample Email</label>

<file>sampleEmail.html</file>

<type>html</type>

</sample_email>

</email>

</template>

In the same config.xml file, add to a reference to the template definition right above the closing </config> tag

<default>

<sample>

<sendemail>

<template>sample_email</template>

</sendemail>

</sample>

</default>

3.       Prep / Call sendTransactional  – In your controller, you’ll need to prep the data and the model necessary for your email.

First, we need to define a reference to your XML email template

const XML_PATH_SAMPLE_EMAIL_TEMPLATE = ’sample/sendemail/template’;

Here’s where we do the heavy lifting. First we set the Design Config on the email template, and then we call sendTransactional. Something not totally obvious, is the sender must be an array that contains both an ‘email’ and ‘name’ unless your email information is setup in the admin console.

$storeId = Mage::app()->getStore()->getStoreId();

$mailTemplate = Mage::getModel(‘core/email_template’);

$mailTemplate->setDesignConfig(array(‘area’=>’frontend’, ’store’=>$storeId));

$emailId = Mage::getStoreConfig(self::XML_PATH_SAMPLE_EMAIL_TEMPLATE);

$mailTemplate->sendTransactional(

$emailId,

array(‘email’=>’sample@sample.com’, ‘name’=>’Sample Sender’),

$email,

$email,

array(’sample’ => $sample)

);

For reference, here’s the sendTransactional method from the core/template model.

sendTransactional($templateId, $sender, $email, $name, $vars=array(), $storeId=null)

In a recent project, we had a ticket filed for a seemingly broken Banner Rotator Widget.  The admin console would allow the creation of the Banner Rotator but nothing seemed to be operational.

After a bit of investigation, we noticed that our ‘Design Package/Theme’ (brim_design) was missing (–Please Select–) in the New Widget Instance->Frontend Properties –>Design Package Theme. This was occurring even though we we’re available to select it from the select drop down menu (see screenshot). After digging into the controller action for this, we discovered that underscores were being striped off in the action. Therefore, since our design package had an underscore, the Design Package was never being set on the Banner Rotator Widget.

A quick fix for this issue was to create a copy of the Design Package (ex: frontend/brim_design) , rename the folder and remove the underscore (ex: frontend/brimdesign), then change the Current Package Name in System->Configuration->Design.

It’s generally recommended that you avoid using underscores in your Design Package names and in other places throughout Magento.