- πΊπΈUnited States mradcliffe USA
I started looking into this and I quickly found that without defining a field_ui_base_route, which automatically pulls in manage fields and manage form display, layout builder quickly throws exceptions instead of handling errors. Additionally, layout builder will continue to throw exceptions if the form display routes are removed.
So in the end as I was playing around with this, I needed to also alter local tasks to hide the manage form display and manage fields, as well as adding a dummy route that redirects to manage display when field_ui is enabled.
It's kind of a hack and pretty much all due to Layout Builder.
I'll create a work-in-progress issue fork and branch shortly.
I also found that the display options configured in Item need work. If a field display options are defined, then warnings will be thrown because of type and label keys.
- Merge request !22Issue #3090366: Adds manage display and default view display β (Open) created by mradcliffe
- πΊπΈUnited States mradcliffe USA
I'm going to guess this should have tests for when field_ui and layout_builder are enabled respectively.
- πΊπΈUnited States mradcliffe USA
I was thinking this over, and I thought "why fight it?" Maybe aggregator items should provide a Manage Fields and Manage Form Display route even if they are not used by default. It might make it easier to extend aggregator functionality dealing with description property in case someone wanted to store other metadata from a feed.
Adding a warning message to Manage Fields and Manage Form Display to indicate advanced / non-default usage would be important to not confuse default users.
Optionally, an additional setting could be added to show/hide the pages would help. Since altering the routes would still be fighting Layout Builder, maybe just hide the local tasks.