Edit layouts fields fix

[artur-stepien]

Summary of Changes

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:

Testing Instructions

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)

Actual result BEFORE applying this Pull Request

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.

Expected result AFTER applying this Pull Request

The ability to override the list of fields to display in those sections without duplicating fields.

Link to documentations

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

[ceford]

I have tested this item :white_check_mark: successfully on 011550392435f4648ab8be192ee5a7ae3d90b3fb

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.}

[artur-stepien]

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:

• Use a temporary fix I created and use the layouts properly in 5.0
• Make a new fix that will accept this parameter both as a layout parameter/argument and as a view property and use it properly in 5.0
• Ignore the fix and change the way those layouts are used in 5.0

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.

[HLeithner]

This pull request has been automatically rebased to 4.4-dev.

[viocassel]

I have tested this item :white_check_mark: successfully on 011550392435f4648ab8be192ee5a7ae3d90b3fb

---

_{This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/41134.}