Magento 2 Developer's Guide

Chapter 1. Understanding the Platform Architecture

Magento is a powerful, highly scalable, and highly customizable e-commerce platform that can be used to build web shops and, if needed, some non-e-commerce sites. It provides a large number of e-commerce features out of the box.

Features such as product inventory, shopping cart, support for numerous payment and shipment methods, promotion rules, content management, multiple currencies, multiple languages, multiple websites, and so on make it a great choice for merchants. On the other hand, developers enjoy the full set of merchant-relevant features plus all the things related to actual development. This chapter will touch upon the topic of robust Web API support, extensible administration interface, modules, theming, embedded testing frameworks, and much more.

In this chapter, a high-level overview of Magento is provided in the following sections:

The technology stack
The architectural layers
The top-level filesystem structure
The module filesystem structure

The technology stack

Magento's highly modular structure is a result of several open source technologies embedded into a stack. These open source technologies are composed of the following components:

PHP: PHP is a server-side scripting language. This book assumes that you have advanced knowledge of the object-oriented aspects of PHP, which is often referred to as PHP OOP.
Coding standards: Magento puts a lot of emphasis on coding standards. These include PSR-0 (the autoloading standard), PSR-1 (the basic coding standards), PSR-2 (the coding style guide), PSR-3, and PSR-4.
Composer: Composer is a dependency management package for PHP. It is used to pull in all the vendor library requirements.
HTML: HTML5 is supported out of the box.
CSS: Magento supports CSS3 via its in-built LESS CSS preprocessor.
jQuery: jQuery is a mature cross-platform JavaScript library that was designed to simplify the DOM manipulation. It is one of the most popular JavaScript frameworks today.
RequireJS: RequireJS is a JavaScript file and module loader. Using a modular script loader such as RequireJS helps improve the speed and quality of code.
Third-party libraries: Magento comes packed with lot of third-party libraries, with the most notable ones being Zend Framework and Symfony. It is worth noting that Zend Framework comes in two different major versions, namely version 1.x and version 2.x. Magento uses both of these versions internally.
Apache or Nginx: Both Apache and Nginx are HTTP servers. Each has its distinct advantages and disadvantages. It would be unfair to say one is better than another, as their performance widely depends on the entire system's setup and usage. Magento works with Apache 2.2 and 2.4 and Nginx 1.7.
MySQL: MySQL is a mature and widely used relational database management system (RDBMS) that uses structured query language (SQL). There are both free community versions and commercial versions of MySQL. Magento requires at least the of MySQL Community Edition version 5.6.
MTF: Magento Testing Framework (MTF) delivers an automated testing suite. It covers various types of tests, such as performance, functional, and unit testing. The entire MTF is available on GitHub, which can be viewed by visiting https://github.com/magento/mtf as an isolated project.

Different pieces of technology can be glued into various architectures. There are different ways to look at the Magento architecture—from the perspective of a module developer, system integrator, or a merchant, or from some other angle.

The architectural layers

From top to bottom, Magento can be divided into four architectural layers, namely presentation, service, domain, and persistence.

The presentation layer is the one that we directly interact with through the browser. It contains layouts, blocks, templates, and even controllers, which process commands to and from the user interface. Client-side technologies such as jQuery, RequireJS, CSS, and LESS are also a part of this layer. Usually, three types of users interact with this layer, namely web users, system administrators, and those making the Web API calls. Since the Web API calls can be made via HTTP in a manner that is the same as how a user uses a browser, there's a thin line between the two. While web users and Web API calls consume the presentation layer as it is, the system administrators have the power to change it. This change manifests in the form of setting the active theme and changing the content of the CMS (short for content management system) pages, blocks, and the products themselves.

When the components of a presentation layer are being interacted with, they usually make calls to the underlying service layer.

The service layer is the bridge between the presentation and domain layer. It contains the service contracts, which define the implementation behavior. A service contract is basically a fancy name for a PHP interface. This layer is where we can find the REST/SOAP APIs. Most user interaction on the storefront is routed through the service layer. Similarly, the external applications that make the REST/SOAP API calls also interact with this layer.

When the components of a service layer are being interacted with, they usually make calls to the underlying domain layer.

The domain layer is really the business logic of Magento. This layer is all about generic data objects and models that compose the business logic. The domain layer models themselves do not contribute to data persistence, but they do contain a reference to a resource model that is used to retrieve and persist the data to a MySQL database. A domain layer code from one module can interact with a domain module code from another module via the use of event observers, plugins, and the di.xml definitions. We will look into the details of these later on in other chapters. Given the power of plugins and di.xml, its important to note that this interaction is best established using service contracts (the PHP interface).

When the components of the domain layer are being interacted with, they usually make calls to the underlying persistence layer.

The persistence layer is where the data gets persisted. This layer is in charge of all the CRUD (short for create, read, update, and delete) requests. Magento uses an active record pattern strategy for the persistence layer. The model object contains a resource model that maps an object to one or more database rows. Here, it is important to differentiate the cases of simple resource model and the Entity-Attribute-Value (EAV) resource models. A simple resource model maps to a single table, while the EAV resource models have their attributes spread out over a number of MySQL tables. As an example, the Customer and Catalog resource models use EAV resource models, while the newsletter's Subscriber resource model uses a simple resource model.

The top-level filesystem structure

The following list depicts the root Magento filesystem structure:

.htaccess
.htaccess.sample
.php_cs
.travis.yml
CHANGELOG.md
CONTRIBUTING.md
CONTRIBUTOR_LICENSE_AGREEMENT.html
COPYING.txt
Gruntfile.js
LICENSE.txt
LICENSE_AFL.txt
app
bin
composer.json
composer.lock
dev
index.php
lib
nginx.conf.sample
package.json
php.ini.sample
phpserver
pub
setup
update
var
vendor

The app/etc/di.xml file is one of the most important files that we might often look into during development. It contains various class mappings or preferences for individual interfaces.

The var/magento/language-* directories is where the registered languages reside. Though each module can declare its own translations under app/code/{VendorName}/{ModuleName}/i18n/, Magento will eventually fall back to its own individual module named i18n in case translations are not found in the custom module or within the theme directory.

The bin directory is where we can find the magento file. The magento file is a script that is intended to be run from a console. Once triggered via the php bin/magento command, it runs an instance of the Magento\Framework\Console\Cli application, presenting us with quite a number of console options. We can use the magento script to enable/disable cache, enable/disable modules, run an indexer, and do many other things.

The dev directory is where we can find the Magento test scripts. We will have a look at more of those in later chapters.

The lib directory comprises two major subdirectories, namely the server-side PHP library code and fonts found under lib/internal and the client-side JavaScript libraries found in lib/web.

The pub directory is where the publicly exposed files are located. This is the directory that we should set as root when setting up Apache or Nginx. The pub/index.php file is what gets triggered when the storefront is opened in a browser.

The var directory is where the dynamically generated group type of files such as cache, log, and a few others get created in. We should be able to delete the content of this folder at any time and have Magento automatically recreate it.

The vendor directory is where most of the code is located. This is where we can find various third-party vendor code, Magento modules, themes, and language packs. Looking further into the vendor directory, you will see the following structure:

.htaccess
autoload.php
bin
braintree
composer
doctrine
fabpot
justinrainbow
league
lusitanian
magento
monolog
oyejorge
pdepend
pelago
phpmd
phpseclib
phpunit
psr
sebastian
seld
sjparkinson
squizlabs
symfony
tedivm
tubalmartin
zendframework

Within the vendor directory, we can find code from various vendors, such as phpunit, phpseclib, monolog, symfony, and so on. Magento itself can be found here. The Magento code is located under vendor/magento directory, listed (partially) as follows:

composer
framework
language-en_us
magento-composer-installer
magento2-base
module-authorization
module-backend
module-catalog
module-customer
module-theme
module-translation
module-ui
module-url-rewrite
module-user
module-version
module-webapi
module-widget
theme-adminhtml-backend
theme-frontend-blank
theme-frontend-luma

You will see that the further structuring of directories follows a certain naming schema, whereas the theme-* directory stores themes, the module-* directory stores modules, and the language-* directory stores registered languages.

The module filesystem structure

Magento identifies itself as a highly modular platform. What this means is that there is literally a directory location where modules are placed. Let's take a peak at the individual module structure now. The following structure belongs to one of the simpler core Magento modules—the Contact module that can be found in vendor/magento/module-contact:

Block
composer.json
Controller
etc
- acl.xml
- adminhtml
  - system.xml
- config.xml
- email_templates.xml
- frontend
  - di.xml
  - page_types.xml
  - routes.xml
- module.xml
Helper
i18n
LICENSE_AFL.txt
LICENSE.txt
Model
README.md
registration.php
Test
- Unit
  - Block
  - Controller
  - Helper
  - Model
view
- adminhtml
- frontend
  - layout
  - contact_index_index.xml
  - default.xml
- templates
  - form.phtml

Even though the preceding structure is for one of the simpler modules, you can see that it is still quite extensive.

The Block directory is where the view-related block PHP classes are located.

The Controller directory is where the controller-related PHP classes are stored. This is the code that responds to the storefront POST and GET HTTP actions.

The etc directory is where the module configuration files are present. Here, we can see files such as module.xml, di.xml, acl.xml, system.xml, config.xml, email_templates.xml, page_types.xml, routes.xml, and so on. The module.xml file is an actual module declaration file. We will look into the contents of some of these files in the later chapters.

The Helper directory is where various helper classes are located. These classes are usually used to abstract various store configuration values into the getter methods.

The i18n directory is where the module translation package CSV files are stored.

The Module directory is where the entities, resource entities, collections, and various other business classes can be found.

The Test directory stores the module unit tests.

The view directory contains all the module administrator and storefront template files (.phtml and .html) and static files (.js and .css).

Finally, the registration.php is a module registration file.

Filter reviews by

All

Amazon verified reviews

Daniel Kratohvil Feb 17, 2016

This is a complete and easy to follow introduction to all the basics of Magento 2. I have really enjoyed reading the book and doing the example module, which is nicely explained and gives you enough insight to tackle any complex requirement. One month before this book was available, I paid $280 for the "Fundamentals of Magento 2 Development" online course offered by Magento, and I wish I would have waited a little longer for this book, since it’s more than enough to grasp the basics, cost much less and doesn’t have errors in the example code like the Magento’s video-tutorial has. I definitely recommend this book to any developer with some previous experience in Magento 1.

Amazon Verified review

tanghia Feb 03, 2017

The best book for Magento 2.

Amazon Customer Dec 30, 2015

For anyone who is interested in eCommerce, Magento development, or web development in general, you will want to read this book, which covers in depth, the long awaited and highly anticipated Magento 2 platform. I was fortunate enough to have been the technical reviewer for this book and I must say even I'm impressed by the attention to detail and thoroughness of the topics covered. The author Branko Ajzele is as top notch as it gets in the world of eCommerce and the Magento sphere. Branko lays it all out from setting up your local development environments, to unit-testing, to advanced module/extension development. All readers— from frontend to backend developers, from noobs to senior developers & engineers, and even people who are new to the Magento platform will benefit from reading this book in more ways than you can imagine. It will take your skill set to the next level and also put you ahead of the game with other developers.

Cameron Tudball Feb 07, 2016

Magento 2 Developer's Guide is exactly what the title indicates: an excellent guide through the logic, file structures and setup of Magento 2 that is firmly aimed at PHP developers. If you are looking for a starting point to understand how Magneto 2 works, and how you can configure and extend Magento to meet your site requirements, then this book is where you should start.None of the topics are covered in depth, which allows this book to provide a firm overview of Magento and yet gives you enough detail that you feel confident exploring topics on your own. The chapter on themes, for example, does not provide you with a step-by-step guide on how to make complex frontends (indeed, such a topic would be its own book). Instead it shows you exactly how themes are structured, which for an experienced developer allows you to understand the overall structure. For me, this was far more useful than a step-by-step tutorial.This is not a guide on how to setup and manage Magento as an eCommerce platform. If you're looking for an introduction to using Magento, then this book is not for you. However if you're fluent in PHP and have a requirement to learn the Magento 2 platform, then this book is exactly what you're looking for.

Anuwat Soita Oct 16, 2019

Smart authors. Great Books.

Magento 2 Developer's Guide: Harness the power of Magento 2 to extend and customize your online store

What do you get with Print?

Magento 2 Developer's Guide

Chapter 1. Understanding the Platform Architecture

The technology stack

The architectural layers

The top-level filesystem structure

The module filesystem structure

Summary

Page 1 of 6

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Product Details

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

FAQs

Magento 2 Developer's Guide: Harness the power of Magento 2 to extend and customize your online store

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

Filter reviews by

People who bought this also bought

FAQs