Magento 2 Request Flow

This entry is part 4 of 5 in the series Magento 2 Series: Understanding the Architecture

URLs in Magento have the format of <AreaName>/<ModuleFrontName>/<ControllerName>/<ActionName>

Magento process a URL request by first stripping of the base URL. The first path segment of the remaining URL identifies request area. For example, admin for adminhtml area, and none for frontend area.

After the area name, the URI segment specifies the frontname which defined in related module. For example, in catalog/product/view, catalog is the module frontname, product is the controller folder, and view is the controller class (replacing action in Magento 1).

We use the router class to assign a URL to a corresponding controller and its action. The router’s match method finds a matching controller, which is determined by an incoming request.

Read More

Magento 2 Application Modes

This entry is part 2 of 5 in the series Magento 2 Series: Understanding the Architecture

There are 3 modes of Magento application, i.e. default (which is the default mode after install), developer, and production.

Here is the difference between them:

  1. default:

    • Not optimized for production
    • Symlinks to static view files are published to the pub/static directory
    • Errors and exceptions are not shown to the user, as they are logged to the filesystem
    • This is the default mode after install, use it if you only want to view and explore Magento. You should avoid using it in development or production environment.
  2. developer
    • Symlinks to static view files are published to the pub/static directory
    • provides verbose logging
    • Enables automatic code compilation
    • Enables enhance debugging
    • Slowest performance
  3. production
    • Errors and exception are not shown to the user, as they are logged to the filesystem
    • Static view files are not materialized, as they are served from the cache only
    • Automatic code file compilation is disabled, as new or updated files are not written to the filesystem
    • Enabling and disabling the cache types is not possible from Magento admin
    • Fastest performance

Read More

Magento 2 Architecture Layers

This entry is part 1 of 5 in the series Magento 2 Series: Understanding the Architecture

The following diagram illustrates the component of Magento 2, and shows the layers or tiers for all components, as well as the Magento framework, 3rd party libraries, the supported database, and other technologies.



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.

How to make all objects in AWS S3 public by default

1. Go to AWS Policy Generator. Fill the form with these values:

Select Type of Policy : S3 Bucket Policy
Effect: Allow
Principal: *
AWS Service: Amazon S3
Actions: Get Object
Amazon Resource Name (ARN): arn:aws:s3:::leo-bucket/* (change leo-bucket to your bucket name)

2. Click Add Statement


3. Click Generate Policy. A popup will appears, containing JSON Document. Copy the JSON strings.

4. Go to your AWS S3 Console. Click your bucket (in my case, leo-bucket). Click tab Permissions -> Bucket Policy. Paste the JSON that you copied before to the editor.

5. Click Save. Then voila… all of your bucket items are now public by default.

Magento 1 Database Diagram

Magento is well known for its flexibility. And the cost of the flexibility.. is complexity. Magento database, as well as its codebase, is quite complex, and sometimes makes us overwhelmed when start using it.


Thanks to Anna Völkl effort, you can view the DB diagram for Magento This diagram will give you a better picture of database flow and its table relationship.

You can still use it for any later version in Magento, since the structure is almost the same.

Here is the database diagram (click the image to view Full Size).

How to read:

  • Catalog: upper left (yellow group)
  • Sales: right (blue group)
  • EAV and Core stuff: middle (brown & orange groups)
  • Customer tables:  middle/bottom (green group)
  • The rest (salesrules, logs, reports, newsletter, tags, poll, etc.) : bottom

Difference of using $this and $block in Magento 2 template

One new thing I found in Magento 2 is the usage of object $block in phtml template to get the block method, instead of using $this as we did in Magento 1.

Let’s say we have this method getFoo() in our block:


then we can call the method from our template with:

and surely will outpout “here is Foo“.

Now, let’s call the method using object  $this:

and… it turns out that its output still the same: “here is Foo“. WHY??

Read More

Mengabaikan perubahan file permission (chmod) pada Git

Selama proses development, kadang ditemukan kasus di mana kita ingin mengubah hak akses (file permission) file atau folder pada repo lokal, tapi tidak ingin mengubahnya di remote repo.

Misalnya kita ingin mengubah file permission folder bernama log agar writable, dengan mengeset chmod 777. Ternyata saat kita cek git status, folder tersebut akan ditandai sebagai modified.

Untuk mencegah git mengabaikan perubahan hak akses file atau folder, cukup dengan mengetikkan perintah berikut di git shell :

git config core.fileMode false

Sebagaimana tertera pada manual git :


If false, the executable bit differences between the index and the working tree are ignored; useful on broken filesystems like FAT. See git-update-index(1).

The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.