Magento mastery… You’ve worked hard for it. Your Magento accomplishments have been hard-fought through blood, sweat, and tears. Okay, maybe not blood, but almost certainly some sweat and tears.
Enter Magento 2. You’ve heard about all the great new features: a new marketplace for extensions, new deployment processes, and more dependency-injection than you can shake a stick at. Just like that, your so-called “mastery of Magento” is gone, right? WRONG. Magento 2 introduces some great new elements, but all of the things that made Magento 1 great are still around.
There are plenty of articles out there highlighting what’s new in Magento 2, but I’d like to examine what’s old.
These are the reasons you’re still a Magento master.
[cta prefix=”Related:” count=”1″][/cta]
Now take a deep breath and let that apprehension over Magento 2 melt away. The more things change, the more they stay the same…
A quick look at the modules in vendor/Magento will tell you that all the familiar module components from Magento 1 are still there. Some of them work a little bit differently, but their roles are the same. Also, note that many of the additions are components you’re familiar with that have been moved from other areas in the Magento file structure into the module directories. For instance, translations located in app/locale in M1 are now in i18n. Module-specific items previously located in app/design and skin are now located within the module’s view directory.
Blocks have changed so little that you can pretty much use them the way you always have. All your favorite methods like beforeToHtml, afterToHtml, and _prepareLayout are present. There are equivalents for M1’s abstract and template block classes (located in vendor/magento/framework/View/Element).
Controllers serve the same purpose you’re used to, but M2 has simplified their structure. Instead of multiple actions on a single controller (such as a customer account controller with login, logout, dashboard, etc.) every action has its own controller. You implement the method “execute” on the controller to perform what would have been in the action method in M1.
If you love xml-based configuration, Magento 2 delivers. The big difference here is that the configuration you’re used to has been divided into more files. For example, instead of having event and cron sections in config.xml, these pieces of configuration have been moved into events.xml and crontab.xml. Global, frontend, and admin nodes in a single file have also been replaced with separate directories. For example, in the catalog module observers in etc/events.xml will function in admin and frontend while etc/frontend/events.xml will only apply to the frontend.
No special caveats here. M2 helpers work exactly as you’d expect.
Models are very similar to M1. There are models, which represent individual entity instances (such as a particular product), and resource models (including collections) which perform the actual database interactions. When accessing models within your module there won’t be much difference from M1. Accessing models in other modules (such as loading products within your custom module) have some caveats related to the new service layer (the module’s API directory – see Advantages of Service Contracts). However, even these new elements are somewhat reminiscent of models and collections in the way they represent data.
It’s also worth mentioning that observers and cron tasks are no longer grouped with models. They each have their own directory in the module.
sql / Setup
In M1 modules contain install and upgrade scripts that are triggered by a discrepancy between the module version (in etc/config.xml) and the module’s record in the core_resource table. This is similar to M2, but the system has been simplified. There are generally fewer files and you don’t have to name them according to the version numbers that apply.
Extensibility has always been a huge focus of Magento, and M2 offers even more options for elegantly modifying how the application runs and appears to the user. However, the M1 concepts are still present and play a big role tailoring your installation to suit your needs.
Magento has always relied on theme fallback to provide presentation flexibility. Files found in your theme will be used. Files that aren’t found will be retrieved from its parent theme. This is the same in M2.
Throughout the Magento application events are deliberately dispatched to allow interference from other modules. This remains unchanged in M2, and it’s still the best place to make a change to behavior if needed. Observers are now located in their own directory (instead of Model) and, just as M2 controllers have one class per action, observers have one class per event with an “execute” method to be run in response to the event.
Rewrites / Preferences
If observers fail to provide the necessary access in M1, rewrites are the go-to solution to modify a class’s behavior. While it’s important to mention that M2’s plugin functionality would be the next best thing after observers, the concept of a rewrite is still around. The closest thing in M2 is a preference, and it’s related to the dependency injection system. Like an M1 rewrite, it allows you to swap instances of native classes with your own so you can override methods and properties on the class.
If you love M1’s xml-based layout system (and I do), M2 layout doesn’t disappoint. It’s conceptually the same, but the organization is just a little different. Comparing the two makes M1 seem a little free-form. M2 takes a more structured approach to layout. For starters, instead of having multiple layout handles per file every layout file is associated with a specific handle. For instance, the contents of catalog.xml in M1 have been broken out as catalog_product_view.xml, catalog_category_view.xml, etc. in M2. The main body of these files feels basically like M1, but instead of just using block tags you’ll also be using container tags. Containers are equivalent to core text lists in M1. They simply render all child elements in the specified order. Blocks work in the same manner as M1 with a few exceptions such as how the block type is defined and the ability to specify constructor arguments.
If you know the catalog in M1, you know it in M2. The core structure, as well as many of the settings, remain unchanged.
Managing product attribute sets and attributes in M2 is virtually identical to M1. Very little has changed with product architecture as well. The available product types are all the same as are most of the attributes. The biggest change in M2 is the presentation. Magento experts may find themselves searching a bit for the settings they’re used to while Magento novices will find a less overwhelming experience. It’s obvious that the changes were intended to streamline the product management process, and I personally think they’re effective. One other part of the new process worth mentioning is the ability to switch between certain product types after the product is initially created. While M1 makes you choose the product type up front, M2 lets you switch between simple, virtual, downloadable, and configurable product types based on your settings. It should also be noted that configurable product prices now originate from the associated simple products rather than a base price + additional option costs.
M2 categories are nearly identical to those in M1. The interface for managing them is the same including the category tree and the tabs (general information, display settings, etc). The major change with categories is the new option to populate them using rules instead of making manual associations, though this feature was also available in Enterprise 1.14.
If you’ve spent your fair share of time learning all the elements of the M1 order flow, you’ll be glad to know that it has stayed pretty much the same. Quotes and quote items become orders and order items. Order states and statuses are all familiar, and shipments, invoices, and credit memos are still around. One nice new feature is the ability to customize the sales grids. You can customize which columns display and save the settings as views for easy access in the future.
Indexing and Caching
You won’t notice many changes with the caches and indexes in M2. The management is what you’re accustomed to. Indexes can be set to update on save or by schedule. The list of available indexes differs a bit, but nothing looks particularly foreign. The caches are equally similar to their M1 counterparts. Cache types can be individually enabled, disabled, and refreshed and the flush Magento cache and flush cache storage buttons are still around. There are a few new cache types, but they’re pretty self-explanatory. One pleasant addition is the page cache in the community edition.
A Bright Future for Magento and You
If you’re getting ready to jump into Magento 2, I encourage you to do it with optimism. I was personally nervous to get started but I was soon surprised at how familiar it feels. Once you get past the initial learning curve of some of the new concepts (with the help of Magento’s documentation site), you’ll realize you’re more equipped than you realize to step into the next generation of Magento development. Happy developing!