Agenda:

  1. #3054663: Allow fields on a layout builder enabled content type to be locked and rendered elsewhere in twig template
  2. 2 new modules for translations

Previous agenda: #3050243: [Layout Initiative meeting] 2019/4/30

0ïžâƒŁ If you are attending, please introduce yourself!

timplunkett (he/him) Hi, Tim, from Philadelphia!
Jeff Hello, Jeff in Knoxville
tedbow Ted from New York, not that New York
kevincrafts Hello I'm Kevin from Colorado
ashrafabed Hey, Ashraf from Virginia
Mihaela (portulaca/prkos) Hi all! Mihaela from Croatia
nord102 (he/him) Hey, Jordan from Canada :wave:
thalles Thalles, Belo Horizonte From Brasil
randyv Hello, Randy from Everett Washington
shaal Ofer, Florida
mikelutz (he/him) Howdy!
bkosborne Brian, from NJ, USA

1ïžâƒŁ First up, @kevincrafts wanted to discuss #3054663: Allow fields on a layout builder enabled content type to be locked and rendered elsewhere in twig template

timplunkett (he/him) .
kevincrafts Does my description/issue make sense?
tedbow Couldn’t some of this be done by https://www.drupal.org/project/layout_builder_restrictions ? or does layout builder not user hte node template at all?
timplunkett (he/him) @tedbow first problem is that we unset all the other fields anyway
timplunkett (he/him) so they're not available at the twig level
nord102 (he/him) I think what this is referring to is making say the template blocks stay where they were placed without allowing for site editors to remove or move them
nord102 (he/him) Almost like forcing the template and allow for additions only
nord102 (he/him) right?
kevincrafts yep
nord102 (he/him) I can definitely see a use case for this, when you don’t want a site editor completely overhauling a layout.. which could be handled via training, but I think it might be useful to have as functionality
Mihaela (portulaca/prkos) LBR seems to apply globally on entities, while you want more fine-grained control WRT user permissions
tedbow I see how this could be useful but it seems like an edge that could be handled by contrib. In contrib you could look certain sections that have the fields you don’t want users to edit
Mihaela (portulaca/prkos) so you wish LBR to include user permissions on top of the existing features?
timplunkett (he/him) this issue is not the same but slightly similar: #3010975: Devise a locking/inheritance mechanism for overrides to mitigate when they become out of sync with the default layout
kevincrafts for our case - we run Drupal as a service for our sites - our editors are pretty un-technical but they still need to do some simple layout of content, but we would like to template a lot of it - makes it much easier support wise for the 1200 sites we run
nord102 (he/him) Yeah, I agree, this might be better suited as a contrib module as opposed to core Layout
kevincrafts as someone just recently looking at this - where would be the best way to insert this from the contrib side?
kevinquillen ^
timplunkett (he/him) even if it's going to be done in contrib there will likely need to be some core patches to get it working
tedbow I simple-ish way would be remove the contextual links for the sections/blocks you don’t want to be altered.  this won’t use  the template but it would allow certain sections to be locked which seems like the use case
timplunkett (he/him) also gotta think about drag-n-drop
bkosborne We also run Drupal as a service and use layout builder. We get around this problem in a sort of interesting way
kevinquillen that wouldnt prevent, say, "Configure Section" > Remove
tedbow if you remove configure section link also it would
timplunkett (he/him) and also, wrt to fields being available in templates, this would be necessary https://gist.github.com/timplunkett/7fd67d16f1edb4957fafb01c284fb3dd
tedbow that seems like a decent idea
bkosborne We create another view mode called "Full page w/o layout builder". That view mode does not have LB enabled, just normal field UI. This is where the admins of the platform (me) configure the fields that we want "locked down". Then, in the actual layout builder for the full page display, we have a special block in there that renders the node using this special view mode.
kevincrafts @tedbow but what you're suggesting is just hiding the links - the fields are still managed by LB right?

2ïžâƒŁ That's it for the official agenda. Please reply to this thread or start a new numbered thread if you have other topics to discuss!

Participants:

timplunkett (he/him), Jeff, tedbow, kevincrafts, ashrafabed, Mihaela (portulaca/prkos), nord102 (he/him), thalles, randyv, shaal, mikelutz (he/him), bkosborne, kevinquillen

tedbow New project https://www.drupal.org/project/layout_builder_at
Mihaela (portulaca/prkos) Does asymmetric mean that you can translate the overrides separately from the global entity layout translation, so translations differ?
tedbow It means you can have different layouts per language for overrides
Mihaela (portulaca/prkos) Or it's more about first-second/left-right depending on LTR or RTL languages?
Mihaela (portulaca/prkos) the latter then, makes sense
tedbow no that is arleady handled by core
timplunkett (he/him) common example is a newspaper. you might want completely different layouts (and content) for a different language
Mihaela (portulaca/prkos) so what exactly is a "section translation"? Just a different layout applied for each language?
tedbow not sure where you are getting “section translation” from
Mihaela (portulaca/prkos) the project page
Mihaela (portulaca/prkos) I think the description could be improved, with a screenshot maybe, it would be less confusing about what it actually does
tedbow I don’t see that phrase on the project page.yeah I didn’t make the project. (edited)
tedbow but yes the description needs to be updated. they just created it today
Mihaela (portulaca/prkos) It makes the layout section field translatable
Mihaela (portulaca/prkos) it is correct to call the Section a field?
tedbow yep sorry i was looking for “section translation”. a bit different but gets into the details.sections are stored in multivalue field for overrides
Mihaela (portulaca/prkos) the second part of the problem is that "translatable" is too vague because we usually imagine translations as text
Mihaela (portulaca/prkos) ty, gotta love all the fieldability around us :slightly_smiling_face:
Mihaela (portulaca/prkos) Is this a good description for this module, in general, and grammar check:
Mihaela (portulaca/prkos) description: 'Apply different layouts to Sections for different languages.'
tedbow no its more like: “Allow each translation to have a completely different layout override.”
Mihaela (portulaca/prkos) so overrides only? pitty
tedbow for now. though it could be supported at the default level. Not sure if they are planning to implement that
tedbow it would be more difficult but probably possible
Mihaela (portulaca/prkos) why more difficult?
Mihaela (portulaca/prkos) I expect most sites would want to apply the layout globally per language, not having to override each translated node just to shift layout
timplunkett (he/him) That's certainly a valid usecase, but not nearly as often requested
Mihaela (portulaca/prkos) I don't think D8 has enough spread yet for multilinguals to come out with demands :slightly_smiling_face:

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/7 » [Layout Initiative meeting] 2019/5/14

Pushing back due to an empty agenda.

kevincrafts’s picture

kevincrafts commented

https://www.drupal.org/project/drupal/issues/3054663

tedbow’s picture

tedbow
he/him
Primary language English
Location Ithaca, NY, USA
commented
Issue summary: View changes

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.

Anonymous’s picture

Anonymous (not verified) commented

quietone credited Jeff.

quietone credited Mihaela.

quietone credited ashrafabed.

quietone credited nord102.

quietone credited shaa.

quietone credited thalles.

quietone’s picture

quietone commented
Issue summary: View changes

quietone credited bkosborne.

quietone credited kevinquillen.

quietone credited mikelutz.

quietone credited shaal.

quietone’s picture

quietone commented
quietone’s picture

quietone commented

Need to add credit for randyv. What is the d.o username for randyv?

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.

larowlan’s picture

larowlan
Location 🇩đŸ‡ș🏝.au GMT+10
commented
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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