[PP-1] Improve the manage form display page by untwining field widgets that belong to the main content and sidebar

We have discussed the issue at 📌 Drupal Usability Meeting 2023-08-11 RTBC . The issue will have a link to a recording of the meeting. For the record, the attendees of the meeting were @aaronmchale, @emma-horrell, @rkoller, and @worldlinemine.

The initial presentation of the issue took most of the remaining time of the meeting so that there wasn't much time left for an indepth discussion and to come up with any recommendations. There was a clear consensus that it is a valid issue. But there was doubt that the proposed resolution by adding a secondary tabbed tab would be the right choice here. The agreement was to continue the discussion about this issue in the #ux channel in the Drupal Slack for now.

Any update on this issue? we also facing same issue.e

@kmani not yet. but i have put the issue on the shortlist for one of the next ux meetings after I've stumbled across Field Layout and both plans for one to deprecate it from Core as well as moving parts of Field Layout into Core (meta: 📌 [META] Enable layout builder for form displays, and deprecate field_layout Postponed and corresponding child issues 📌 Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase Needs work and #2880746: [PP-1] Move Field Layout UI directly into Field UI → ). I haven't taken a look into Field Layout in quite a while but it turns out the capabilities it provides on Manage form display pages are directly related with the changes proposed for this issue - it suffers from the same problem being able as a user to distinguish and actually relocate any fields in the sidebar. based on the number of columns field layout is adding sections are added to the list of fields on the Manage form display page. I think the solution for the aforementioned meta issue and this issue should be coordinated and discussed since they are related. That is the reason why i've put it back onto the ux meeting shortlist.

We discussed this issue at 📌 Drupal Usability Meeting 2024-02-09 Needs work . That issue will have a link to a recording of the meeting.

For the record, the attendees at the usability meeting were @AaronMcHale, @benjifisher, @duncancm, @rkoller, @shaal, @simohell, and @worldlinemine.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

The main underlaying problem is that the theme has the final say how the fields available are used no matter if it is in Claro or Olivero (substitutional for any admin and frontend themes).

In the case of an admin theme that fact is way more problematic as illustrated in the issue summary. The consensus in the group was that it would be desirable that the experience is more clear and that administrators and site builders are more in control how forms that were set up are actually rendered.

But there was a clear consensus, with 📌 [META] Enable layout builder for form displays, and deprecate field_layout Postponed in place, it doesn't make any sense to ideate on any potential implementation details for this issue at this point. It was only noted having a layout set on a Manage form display page and having more sections than enable/disabled (by installing the field layout module) makes the problems outlined in the issue summary even worse. The agreement was to postpone this issue on the aforementioned meta issue.

And it was noted when this issue gets active again that it should be checked which theme is actually used by the user, some users are able to use the admin theme, some others are only able to use the default theme, depending on the View administration theme permission. That aspect should be minded.

The field group module → is already offering such "feature". More kind of a work around because things are not wel managed in core.

The issue ticket where that was developed: #2652642: Allow to position the group in the advanced (sidebar) column →
Hope this ads some extra info / context.

Great to see some fresh conversations are there.

Interesting! thanks a lot for bringing that fixed issue and the Field Group module in general into the discussion. I have to admit I haven't had the Field group module on my radar. I've quickly tested the Details sidebar functionality. And i agree it is sort of a workaround since it is only providing a clear context for fields dragged into that Details sidebar group, for the rest the underlaying problem still persists. On a side note it seems there is no real way to alter the relative position to the other detail elements in the advanced column. One interesting detail i've discovered within the comments, I've added #2845425: Replace hook_form_node_form_alter() implementations with configured field layouts → as an related issue since it might be relevant covering one potential implementation aspect for this issue.