You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue appears when we use any custom module that contains an admin grid. The grid is breaking when you install the Icecat_DataFeed module and visit that grid it throws an error. “Not registered handle” with the Exception error. It is also affected with the Magento default modules. Which also displays the same error “Not registered handle” with the Exception error.
I have found an error when editing the content page and adding it into HTML code and configuring with insert image same error was appered.
This error might affect other modules too.
Error Screenshot:
“This error occurs when visiting the custom module admin grid, it will throw the error Not registered handle with the exception error."
Steps to Reproduce (In Default Magento):
Get the Magento clean shop.
Install Icecat_DataFeed module.
Navigate to the Content > Elements > Pages.
Edit any page (ex. Home page).
Go to content and edit the page builder.
Add HTML code element.
Click on the insert image button, it is throwing an error as mentioned.
Error:
Steps to Reproduce (with Custom Module):
Get the Magento clean shop.
Create a custom module with the admin grid.
Check it is working on the backend.
Now, Install Icecat_DataFeed module.
After Installing the Icecat module check your custom grid it is throwing an error as mentioned.
Expected Behavior:
The expected behavior should be that the Icecat_DataFeed module can be installed without disrupting the custom module's admin grid. This means that when you attempt to retrieve a collection array from "Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory," it should not result in an exception error within the grid, and the grid should function smoothly alongside the Icecat_DataFeed module.
Additional information:
Error occurs because of the icecat module configured the "Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory" Configuration specifically in the etc/adminhtml/di.xml file.
also, I observed that the Icecat module has been manually adding Magento's default collection array argument in "icecat/magento2-extension/etc/adminhtml/di.xml." This manual addition may lead to potential conflicts with Magento.
As a consequence of these manual additions, errors may occur in all Magento functionalities that are not explicitly included in the "icecat/magento2-extension/etc/adminhtml/di.xml" file. It's important to note that there is no need to manually add items in this file to ensure smooth integration with Magento.
This is a very potential error for the Magento environment. it's important to consider potential conflicts with Magento and other custom modules.
Many Magento default modules use the same argument,
“Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory”, globally in the "etc/di.xml" file.
In my defense, I think my understanding is a reasonable conclusion from Magento's documentation which reads: “Each module can have a global and area-specific di.xml file. Magento reads all the di.xml configuration files declared in the system and merges them all together by appending all nodes”
When parsing DI configuration files, declarations from the area-specific files such as etc/adminhtml/di.xml will override argument declarations from the Global DI file (which is in the etc folder).
You MUST declare such configuration in your module's "Global" DI Configuration file (i.e., etc/di.xml otherwise you will effectively "override" all other DI configurations for the "collections" argument of the targeted type.
This is a confusing problem to debug/understand if you have a couple of modules you have written, both following the same method of declaring arguments in the area-specific DI file. In this scenario, your UI Components will work, but built-in Magento components will not. This is because, as I've explained, declaring arguments in the area-specific di.xml will override arguments in the Global di.xml file.
I hope you can grasp the issue that arises due to argument declarations within the "etc/adminhtml/di.xml" file. It is essential to declare these arguments as "global" within the "etc/di.xml" file to resolve the problem effectively.
The text was updated successfully, but these errors were encountered:
Hello,
exactly this happens, they are not defined in the global di.xml, removing this file: etc/adminhtml/di.xml
And including all declarations in this one: etc/di.xml
The issue is resolved, I hope they have it fixed in the next version of the plugin.
Thank you.
Environment
Module Version: 2.0.0 (icecat/magento2-extension).
Magento Version: 2.4.6-p2.
Issue Description:
The issue appears when we use any custom module that contains an admin grid. The grid is breaking when you install the Icecat_DataFeed module and visit that grid it throws an error. “Not registered handle” with the Exception error. It is also affected with the Magento default modules. Which also displays the same error “Not registered handle” with the Exception error.
I have found an error when editing the content page and adding it into HTML code and configuring with insert image same error was appered.
This error might affect other modules too.
Error Screenshot:
“This error occurs when visiting the custom module admin grid, it will throw the error Not registered handle with the exception error."
Steps to Reproduce (In Default Magento):
Add HTML code element.
Error:
Steps to Reproduce (with Custom Module):
Expected Behavior:
The expected behavior should be that the Icecat_DataFeed module can be installed without disrupting the custom module's admin grid. This means that when you attempt to retrieve a collection array from "Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory," it should not result in an exception error within the grid, and the grid should function smoothly alongside the Icecat_DataFeed module.
Additional information:
Error occurs because of the icecat module configured the "Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory" Configuration specifically in the etc/adminhtml/di.xml file.
also, I observed that the Icecat module has been manually adding Magento's default collection array argument in "icecat/magento2-extension/etc/adminhtml/di.xml." This manual addition may lead to potential conflicts with Magento.
As a consequence of these manual additions, errors may occur in all Magento functionalities that are not explicitly included in the "icecat/magento2-extension/etc/adminhtml/di.xml" file. It's important to note that there is no need to manually add items in this file to ensure smooth integration with Magento.
This is a very potential error for the Magento environment. it's important to consider potential conflicts with Magento and other custom modules.
Many Magento default modules use the same argument,
“Magento\Framework\View\Element\UiComponent\DataProvider\CollectionFactory”, globally in the "etc/di.xml" file.
In my defense, I think my understanding is a reasonable conclusion from Magento's documentation which reads:
“Each module can have a global and area-specific di.xml file. Magento reads all the di.xml configuration files declared in the system and merges them all together by appending all nodes”
When parsing DI configuration files, declarations from the area-specific files such as etc/adminhtml/di.xml will override argument declarations from the Global DI file (which is in the etc folder).
You MUST declare such configuration in your module's "Global" DI Configuration file (i.e., etc/di.xml otherwise you will effectively "override" all other DI configurations for the "collections" argument of the targeted type.
This is a confusing problem to debug/understand if you have a couple of modules you have written, both following the same method of declaring arguments in the area-specific DI file. In this scenario, your UI Components will work, but built-in Magento components will not. This is because, as I've explained, declaring arguments in the area-specific di.xml will override arguments in the Global di.xml file.
I hope you can grasp the issue that arises due to argument declarations within the "etc/adminhtml/di.xml" file. It is essential to declare these arguments as "global" within the "etc/di.xml" file to resolve the problem effectively.
The text was updated successfully, but these errors were encountered: