Get Free Audit

Get Ready for Magento Certified Developer Exam. Describing Methods for Resolving Module Conflicts

Apr 25, 2012

1013 Dzmitry Pakhunou

We suppose you continue following our Magento certification-dedicated posts in our blog. This time we will tell you about methods for resolving module conflicts.

First we should determine what type of conflict we are dealing with and then figure out the appropriate solutions.

magento-ezam32

There are 3 levels of modules compatibility conflicts:

1) Conflicts in configuration files
2) Conflicts with the software part
3) Conflicts in a module display

Conflicts in configuration files

Let’s start with describing the causes of conflicts with configuration files and solutions for it. Primarily, pay attention to the module definition file (Namespace_Modulename.xml), which is located in the app/etc/modules/folder. This file contains the module status (enabled/disabled) and its relation to Magento codepool. Besides, this file allows determining the dependency, which is located between the <depends> </depends> tags.

If, for example, two modules use the same class dependence, future conflicts may appear in the program parts of modules (improper use of the class constructor). This group of problems is closely connected to our second group – conflicts with the software part, which we consider later. If you experience problems with the compatibility of the modules due to the improper use of <depends>, a possible solution will be to indicate one class as dependency for another and use this dependency in class inheritance in the programming part later on. That’s what you can do:

a) Replace this code…

Namespace_OtherModulename.xml


Namespace_Modulename.xml


b) …with that one
Namespace_OtherModulename.xml


Namespace_Modulename.xml

Andrey_Dubina
Partner With Us Let's discuss how to grow your business. Get a Free Quote.
Talk to Andrey

Conflicts with the software part

As mentioned earlier, the main reason for module conflicts could be in the use of dependencies and class rewriting. You should regard your module configuration file (/Namespace_Modulename/etc/ config.xml), in which the class rewriting with <rewrite> </rewrite> tags can be used. For example,


Incorrect use of class methods is the main reason of conflicts origin. There are several ways to solve this problem, but I would like to highlight the very best and most correct way in my opinion – the elimination of classes overriding. The idea of this method is similar to the previous method of module conflict resolving and offers setting the dependence of one class from another.

Namespace_Modulename/etc/config.xml


Namespace_OtherModulename/etc/config.xml

1) In the first place remove the rewriting for the first module. Here are the lines:

2) Use the first class inheritance from the second one:

Class Namespace_Modulename_Block_Rewrite_BlockClass extends Namespace_OtherModulename_Block_Rewrite_BlockClass

Despite the flexibility of this method, it has drawbacks. In particular, you should carefully check the same functions use by these two classes. There may be problems with value return and parent::functionName(); use.  However, I personally consider this method a high-priority in fixing module conflicts on the programming level.

Conflicts in a module display

The most frequent conflict appears while using several modules – problems with displaying module on the frontend. There are several reasons why this happens: blocks overriding in layout settings, the use of different template for the same blocks, removing blocks for another module to be embedded in. Let’s take a closer look at locations, where module conflicts may occur.

  • theme configuration files (app/design/frontend/default/your_theme/layout)
  • templates (app/design/frontend/default/your_theme/template)

If your module is not displayed at all or displayed with errors on the frontend, the high probability that conflicts arise in these files.

First, check your files and files of other modules for display settings on the frontend, which are located in app/design/frontend/default/your_theme/layout. If several modules use the same block, but allocate various templates to it, you need to change these configurations for template allocation to be used only once for the block. In this template other modules templates will be combined, for which we removed the templates allocations.

It is also a common mistake to replace a standard block by the module block with a new name. In this case all other modules, which used the standard blocks with the help of <reference> </reference> tags, will not work because of a changed name. Thus, you need to use a new block name for all dead modules, where this block is applied to theme configuration files (layouts folder).

There are also some cases, when modules use their own templates that are hardly compatible or not compatible with other modules at all. This is single occasions and the solution strongly depends on a specific case.

Read our previous posts.

Class Naming Conventions and Their Relationship with the Autoloader

The Main Magento Design Areas and More…

Magento Module Structure

Magento Codepools

Andrey Dubina
Partner With Us Looking for a partner to grow your business? We are the right company to bring your webstore to success. Talk to Andrey

6 Comments

  1. Hi!
    In “Conflicts in configuration files” section, in a) and b) paragraphs code seems to be equal. Do I miss something or this is a misspelling?

    Thanks!
    D.

  2. Alexander Turiak,

    Thanks for finding this post useful.

    Special “certification” tags are post titles (related posts always start with “Get Ready for Magento Certified Developer Exam”) and category. We have created Certification category on the menu panel right for this purpose.

  3. Great post, will definitely be useful for those taking the exam
    Please add “certification” tag to it
    Thanks!

Post a new comment

BelVG Newsletter
Subscribe to our mailing list and get interesting stuff and updates to your email inbox.
Email *