Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
Problem/Motivation
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Comment | File | Size | Author |
---|---|---|---|
#36 | themes_layout_api_integration-2811179-36.patch | 11.51 KB | vacho |
| |||
#25 | 2811179-theme-25-do-not-test.patch | 7.87 KB | tim.plunkett |
#25 | 2811179-theme-25-combined-with-2860346.patch | 11.76 KB | tim.plunkett |
#23 | 2811179-theme-23.patch | 9.43 KB | tim.plunkett |
#21 | 2811179-theme-21.patch | 7.77 KB | tim.plunkett |
Comments
Comment #2
tim.plunkettBorrows code from #2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts.
Comment #3
tim.plunkettComment #5
tim.plunkettComment #7
tim.plunkettMy only worry with this issue is that right now it adds very little value.
The motivation here is to keep the block/theme system up to date with the other layout work happening in #2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts
With entity displays, there is no mechanism for layout, so adding that single feature is a big step forward.
Themes already define complex layouts, and while adding a new region is a two or three step operation, it is completely doable.
Without advanced features like variants and context, this change is almost worthless.
The question becomes, should work here continue, or should it wait until field_layout and layout_plugin go in, and work on variants and context begin?
Comment #8
tedbowMy opinion is that it adds very little value without the ability to use different layouts in different pages and under different conditions.
It seems like it would be more valuable to select which block show up under different conditions even it is uses the same layout than to be able to switch global layout but have it always apply on your site.
Most sites will probably be extending a base theme either from core or contrib. So they could easily customize the layout they want.
Comment #9
xjmSo per @tim.plunkett this is at least postponed on #2296423: Implement layout plugin type in core and maybe #2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts.
Comment #10
jibranI think we should move #7 and #8 to #1787942: Allow assigning layouts to pages for further discussion.
RE #9: #2296423: Implement layout plugin type in core is in but I don't think this issue is dependent on #2796173: Add experimental Field Layout module to allow entity view/form modes to switch between layouts.
Comment #11
jibranComment #13
tim.plunkettWe might descope this to just respecting *.layouts.yml in themes, with no UI. TBD.
Comment #15
tim.plunkettLet's actually use the layout.
Comment #17
tim.plunkettThis removes the UI and ability to switch layouts.
Comment #19
tim.plunkettDon't need that schema file anymore either.
Comment #21
tim.plunkettTrying it without the hook_install bit
Comment #23
tim.plunkettRewriting to be part of layout_discovery.
Comment #25
tim.plunkettBuilding on #2860346: Reset plugin discovery when a module/theme is installed
Comment #27
andypostwhy limit themes with one layout only?
and why that works for themes only?
config install will care about install themes last so all config that depends on layout will wait theme install.
I know that orthogonal to the issue but related to how installer will gather info from themes
Comment #28
tim.plunkettHere's the problem with this approach:
I'm not sure what to do about this without making changes to system.module...
#27, earlier patches attempted to support multiple layouts. But that would require a UI, which is a much bigger task.
Once the code supports one layout, it can be expanded quite easily.
Blocks are already hardcoding region names, this doesn't change that. See block_theme_initialize().
Comment #31
markhalliwellI'm a little confused. What is this issue attempting to solve? It looks as if this allows a theme to define its regions from a layout and then render the page via the layout template? Is that correct?
Comment #32
tim.plunkettThis was a bit of exploratory coding to see if we could replace theme regions with a layout-based approach.
Not convinced that it's worth pursuing yet.
Comment #33
markhalliwellOh, awesome! Actually, I think it is. It'd be very nice to be able to use a layout for rendering the entire page.
Especially in base themes like Bootstrap where we have to manually add classes to support the columns. It'd be way easier if we could just use one of our layouts.
Comment #36
vacho CreditAttribution: vacho at Skilld commentedVery interesting approach. I re-rolled it.
Comment #37
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation commentedComment #38
Manuel Garcia CreditAttribution: Manuel Garcia as a volunteer and at Appnovation commentedRe #32:
Curious what you mean by "yet" - what (in your opinion) needs to happen before pursuing this would be worth it?
Comment #40
jhedstromSetting to NW for the issue summary update to clarify what the approach is here.
Comment #48
tim.plunkettComment #49
Wim LeersAlmost 5 years after @jhedstrom in #40, the empty issue summary makes it difficult to understand what the intent is.
@tim.plunkett in #7 and @tedbow in #8 both indicated they see little value.
So … should we close this now? Is #1787942: Allow assigning layouts to pages perhaps the spiritual successor?