Türchen 5: Why is Magento 2 so difficult


This article is also available at medium.com


Magento 2 has a lot of awesome new approaches to day-to-day issues, but also suites the classical Magento mantra “Let’s make standards the Magento Way™”

If you give it a chance and find your way around the quirks of it, it’s not so difficult at all.

They are using standard components

Magento 2 switched to very common standard components, which a lot of you already know: jQuery, requireJS, knockout.js – Some are not so common: Less

But unfortunately they still follow their Mantra to implement these standards in a slightly Magento’ish way. On one hand I can absolutely understand their reasons to do so, on the other hand: it makes it much more difficult to get started with Magento2.

Let’s talk about that “Less” thing

Yes: the bigger part of web-development-land uses scss. But to be honest: Less isn’t that different at all. Slight syntax differences but the concepts are identical.

Then why in lord’s name did they choose Less

Well, when this part of Magento 2 was built, there was no stable and maintained PHP-based scss parser. So they used Less for Magento 2.

But why not real Less?

Real Less, that you can directly parse with a native less compiler? Modularity doesn’t go well hand-in-hand with plain Less files. You can’t tell the processor, to include files from different directories based on patterns.

You only have two options now:

  1. Code some voodoo magic that runs ahead of the processing
  2. Have core files being changed by various people with merging conflicts and content duplication and what not …

I would have created something similar to Magento’s //@magento_import ‘hack’. Once you understand that concept it’s not just easy but also very flexible and saves resources if specific modules are turned off.

Speed of development

If you work with Magento’s native PHP-based Less workflow it’s very frustrating. Whenever you change a source file in your theme, you have to delete at least 3 different files in at least 2 different directories. There’s no built-in automation for that (var/view_preprocessed and pub/static)

If you complain about that at Magento, they gonne reply that no one is using that. That’s not quite true, I would say, but what’s the preferred way then? Well … just use a local task runner like Grunt that does it for you. Magento 2 already ships default config files for nodeJS and grunt so you can start right away and take advantage of the file watcher benefit — change your less file, get rebuilt css filesautomatically.

Using that adds additional technology layers on top of your already quite high technology stack (hmtl, css, less, php, mysql, javascript + nodejs, grunt)

Did you hear about these UI components?

Yeah … okay … that one particulary is a pain in the ass. It’s a freaking mashup of random configurating XML, knockout.js with html templates, requireJS and jQuery Widgets … It takes a good while to understand it, if you really accomplish the “understanding”.

Magento thought about a way to load data asynchronously together with reusable generic elements in the backend and frontend. In order to not rewrite every component, there had to be a way to configure each component individually. That’s usually done with json injected into the component.

There’s one more thing …

But Magento wouldn’t be Magento if they’re not using ..xxXML for it! With Magento 2’s new layout xml capabilities you can create hierarchical structures containing arrays and data (like objects i.e.). So you can also create the configuration for UI components via layout XML …

That might look like some arbitrary XML that doesn’t follow any rules. Which … more or less …is exactly that: arbitrary XML 😶 but it’s flexible and interchangeable!

If you want to get a better understanding of UI components, I can highly recommend Alan Storm’s Series about UI components in Magento 2.

That’s one of the smaller parts of Magento 2 where no tool can help you and where no palliation is available.

But there are other crucial parts, where someone is to our rescue …


Magento’s Caching now supports a full page cache as well as a wide variety of other cache types. If you’re writing an extension that touches different parts of the app you gotta clean the caches A LOT … So the easiest workaround here would be: disable the caches. Haha … yeah … it doesn’t work that way.

No Cache … No Performance

If you disable the caches Magento becomes ridiculously slow on every request. Manually partial cache cleaning instead is a pain in the but again, because you always have to think about which caches you have to clear. And if config is one of them — get yourself a coffee 🙂 because you can’t kick out just the affected cache fragments but have to clear the full cache section.

Make sure you’re using redis to have a faster cache backend; that doesn’t solve the problem, but at least makes everything a tiny bit faster.

The only thing that might help you here is a nice nodeJS based tool, developed by mage2tv’s Vinai Kopp, named cache-clean.js. Running as a watcher, it’ll clean just these fragements/cache types that are affected by your file changes. In that case you can have all caches enabled but still work with 95% of the full cached performance!

There’s a very quick but yet effective tutorial on how to set it up with PHPStorm, written bei Timon de Groot.

Plugins? I like them … not just in WordPress *cough*

Functional extensibility is always a tricky topic and not easy to handle. Most application chose to go along with publish/subscribe implementations. You can still create subscribers (called Observers) in Magento 2, but there’s a more powerful way: Plugins!

Before … or after … or … around!

Magento 2 generates a lot of PHP classes automatically based on configuration options and source code. By simply creating 3 lines of XML together with a new class, you can hook into almost every public method call. That’s done by parsing your new class and look for method names of the original class, prefixed by either around, before or after. Magento will then magically create a new class (called Interceptors) that (i.e. before) first calls your method and after its execution calls the original method.

1 … 2 … STEP

And the cool thing here is: you can have as much plugins chained in a specific order as you like. Even around, before or after. Magento takes care of it.

But why is this difficult?! That’s awesome, man!

It is! But in developer mode … oh hell … Magento will create those intercepting classes all the time for all the methods, no matter if you need them or not as long as there’s a plugin configured. And I dare you to go for it with xDebug … The stack traces are toilet paper long!

If you don’t care about these repetitive debug cycles with “autogenic training” like immersion … you’re fine! One note: Only use around Plugins if it’s unavoidable. Their impact in performance is much worse than before and after.


Magento 2 is more difficult than Magento 1, especially looking into frontend development. As always: the wonderful Magento community takes care of some of Magento’s ceveats and try to help with their expertise. Be it with tutorials or tools. Once you understand the ups and downs of Magento 2, how you probably did with Magento 1 years ago, you might have some real fun and some very tragic moments with it!

Read more in the DevDocs

Magento’s Developer Documentation is a very good way to start diving into Magento.

Leave a Reply

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