bug PR-4.4-dev Pending

User tests: Successful: Unsuccessful:

avatar artur-stepien
artur-stepien
10 Jul 2023

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:
obraz

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

avatar joomla-cms-bot joomla-cms-bot - change - 10 Jul 2023
Category Administration com_menus Layout
avatar artur-stepien artur-stepien - open - 10 Jul 2023
avatar artur-stepien artur-stepien - change - 10 Jul 2023
Status New Pending
avatar artur-stepien artur-stepien - change - 15 Jul 2023
The description was changed
avatar artur-stepien artur-stepien - edited - 15 Jul 2023
avatar artur-stepien artur-stepien - change - 15 Jul 2023
The description was changed
avatar artur-stepien artur-stepien - edited - 15 Jul 2023
avatar ceford ceford - test_item - 25 Sep 2023 - Tested successfully
avatar ceford
ceford - comment - 25 Sep 2023

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.

avatar artur-stepien
artur-stepien - comment - 25 Sep 2023

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.

avatar HLeithner
HLeithner - comment - 30 Sep 2023

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

avatar viocassel viocassel - test_item - 22 Nov 2023 - Tested successfully
avatar viocassel
viocassel - comment - 22 Nov 2023

I have tested this item ✅ successfully on 0115503


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

avatar richard67 richard67 - change - 24 Feb 2024
Labels Added: bug PR-4.4-dev
avatar richard67 richard67 - alter_testresult - 24 Feb 2024 - viocassel: Tested successfully
avatar HLeithner HLeithner - change - 24 Apr 2024
Title
Edit layouts fields fix
[4.4] Edit layouts fields fix
avatar HLeithner HLeithner - edited - 24 Apr 2024

Add a Comment

Login with GitHub to post a comment