Data is one of your enterprise’s most valuable assets. And synching data between systems is a crucial step in Adobe Commerce development. 

Moving files in and out of a Magento instance can be a real pain-in-the-neck, especially when processing thousands of files within a cloud-based system like Adobe Commerce.

At Atwix, we are quite used to working with Adobe Commerce projects hosted on cloud infrastructure. And so, copying files between Adobe Cloud instances is a pretty common task for our teams. Any given day, we  might be introducing storefront changes, working with myriad new media files on a pre-production instance, or delivering those sometimes-tricky files to the production environment.

As a certified Gold Adobe Solution Partner, Atwix follows the latest best practices when working with Adobe Commerce Cloud across all projects. In this article, we share tips and tricks for copying files between Adobe Commerce instances most efficiently, and according to world-class best practices. 

With 15 years in the market, and more than 150,000 online stores running, Magento is a powerhouse in the ecommerce industry. It’s flexible and feature-rich – hence, the top choice among mid-sized and large businesses – all thanks to the thriving community built around it. 

But as it often happens, there’s no rose without a thorn. And in the case of Magento, for many merchants, the thorn is the level of ‌technical expertise required to unlock Magento’s power. Most often, this requires a skilled Magento development team – internal or external. And If you don’t possess the needed development skills within your company,  how then do you choose a professional Magento development team from the vast pool of available talent, and without becoming overwhelmed?

As a certified Magento / Adobe Partner, and a Magento development firm with 15 years of expertise, Atwix is here to shed some light on the issue. Read on to learn what truly matters when choosing a Magento ecommerce agency.

In our “Close Magento store for maintenance” blog post, we described how to close a store for maintenance and what restrictions we have for the maintenance mode in Magento 1. Fortunately or vice versa, time goes fast, and things change. Magento application also changes and gets more agile to business needs. 

Today we already have Magento 2 and would like to discuss the opportunities that Magento Open Source and Adobe Commerce offer for website owners (merchants) regarding maintenance mode features. Also, we will overview their advantages and disadvantages and applicable cases of each solution. So, let’s get started.

Discover insights around specifics of storefront notifications which Magento 2 uses to inform website visitors as well as existing best practices we recommend to be followed and used by Magento developers.

Working on the same technology, on the same project, on the same code – year over year – will inevitably make a developer strong, knowledgeable and something of a subject matter expert.  However, being hyper-focused for such long stretches of time introduces a variety of risks to the developer and the project assignment, namely a potential loss of interest or worse – burnout.

Magento 2.3 GA release has finally landed. It is one of the most awaited releases that Magento ever had, and it is a thrilling moment for us at Atwix. Not only our clients can now benefit from all the new features that are available in 2.3, but also we can now see live features that our team developed working closely with other community contributors as well as Magento Community Engineering team.

In order to add a custom layout handle to category page, a (basic) Magento 2 module with these additional files and their content is needed:

1. The events.xml file to “subscribe” to the event and say which observer should be fired ↵
2. An observer that adds a new layout handle to the page ↵
3. A layout file that adds needed changes to the page ↵

One of the things that Magento first version lacked was an ability 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 this case, an automatic removal tool of such data would be very useful.

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.

Magento 2 Command-line interface (CLI) tools differ from those in Magento 1. In Magento 1 you could simply add a script to the “shell” directory, include abtract.php, and extend from it. Magento 2 is a bit more complicated. This post will show you how to create a simple CLI script in Magento 2.

It has never been easier to create a development environment. No meter what operation system you use with Docker you can build the exact configuration you need. In this post we will provide steps for creating a sample Magento development environment configured in a single docker-compose.yml file.