[policy] Deprecate field_layout module and move it to contrib

The manage form display part should be stabilised and moved into Field UI.

This needs an issue.

Retitling to what I understand this issue to be, but please correct me if I'm wrong.

Added the other child issue #2880746: [PP-1] Move Field Layout UI directly into Field UI
Both child issues need to be updated to clarify that they are only about the form portion, not the display.

I have slight reservations about removing the Manage Display Field Layout customisations, Layout Builder seems a little over the top for just customising the Layout of fields in the display if that's all you need.

Say if someone has been using Field Layout to customise the Form Display, but then when they go to customise the View Display they can't unless they enable a separate module which has a drastically different workflow, when currently they can use the same module to customise both the Form and View Display. I can't see the logic in forcing that on people, and I can definitely envision the endless amount of feature request issues that this change will generate.

In that case, I'd just as soon remove the entire module and put it in contrib.

I think parity between Manage Display and Manage Form Display is a worthwhile consideration. Out of curiosity, why not...

1. Move existing Field Layout capabilities to Field UI, for both displays and form displays.
2. Eventually, make Layout Builder also work for customizing form displays too.
3. And maybe even further down the road, make Layout Builder capable of outputting reusable layout plugins (that are not bound to specific entity types/bundles), where LB "sections" could be given region names, that Field UI could then use in #1 above.

There may well be good reasons to not do any of the above, but just curious what they are.

+1 for moving existing Field Layout capabilities for both displays and form displays to Field UI.

Edit: That is, if any Field Layout capabilities are moved to Field UI.

+1 to comment #8

I think that Field Layout and Layout Builder are not exclusive, rather they are complementary, because in entities the view modes represent how I want the entity to look, and when I think of that entity as a whole page it makes sense to be able to use Layout Builder to arrange the elements, but there are other view modes in which I want to present the entity as if it were a design component (thinking of components such as Bootstrap), for example I might want to present an entity as a card, and have a card view mode to present that entity as a card (in terms of Bootstrap) and I don't want to manipulate the layout in that scenario, I just want to arrange the fields in the corresponding regions as Field Layout allows.

This is useful because later I can make use of that presentation (that card view mode), as a component (block) that I can position on some page with Layout Builder. And in both Panels IPE and Layout Builder it is possible in the case of blocks to select the view mode, so it is very useful to have view modes that represent design components, the point is that without Field Layout there is no way that a site builder can assign a design component to a specific view mode, and requires you to create a template for that view mode.

Adding related issue.

@roberto_araya you might want to check that issue out! :)

Also want to check in to +1 the idea of moving field layout capabilities to Field UI. I also see Layout Builder and Field Layout as complimentary. Field Layout being more efficient for managing the layout of individual (or perhaps smaller scale) components and Layout Builder being the ideal place to manage the layout of multiple components together in larger regions or for the entire main content area of a view mode.

#11
Except they currently work on the same exact level, and could never be used on the same entity display alongside each other.

I started back working on #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase for those interested.

@tim.plunkett Different UIs would be used for different entity displays. So a non-visual one could be used e.g. for a paragraph type display, and a visual one for a node display.

Personally I'd just love to have some alternative non-visual layout UI in core, could be the alternative accessible Layout Builder UI too.

+1 to move parts to field UI module and data model suitable for FL & LB to entity display (which is overriden by LB to add sections)

Also it may stand as solution to long lasting #1875974: Abstract 'component type' specific code out of EntityDisplay

I just want to ask/clarify that because this is tagged Drupal 9, does this mean we have a good reasonable amount of time before we need to start thinking about refactoring existing sites that leverage Field Layout, do we gain anything by prioritizing this refactoring earlier than D9?

For context, I have 16 content types and 2 ECK entity types, and 3 to 4 Group module types that will need to be refactored (meaning touching all the twig templates with references to things like {{ content._field_layout.content.field_myfield }}. This is a significant overhaul.

I'm not sure what the D9 tag implies, but this issue is filed against 8.7.x

I have to ask though, what's the point of using Field Layout if you are also overriding the templates and hardcoding content._field_layout?
That _ prefix on field_layout is explicitly there to indicate that it is an internal structure that shouldn't be manipulated from the outside.
There is NO backwards-compatibility promised on that key.

what's the point of using Field Layout if you are also overriding the templates and hardcoding content._field_layout?

Couple reasons

* To be able to group fields into certain regions and theme their wrapper divs in one single template. The theme allows two kinds of regions and fields in the layouts: edge-to-edge and constrained. Typically Paragraphs fields would be put into the edge-to-edge region, and other fields are placed above or below. The only way to theme this is to reach in and render content._field_layout.regionname

* Sometimes fields in one of these regions need additional theming rather than just throwing them inside the template stacked, thus when you have a site that starts out using a basic field layout, and need to override the display on one field, you have to further reach into content._field_layout.regionname.field_fieldname .

At the time the site was architected, Field Layout was the go-to tool for creating page layouts in core, in a way that was very similar to how CTools Layout templates worked in Drupal 7. It was much less cumbersome to use pre-defined layouts with preconfigured region names, rather than clicking through the UI using Field Group on each entity to build out groupings of fields. I'm totally open to suggestions on other ways that this should have been architected.

Screenshots depicting what I'm talking about:

Can we please make some decisions about this topic? I would say we move it soon as possible to core #2844302 :)

There is really no clarification as to what features are "essential features" to move and which ones are non-essential.

To be able to have multiple view (fields) displays for different components (for blocks and views) is needed.
To have the ability for different forms (form modes) of the same type/bundle to render is needed.

Would these be part of the essentials?

If we want to move functionality into core, that should be a new experimental module or core patch. If we want to remove field_layout because it's never going to leave the experimental state, then I think we should do that. I don't think the two are linked necessarily.

Tagging for review.

Cross-linking #3099427: [random test failure] FieldLayoutTest::testEntityView().

Bumping to critical since this blocks #3013276: [META] Remove deprecated modules on the Drupal 9 branch and we need to make a firm decision and implement it before beta, whatever that decision is.

Should a patch be uploaded here, given it's a meta issue, or should a sub issue be added for the code changes?

If we decide on a straight removal I think it's fine to just have a patch here (also fine for there to be a patch to review while the decision is made). Apart from keeping the module in Drupal 9 as experimental I don't really think there's another option at this point.

Ok then. This removes the module, removes it from core/composer.json, removes layout_builder_install() as it was focused on migrating displays from Field Layout to Layout Builder, and removes Drupal\Tests\layout_builder\Kernel\LayoutBuilderFieldLayoutCompatibilityTest as it just dealt with compatibility between the two.

Should we specifically create a contrib module for Field Layout to let folks continue it, or leave it up to anyone who wants to take on this responsibility to do the work? I'm inclined to do the latter.

Queued #28 to run on 9.0.x core, hope that helps. ;)

Cheers,
-Derek

Created a contrib for field layout https://www.drupal.org/project/field_layout
The field_layout path was available, but not the name "Field Layout" so the current name is "Field Layout (core)". This contrib should make it easier for D8 sites to update to D9.

I think layout_builder_install() should be brought back as it could be useful to sites updating from 8 to 9 that want to convert Field Layout data to Layout Builder.

The drupal/field_layout requirement should also be removed from composer.lock

Oh, good catch, I never noticed that file listed all the modules too.

Whoops, I was in the wrong terminal window when I generated those patches.

This should work.

I think layout_builder_install() should be brought back as it could be useful to sites updating from 8 to 9 that want to convert Field Layout data to Layout Builder.

Makes sense to me.

As a Drupal 8 user who is using Layout Builder, Field UI, and Field Layout I have some question related to the removal of the Field Layout.

What was ultimately decided? Is the plan still to remove the Field Layout and migrate all of the functionality to Field UI?

And does that mean if I am using Field Layout when I upgrade my site to Drupal 9 (I assume that is when Field Layout will be removed completely) that my site will still work the same way it does now?

Or is there going to be some migration plan for devs using Field Layout?

@rfletcher73 the mitigation for removing it from core would be the contrib module: https://www.drupal.org/project/field_layout

We haven't yet confirmed whether we're going to remove it in 9.x or 10.x yet though.

If #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase happened it would probably end up as a stub module rather than being removed as such, but not clear what the status of that issue is.

@catch - thank you for your quick reply.

Drupal 10. :)

We'll deprecate it in Drupal 9 once the useful bits are copied into core and the module becomes just a wrapper.

I think this is postponed on #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase then.

While there is no explicit plan yet, I think this is a more accurate issue title for what we'd like to happen.

LB still doesn't support form modes, so the way remains #2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase

Should we warn users that the module should probably not be used? I have created #3370887: Inform users that Field Layout is deprecated.

In today's Usability Meeting #3418992: Drupal Usability Meeting 2024-02-09 we've discussed #3344498: Improve the manage form display page by untwining field widgets that belong to the main content and sidebar outlining an underlaying problem which is relevant for this issue as well as for the Field Layout contrib module. The issue illustrates that things are already problematic without Field Layout being installed and you only have an enabled and disabled section on the Manage form display page. But with Field Layout set to for example a two column layout the problem gets worse. We've agreed on postponing #3344498: Improve the manage form display page by untwining field widgets that belong to the main content and sidebar on this issue and bring it on everyone's radar.

In an effort to get this moving I am setting the status to active. There is discussion here on a) moving it to contrib and b) to copy all the useful bits to core. The latter being in #8 and the child issue. The latest comment supports "If we want a "clean solution" we can deprecate and move it out to contrib like other core modules."

I would prefer the clean solution which is to deprecate and move to contrib and in Slack catch said the same. Shall we pursue that?

#2844302: Move Field Layout data model and API directly into \Drupal\Core\Entity\EntityDisplayBase is a complete re-implementation of what field_layout tried to do, so I don't think we are really gaining anything by keeping it in core until that's done - the only reason to do so would be to provide an 'upgrade path' for sites using the experimental module, but we don't even know if that will be the case. So I think it's clearer if we move the module to contrib, on the basis some sites might be using it and we don't want to them to be left in a complete dead-end. It's been several years since field_layout was abandoned and keeping it in core isn't helping us replace it.

Removing the 'needs release manager review' tag too given +1s from both me and @quietone.

Adding "Add Field Layout to Deprecated and obsolete extensions" under Remaining tasks.

Perhaps add it now, and state that it "will be removed in a future version"?

OK. product and release managers agree to remove Field Layout from core.

That will be done in #3517712: [meta] Tasks to deprecate the Field Layout module

In the ~5 years that have passed since I first created the Field Layout contrib version, I have less overall bandwidth to be an adequate maintainer, so I'm happy to add some additional ones.

What is the recommended alternative to this module?

There's no alternative yet, so I'm willing to maintain it in contrib

thank you.

catch asked in committer slack if there was anything else to do here. That caused us, include @Gábor Hojtsy, to take a second look here. And there is nothing more to do. There is clear agreement on deprecating field_layout.

Thanks everyone for resolving this.

The work to implement this starts in #3517712: [meta] Tasks to deprecate the Field Layout module.

Changing to latest version when this was closed.