Although it seems this repository is not maintained any longer, I thought it worth logging this issue, in case anyone else comes across it.
I had a situation where I enabled the module on one store, and disabled it on the other. The bug resulted in some of the module being disabled, and breaking JavaScript on the site in several places including in the checkout.
The bug exists within the helper class which is responsible for retrieving the config values. Because it doesn't specify a scope ID, the values are always being taken from the default store, regardless of which store is being visited on the frontend. This affected the module enabled check resulting in the layout processor changes to fire, but the JS blocks not to output as they are controlled via an ifconfig layout parameter, which is scope aware. The simple fix is to supply a store ID when retrieving the values. I will create a PR shortly for this.
Although it seems this repository is not maintained any longer, I thought it worth logging this issue, in case anyone else comes across it.
I had a situation where I enabled the module on one store, and disabled it on the other. The bug resulted in some of the module being disabled, and breaking JavaScript on the site in several places including in the checkout.
The bug exists within the helper class which is responsible for retrieving the config values. Because it doesn't specify a scope ID, the values are always being taken from the default store, regardless of which store is being visited on the frontend. This affected the module enabled check resulting in the layout processor changes to fire, but the JS blocks not to output as they are controlled via an
ifconfiglayout parameter, which is scope aware. The simple fix is to supply a store ID when retrieving the values. I will create a PR shortly for this.