User tests: Successful: Unsuccessful:
This fixes the functionality of selecting what fields should be rendered in the edit layouts. Currently this function is dead, cause if you try to use it, you end up having duplicated inputs or strange workarounds. The issue is the fields
property exists on a view instance, not per layout. Editing every layout usage in a way that view instance and layout parameters are passed as an array would require a lot of changes and still would be prone to cause errors in third-party components. By prefixing the fields
property like in this PR we unlock the function most likely without causing third-party components issues.
Here is the proof this property is duplicated:
Compare the article edit few before and after the changes. They should look and function the same as those fields are not used in core components (layouts default views are used)
When you set the fields
property on the view it applies not only to a single layout but to all layouts using this property for filtering fields to render. Because of this, you end up in duplicated inputs all over the view. As core components don't use this property they are not affected by it. But any other component using build-in layouts with custom fields for example in publishing section will end up in duplicated fields.
The ability to override the list of fields to display in those sections without duplicating fields.
Please select:
Documentation link for docs.joomla.org:
No documentation changes for docs.joomla.org needed
Pull Request link for manual.joomla.org:
No documentation changes for manual.joomla.org needed
Category | ⇒ | Administration com_menus Layout |
Status | New | ⇒ | Pending |
I have tested this item ✅ successfully on 0115503Editing an article continues to work with the patch applied. I added a Field in Articles and Users - OK. However I am not confident I know enough to foresee any potential problems. In particular I was wondering where the $displayData->get('fields') and their replacements come from
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/41134.
This is data passed to the layouts. The problem is, it is not passed by a layout parameter. Instead, it is passed as a view class property and the view class itself is passed as a parameter (example). I suppose it was made to allow overriding the list of fields displayed or ignored in the layouts I changed. It is not used in the core components cause in the layouts it loads default value every time and in the view it is not overwritten (if you would try to use it it would cause fields duplication cause same view property is used to override the list of fields in multiple layouts.
If we would want to fix it properly we would have to change every layout of the ones I changed to be used with layout parameters (like it should be from the beginning). The problem is, the layouts are used in third-party components where we can't change the way they are used. We would have to accept both ways to pass those fields.
I see two solutions:
One way or the other it has to be fixed finally cause the functionality is dead. I didn't saw a single custom component using this but I had to use it while I was creating a custom one that is not using fields defined in a default value of this property.
This pull request has been automatically rebased to 4.4-dev.
I have tested this item ✅ successfully on 0115503
Labels |
Added:
bug
PR-4.4-dev
|
Title |
|
This pull request has been automatically rebased to 5.2-dev.
Title |
|
I have tested this item ✅ successfully on 0115503
Editing an article continues to work with the patch applied. I added a Field in Articles and Users - OK. However I am not confident I know enough to foresee any potential problems. In particular I was wondering where the $displayData->get('fields') and their replacements come from
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/41134.