Magento 2 frontend architecture

Magento 2 Logo

Although still in development phase, Magento 2 comes with a distinctive set of changed/improved frontend approaches compared to its predecessor Magento 1.X. The big difference is that frontend is now updated with newer technologies such as HTML5, CSS3 and jQuery.

There are also significant changes/improvements to overall layout manipulation, file structure and a brand new introduction to Magento UI library heavily based on LESS preprocessor with built in compiler.

One of the main goals besides performance and scalability was to serve RWD out of the box. In this article I’ll try to cover some of the main differences, dive into development and demonstrate some practical examples.

Theme workflow changes

When creating a new theme theme_root_dir/theme.xml file is required to actually initialize it. There are a couple of other options to be taken into account as well. Add placeholder image for preview in administration, configure its parent theme, declare theme version etc. It’s quite similar approach to the one used in the newest 1.X versions.


One of the first changes I’ve noticed when starting to tackle Magento 2 was certainly the removal of skin directory. Everything is organized directly under the app structure.

Another big change is that every module has its own VIEW directory where all module-specific template, layout, js, and css/less files are stored. This is a better approach and certainly it will be beneficial for module developers. All visual content will be stored directly within the module separating it from Magento core.

What does it mean for us fronted developers?

It means that structure inside app/design/frontend/vendorName/newTheme/ is no longer divided into layout and template directories. Instead we need to include module directory and its complete hierarchy to override default directory structure.

Example 01

Example of a new architecture

For example, if the plan is to change something in 1column.phtml, it’s required to follow full directory hierarchy for a module Magento_Theme (this was a part of the page directory in 1.X versions).

Theming inheritance is now completely redesigned to support unlimited fallbacks and app/design/frontend/base/default directory is no longer included. From the documentation provided so far, the recommended approach is to fallback to blank theme as a starting point.

At the time of writing this article I was not in a position to properly test other options except to falling back to blank, but it seems this approach is beneficial only for the projects requiring slight styling modifications/updates. From custom development perspective, in some cases where development differs very much from default settings it might produce an impact on the performance.

Theme declaring process is pretty much the same as in previous 1.X versions except that now it’s possible to create a new theme from administration.

Layout updates/improvements

When it comes down to layout manipulation there are some really cool and interesting new improvements.

Before diving into practical examples it’s important to mention that layout files are now divided into smaller parts. Practically explained — what once was a layout handle now is a separate file.
Probably the intention was to simplify the maintenance.

Example 02

Magento 2 introduces the whole new concept for product/media image resizing actions right from the layout. Layout file view.xml is responsible and it needs to be placed under app/design/frontend/vendorName/newTheme/etc/ directory. Here is an example of resizing product catalog images in action.


Although I presume that the main goal was to simplify actual resizing process for developers, it will certainly fail under majority of responsive design situations. For example, we don’t want to serve big images for smartphone users on edge connection. Resizing from template files offered a better way to serve out multiple sources for different end user profiles. Right now inspecting a blank theme I only see a situation with just scaling images down in html.

One of the great and more than welcome changes is an introduction of a container wrapper, successor to a core/text_list block type which served the role of a structural block in the previous versions of the system. What is really interesting is a possibility to pass attributes like htmlTag, htmlClass, htmlId directly from layout files.

My personal favorite is move method introduction. It’s a sort of refined action method set/unsetChild but now the process is much more intuitive. For example, if we need to insert source block1 into destination block2 this is the way how we can do it:


It automatically makes source block1 a child of a destination block 2.

It’s important to mention that Magento 2 offers a system validation for XML files using xml schemas for individual and merged layout files.

Magento UI library introduction

Magento 2 offers a complete UI library build up on LESS to match the specific system requirements. Reason for choosing LESS over other pre-processors is because Magento 2 comes with internal compiler to compile CSS directly from PHP. This will, according to Magento team, speed up development and allow developers to focus just on file editing/production while the system covers all the hassle with compiling etc.

However, this, of course, is not the only option to go with. This approach can be ignored and focus can be set on manually compiling with SASS or even writing down pure CSS.

UI Library itself provide tons of mixins (vertical rhythm,@font-face .etc) and a huge set of predefined variables to make the process more intuitive and less demanding for a fronted developer. Does it really accomplish that?

Let’s see some practical examples following the recommended approach.

Magento UI library is located under store_root_dir/lib/web/css/source/lib

Example 03

Element structure is quite in a way how I configured my own SASS files while dealing with Magento 1.X. I found it quite familiar. 🙂

Now let’s see how can we extend some of the files and its mixins etc. To import UI library to our theme it’s required to call/import lib.less file into styles.less which is default less file for a theme.

@import “source/lib/lib.less"

It’s impossible to explain all variations and possibilities in one article so my focus will stay on a few practical examples to encourage you to check it out on your own if you didn’t do it already.

Let’s say that we want to extend predefined @font-face mixin to include our own font to the site. Open Sans is already included by default. So let’s replace it with our own Lovelo Black. Let’s check default mixin for @font-face under the store_root_dir/lib/web/css/source/lib/typography.less

    @font-weight: normal,
    @font-style: normal
) {
    @font-face {
        font-family: @family-name;
        src: url('@{font-path}.eot');
        src: url('@{font-path}.eot?#iefix') format('embedded-opentype'),
        url('@{font-path}.woff') format('woff'),
        url('@{font-path}.ttf') format('truetype'),
        url('@{font-path}.svg#@{family-name}') format('svg');
        font-weight: @font-weight;
        font-style: @font-style;

Pretty much straightforward, required parameters are @family-name and @font-path.

What we need to do now is to extend default typography.less. We’ll accomplish that by copying file to our theme directory. Here is an example of theme.less file after including typography.less

/* Magento/blank */
.magento-reset();   // Reset default styles with magento_reset
// Import theme vars overrides and mixins
@import "source/lib/lib.less"; // Import all lib files
@import "source/theme.less"; // import theme styles
@baseDir: "../"; //default
@import "source/typography.less"; // extending theme typography
@import "source/lib/responsive.less"; // extending responsive styles

Once the procedure is completed it’s time to extend @font-face mixin to suit our needs.

  @family-name: 'Lovelo Black',
  @font-path: '@{baseDir}fonts/lovelo_black/Lovelo_Black',
  @font-weight: 300,
  @font-style: normal

And that’s it. We are now successfully extended UI Library @font-face predefined mixin. 🙂

Magento UI Library certainly provides a lot of powerful material and ideas in general, especially for projects that require more of a skinning type approach. On the other hand, I found it quite overcomplicated in some occasions, especially for complex custom responsive projects that pretty much differ from default layout architecture.

For example, the entire responsive construction is relying on 3 predefined variables @tablet @ desktop @mobile but even as it may be good for a starting point, it’s certainly not a fully scaled solution. Responsive design is all about content while this reminded me more of an adaptive approach with few predefined pixel based queries. Although the fact is that we can always upgrade and extend the system. After all, we can even avoid it altogether and start building our own architecture powered with SASS instead. We’ll certainly experiment with other approaches in the near future.

jQuery integration is a topic of its own and it’s too complex for this article so I’m planning to write another one in the future.


It’s great to see that the new platform is finally shaping up. Now when the potential launch dates are known, it’s even more interesting. Although still in development phase, Magento 2 is a substantially improved system when it comes to frontend development, compared to its predecessor. With all new technologies included, improved architecture and workflow, frontend development now requires by far more professional approach than before.

In case you feel you need some extra help, we can offer you a detailed custom report based on our technical audit – feel free to get in touch and see what we can do for you!

You made it all the way down here so you must have enjoyed this post! You may also like:

How did we standardize Magento 2 frontend development? Ljiljana Milkovic
Ljiljana Milkovic, | 8

How did we standardize Magento 2 frontend development?

Javascript Bundling in Magento 2 Nenad Andrakovic
Nenad Andrakovic, | 18

Javascript Bundling in Magento 2

Meet Magento Spain features an Inchooer talking about Magento 2 Javascript workflow Ivona Namjesnik
Ivona Namjesnik, | 0

Meet Magento Spain features an Inchooer talking about Magento 2 Javascript workflow


  1. for some reason i do not have 1column 2column files. anyway i am intereseted in if there is any better solution than template path hints. because if i activate it, page is really broken, everthin is floating sometimes in wrong position and i cannot figure out what block belongs to which file. i am thinging about to somehow create module that wraps blocks between html commnets like filecontent here but i have no idea how to do it

    1. (edit) html comments like :

      <!-- filepath.phtml --> hmlt content of block <!-- end of filepath.phtml -->
  2. Hey Guy,
    🙁 i can’t do it. Can you make a video training detail step by step the way add many theme download to Magento 2. Thanks so much.
    Hope them so much 🙁

  3. Hi Filip, you wrote:
    “…Magento 2 comes with a distinctive set of changed/improved frontend approaches compared to its predecessor Magento 1.X. THE BIG DIFFERENCE is that frontend is now updated with newer technologies such as HTML5, CSS3 and jQuery”

    In true, at least as I understood, just with version 1.9 Magento introduced core theme changes built on the modern technologies like CSS3, HTML5 and natively available jQuery and design incorporates the best practices for mobile sites.

    Is not like this?

  4. Where is the best place to ask questions around Magento 2? I’m having trouble getting the install working and am not sure where to turn.

  5. Amazing stuff but i am having some problems with the compilation of .less files.

  6. Hi Filip!
    I try to make changes in .less files in my custom theme,but changes aren’t applied on frontend. Do i need some compiler for .less files?

    1. You need a compiler for less. Can you run lessc from your terminal ?
      All your less files will be compiled into CSS. If the compiler isn’t running, your new stylesheet won’t be generated. Which is why your changes are displayed in front-end I guess 🙂
      Source :

  7. Ahh, it looks like that


    is going to help us easily rely on parent theme, instead of relying on directory structure.

    Also the idea of

    <var name="product_base_image_size">275</var>

    Looks good to me. Somehow same kind of feature was available in catalog.xml but hardly found it used.

    I am so excited to explore the new version of Magento.

  8. Please explain me what is the core features for magento 2 if we compare it with magento CE

  9. Hi Filip,
    in Magento 2 is there any kind of development environment. I’ve done some test with theme creation but i sow that the .LESS files are compiled on the first run and if I change something changes are not re-compiled. Please let me know if there is some setting/configuration to let Magento recompile the .LESS files each time I do changes. Thank you and keep posting useful Magento 2 blog posts.

    1. Hi Desislav,
      you can trigger recompiling process from console under \dev\tools\Magento\Tools\View\
      php -f deploy.php
      Or you can enable developer mode in .htaccess
      SetEnv MAGE_MODE "developer"
      but once you do that be aware that Magento recompiles everything from that point on.
      Hope this helps. 🙂

  10. It would be nice if you could make a tutorial how to actually get Magento 2 running.

  11. @Filip Svetlicic

    Let me make myself more clear because I know how to overwrite template and layout files but I want to overwrite a BLOCK file, for instance:


    but when I add a ‘Block’ folder (and I follow the exact directory structure) in my Magento_Theme folder nothing happens so overwriting a block file has to work different I guess…

    Any idea?

    1. Hello Dennis, blocks can’t be changed/rewritten from theme in Magento. Changing block behavior is only possible through modules, let’s say to code your own module in /app/code/MyNamespace/MyModuleName and either rewrite original block from there or create your own custom one.
      It’s usually best practice to create your own block in your own module that extends original block:

      class \MyNamespace\MyModuleName\Block\Html\Topmenu extends \Magento\Theme\Block\Html\Topmenu{ }

      And then change class used from layout to your own

      <block class="MyNamespace\MyModuleName\Block\Html\Topmenu"
  12. Hi Filip,

    Eagerly waiting for Magento 2 to be released. Do we have any release date yet?

  13. I’m trying Magento 2 for a few weeks now and I agree on most. Espescially ‘image resizing not being responsive friendly’. Also using the BLANK theme as starting point is something I don’t prefer at all. You rather should use a copy of the original Magento templates files as starting point for your custom theme.

    Overall I’m positive allthough not blown away at this time.


    Have you figured out how to overwrite core (app/code/Magento/..) files yet? I’ve tried lots of possible solutions but couldn’t figure it out so far and there’s not much online to find.

    1. @Dennis
      Hi, I’m not sure if I understood you correctly but if you’re trying to overwrite something from app/code/Magento/Module_Name/view/frontend the procedure is as explained under the first chapter of the article.

      Inside your theme create directory and name it adding vendorName prefix to the name of the module you’re planning to overwrite.

      For example, if you want to overwrite something from app/code/Magento/Catalog/view/frontend, add Magento_Catalog directory to your theme. Once in there just follow exact directory structure and copy/overwrite required files.
      Hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <blockquote cite=""> <code> <del datetime=""> <em> <s> <strike> <strong>. You may use following syntax for source code: <pre><code>$current = "Inchoo";</code></pre>.

Tell us about your project

Drop us a line. We'd love to know more about your project.