Tag: magento

Magento 1.5 以后就允许修改订单地址了，Plieninger_Editable module 就没必要存在了，留着它反而会出错。

当年想找一个修改订单地址的方案，就找到了 Plieninger_Editable，一用就用了一年。虽然一直不满意它的界面，一直想自己写一个，但一直忙于其他事务。现在跟它说 bye bye，还是很感谢它的。

Where and how to change the code?

At first, I thought overriding Mage_Catalog_Model_Product_Type_Configurable::getOrderOptions().
Original code

$options['product_calculations'] = self::CALCULATE_PARENT;

change to

$options['product_calculations'] = self::CALCULATE_CHILD;

However, it does not work.

Then I tried to observe the event tax_rate_data_fetch and modify the rateRequest object. But inside rateRequest there is no reference to quoteItem. Only product tax_class_id is there. In the observer class, I do not know when to modify it without reference to quoteItem.

At last, I had to modify the code in class Mage_Tax_Model_Sales_Total_Quote_Tax. There are several places to change depends on System Configuration. Change where is appropriate.
Original code

$taxRateRequest->setProductClassId($item->getProduct()->getTaxClassId());

change to

if ($item->getProductType() == Mage_Catalog_Model_Product_Type::TYPE_CONFIGURABLE) {
	$child = current($item->getChildren());
	$taxRateRequest->setProductClassId($child->getProduct()->getTaxClassId());
}
else {
	$taxRateRequest->setProductClassId($item->getProduct()->getTaxClassId());
}

It is not a neat approach. Let me know if you have a better idea.

Magento 里还是有不少 bugs，我能看出来的就不少。可是我一直懒于 report bug，总觉得我都能发现的 bug，大把有人发现。

今天心血来潮，大概受“莫以善小而不为”驱使，平生第一次 report bug to Magento。事关 js/mage/adminhtml/product.js 文件里第406 行（Magento 1.5.0.1）, 有个笔误，把 readonly 写成了redonly。Associated Products tab of Configurable Products 受此影响，本应只读模式的文本框仍可输入数据。

非常小的错误。

今后我把我的发现记载下来。

Long long time ago, I installed Customshippingrate module, but never made it work on my site. The module sits on the disk but disabled. Recently I took some trouble and about three days developing my own module Cush for admin panel users to charge special shipping price when creating an order.

Cush module does not override any Magento classes so it is virtually 100% compatible with other modules. Neither does Cush module override any Magento templates so basically it reuses Magento native interface. Cush is not a shipping method so it can work with any Magento shipping methods or 3rd party shipping methods.

Cush module injects customisation logic by javascript. What it actually customise are values in magento_sales_flat_quote_shipping_rate where is pool of shipping quotes. Values customised belong to an individual quote so the customisation hits its point.

When writing Cush module, I found a defect in Magento own code app/design/adminhtml/default/default/template/sales/order/create/shipping/method/form.phtml.

echo $this->getCarrierName($_rate->getCarrier());

The above code reads value from configuration and shows it as carrier title. If I was not injecting shipping method customisation logic, I would not realise it is a defect. Carrier title value, like method title and shipping rate, if read from magento_sales_flat_quote_shipping_rate using $_rate->getCarrierTitle(), will make more sense. Values from configuration will not reflect carrier title changes done by Cush. I respect Magento own templates, especially adminhtml templates. Instead of overriding this template, I wrote some additional javascript in Cush module to correct carrier title. I stick to my green principle although it costs much more time developing.

Upon installing Cush module, I removed all files of Customshippingrate module. A small accident happened – can not create shipment. It turns out during creating shipment, Magento is gathering all config paths start with “carriers/” and working out all carriers between two slashes. It is a bad logic, or I can call it a bug. It does not check whether this carrier exists or is active. So, very bad.

Just add to my Magento caveats: after removing a shipping method, remove all entries of “carriers/CARRIER_CODE/*” in magento_core_config_data.

There are three ways to override controller in Magento. They fit for various purposes.

The first and easiest way can be used to route the request to more than one module. When a request arrives on a frontName, it usually is rounted to a module. For example, /cms/page/view is routed to cms module page controller view action. If I have developed a cms related module called “faq” with a brand new controller “QuestionController”, but I want it share the same cms frontName with cms module, i.e., I want /cms/question/any_action be routed to faq module.

It is very easy to achieve by a config.xml like the following:

<config>
	<frontend>
		<routers>
			<cms>
				<args>
					<modules>
						<any_name>MyNamespace_Faq</any_name>
					</modules>
				</args>
			</cms>
		</routers>
	</frontend>
</config>

Strictly speaking, no overriding in above example because it only activates a brand new controller. In a truly overriding example, if I want PageController of faq module override PageController in cms module, I can add before=”Mage_Cms” to make sure PageController of faq module supersede the same name controller in cms module. The complete configuration is shown below:

<config>
	<frontend>
		<routers>
			<cms>
				<args>
					<modules>
						<any_name before="Mage_Cms">MyNamespace_Faq</any_name>
					</modules>
				</args>
			</cms>
		</routers>
	</frontend>
</config>

The second way can be used to mass override controllers.

<config>
	<global>
		<rewrite>
			<any_name>
				<from><![CDATA[#^/cms/#]]></from>
				<to>/faq/</to>
				<complete></complete>
			</any_name>
		</rewrite>
	</global>
</config>

The above configuration makes all controllers in faq module override same name controllers in cms module. In class Mage_Core_Controller_Varien_Front, there is

$pathInfo = preg_replace($from, $to, $request->getPathInfo());

doing path info string replacement based on regular expression. And because it is based on regular expression, I can do mass replacement at a time.

The tag flags whether requested path info should be turned into new module path info. In other words, when the request arrives on /cms/page/view, it is rewritten to /faq/page/view. Without tag, the action layout handle is cms_page_view; with tag, the action layout handle is faq_page_view.

I can use this method to route the request to a brand new controller, i.e.

<config>
	<global>
		<rewrite>
			<any_name>
				<from><![CDATA[#^/cms/question/#]]></from>
				<to>/faq/question/</to>
				<complete></complete>
			</any_name>
		</rewrite>
	</global>
</config>

Note that cms module does not have question controller, but the above configuration will not cause any error.

The third way can be used to override individual actions.

<config>
	<global>
		<routers>
			<cms>
				<rewrite>
					<page>
						<to>faq/question</to>
						<override_actions>true</override_actions>
						<actions>
							<view_action><to>new_module/new_controller/new_action</view_action>
						</actions>
					</page>
				</rewrite>
			</cms>
		</routers>
	</global>
</config>

This method is documented in class Mage_Core_Controller_Varien_Action.

* This will override:
* 1. cms_module/page_controller/view_action to new_module/new_controller/new_action
* 2. all other actions of cms_module/page_controller to faq_module/question_module

It is very handy to precisely control the request rewrite to action level, but it can not route to a brand new controller. The following code will cause an error.

<config>
	<global>
		<routers>
			<cms>
				<rewrite>
					<question><!-- Error: cms module does not have question controller -->
						<to>faq/question</to>
						<override_actions>true</override_actions>
						<actions>
							<view_action><to>new_module/new_controller/new_action</view_action>
						</actions>
					</question>
				</rewrite>
			</cms>
		</routers>
	</global>
</config>