Do not rewrite classes in Magento
For about two years now I have been working closely with the Magento system. During this time I had the opportunity to work with other people's modules and projects, and I realized that in our company the code is at a good level. Probably because we specialize in Magento.
So, you often have to observe errors and compatibility problems in other people's modules. The specific problem of most modules will be discussed in this article.
If you are new to Magento and want to somehow change or expand its basic functionality, then on the Internet you will most likely be advised:
1. to make changes directly to core files;
2. copy the class file with the folder structure from app / code / core to app / code / local and make changes to the local copy;
3. rewrite the class through the XML configuration in its module.
The first option should not be considered at all. The second - in rare cases, if you really need to rewrite some abstract class or library class. The third is if you are rewriting a class of a model, block, helper or controller.
I suggest the fourth option:
4. Do not rewrite classes in Magento!
Why is the fourth option? The first two options are bad because they are not compatible with a kernel update. This is a significant problem, since Magento is developing rapidly and versions come out stably often. The option of rewriting via XML configuration allows you to inherit the rewritable class, therefore it is not so attached to the kernel version. But there is a significant drawback of this approach - if the same class rewrites another module, then only one version will be used, yours or someone else's. The priority is alphabetical and will depend on the name of your module. That is, if your module is called Abc_ModuleOne, and the alien is Zyx_ModuleTwo, then, alas, your rewrite will not be used. And even if you name your module Zzzzzz_Zzz, the problem will not go away - after installing your module, someone will break something and the store owners will ultimately blame you.
An alternative is the use of event observers, the benefit of events in Magento is quite a lot. Do not be lazy, look in the kernel for an event that you would like to use. If such an event was not found, try to use the closest during the execution of the program. In many cases, the problem can be solved using event handlers. How to use observers in Magento can be easily found on the Internet, but I can also prepare an article here if it is interesting.
For some problems, there are specific methods of solution. For example, if you somehow need to change the method of calculating the total amount of the order or any component of this amount. All of this in Magento is called totals. In the basic delivery, there are subtotal, shipping, tax, discount, grandtotal, which are executed in a certain order. But you can easily add your handler anywhere in the totals chain via XML. Payment methods and delivery methods are also easily added. If you wish in the comments, I can cover these topics in more detail.
So, you often have to observe errors and compatibility problems in other people's modules. The specific problem of most modules will be discussed in this article.
If you are new to Magento and want to somehow change or expand its basic functionality, then on the Internet you will most likely be advised:
1. to make changes directly to core files;
2. copy the class file with the folder structure from app / code / core to app / code / local and make changes to the local copy;
3. rewrite the class through the XML configuration in its module.
The first option should not be considered at all. The second - in rare cases, if you really need to rewrite some abstract class or library class. The third is if you are rewriting a class of a model, block, helper or controller.
I suggest the fourth option:
4. Do not rewrite classes in Magento!
Why is the fourth option? The first two options are bad because they are not compatible with a kernel update. This is a significant problem, since Magento is developing rapidly and versions come out stably often. The option of rewriting via XML configuration allows you to inherit the rewritable class, therefore it is not so attached to the kernel version. But there is a significant drawback of this approach - if the same class rewrites another module, then only one version will be used, yours or someone else's. The priority is alphabetical and will depend on the name of your module. That is, if your module is called Abc_ModuleOne, and the alien is Zyx_ModuleTwo, then, alas, your rewrite will not be used. And even if you name your module Zzzzzz_Zzz, the problem will not go away - after installing your module, someone will break something and the store owners will ultimately blame you.
An alternative is the use of event observers, the benefit of events in Magento is quite a lot. Do not be lazy, look in the kernel for an event that you would like to use. If such an event was not found, try to use the closest during the execution of the program. In many cases, the problem can be solved using event handlers. How to use observers in Magento can be easily found on the Internet, but I can also prepare an article here if it is interesting.
For some problems, there are specific methods of solution. For example, if you somehow need to change the method of calculating the total amount of the order or any component of this amount. All of this in Magento is called totals. In the basic delivery, there are subtotal, shipping, tax, discount, grandtotal, which are executed in a certain order. But you can easily add your handler anywhere in the totals chain via XML. Payment methods and delivery methods are also easily added. If you wish in the comments, I can cover these topics in more detail.