[META] Gradual changes to Field UI

Created on 2 September 2012, over 12 years ago

Updated 22 July 2023, over 1 year ago

Meta issue to list small, subtle changes we want to do on Field UI for Drupal 8. The pie in the sky - I know a lot of people really really want the form builder approach - see 🌱 Redesign the Field UI Active and ✨ Fields UI improvements using form builder pattern Closed: duplicate - is not our goal here. Not all ideas have issue created yet, but will be as soon as possible.

📌 Use dialog api for formatter settings Needs work : Use modal for formatter settings
#1786198: Make consistent regions in code for fields UI overview screens → : Add region concept to field ui.
Use temp store - over at #1642062: Add TempStore for persistent, limited-term storage of non-cache data → - so we can kill 📌 Add a "changes not applied until saved" warning when changing widget/formatter settings Fixed

Committed to 8.x

I (swentel) started on that FB approach and I still have the code. However, I 100% completely support making changes on the current Field UI as getting my form builder approach ready before 1 dec is just impossible. Once we hit feature freeze, we simply need to take this up as a big community task in contrib and make sure we can hit it for D9 - although even at this point I'm still not convinced that I could live with that approach on entity level, both for forms and display.

Original summary

As maintainer of field_group and co-maintainer of display suite, I know very hard stuff needs to be done when you want to change the field UI. Lots of form altering needs to be done and worse, lots of duplicate code and behavior.
All of this is just a proposition.

What can we do

Make the row handles generic and/or more extendible
Change the behavior for the field instance and display settings to a popup/modal/overlay
Add a system to nest fields in 'groups' which field_group can implement
Create a region system by default in field_ui. This will make it possible for Display Suite to pick in rather than override almost everything. By default the hidden section would be a UI-region and the visible should start as the visible or "content" region (by convention or not)
Make an early start for a UI switch to DS layouts. This will very much need a separate issue if we try it.
Take an attempt to try rendering the row in ajax and not the form?

I would like to check in a new branch what can be done and like to do a suggestion. Question: What is the branch I should branch from to start this intent?

Any recommendations and thoughts would be very helpful.

📌 Task

Status

Closed: duplicate

Version

9.5

Component

Field UI →

Last updated 18 minutes ago