This issue is automatically created based on existing pull request: #30119: Added a dedicated modifier pool for categories
Description (*)
This PR greatly decreases chances for conflicts if your application has more than one custom or 3rd party module extending category edit form using modifiers.
The problem:
As we know, ui component forms can be extended either in xml files or using modifiers written in PHP and injected via modifier pools to their corresponding form.
This is easy for products, the etc/adminhtml/di.xml file in the Magento_Catalog module defines a Magento\Catalog\Ui\DataProvider\Product\Form\Modifier\Pool virtual type with some modifiers already there and injects it as the pool argument for Magento\Catalog\Ui\DataProvider\Product\Form\ProductDataProvider. If you want to add your own argument, you simply target that virtual class in your own di.xml and add a new item to the modifiers array.
However, in case of categories it's not that straightforward. Although the overall logic is the same, categories don't have any virtual type for the pool defined. So they get null as the pool argument and end up with the generic Magento\Ui\DataProvider\Modifier\Pool as the pool, which is added in the parent constructor of the data provider. Needless to say, you can't add your own modifiers that are related to category form to that generic pool.
This means that if you want to add modifiers to category form, you need to create your own virtualType for the pool, add your modifier to it and inject it as the pool argument for the data provider for the category form. Which works if you happen to have only one module doing that, but if you have more than one, a conflict is guaranteed (they last one to load wins and overwrites the pool argument with its own pool).
A solution to that is adding a new virtualType for that pool and injecting it as the pool argument directly in the Magento_Core. Although that pool doesn't contain any actual modifiers by default, it serves as a point to which custom/3rd party modules can hook to and add their own modifiers without conflicts.
This is also a backwards-compatible solution, because if you happen to already have some module adding its own pool to the category form, that pool will overwrite the empty one added in this PR (assuming you have a correct sequence in your module.xml, with Magento_Catalog added there).
Manual testing scenarios (*)
- None really. Go to a category edit page in the admin panel (which is the only page loading the affected functionality) for any category and ensure it still works if you want to test something.
Contribution checklist (*)
This issue is automatically created based on existing pull request: #30119: Added a dedicated modifier pool for categories
Description (*)
This PR greatly decreases chances for conflicts if your application has more than one custom or 3rd party module extending category edit form using modifiers.
The problem:
As we know, ui component forms can be extended either in xml files or using modifiers written in PHP and injected via modifier pools to their corresponding form.
This is easy for products, the
etc/adminhtml/di.xmlfile in the Magento_Catalog module defines aMagento\Catalog\Ui\DataProvider\Product\Form\Modifier\Poolvirtual type with some modifiers already there and injects it as thepoolargument forMagento\Catalog\Ui\DataProvider\Product\Form\ProductDataProvider. If you want to add your own argument, you simply target that virtual class in your own di.xml and add a new item to the modifiers array.However, in case of categories it's not that straightforward. Although the overall logic is the same, categories don't have any virtual type for the pool defined. So they get
nullas thepoolargument and end up with the genericMagento\Ui\DataProvider\Modifier\Poolas the pool, which is added in the parent constructor of the data provider. Needless to say, you can't add your own modifiers that are related to category form to that generic pool.This means that if you want to add modifiers to category form, you need to create your own virtualType for the pool, add your modifier to it and inject it as the
poolargument for the data provider for the category form. Which works if you happen to have only one module doing that, but if you have more than one, a conflict is guaranteed (they last one to load wins and overwrites thepoolargument with its own pool).A solution to that is adding a new virtualType for that pool and injecting it as the
poolargument directly in the Magento_Core. Although that pool doesn't contain any actual modifiers by default, it serves as a point to which custom/3rd party modules can hook to and add their own modifiers without conflicts.This is also a backwards-compatible solution, because if you happen to already have some module adding its own pool to the category form, that pool will overwrite the empty one added in this PR (assuming you have a correct sequence in your module.xml, with Magento_Catalog added there).
Manual testing scenarios (*)
Contribution checklist (*)