[Weekly Meeting] 2018/05/15 [#2972783]

Next week's agenda: #2973103: [Weekly Meeting] 2018/05/22

Moderated By: timplunkett

Hello! Welcome to our weekly Layout Initiative meeting.

This meeting:
➤ happens right here every Tuesday, 1pm ET / 10am PT / 17:00 UTC
➤ is chat only (no audio or video)
➤ happens in threads so keep an eye on those notifications
➤ there are 5 minutes between topics, sometimes more, for people who are multitasking to follow along.
➤ the agenda is public and anyone can add to it: `https://www.drupal.org/project/layout_initiative/issues/2972783`

Please leave a comment on today's agenda issue to receive credit for attendance

1️⃣ Introduce yourself if you are attending this meeting!

tedbow	Hi ya from the Finger Lakes, USA
timplunkett	Tim Plunkett, from Philadelphia
madsciencepro	Tony Wilson, North Carolina
dyannenova	Emilie Nouveau, currently in Charlotte, NC
phenaproxima	Hi, everybody. Adam H., in Boston.
johndevman	Hi. John S, from Sweden
ACFind	I’m Alexis Findiesen from Washington, DC
balsama	o/ Adam B, also in Boston
samuel.mortenson	:wave: Sam from Portland, Oregon, USA
timplunkett	Thanks for attending! Be sure to comment on https://www.drupal.org/project/layout_initiative/issues/2972783
johndevman	@timplunkett updating IS, enough? :slightly_smiling_face:
timplunkett	Yes!

2️⃣ Update on Lightning Layout sprint

timplunkett	Acquia hosted a sprint on Layouts two weeks ago
timplunkett	The focus was around replacing Panelizer with Layout Builder for the Lightning distribution
phenaproxima	There is a Google Doc summarizing the outcomes: https://docs.google.com/document/d/1IX-yGjHBHmwa-ZXgOe-V90HYWiyzI7T5soGE...
balsama	High-level user stories that Lightning is trying to accomplish with Layout Builder: https://gist.github.com/balsama/f2f39d9d191be09544e7acfe1854c859
balsama	Big gaps between what we can do with Panelizer/Panels and Layout Builder right now: * Add content through the UI * Define multiple layouts for a bundle that an editor can choose from * Static contexts

3️⃣ Quick review/discussion of https://www.drupal.org/node/2941806 and further issues in that module, as requested by @phenaproxima

timplunkett	Note that this is for a contrib module Layout Library, not for core
tedbow	@phenaproxima I still think that issue summary could have a little detail of how this is suppose to work.
phenaproxima	@tedbow I can do that once I get tests passing. Currently I'm in the "how the hell did this ever pass tests" phase
tedbow	base field vs config field, any details
tedbow	ok
phenaproxima	@tedbow I'd rather not fuck around with base fields
tedbow	k
phenaproxima	@tedbow Configurable fields, you can create and destroy more or less at a whim...base fields aren't really designed to be removed
tedbow	@phenaproxima is dependent on layout builder module?
phenaproxima	@tedbow Yes
tedbow	could you just store the info in the existing layout builder field?
tedbow	I guess you don’t have real reference then
tedbow	nvm
phenaproxima	@tedbow We DO need a reference, but only to know which layout to copy from.
phenaproxima	@tedbow The actual layout data is copied into the LB field.
phenaproxima	@tedbow Then the act of reverting it becomes "re-copy the data from the referenced layout"
phenaproxima	@timplunkett And, it's back to a happy place. What do you think it might take to get it committed? https://www.drupal.org/project/layout_library/issues/2941806#comment-126...
timplunkett	`options.module`, lol
phenaproxima	@timplunkett Welp, it's what has the widget I'm using =P
phenaproxima	@timplunkett Eventually I think it should be a set of radios with the layout icons
phenaproxima	@timplunkett But for now...
timplunkett	Is there literally any other widget we can use? Changing dependencies can be a PITA
phenaproxima	@timplunkett I mean, I could use any widget that comes with core. How about this...I'll use autocomplete by default, but delegate over to options_select if options is installed
phenaproxima	@timplunkett Okay, fixed
timplunkett	Cool, I'll take a deeper look later today
phenaproxima	Thanks!

4️⃣ Determine if https://www.drupal.org/node/2937199 is a good idea, as requested by @johndevman

johndevman	the issue states it should be convinced to people, so im asking, is there any reason why we should not do this? as an alternative example quickedit does create a revision (for nodes only atm) when saving. we’ve also noticed this behaviour is/might be needed on inline blocks.
timplunkett	@eclipsegc If you're around, this might be of interest to you
tedbow	@johndevman so basically when you click “save layout” on a override if the default for the bundle it will create a new revision?
johndevman	yes
tedbow	that seems like good idea
eclipsegc	https://www.drupal.org/project/drupal/issues/2937199
eclipsegc	so my reason for not pushing ahead on this was content moderation and now workspaces
eclipsegc	I just feel like we should have a plan for how we want to interact with those before we go writing what we consider sane
tedbow	should we add a meta issue for how layout builder should function with those 2 modules?
tedbow	and detailing the complexities
eclipsegc	yes, I think that's totally reasonable
tedbow	rather than discuss on a particular implementation issue of 1 detail
johndevman	alright makes sense, wondering if quickedit would need a plan to given its current functionality
johndevman	is anyone interesting in creating that meta issue, or should I?
eclipsegc	I would like us to keep punting on QuickEdit. We're not stable right now, quick edit doesn't play nice with revisions, and any time LB & Revisions becomes a focus, adding QE seems like a recipe for failure to me
timplunkett	A meta issue around QE breaking other core experimental modules sounds worthwhile. But it should be clear that LB is only one of them, and that it's QE's "fault"
johndevman	so, potentially 2 metas?
eclipsegc	I like that idea
timplunkett	Okay. Because while I'm fine with punting on things, we should document that we are punting, and why
eclipsegc	yup

5️⃣ Open floor! Reply to this thread with anything that didn't make the agenda.

timplunkett	.
timplunkett	@phenaproxima what was that about Layout Library testing?
phenaproxima	@timplunkett I think 8.x-1.x HEAD might be broken. The last time tests ran there, it was May 6th.
phenaproxima	@timplunkett So I was just hoping you could trigger a re-test
timplunkett	I saw https://www.drupal.org/project/layout_library/issues/2941806#comment-126... fail because you tried to use `enable_defaults` which doesn't exist yet. but i'll double check the test config
phenaproxima	AHHH...that's probably what happened! I'm dev'ing against an 8.6.x branch with a bunch of layout patches applied. My bad.
phenaproxima	I'll try this again on 8.6.x HEAD
timplunkett	Yep, that `enable_defaults` is something from the opt-in issue I was working on
timplunkett	so right now LL runs tests on commit, and on patches. I also set it up for weekly runs. idk that it needs daily
phenaproxima	IMHO it should run daily, to catch failures due to 8.6.x HEAD changes
phenaproxima	But that's just my opinion
timplunkett	I can switch it
timplunkett	done
phenaproxima	Thanks!!

6️⃣ Discussion of general idea of Entity tracking as it relates to https://www.drupal.org/comment/12615133#comment-12615133

timplunkett	.
tedbow	so to have non-reusable blocks here we need tracking of BlockContent entities.
tedbow	when make a new revision you can’t delete BlockContent entities from last revision
tedbow	so when finally delete a parent entity you may have 100s of revisions all with different BlockContent entities.
tedbow	so I implemented generic entity tracking. that doesn’t assume anything about the entity being tracked(files have temp built in)
tedbow	I am keeping usage records with `count == 0` so you can tell that entity did have uses but now doesn’t
tedbow	modules using the tracking would be responsible for deleting the entities when `count == 0`. layout builder will do it on cron b/c may be to many to delete in `hook_entity_delete`
johndevman	yah, and its not coupled to deleting, you could technically use it for something else, right
tedbow	so entities are tracked on ‘entity_view_display’ entities for defaults and then content enities for that have the layout field
tedbow	@johndevman yes you could
johndevman	so this could also replace file usages eventually in future
tedbow	presumabley we could use this for media and other entities that are embedded in text fields. not sure how that is done now
tedbow	@johndevman yeah I think we could used this for file usage. though would have to very careful there
tedbow	Block config entites would a be little different because it is always a 1 to 1 with user to used entity
tedbow	also getting this functioning correctly will depend on https://www.drupal.org/node/2937199