Inform users that Field Layout is deprecated

PLease keep it until Layoutbuilder supports form modes:
LB still doesn't support form modes, so the way remains https://www.drupal.org/project/drupal/issues/2844302 📌 Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase Needs work

I agree it should definitely not be removed, until everything is ready.

I only suggest to update the description, so that users don't needlessly spend time consider using the module in new projects, only to find out that it might at some point be removed.

Well, for now as far as I know it is the only option...

Sadly the module is only working solution to allow configure form modes

@maxilein: Sorry, I haven't been thorough enough in the Issue Summary, and an important part of the background is missing.

The reason I spent some thing investigating the Field Layout Drupal core module in the first place was because I wanted to use the Field Group → module for grouping and ordering fields in the form display, since that is what the description says it enables:

Allows users to configure the display and form display by arranging fields in several columns.

That sounded interesting, and I considered using Field Layout, and not Field Group. But when I realized that Field Layout may get removed, I decided to not use it, and created this issue.

@andypost: Interesting, the removal may happen a long time into the future, or maybe never?

@ressa Thank you for sharing your case! It's very representative!

IIRC effort was
- to incorporate the module into core 📌 Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase Needs work
- postpone field group issue ✨ Add field grouping to core Needs work as both are covered by LB
- minimize API surface maintenance - all outreach went toward LayoutBuilder

You're welcome @andypost! And thanks by the way for your great efforts working on Drupal core, I really appreciate it.

Thanks for the links. I left a comment, and added a reference to the other issue in ✨ Add field grouping to core Needs work to connect them. I hope that either Field Group or Layout Builder gets added to core.

What do you think about my idea of updating LB the description, until a decision is made? With the new information from you, is this worth considering?

-description: 'Allows users to configure the display and form display by arranging fields in several columns.'
+description: 'Allows users to configure the display and form display. Note: Might get deprecated, see #3007167.'

I don;t think it good idea to update title, all approaches are applicable for own cases and core should not limit

The module already marked as experimental so users should understand risks lifecycle: experimental

All right, thanks for sharing your opinion.

I would like to point out that it would greatly improve usability, if Display and Form would be (automatically) in sync.

I could even image an option, where creating a layout for a display -> automatically creates the same layout for the form.

It would be much easier to work with nodes, when the field I see at (e.g.) the top right of the third column on Display also can be edited at that approximate position.
The more fields a node has the more important this gets.
If you have e.g. 3 columns with 25 fields spread allover, and on the form edit they are all a list and you have to search for them each time ... is just not very productive nowadays.

users should understand risks lifecycle: experimental

Sadly some folks, myself included, might think that if a module made it into Drupal core and was listed as experimental, it's because it was considered to be a solid idea with momentum and that eventually it would become stable; not really considering that it would languish by the wayside because the winds shift and alternative solutions architectures gain favor. At this point, the Field Layout module is not really experimental in a real sense, because the module has been working and functionally stable in core for years; it was just never officially blessed as "the way".

Maybe this is an argument for considering another lifecycle state somewhere in between "experimental" and "deprecated", that more fully presents this risk of something on track to be soon deprecated in future versions. Maybe "slated for removal" or similar.

Sorry, I am a bit confused here.

I have can see the following interpretations of what the future would look like:

1. Everything will be done with layout builder. Not only field_layout will be removed eventually, but all of the tabledrag view mode config. Also field_group module will disappear.
2. Both layout builder and the classical tabledrag view mode configuration will remain. Only the field_layout module will be removed, because we don't like it somehow, or because we are undecided between layout builder and field_ui, and until then we are paralyzed.
3. Both layout builder and the classical tabledrag view mode configuration will remain. The field_layout will be merged up, so that we get this functionality out of the box. 📌 Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase Needs work , 📌 Make regions and fields pluggable or alterable in EntityDisplayFormBase Active Also field_group will move into core ✨ Add field grouping to core Needs work .

It seems that (3) is the direction we are going. And I support it!

To (1), I would absolutely hate to see us drop the tabledrag-style view mode and form mode configuration. To me, layout builder is a dead end. This is not about "can be improved", but about the basic ideas it is based on. And I think it is ok in a project like Drupal to maintain two ways to do things, as long as each can do something the other can't.

To (2), I think we need to avoid slowing down on one direction, if there is the idea that we might at some point do something else instead.
We had the same kind of stalemate with hooks vs events. We still have hooks, but we missed the opportunities to improve that system.

The remaining problem now is that site builders don't really know if it is responsible to use field_layout in a project, or if they need to wait for something. At the same time, core contributors don't know if they should put effort into improving it, or what exactly is missing for it to be considered mature. So again, another type of stalemate.
It seems this is not a technical problem but a communication or perception problem.

----------

Btw, personally I would like to see "nested" layouts, that is, layout within a layout.
We already used this approach in a project, implemented as field group formatters (not using field_group_layout but something custom: we automatically put one field per region, and then the rest of the fields in the default region). This brought us great flexibility, but our custom solution is definitely not ready for contrib or core.
The benefit of nested layouts is that the individual layout can be very simple, and you can compose many differnet types of "cards" (I think designers like this term).

---------

I think a good step to move forward would be to make the base classes EntityDisplayBase and EntityDisplayFormBase more flexible, so that field_layout does not need to rely on inheritance anymore. See 📌 Make regions and fields pluggable or alterable in EntityDisplayFormBase Active .

Then contrib can make its own attempts at field layout solutions.

This should also attempt to make field_group easier. Currently field_group contrib module needs ugly workarounds to achieve what it does.