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?

We decided to put all of our wallpapers in one place. Just hit the image that you like most and download in any resolution you need. Enjoy!

When you are developing an application that includes webhooks (Slack, OKTA, etc) you need a publicly accessible URL to connect the webhook service with. Usually you develop on localhost and there is no access for someone else to it. So, how can you test your webhooks in such situation?

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.

Despite the incredible convenience of online shopping, including saved time and efforts, wide ranges of products to be compared and purchased, provided discounts, and detailed product information, eCommerce has not yet completely replaced traditional trade.

One of the main reasons here is that customers have no physical access to products and can not touch, feel, and closely examine the items they buy. This drawback becomes even more significant in the case of digital fashion stores selling clothing, shoes, and accessories, where shoppers additionally need to make sure about the size and look. Note that, the average return rate for apparel stores is between 20-30%, which is much higher than the 10% rate for gifts, toys, and home products.

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.