Magento event system is one of the most powerful and commonly used techniques for extending the standard back-end logic. What’s more, choosing the right event for a custom logic interpretation is an essential part of development.

Even though event systems in Magento 1 and Magento 2 share similarities, developers will find it useful to understand how the Magento 2 event system operates specifically. Read on to see a list of the framework-level events that help understand which event will be perfect to monitor and track in Magento 2.

System configuration is a simple way to store single values required for application functionality in both Magento 1 and 2. In this post, we will show you how to add custom system configuration settings in Magento 2.

System configuration values in Magento 2 are stored in the core_config_data database table, which is exactly the same as in Magento 1. But the xml config files differ.

Starting with the Magento 2 registry deprecated, which has been widely used by developers and extension vendors, is declared deprecated. 

Class comments often suggest using service classes or data providers, but no examples are provided. In In this article, we’ll show you how to obtain the necessary data using best practices and service classes.

We’ve previously talked about a handy n98-magerun CLI tool, which was a game-changer for Magento 1 developers, turbocharging their development workflows.

Now, let’s shift our focus to n98-magerun2, the next-gen counterpart tailored for Magento 2, courtesy of netz98. Its previous version was popular among Magento developers and we think that n98-magerun2 should be another useful command line interface tool for every new Magento version.

So, let’s install n98-magerun2 and try how it works.

The logging system comes super handy in Magento development. Developers use it as a go-to tool for code debugging. There is a reduced chance of encountering a raw Magento 2 internal server error without handling it via Magento 2 logging, compared to Magento 1.

Log files show us how the store works, reveal pesky issues under the hood, and even snitch on the functions that aren’t pulling their weight. In this article, we will describe the logging system in Magento 2 and how it differs from Magento 1.

Before COVID-19 cut the possibility of public gatherings, we had plenty of offline hackathons or contribution days in the Magento community world. An essential part of a working toolkit at such events is, obviously, a laptop (there were gurus that wrote the code even on tablets but that’s a different story). At every table, alongside ten developers with serious expressions, you would typically find at least seven MacBooks and three other devices running Ubuntu. If you’re lucky, you might encounter a developer who uses a Windows-based laptop as their workstation, but this is a rare exception.

The growing unpopularity of Windows-based laptops among web-developers in the past has its roots. There was a period when Windows could not provide a toolkit powerful enough for productive web application development. Many developers, who made the switch from Windows to OSX or Linux, never looked back. But during the last few years, the situation with the Windows platform has changed dramatically. Microsoft took the direction of improving the development tools they own (VS Code, WSL) and acquiring new ones (GitHub). We would like to share our recent experience in building Magento 2 local development environment using Docker and WSL 2.

Magento events and observers are a good old way of extending Magento. This approach originated from Magento 1 and is well-known beyond the Magento community and platform. It follows an observer design pattern and has different implementation and variations in different frameworks. This article covers how the Event Framework was implemented in Magento and how it is recommended to be used by the Magento Development Team..

You already know how to create a simple CLI script. The CLI scripts are initialized with a different area – essentially, with a separate CLI area\application, which lacks the standard frontend\admin localizations functionality. We faced that when developing a script for sending order emails via CLI – the emails were missing translations of the origin of the order. Let’s try to figure out “why?” and “how to fix?”.

It is always good when you can test your features fast. But sometimes it’s literally hard and takes a lot of time to test something in Magento. When you make one little change in code and want to test it, it can take much more time to test it rather than make the change itself. Nevertheless it’s a common situation taking into account the complexity of Magento.

Every unit test ninja faces troubles whenever he wants to test some real class functionality. Have you ever invoked toHtml() method of some block or beforeLoad() method of any collection? If you want to do it, you will need to mock a lot of classes that depend on other classes and so on. You would need to mock all of them, which would take a lot of time and effort. In a long run, you may blow up deadlines and it would really suck. Yes, you can try to change your testing strategy to avoid invoking such methods. But what if you still need to test them? Let’s explore how I addressed this issue.