Magento 2 Certified Solution Specialist is out there for a while and some of you may have already registered and are up to get more familiar with what to expect from the exam. However, some of you might still be wondering if it’s worth spending time on the preparation and test itself.

The Magento Functional Testing Framework was presented by Tom Erskine during the contribution day following MageTestFest, held in Amerfoort in November of the previous year. Currently under heavy development, it has already seen 2 releases and has reached version 2.0.3.

System configuration is a very useful feature of the Magento platform. At the same time, it’s easy to create new configurations for your own custom solutions. We’ve previously discussed on how to add new system configurations with different fields. Today I would like to describe one more type of fields, which can be used depending on your needs. This is a dynamic field block. At times, managing complex data through system configurations is necessary, especially when the number of records to be added isn’t predetermined. In this case it’s impossible to create the exact fieldset in a system configuration tab. Thus, dynamic fields prove to be invaluable.

Magento developers frequently encounter problems accessing custom attributes during product collection loading. For example, when you try to get a product from a quote or a wishlist item. As a result, we’ve identified intriguing workarounds to circumvent this issue, such as repeatedly loading the product. However, there is a proper way to make these attributes accessible. We would like to tell you more about it.

In the past, there was a big challenge to keep a package-based PHP project up to date. We had sort of package managers like PEAR and PECL, but frequently they caused more challenges rather than provided a handy possibility to install and manage packages quickly. Fortunately, the dark age of the mentioned managers is history now, as the Composer comes to fix difficulties. With every new version, Composer has seen significant improvements, and many modern platforms/frameworks like Symfony, Laravel and Magento use Composer as a part of their systems.

It’s well-known that the Magento team announces new platform upgrades quite often. There is a minor upgrade every second month and a more critical upgrade with new features and more changes to the core almost every quarter on average. If we look back, since the release of Magento 2.0 in November 2015 there were around 30 releases for Magento Open Source and Magento Commerce. Looks like a lot, doesn’t it? So the question arises: do these changes actually bring any value to the website?

After the latest Database data format changes in Magento 2.2.x version, there is a need to convert existing PHP serialized data to JSON format. The new release provides upgrade scripts that convert Magento serialized data. But how to deal with custom extensions, which also use automatic serialization mechanism provided by Magento framework? Thankfully, Magento took care of that too.

The new Magento 2.2 release replaces the usage of default PHP serialized format to JSON format. The release also upgrades scripts that convert Magento data that is stored in serialized format e.g. Magento\Sales\Setup\SerializedDataConverter, Magento\Sales\Setup\SalesOrderPaymentDataConverter, Magento\Framework\DB\DataConverter\SerializedToJson classes. These major changes may affect the correct functionality of already existing custom modules and related data that is stored in the database.

One of the shortcomings of Magento’s first version was the inability to clean up module data from the database upon its removal. This is a common situation when you uninstall an extension but all the related data remains in the database. You can only get rid of it manually. It is inconvenient especially if the module has created a bunch of new tables, custom attributes, system configurations etc. In such cases, an automatic data removal tool would be highly beneficial.

In Magento 2 there is a great feature, which allows to create an uninstall script for your module. Let’s find out how it works.

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?”.