Get Free Audit

Utilizing Modes and Application Initialization in Magento 2

Jun 7, 2018

2616 Andrey Litvin

Utilizing Modes and Application Initialization in Magento 2

Application initialization is done in 9 steps, each one is described below. We are also going to talk about 3 Magento 2 modes and help you learn their advantages and disadvantages.

Application initialization
Designing a customization
How to use Magento modes
Developer mode
Production mode
Default mode
Enabling/disabling maintenance mode
Front controller responsibilities

Application initialization

Step 1

Request to index.php (entry point) in the root of the site or in pub/index.php. When in developer mode, you should use index.php as the entry point in the root of the site, while for production mode, it is recommended to use pub/index.php.

Step 2

Connecting the file to bootstrap.php:

in which autoload.php is loaded and connected:

and the translation mechanism is implemented:

Step 3

The autoloader can call the create () method of the Bootstrap class:

which returns a Bootstrap object, which in its turn contains the ObjectManagerFactory object:

Step 4

Next, the createApplication() method of the Bootstrap object is called:

$app = $bootstrap->createApplication(\Magento\Framework\App\Http::class);

This method creates an instance of the Magento\Framework\App\Http class using the objectManager and returns to index.php.

Step 5

Next, the run () method of the Bootstrap object is called to start the application, which in its turn calls the launch () method of the application object.


Step 6

The http instance of the object performs initial routing — the scope from the URL is determined and set to $this->_ state->setAreaCode($areaCode). After setting the scope, the required configuration for the given area is loaded.

Next, an object of the \Magento\Framework\App\FrontController class is created and its dispatch($this->_request) method is called in which the request is passed.

Step 7

The dispatch() method of the FrontController class defines the current router and determines the current action controller. Then, the dispatch() method is called from the action controller.

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

Step 8

The dispatch() method is implemented in Magento\Framework\App\Action\Action.php.

We are inherited from this class when creating our own controllers. Action controller method returns an object that implements ResultInterface through execution of the execute() method.

Step 9

FrontController returns ResultInterface into Application Instance, which displays response.

Designing a customization that acts on every request

To obtain data from each request, you can create an observer for controller_front_send_response_before event (Magento\Framework\App\Http::launch()).

There is an implementation in Magento\Customer\Observer\Visitor\SaveByRequestObserver.

How to use Magento modes

Magento 2 can be launched in one of the three modes — developer, production and default. The main difference between the modes is in how Magento will get access to static files. Static files include css, javascript files and pictures.

There is also a maintenance mode, but it serves to prevent access to the system.

To view the current mode, use the CLI command bin/magento deploy:mode:show.

To switch between the modes use bin/magento deploy:mode:set.

The pros and cons of using developer mode/production mode

Developer mode

In developer mode, static files are generated in each request. In pub/static symlinks are installed on real files from modules and libraries.


The advantage of this mechanism is that it immediately displays all the changes that you make. The disadvantage — decrease in performance due to the lack of static content caching.

Uncaught exceptions are displayed. Additionally, you need to configure app/bootstrap.php.

Error logging in var/log/exception.log.

Developer mode is recommended for development and customization of modules or themes. Its main advantage is the display of errors in the browser and fast editing of static files, while the disadvantage is low performance.

In Developer mode, static view files are generated each time they are requested. They are written to the pub/static directory, but the cache is not used. This has a big performance impact, but any changes a developer makes to view files are immediately visible.

Uncaught exceptions are displayed in the browser, instead of being logged. An exception is thrown whenever an event subscriber cannot be invoked.

You should use the Developer mode while you are developing customizations or extensions.

Production mode

Production mode is recommended for using on a production server. This is the most productive mode available.

When switching to this mode, errors will not be displayed to a user but will be logged into files. (check out the article Developer Mode and Debugging in Magento 2 for more information about debugging)

In this module, static files will not be generated on the fly but will be deployed to the pub/static directory using the command <your Magento install dir>/bin/magento setup:static-content:deploy. This mechanism allows you to significantly increase the performance, but it is required to redeploy static content after each change.

Default mode

Default mode is how the Magento software operates if no other mode is specified.

This mode is set by default during the initial Magento installation.

In this module, the errors are not displayed to users but are logged to var/log. Files in pub/static are generated on the fly, and then cached.

Unlike the developer mode, the file changes are not displayed until the generated static view files (var/view_preprocessed) are cleared.

Default mode is not optimized to work in production as well as the production mode is, because the creation of files on the fly and their further caching is less productive than the preliminary creation using the command line tool.


Enabling/disabling maintenance mode

bin/magento maintenance:enable

bin/magento maintenance:disable

Front controller responsibilities

  • Gathering all routers (injected into the constructor using DI).
  • Finding a matching controller/router.
  • Obtaining the generated HTML for the response object.

Front controller is the first step (entry point) for processing the flow of requests. Basically, the front controller controls all the other controllers. In Magento 2 it collects routes, matches the controllers, and receives the HTML generated for the response object (converting the query to a result). It is not used in the API or console.

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

1 comment

  1. Hey there.
    Could you guys please re-check “Designing a customization that acts on every request” paragraph.
    I think those mentioned approaches will not work in case of REST API or SOAP API requests.
    “controller_front_send_response_before” event should make the deal.


Post a new comment

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