Agenda:

  1. #2924058: Discuss using Layout Builder to control full site layout and replace Block UI
  2. 2 new modules for translations

Previous agenda: #3051782: [Layout Initiative meeting] 2019/5/14

0ļøāƒ£ Please introduce yourself if you are attending

timplunkett (he/him) Hi, Tim from Philadelphia
dyannenova Hi, Iā€™m Emilie in Portland, OR
shaal Hi, Ofer Shaal, Florida
tedbow Hello, Ted form Ithaca, NY
Alona Oneill Hello. Iā€™m Alona from San Francisco, CA
joshuabud I'm Joshua in Spartanburg, SC
digantdj Hi, I'm Digant from San Diego, CA
philalonso Iā€™m Phil in Phoenix, AZ
thalles I'm Thalles in Belo Horizonte-MG, BR
johnwebdev John from Sweden
mark_fullmer (he/him) Mark from Tucson, Arizona
webchick Angie from Vancouver, BC
damienmckenna Damien from Bangor, ME, USA.

1ļøāƒ£ Let's discuss possibly replacing the Block UI with Layout Builder

timplunkett (he/him) #2924058: Discuss using Layout Builder to control full site layout and replace Block UI
timplunkett (he/him) Doing this in core could be very tricky, because we'd need to land it with a migration path from Block UI
timplunkett (he/him) It might be a lot more straightforward to do it from contrib, and indicate that you'd need to start from scratch with it (as part of an MVP)
tedbow would have to do migration or could this something new sites could have and/or site opt into?
tedbow Not that I donā€™t think contrib is not a good place to do it
timplunkett (he/him) If it were in core, it'd be easy to switch Umami to it. I'm just worried about existing sites
tedbow yep. but possilbly could opt in like LB does now(though this would be for whole site)
timplunkett (he/him) right now we can cleanly copy over their Manage Display config to LB, because it's all one column
tedbow sorry to side track. can be determined later. probably better to start in contrib anyways. just thinking of eventual core inclusion which we donā€™t need to worry about now
mark_fullmer (he/him) Just to consider options, would ā€œjustā€ doing a UI makeover of the Block UI that is Layout Builder-esque, be an option, without providing a unified API?
mikelutz (he/him) The actual migration is probably doable, but I worry more about sites that donā€™t currently use LB being forced to. Ā I know currently my custom themes donā€™t play well with LB (Iā€™m working on them), and I donā€™t want to be forced into LB before Iā€™m ready.
timplunkett (he/him) afaik we'd probably need a completely separate page.twig.html anyway, so yeah it'd be a big switch
timplunkett (he/him) similar to how Panels Everywhere needed its own stuff at the theme layer
thalles And a submodule of LB?
timplunkett (he/him) haven't thought that far out @thalles, but probably. though core doesn't do submodules, it'd be alongside it in the /core/modules dir
timplunkett (he/him) So far this has been a good meta/strategic discussion. I'm going to start another thread (3ļøāƒ£) to discuss how we'd expect it to work from the editors perspective
thalles I think this would be a middle ground
damienmckenna There's also the question of how it would be handled - would LB_Anywhere just use the content section or would it take over the block region rendering?
tedbow I think the idea is you wonā€™t have theme regions.
tedbow but maybe the theme could provide default sections?
tedbow to use in the layout everywhere?
kevincrafts If a theme is already providing regions, I would just like to use layout builder within those regions
kevincrafts as those regions should contain sections
damienmckenna And that's why I asked the question - there's a difference of opinion between how different people view this, and I think the back-end developers should defer to the front-end developers in this regards.

2ļøāƒ£ There's a pair of new contrib modules aimed at supporting translations for LB

timplunkett (he/him) https://www.drupal.org/project/layout_builder_st https://www.drupal.org/project/layout_builder_at
tedbow layout_builder_st is a port of #2946333: Allow synced Layout override Translations: translating labels and inline blocks which hopefully will be in core 8.8.0
tedbow Right now I donā€™t think you can have both enabled. or at least they wonā€™t work

3ļøāƒ£ Continuing from the first thread, let's talk about how a LB-based Block UI would function from the editors perspective

timplunkett (he/him) What expectations do people have for this?
dyannenova Iā€™ve been leaning towards an interface where a site editor can edit the global layout content from the same interface as the content layout, instead of a separate page.
dyannenova Is that something that sounds useful? It gives the editor a more intuitive way to edit the site layout everywhere, but means we would need a way to illustrate which regions are global vs which are content.
tedbow so then there would always be 1-to-1 relationship with lb content to lb fullsite?
tedbow I guess the question is is there only 1 full-site setting like block UI or variations like Page Manager?
dyannenova Variations would be interesting, I havenā€™t heard anyone ask for that as an mvp, but it could be a really useful feature further on
tedbow ok give there is only for at first. editing in the same UI sounds great. buy also maybe where you could edit with a content setting. Ā For instance it would be in effect for Views pages also
tedbow So even if ā€œinterface where a site editor can edit the global layout content from the same interface as the content layout, instead of a separate page.ā€ would there also be separate page for instance if you havenā€™t enabled layout builder for a content type but still want to use it for the site-chrome?
damienmckenna @dyannenova: is the intention that LB_Anywhere :wink: would control what goes in the theme's regions, or would it introduce another layer on top of that with its own layouts that ultimately go into the page's content area (ala panels_anywhere)? Or is this question redundant/outdated in D8?
dyannenova @tedbow Thatā€™s a good point. It would be useful for sites that arenā€™t using LB for content too.
dyannenova @damienmckenna the idea so far is that it would replace theme regions with a layout builder-esque interface that builds the site layout with sections.
damienmckenna @dyannenova: I would suggest discussing this with some additional theme maintainers to see how best to bridge the gap and ensure that existing functionality wouldn't get lost along the way.
kevincrafts I would certainly need rule type variations, or if possible a cascading set of chrome layouts that could be applied to a particular node. For instance, adding in a list of articles in the sidebar of the page of all article nodes, and adding additional content in the sidebar for articles tagged with a particular term.
damienmckenna At the very least there would need to be visibility rules to control it, or allow a way for something akin to Block Visibility Groups.
damienmckenna And would lb_everywhere configurations be tied to a theme, so if you used a system to swap themes e.g according to different path, would the layout persist across the different themes, or would you need a different layout per theme?
damienmckenna (for the last question, it seems like it would be tied per theme based upon comments above)Ā (edited)
timplunkett (he/him) Right now the page.html.twig is primarily concerned with printing out the theme regions
timplunkett (he/him) which is why placed blocks are tied to a theme, because of the regions
timplunkett (he/him) in theory, if we do it right there's no need to tie this to themes

4ļøāƒ£ Open floor! Feel free to bring up any topic either in this thread or a newly numbered thread

mark_fullmer (he/him) Is there an existing issue that would be appropriate for making suggestions to the Layout Builder drag-and-drop UX? Our team was identifying some research-based best practices for a drag-and-drop interface, including a drop shadow on the moving object, a grab/grabbing cursor, and outlined blocks even when not in motion.
timplunkett (he/him) I don't think there's an issue for that, unless @dyannenova knows of one off-hand
dyannenova There isnā€™t an issue open for that right now. It would be great to have one.

:five: Following up on the screenreader walkthrough two weeks ago, Berkeleyā€™s WebAccess team will be doing a similar walkthrough with speech control next week at 10 am Pacific time. Iā€™ll post a link to the remote meeting just before it starts.

Participants:

timplunkett (he/him), dyannenova, shaal, tedbow, Alona Oneill, joshuabud, digantdj, philalonso, thalles, johnwebdev, mark_fullmer (he/him), webchick, damienmckenna, mikelutz (he/him), kevincrafts

Comments

tim.plunkett created an issue. See original summary.

tim.plunkettā€™s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Title: [Layout Initiative meeting] 2019/5/21 Ā» [Layout Initiative meeting] 2019/5/28
tim.plunkettā€™s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Issue summary: View changes
tim.plunkettā€™s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented
Title: [Layout Initiative meeting] 2019/5/28 Ā» [Layout Initiative meeting] 2019/6/11
tedbowā€™s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue summary: View changes
alonaoneillā€™s picture

alonaoneill commented

Version: 8.8.x-dev Ā» 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9ā€™s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev Ā» 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev Ā» 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

quietone credited johnwebdev.

quietone credited philalonso.

quietone credited shaal.

quietone credited thalles.

quietoneā€™s picture

quietone commented
Issue summary: View changes

quietone credited DigantDj.

quietone credited JoshuaBud.

quietone credited mark_fullmer.

quietoneā€™s picture

quietone commented

Version: 9.2.x-dev Ā» 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev Ā» 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev Ā» 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev Ā» 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev Ā» 11.x-dev

Drupal core is moving towards using a ā€œmainā€ branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgraveā€™s picture

smustgrave commented
Status: Active Ā» Fixed

Status: Fixed Ā» Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.