A Couple of the More Interesting Bugs We Have Found Whilst Working With Magento 2

This post is about a couple of the more interesting and fundamental bugs which we have come across whilst working with Magento 2.

This post is about a couple of the more interesting and fundamental bugs which we have come across whilst working with Magento 2. A few of these took a while to find and resulted in quite large issues on production sites. Knowing a few simple things can save you a lot of time and effort.

Firstly a word regarding how we like to include fixes for bugs we find. We tend to keep these within an individual ‘fixes’ module. This allows us to keep them all in one place which is useful to reference back to, particularly when updating Magento to try to ascertain what is still required and what has been fixed in the particular release. For our PHP based fixed we tend to prefer the use of plugins but will often be forced to use preferences due to function visibility or the nature of the bug itself. For our JS fixes we will tend to use JS mixins. Again, we would fall back to overrides where absolutely necessary.

Product Data Mysteriously Becomes Specified on Store Scopes When Saving in Admin

A client reported to us that data was being specified on store scopes when they had not actually set this themselves. Looking into the issue we found that this was actually happening in a very specific circumstance. If you visit a product in the admin, change to a store scope and then save the product (without expanding any tabs). What actually happens is only the fields which are rendered are sent to the server. Due to the use of Knockout, those in tabs which have not been opened are not rendered. This means that all those, including the ‘Use Default’ checkboxes, which sit within collapsed, and unopened, accordion tabs never actually get sent when making the POST request to save the product. Magento does not handle this well and therefore data – previously set on the default scope – becomes specified on the store scope. It is important to highlight that the fields are rendered when having opened the tab and then closed. This is an important fact as it is what we, and likely what you would do when trying to diagnose this issue and thoroughly checking the states of the fields when trying to reproduce.

This was reproduced on Magento v.2.2.2.

Below is a snippet from the Knockout template (vendor/magento/module-ui/view/base/web/templates/form/fieldset.html) responsible for this:

        if="opened() || _wasOpened"
        each="data: elems, as: 'element'" render=""/>


What we did to get around this was a temporary measure but was to modify the knockout template so that all of the accordion tabs’ content gets rendered (essentially removing the if binding). This will slow down the page but it really is the lesser of two evils.

Saving Customers Directly Results in a Loss of Data

If you attempt to save a Customer Model directly you will find that data for your custom attributes actually gets deleted! The reason this is occurring is actually because the attribute set is not set on the Customer Model. This is not an issue when saving via the Customer Repository or via the updateData function on the Customer Model. There are actually comments within the core code that acknowledge this issue, for instance the within the save function of the Customer Repository:

// Need to use attribute set or future updates can cause data loss
if (!$customerModel->getAttributeSetId()) {


More information on the technicalities of this issue can be found on a ticket we raised with Magento here – This has been acknowledged by Magento as an issue on 2.1.x, 2.2.x and 2.3.x. but for the time being we should remember to use the repository to save customers.

About the author

Dan Cook

Dan’s our Magento 2 guru, and master of front-end development - he loves JavaScript (maybe too much), and enjoys playing his guitar.