Book Image

Magento 2 Development Quick Start Guide

By : Branko Ajzele
Book Image

Magento 2 Development Quick Start Guide

By: Branko Ajzele

Overview of this book

Magento is an open-source, enterprise-level e-commerce platform with unlimited scope for customization. This makes it a great choice not only for vendors but for developers as well. This book guides you through Magento development, teaching you how to develop modules that extend or change its functionality, leading to more ?exible and profitable Magento stores. You start with a structural overview of the key Magento development components. You will learn where things such as plugins, events, models, controllers, layouts, and UI components ft into the development landscape. You will go through examples of using these components to extend Magento. As you progress, you will be building a diverse series of small but practical Magento modules. By the end of this book, you will not only have a solid foundation in the Magento development architecture; but you will also have practical experience in developing modules to customize and extend Magento stores.
Table of Contents (11 chapters)


The area is a logical component that organizes code for optimized request processing. While the majority of the time we don't really have to code anything specific regarding areas, understanding them is key to understanding Magento.

The Magento\Framework\App\Area class AREA_* constants hint at the following areas:

const AREA_GLOBAL = 'global';
const AREA_FRONTEND = 'frontend';
const AREA_ADMINHTML = 'adminhtml';
const AREA_DOC = 'doc';
const AREA_CRONTAB = 'crontab';
const AREA_WEBAPI_REST = 'webapi_rest';
const AREA_WEBAPI_SOAP = 'webapi_soap';

By doing a lookup for the <argument name="areas" string across all of the <MAGENTO_DIR> di.xml files, we can see that five of these areas have been explicitly added to the areas argument of the Magento\Framework\App\AreaList class:

  • adminhtml via <MAGENTOI_DIR>/module-backend/etc/di.xml
  • webapi_rest via <MAGENTOI_DIR>/module-webapi/etc/di.xml
  • webapi_soap via <MAGENTOI_DIR>/magento/module-webapi/etc/di.xml
  • frontend via <MAGENTOI_DIR>/magento/module-store/etc/di.xml
  • crontab via <MAGENTOI_DIR>/magento/module-cron/etc/di.xml

The default area is frontend, as defined by the default argument under module-store/etc/di.xml. The global area is used as a fallback for files that are absent in the adminhtml and frontend areas.

Let's take a closer look at the <MAGENTO_DIR>/module-webapi/etc/di.xml file:

<type name="Magento\Framework\App\AreaList">
<argument name="areas" xsi:type="array">
<item name="webapi_rest" xsi:type="array">
<item name="frontName" xsi:type="string">rest</item>
<item name="webapi_soap" xsi:type="array">
<item name="frontName" xsi:type="string">soap</item>

The frontName is what sometimes appears at the front of the URL, whereas the area name is used internally to refer to the area in configuration files. Different areas defined by Magento can contain different code for processing URLs and requests. This allows Magento to load only the dependent code for the specified area.

When developing modules, we define which resources are visible and accessible in a given area. This way, we get to control the specific area behavior if needed. An example of one such behavior might be the definition of the event observer under the frontend area for customer_save_after event. This observer would only trigger on customer save operations that are triggered from the storefront, which usually indicates a customer register action. The adminhtml area operations, such as Magento admin manually creating a customer, would fail to trigger this observer, as it was defined under the frontend area.

On occasion, we might need to run some code that only executes under certain areas. In such cases, emulation helps us emulate any store programmatically. The Magento\Store\Model\App\Emulation class provides the startEnvironmentEmulation and stopEnvironmentEmulation methods, which we can use for this purpose, as per the following partial example:

protected $storeRepository;
protected $emulation;

public function __construct(
\Magento\Store\Api\StoreRepositoryInterface $storeRepository,
\Magento\Store\Model\App\Emulation $emulation
) {
$this->storeRepository = $storeRepository;
$this->emulation = $emulation;

public function test() {
$store = $this->storeRepository->get('store-to-emulate');
// Code to execute in emulated environment

While it is not a common thing to do, we can further register new areas ourselves. This is easily done by using the module's di.xml.