Closed mattijv closed 5 years ago
Hi @mattijv. Thank you for your report. To help us process this issue please make sure that you provided the following information:
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
@magento give me 2.3-develop instance
- upcoming 2.3.x release
For more details, please, review the Magento Contributor Assistant documentation.
@mattijv do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?
Since there seems to be no label for it, I want to stress that this is strictly a developer experience issue.
Hi @engcom-Delta. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:
[ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).Details
If the issue has a valid description, the label Issue: Format is valid
will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid
appears.
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description
label to the issue by yourself.
[ ] 3. Add Component: XXXXX
label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.3-develop
branchDetails
- Add the comment @magento give me 2.3-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.3-develop
branch, please, add the label Reproduced on 2.3.x
.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
[ ] 5. Verify that the issue is reproducible on 2.2-develop
branch. Details
- Add the comment @magento give me 2.2-develop instance
to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.2-develop
branch, please add the label Reproduced on 2.2.x
[ ] 6. Add label Issue: Confirmed
once verification is complete.
[ ] 7. Make sure that automatic system confirms that report has been added to the backlog.
Hi @mattijv thank you for your report. I'm not able to reproduce issue by steps you described on clean 2.3-develop.
If you'd like to update issue, please reopen it.
@engcom-Delta To clarify: by dynamic I don't mean the FieldArray input type. I guess "dynamic" was not a good term.
What I mean by "dynamically" is to use a plugin to add fields (of any input type) that are not defined in a system.xml file. For example by creating a plugin for the setData
method of `app/code/Magento/Config/Model/Config/Structure/Element/AbstractComposite.php``that adds an additional field besides those defined in a system.xml file.
EDIT: I'm leaving this closed since it's a developer experience issue rather than a functional issue and it's more your decision if you wish this to be discussed more.
Summary
We have a module that adds config fields dynamically to the admin shipping method page. When testing the module in M2.3.2 we ran into an issue where saving any values via the admin page was impossible. The reason is the filter in the save controller added in this commit https://github.com/magento/magento2/commit/8089bd741cd3521943c1b33b6d80c74df8a49667 that strips out all fields not defined in a system.xml file.
In our use case (dynamically created shipping methods) it is impossible to create corresponding system.xml files. Fortunately we can bypass the new filter by making a plugin to the Magento/Config/Model/Config/Structure::getFieldPaths-method. This, however, seems a bit kludgy and non-semantic.
Examples
Works in <= M2.3.1, but not in M2.3.2.
Proposed solution
I'm not 100% sure this even is an issue, since the workaround is fairly obvious. However, I feel there could be a more semantic way of being able to use dynamic fields in the adminhtml. Tricking the filter into believing there are system.xml paths for the config values isn't a great for code smell and readability perspective.
I am not sure what the addition of the filter was meant to fix as there is little info in the commit, but I assume a filter like that is necessary. As I don't think our use case is that outlandish for an extension developer, I think there could be a more obvious method added that can be pluginized into, or some other way of whitelisting fields for the filter. Thoughs?