Complete Guide on Magento 2 Development Best Practices

Home >> Blog >> Magento 2 >> Complete Guide on Magento 2 Development Best Practices

Magento is one of the leading e-commerce platform in the world. Most of the big brands in the world use Magento for their e-business because of its flexibility, reliability and open-source nature.

Many of the leading online businesses and even small retail businesses are migrating from other ecommerce platforms to Magento because of its wide range of inbuilt functionalities, high scalability and continuous growth in development.

With release of Magento 2 in 2015 it took the online market share of platform to around 30% of total market. Magento 2 is now considered to be dominating all other ecommerce platforms with its powerful features like improved performance with NGINX, Redis, Varnish support, inbuilt Full Page, Cache CSS preprocessing, CSS and JS Minification, Code generation, Requirejs for improved JS and User-friendly Checkout. So you should consider to upgrade your magneto 1 website to magento 2 asap

With these major upgrades it requires specific technical and more advanced development skills for any modifications on the platform. With years of experience on magneto development, here we have listed guidelines for best practice on magento development for any newbie and experienced magento ecommerce developers. These points will help for advanced module development for Magento 2 and also for Magento 1 as they include basic Magento Development Practices.

Coding Standards

Always follow coding standards and never edit core files as it can break default Magento behaviour and leave you with vulnerabilities.Many times what happens is that your project or task requires a fast turnaround so generally all the developers lose focus on adhering to standards. You may get the results quickly but your work will lack quality and progress will be stalling in short time.

By following the standard conventions, you give your code a professional look while making it easier to read. Ensure that your Magento coding standards are based on Zend coding standards, PSR1, PSR2, and PSR4.

Module Development

Magento consists of the core code and optional components that enhance or replace the core code. There are over 100 out-of-the-box components in the form of modules, themes, and language packages available for Magento 2. Magento’s architecture allows for enhancements by letting you develop your own components.

You will always need the feel to create a new module for any functionality but before you do make sure that it actually requires you to create a new module. Instead of developing new module from scratch you can get the default code and override it to suit your requirements which will save you lots of time and hassle. Also when overriding core for rewrite, ensure that you rewrite only the required code and new class extends the original main class for following other codes.

While developing any module first thing you want to make sure is that proper naming conventions are being followed and case. You must maintain consistency while naming conventions for files, folders, methods, and classes.

Magento 2 requires a lot of additional coding but it is based on simple and clear concepts, so if it is too complicated then probably it is not the right way to do it. If you do not know how to do it, then look at Magento source code. Magento code is often a source of inspiration when you are approaching something new.

Know the Magento 2 framework

There have been significant changes from Magento 1. Be sure to study the capabilities and standards of the Magento 2 Framework.

Instead of creating custom validators from scratch, implement the \Magento\Framework\Validator\ValidatorInterface.
Instantiating a database connection can be expensive and unnecessary. Magento provides resource models for performing SQL commands. (See Persistence Layer)
Consider using Magento framework conventions instead of low-level or PHP functionality.
Use the Magento\Framework\Data\Collection class to retrieve a collection of filtered objects instead of directly querying the database.

And be careful when using third party modules, the developers may have not correctly understoodMagento standards sobefore using it in production take some time to explore their code and make sure they are proper.

Always use git to version your code, use an automated deployment tool like capistrano and use a local virtual machine for development (vagrant or docker can be good tools).

Write and utilize re-usable code

Avoid using redundant or duplicate code, which can be hard to maintain. Instead of copy and paste of same code, create a single class or method and reference it when needed. As a general rule of thumb, be sure to reuse code as much as possible.

The code you write should be small, focused, and should provide a generic solution. This will let you re-use these pieces again in future development.

Avoid creating helper classes

Helper or utility classes are classes filled with static methods that do not quite fit anywhere else. These classes are considered an anti-pattern and go against the principles of object oriented programming. If you have ClassA and a ClassAHelper with static functions that work on ClassA, you should consider refactoring those functions into ClassA.

A helper class that functions as a catch-all for random methods breaks the single responsibility principle because it is an attempt to solve multiple problems in a single class. You should rewrite your code and move those functions into the appropriate classes they should only work on.

Observer Overriding

Observers are capable of modifying the behaviour of a Magento application because they are dynamically injected into the execution flow. Poorly designed and coded observers can cause issues, instabilities, or otherwise break the application.

Follow these guidelines to reducehassles when your observer is executed.

Make your observer efficient

Try to keep your observer small and efficient by avoiding complex computations, if possible. This is especially important when your observer is listening to an event that is frequently dispatched. Having complex computations in your observer can slow down application processes.

Do not include business logic

Your observer should not contain logic other than what is needed for it to run. Business logic should be encapsulated in other classes that your observer uses.

Declare observer in the appropriate scope

Make your observer as specific as it needs to be. This means that if your observer is only concerned with front end events, you should declare your observer in the /etc/frontend/events.xml file instead of the global /etc/events.xml file.

Avoid cyclical event loops

Cyclical event loops occur when your observer calls the method of an object that dispatches an event that triggers a chain of events that ends up dispatching that same initial event that executes your observer in a recurring manner. Make sure your observer is not dispatching an event that it immediately listens to or will listen to in the chain of events that follows.

Do not rely on invocation order

Your observer should not make assumptions about the order in which it will be invoked nor should it rely on the execution of another observer. Observers listening to the same event may be invoked in any order when that event is dispatched.

Layout XML

Magento 2 has updated its layout definition to more advanced one to restrict the modifications you can do in template files which were possible in the previous version. With new additions of container, move, referenceBlock, referenceContainer, move, update and argument tags the complete definition for layout xml results in below.

...

</container>

...

</container>

Also, new tag can be applied by following below examples.

Arguments values set in a layout file can be accessed in templates using the get{ArgumentName}() and has{ArgumentName}() methods. The latter returns a boolean defining whether there’s any value set. {ArgumentName} is obtained from the name attribute the following way: for getting the value of the method name is getSomeString().

Setting a value of css_class in the app/code/Magento/Theme/view/frontend/layout/default.xml layout file:

...

<argument name="css_class" xsi:type="string">header links</argument>

</arguments>

...

Using the value of css_class in app/code/Magento/Theme/view/frontend/templates/html/title.phtml:

...

$cssClass = $this->getCssClass() ? ' ' . $this->getCssClass() : '';

...

### {#arguments} is a required container for . Does not have own attributes. Example:

...

<argument name="css_class" xsi:type="string">header links</argument>

</arguments>

...

Same as not modifying the core files, its best practice to not modify base design files but instead follow coding standards and extend or override a layout for any modification.

Extend Layout

Rather than copy extensive page layout or page configuration code and then modify what you want to change, in the Magento system, you only need to create an extending layout file that contains the changes you want.

For example, to customize the layout defined in /view/frontend/layout/catalog_product_view.xml, you need to add a layout file with the same name in your custom theme, like following:/Magento_Catalog/layout/catalog_product_view.xml

Override Layout

Not all layout customizations can be performed by extending existing layouts. If the amount of customizations is large, you can use the overriding function for the needed layout file. This means that the new file that you place in the theme will be used instead of the parent theme layout file of base layout file.

Clear Cache

Forgetting to clear or disable caching can cause a lot of development headache. Visual spot checks on rendered content are unreliable when the content being displayed is retrieved from the cache. We recommend clearing your cache before doing visual checks for your theme to make sure the content displayed is correct.

While you’re developing Magento components (modules, themes, and language packages), your rapidly changing environment requires you to periodically clear certain directories and caches. Otherwise, your code runs with exceptions and won’t function properly.

Follow below guidelines on when and how to clear specific cache directories. Make sure you are in the root directory of your Magento installation.

To only clear directories and not perform other actions, log in to the Magento server as the Magento file system owner and clear directories using a command like the following.

1	rm -rf /var/di/* /var/generation/*

To update magento database and schema whenever there is change in class or change resulting in generating factories or change in any di.xml or add/remove any module then below command is required to run. This will clear these directories: var/di, var/generation

1	php -f bin/magento setup:upgrade

After running above command its required that this directory is cleared with below command to generate the compiled code which doesn’t have any errors:var/generation

1	php -f bin/magento setup:di:compile {mode}

When changing the mode to developer or production or edit in any design file, layout or template these directories need to be cleared with below command: var/di, var/generation, var/view_preprocessed

1	php -f bin/magento deploy:mode:set {mode}

After running any of the above last 3 commands to reflect latest changes these directories need to be cleared with below command: var/cache

To reflect latest changes in CMS page, cacheable block, or change the configuration from admin you need these to be cleared with below command: var/cache, var/page_cache

1	php -f bin/magento cache:clean

And after finishing any task of the above the final precaution needs to be taken care of by developer is to make sure that all the directory and file permissions are set to their respective user levels so there are no chances for unauthorised access to file system.

It is very important for any magneto web store owner that your magento 2 development agency is aware of all these development best practices.nfiguration from admin you need th