Blog

This post was originally published on August 6th, 2015 and has been updated. All information is valid as of August 2017/Magento 2.1

If you haven’t heard the news, the Magento 2 is here, and Magento 1 will, in time, be on the way out.

With it come a lot of questions, like:

• What year is it?
• Where are all the flying cars?
• How much should I be worried?
• And what’s all the bother, anyway?

I don’t have all of the answers, but the year is 2017, the flying cars are conspicuously missing, and Magento 2 is the future. I’ve been following Magento 2 for a while and I’d like to share some of what you can expect as a developer going through the transition.

There’s no avoiding it: Magento 2 will be intimidating at first look, if not downright scary. It uses new tech all over in order to become the best platform it can be for the next ten years. But, if you already know Magento 1, there are a lot of similarities. I’ll walk you through some of what’s new:

1. Module separation

If you know Magento 1, you know modules were spread all over the place: code here, templates there, and JS and other resources in any of several places. No more. Code pools (app/code/core, community, local) are also no more. Everything related to a module is now contained within that module’s directory: app/code/{vendor}/{module}/.

The folder structure within a module is mostly arbitrary now, though there are still some conventions (Block, Controller, Helper, Model). There are some exceptions:

• Config still goes into etc/.
• DB setup scripts go into special files in Setup/.
• Template files, layout XML, CSS, JS, etc. go into respective folders within view/.

2. The Mage:: “god class”

…is also no more. This is probably the most far-reaching change of all. All of the things you used to access through the Mage class have been split up into separate libraries or otherwise replaced. Mage::registry became MagentoFrameworkRegistry. Object loading (Mage::getModel) is now through dependency injection (discussed later), which forces you to be more explicit and careful about what you’re loading. Logging (Mage::log) is through the Monolog library and already injected in many objects.

Most of what was Mage, along with all of the Varien libraries, now lives in lib/internal/Magento/Framework. The beloved Varien_Object class is now MagentoFrameworkDataObject. The magic getters and setters are still there too, although IDEs hate them—it’s better to define them explicitly.

3. Dependency injection (DI)

The big headline change in the architecture is dependency injection. You can’t open a source file without seeing it. It allows for proper unit testing, module separation, customization, and dependency management in a way that was never possible before.

In brief, you define the objects you want access to as arguments to the constructor for each class and then store them as class members for later use. Magento will automatically generate the appropriate objects when your class is created, and “inject” them into the constructor for you. Depending on the type of class, you might be able to inject it directly, or you might need to use an interface (abstract class type) or a factory (creates database models, collections, etc.).

I’m not going to explain all of how it works, but there are a lot of good resources on the subject, including the Fundamentals of Magento 2 Development course and the official Magento 2 documentation.

4. Controllers

Controllers are just normal classes now. They’re named, auto-loaded, and extended like every other class. Isn’t that nice? No more ‘IndexController’, ‘IndexAction’, and rewriting headaches.

Beyond that, you’ll find that there are a lot more of them than before. In Magento 1, you had one controller file containing a group of actions. Now, that controller is called the path, and it’s a folder. Every action becomes its own controller file, and Magento 2 calls an “execute()” method to run it.

Note that this is discussed in great length in the “Fundamentals of Magento 2 Development” course.

5. Blocks

This one might seem silly. In Magento 1, template phtml files were executed within the scope of their block class. That meant $this referred to the block class, and you could use $this to get to any public, protected, or private member or method within that class. That is no longer the case.

To access the block class from a template in Magento 2, you need to use $block, and you can only access public methods. There are some other changes (and a lot of new frontend code standards), but that one stands out.

6. Configuration

In Magento 1, module configuration was rather arbitrary. You had etc/config.xml, and if you were in a good mood, maybe you had adminhtml.xml too. And, if everything went really well, you didn’t have any typos.

In Magento 2, all config xml has an explicit structure, defined in .xsd files. Your module is defined in etc/module.xml. Events are defined in etc/events.xml (or etc/{area}/events.xml). Settings are defined in etc/adminhtml/system.xml, and their defaults (and nothing else) are in etc/config.xml. There are a variety of other config types, and you can add your own too, if needed.

Along the same lines, layout XML files are also strictly defined now and the way they’re written and combined has changed a lot since Magento 1. Each layout handle gets its own file, but the concepts are pretty much the same.

7. Command-line tools

Magento 2 is pushing heavily toward command-line management tools of all shapes and sizes. You can install and manage modules with Composer. Also, bin/magento is a CLI tool that can provide a wealth of functionality, like: completely installing/uninstalling Magento, managing the cache and indexes, setting store configuration values, and more. This provides lots of power for automated build and deployment processes.

There are a variety of other command-line tools and composer libraries included, including performance and testing packages. You’ll have to explore those yourself. See vendor/bin/ to start.

8. Complexity

Now, I’ve always been a strong supporter of the Sublime Text editor. I love it, and I love to help others love it. But Magento 2 is a bit of a maze to find your way around, and the new code standards, dependency injection, and strict XML make for a lot of extra work, even in a fancy text editor.

I’ve switched to the PhpStorm IDE for all of my Magento 2 development, and you should try it too, if you haven’t already. The ability to type hint and click to class references is invaluable, but PhpStorm also has features that will save a lot of time: I have mine configured to auto-generate DocBlock structures, validate the PSR-2 coding standards, and auto-run the php-cs-fixer tool every time a file is saved to fix anything I missed (via a file watcher). It saves me a massive amount of time and headache.

I hope this quick overview gives you an idea of what to expect. All said and done: if you know Magento 1, you already know a lot of what’s going on in Magento 2. Many of the modules and functionality have been almost directly ported onto the new framework.

That’s not to say there isn’t a learning curve. There is. All of those things above will take getting used to and there are lots more to discover. But, it is manageable.

If you’re just getting started with Magento 2, I’d strongly recommend going through the Fundamentals course. It’ll walk you through the new architecture and a lot of what I touched on here, with exercises to really grind that knowledge in.

A lot of the architecture changes are also covered in the official documentation, which makes for a good reference. And, if all else fails, there’s the Magento Stack Exchange.

Don’t expect to master it in a day, but you’ll get there.

Have more questions about Magento 2?

Don’t be afraid to ask. Get in touch today!

Click Here