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

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.

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

I have tested this item ✅ successfully on 0115503

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

Could you please explain with an example what do you want to do?

Could you please explain with an example what do you want to do?

Joomla allows you to chose which fields will be rendered in various common layouts (check the changed files list in this PR). The problem is, all of the layouts using this functionality use the same view property (fields). So if you try to change fields rendered in 2 layouts used in your single view, you will provide same list to both layouts or you have to override the list before rendering next layout.

So its a broken functionality. This should use layout parameters from the start instead of the view property but would require rewriting plenty of layouts and most likely broke some third-party components in the way. That's why I just created a separate property per layout. All components I know use a fall-back list from layout itself instead of the view property. But I was creating a custom extension where I needed to change the list of fields rendered in 2 layouts used in the same view and noticed the issue.

What I provided is a temporary workaround. What have to be done in the end is rewriting those layouts and some extensions to pass this fields parameter as a layout parameter, not view property. But that has to be done in a major update. (6?)

I guess I get what you are trying to do here. I understand your problem, but making change like this will make the code which uses these shared layout broken (in case they pass the fields they want via fields property of the view)

Personal, I think re-assign fields property to the view class before rendering should not be any problem (as we do that in the core), but Yes, your propose code make it more flexible

I don't know if maintainers will accept it. But if you want to implement this kind of changes, there need to be fall back for backward compatible purpose. Something like:

$fields = $displayData->get('menu_edit_modules_fields') ?: $displayData->get('fields') ?: ['field1', 'field2'];

Then update the caller code to pass the fields to uses the right property. I'm unsure if it is worth to spend time doing that :).