Magento события и rewrite классов

Стараясь сделать свою систему максимально гибкой и расширяемой разработчики Magento предусмотрели возможность перезаписи любых классов, при чем аж двумя разными способами. Первый базируется на 3-х скоупах и особенностях автолоадера (назовем его copy-paste), а второй на конфигурации модуля (назовем его extends).

Magento: Overriding Core Files (Blocks, Models, Resources, Controllers)

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:

>

> >My_Module_Block> > > > >My_Module_Block_Catalog_Product_View> > > > 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:

>

> >My_Module_Model> > > > >My_Module_Block_Sales_Order_Invoice_Item> > > >

---

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:

>

> >My_Module_Model> > > > >My_Module_Model_Catalog_Resource_Eav_Mysql4_Attribute> > > >

---

Overriding Admin 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:

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:

>

> > > > > before="Mage_Adminhtml">My_Module> > > > > > >

---

Overriding Frontend Core Controllers

Lets override the Onepage Checkout controller: Mage_Checkout_OnepageController. First thing is to create the controller in your module. I would put mine in My/Module/controllers/Checkout/OnepageController.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:

include_once('Mage/Checkout/controllers/OnepageController.php');
class My_Module_Checkout_OnepageController extends Mage_Checkout_OnepageController
{
...

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. Unlink overriding an admin controller, here will will put our router info inside the ‘frontend’ tags.
Here is the example for the above controller:

>

> > > > > before="Mage_Checkout">My_Module_Checkout> > > > > > >

---

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.

Источник

Optimising Magento for Performance

Following our earlier entry about installing Magento Enterprise, we thought it would be appropriate to follow up with some tips for getting more from your Magento installation. One of the major criticisms leveled at Magento is its speed; many complain that it is far too slow. In this article we'll go through some steps you can perform to fine-tune your server to allow Magento to run more smoothly and more quickly in a production environment. Our examples are geared at a Debian-based LAMP stack, but most can be adapted for other platforms.

Magento robots.txt

Magento robots.txt

Magento comes without robots.txt functionality. It can be useful to add one yourself to tell the search engines where they are not allowed to index. It will hide your javascript files, hide SID parameters and prevent some duplicate content. It will help your SEO process and reduces resources on your server. In this blogpost I explain you how to set your own Magento robots.txt using an existing example and using an extension. Both solutions are easy to handle.

Import/Export Large MYSQL Databases

When working with MYSQL I often use phpMyAdmin, which is a nice GUI way to manipulate my database. But some operations won't work in phpMyAdmin when the database is too large. In particular, you can't import or export really large databases using phpMyAdmin. So sometimes you need to do things on the command line.

So I thought I'd document some of the command line snippets we use frequently. In the following, replace [USERNAME] with your mysql username, [DBNAME] with your database name, [/path_to_file/DBNAME] with the path and name of the file used for the database dump, and [/path_to_mysql/] with the path to mysql bin (like /Applications/MAMP/Library/bin/).

Copy/Export a Large Database

MYSQL has no 'Copy' function. You create a copy by dumping the database with mysqldump.
To dump the database and gzip it at the same time, use the following. This will prompt you for your password.

mysqldump -u [USERNAME] -p [DBNAME] | gzip > [/path_to_file/DBNAME].sql.gz

Import a Large Database

If you want to replace the database with a fresh dump created by the above process, do the following.
First, unzip the file.

gzip -d [/path_to_file/DBNAME].sql.gz

Get to a mysql prompt (you will be asked for your password.)

[/path_to_mysql/]mysql -u [USERNAME] -p

Then do the following to wipe out the old database and replace it with the new dump:

SHOW DATABASES;
DROP DATABASE [DBNAME];
CREATE DATABASE [DBNAME];
USE [DBNAME];
SOURCE [/path_to_file/DBNAME].sql;

Conditional Dumps

Sometimes the search index is huge and you want to omit it from the dump. Do so with:

mysqldump -u [USERNAME] -p [DBNAME] --ignore-table=[DBNAME].search_index | gzip > [/path_to_file/DBNAME].sql.gz

There are actually a number of tables you could exclude, like the sessions table, the watchdog table and all the cache* tables.
But if you use the above technique to destroy and recreate the database after doing this, you will be missing all those excluded tables. So you will want to do a two step process instead:
First, create a backup with ONLY the table information, no data.

mysqldump -u [USERNAME] -p [DBNAME] --no-data | gzip > [/path_to_file/DBNAME].info.sql.gz

Then create a backup, including only data from the tables you need.

[path_to_mysql/]mysqldump -u [USERNAME] -p [DBNAME]  --no-create-info --ignore-table=[DBNAME].search_index --ignore-table=[DBNAME].cache --ignore-table=[DBNAME].cache_block --ignore-table=[DBNAME].cache_content --ignore-table=[DBNAME].cache_filter --ignore-table=[DBNAME].cache_form --ignore-table=[DBNAME].cache_menu --ignore-table=[DBNAME].cache_mollom --ignore-table=[DBNAME].cache_page --ignore-table=[DBNAME].cache_pathdst --ignore-table=[DBNAME].cache_pathsrc --ignore-table=[DBNAME].cache_views | gzip > [/path_to_file/DBNAME].data.sql.gz;

Well that's a lot of typing. Wouldn't it be nice if there was a wildcard we could use instead of typing out all those cache_ tables? Well there is!! You can do:

[path_to_mysql/]mysqldump -u [USERNAME] -p [DBNAME]  --no-create-info --ignore-table=[DBNAME].search_index --ignore-table=[DBNAME].cache% | gzip > [/path_to_file/DBNAME].data.sql.gz;

After doing this, just import the two files as above, first the one with only the table info, and then the data. Result, a (relatively) small database with all the optional tables emptied out.
Note that the wildcard trick above is not documented anywhere that I can see, so you'll want to test that it works in your setup.

Источник 

Magento аттрибуты

Отображение атрибутов на странице списка товаров

Было:


Стало:

Zend Router

resources.router.routes.news.type = "Zend_Controller_Router_Route_Regex"

resources.router.routes.news.route = "news/(.*)\.html"
resources.router.routes.news.defaults.controller= "news"
resources.router.routes.news.defaults.action= "index"
resources.router.routes.news.defaults.name = "none"

resources.router.routes.news.map.1 = "name"

resources.router.routes.news.reverse = "news/%s.html"

разберем построчно

с 1ой строкой все понятно;

во 2ой задается регулярное выражение;

3,4,5 настройка контроллера, экшена и значения переменной name по умолчанию;

6 (предпоследняя) маппинг параметров у нас здесь один параметр и он будет присвоен переменной name;

7ая строка при генерации ссылок через вью хэлпер url будет использоватся это выражение.

 

resources.router.routes.id.type = "Zend_Controller_Router_Route_Regex" resources.router.routes.id.route = "articles/(\w+)" resources.router.routes.id.defaults.module = default resources.router.routes.id.defaults.controller = articles resources.router.routes.id.defaults.action = id resources.router.routes.id.map.1 = "id" resources.router.routes.id.reverse = "articles/%s"

Вы укажете Zend Framework при переходе на страницу типа articles/5 определить 5 как id.
Получить значение Вы можете розместив в action:

$this->getRequest()->getParam('id');

Zend router можно реализовать и в другом формате:

resources.router.routes.articles.type = "Zend_Controller_Router_Route_Regex" resources.router.routes.articles.route = "articles/tag/(\w+)" resources.router.routes.articles.defaults.module = default resources.router.routes.articles.defaults.controller = articles resources.router.routes.articles.defaults.action = tag resources.router.routes.articles.map.1 = "tag" resources.router.routes.articles.reverse = "articles/tag/%s"

Тут, соотвественно, данные будут в articles/tag/zend.