If you find that you want to change the behaviour of a core controller, say Mage_Customer_AccountController, then prior to this module, you had to use url rewriting. Now, using LKC_ModularRouters, you can treat controllers like models/blocks/helpers.
When writing a controller for the new routers, you no longer have to end the classname with ‘Controller’ but you MUST extend Mage_Core_Controller_Varien_Action in some way.
Looking at the class below, you will see that we extend Mage_Customer_AccountController which extends Mage_Core_Controller_Front_Action with extends Mage_Core_Controller_Varien_Action, so we know it is a valid controller.
In our new controller, we will override a single action, loginAction(), so we can insert our custom code. You have the option of calling the parent action if needed.
First, we need to actually tell Magento that our project depends upon LKC_ModularRouters /app/etc/modules/MyCompany_MyModule.xml
Next, we need to write our new controller that extends Mage_Customer_AccountController. /app/code/local/MyCompany/MyModule/Controller/Frontend/Customer/Account.php
// This is needed since Varien used a layout that is not easily auto-loadable require_once("Mage/Customer/controllers/AccountController.php");
class MyCompany_MyModule_Controller_Frontend_Customer_Account extends Mage_Customer_AccountController { public function loginAction() { // Your custom code here
// You can call the parent action as well, if you need to parent::loginAction(); }
// This is to fix an assumption in Magento that breaks translations protected function _getRealModuleName() { return "MyCompany_MyModule"; } }
Finally, instead of using URL rewriting, we are going to use the same method you use to rewrite a model/block/helper object. /app/code/local/MyCompany/MyModule/etc/config.xml
That’s all there is to it. You now have a clean override of the core controller for customer accounts. This can be used for core or 3rd party modules.
Note:due to a small limitation that will be resolved soon, you cannot use the short ‘frontname’ of a module when rewriting, you must use the actual module name. Note:if the controller you are overriding is written to live under the /controllers directory (like the core controllers) then you will need to manually include the class file since the autoloader cannot find it.
Unfourtunately, this doesn’t work as that well. The Zend_Loader::loadClass() function fails with an “cannot find file” exception, even if the file is definately there and the xpath to it correct. Bump.
Thanks for this great contribution! Without this extension, I was not able to implement VAT-free deliveries inside Europe for companies. There are many topics about this.
However, there is a small typo in your code, which took a lot of time to find. In the config.xml file, your last tag is <config> and should be of course </config>. Small detail, but the difference between errors and hapiness
Thanks for catching that. I was wondering why the config file wasn’t working for a few people, now I know. =)
I’m glad the module is helpful to you.
I will be posting 2 more sample usages in the near future. One detailing a good way to separate your admin and frontend controllers, the other detailing how to get your admin controllers to appear under the /admin url like the core admin controllers. So, keep a look out.
Well, this isn’t really a bug forum, but I’ll respond.
I’ve been out of town since 1.3 came out. Now that I am back, I’m looking at what is required to make this work for 1.3 and attempt to retain 1.2 compatibility.
I’m trying to override /app/code/core/Mage/Adminhtml/controllers/Sales/OrderController.php but am struggling to do it the ‘usual’ way.
Is the way proposed in this thread the only currently accepted way to do it? In other words, it definitely can’t be done the way we override and extend blocks?
