Backdrop CMS Weekly, 17 Aug 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Backdrop Weekly Aug 17th

Description

Today’s development agenda: http://bit.ly/2hPMmlq

A

All right we are on air, it is Thursday August 17th. Thank you guys for coming. This meeting is a check-in on active development tasks for back job CMS, clicked update from the PMC. We are still working on signing and returning our contracts to get our fiscal agreement in place with the Conservancy.

A

We should have an update on that as soon as they get all of our contracts from us backed up CMS org has also been updated to the latest secure version of backdrop which was released yesterday. Hey I, don't know. If you want to talk about 170 or maybe Jeff, you did the release.

A

Know here, muted.

B

Okay, yeah I'd be happy to talk about it. Okay, so 1.17 came out yesterday we coordinated the release with Drupal that there was extra, wasn't the drupal of seven released yesterday, but there was a views release yesterday for Drupal 7, and so the security fix that we included correspondent to the new release of views, and we also fixed one of an issue, and that was exclusive to backdrop that was introduced in 1.7.

B

So it's great to knock out a couple of those security fixes in 1.72 also has a bucket of other just small bug, fixes here and there and so yeah. It was great to get that up and big big big. Thank you to John and Jeff for pretty much running, that entire release from the merging to the tagging, to the releasing to the release, notes sing to the security man spinning. So that was awesome. I, don't think that I would have we pushed that change out to the panthéon upstream and docker images.

B

Yet, yes, we've got a couple of follow-up issues there that will be working through either today or tomorrow, to kind of make sure that all of our upstream sources of backdrop are all up to date as well yeah, and if you run a backdrop website, we recommend you update as soon as possible.

B

We also had this is the first security announcement and we got to use the fancy-pants new security announcement, functionality on backdrops new messed up org, and so, if you have a user account backed web CMS to work, you can sign up for security. Malin was but in your profile and that automatically went out yesterday. So that was awesome to see that go off and fire and have all of that stuff, automated, so very cool.

B

Ok, so that's at one point: seven two, which means all of the items that are slated for the next bug fix release that aren't in 1/72 are now candidates for being concluded in 173. The next bug fix release and we'll see how this goes. You know, with the release of 1.8 coming up in less than a month. 1.73 may be the last bug fix release for 1.7, and if we don't have another bug fix release before September 15th, then 1.73 will come out at the same time as 1.8.

B

Does this count the last maintenance release of the 1.7 branch sort of got a bunch of minor little issues? We've been going through and kind of picking these up, picking up, long-standing issues issued 1200 fixed the way the captions are handled. That is just getting a little reroll and then we think that will likely be complete a whole bucket of cross ports from Drupal. We've got issue 2013, that is for Drupal, 7.50 and previous versions.

B

If that one's more than halfway done and there's probably some new PRS there that are probably ready for review as well, and then we have three more cross supporting issues that are issued. 27, 74, 75 and 76 and I won't go through all of those individual ones, but it would be nice as always to kind of keep up with the minor fixes that are happening on the Drupal site as well.

B

Even if they're just things like expanding test coverage and fixing code style and documentation, that's a lot of what these fixes usually aren't, but there's some real gems in there as well.

B

Let's see so, you can pick up the extractor on micropenis org for issues that are slated for a 1.73 raise another point. So do pilots don't get up?

B

Okay next up is 1.8. 1.8 is the next minor version of the backdrop that will be coming on September 15 2017.

B

We have a couple of changes that have been introduced in 1.8, mostly minor little additions here and there, and we have got a couple larger items that we are still working through, that we'd love to include in 1.8.

B

The first item that we've gotten. That list is lamp relationships, which is this your 21 34 no new activity on this. Since last week, though I don't know, I've been giving some thought to the way that we handle that particular issue that I'm torn between, like going with what we have here, which is something we talk about a lot put together last release, and it looks really pretty good. First is some new thoughts that I've been having a great this so anyway,.

A

B

One's probably I need to get some reviews and thoughts in there, although more feedback from other people's always appreciate it.

B

Blue, mmm have you written down you it no I, haven't and that's why I was like I, think I'll probably hold off on just verbalizing them and instead write them all down.

C

Or maybe you could look, maybe verbalize.

B

At the end of the meeting, Chuck yeah you well, we could do post if you wanted to yeah, let's sort of theme, the meeting, let's put that in the net general discussions. Okay,.

B

Are you I did that after broadcast? Oh sure, we can go, that's fine yeah, that's stirred drink. That could be fun day. Okay, let's continue on 1.8, though so 1.8 we're, also working on improving the media handling in general and specifically around files and images, and there's a metaphor that at 14 48 is within that category include making files into proper field to both entities. 30 are entities, but making them feel double is issued, 26 32 and that one is in a needs.

B

Reviews data hasn't seen any updates recently, but the code is, is there and functional and that mostly needs review from other contributors.

B

Editing an existing managed file is 27 96. This is a new one that has come up just this past week. That kind of separates off the task of creating new files from the managed file interface to just suffering the create from the edit and edit is a lot easier for now.

B

So if we want to iterate and just get edit completed, that one is a really good candidate to knock out right away, especially 27 96, so that one we could probably complete immediately and then we're coming, adding a file which is issued 2633 and that issue needs some additional work. Yet we also have another issue worth calling out issue 1380, that is adding support from multiple file upload, and the most recent suggestion in here is that we port a report.

B

The approach from a module from Drupal 7 called file Reis up, which is resume upload I, think, is what they're trying to abbreviate there, which is a neat module that not only allows multiple file upload but also allows stopping and resuming uploads, and that requires a lot fewer changes.

B

It's just JavaScript additions to the existing file widget, so that could be a way for us to achieve multiple file upload without doing a huge amount of refactoring I looked at the the underlying approach and it looks pretty good, but it's a little bit concerning because it like requires, like a database table to track in progress, uploads, so I'm, not totally sure about the repercussions of implementing that approach. Yeah.

C

This seems like a big thing and we're fairly late in the game here so can be. Is it did we just shell, this part of the file stuff until the next release.

B

It's a kind of a lower priority, one.

C

B

It's probably the first one to get bumped yeah.

C

I would say we bump it cuz, it's yeah, just it seems like there's several. It seems like there's some fundamental differences in the different ways that they handle it. So we might want to have a larger discussion on this sort of how we want to handle this stuff. Yeah.

C

Okay, is there anything to contribute those with right now, yeah.

B

That's good print. You could just take this file receptor module important to backdrop that one yeah.

A

B

Orange yeah I think yeah any the other modules.

A

That are mentioned in that issue, like there's a ton of solutions and contributor poll yeah yeah. So it's not like people are having problems. We just it would be nice to solve it. So I think it's totally fine to bump this a release yeah.

C

And I say I'd say we get ticket Ripper, so we can test it out. That would be better.

B

It's a really fun little known feature that we included, probably and I. Think at one point four or 125 did you know that if you're on a mobile device and you upload a file from backdrop, you can use the camera on your phone to upload a file, pretty cool.

C

That actually is pretty cool yeah.

B

I think that's really neat. That was a yeah. It was a gem discovered by a clone us. It was actually really trivial and awesome to implement.

B

Okay, let's see, let's carry on there's a couple of new items in here that looks like Jen may have added date: module pager, which is issued 2766. Could you recap that one for us, Jen, I'm,.

A

Sure so it was just a part of date, module that was accidentally not included when we moved to date module into core, and so somebody knows that this feature was missing and created an issue, and then they read all of the date module port issues like it doesn't look like this was intentionally and excluded, so I've ported it so as originally tagged as a bug fix, but because we're adding a new feature and it's gonna need new testing I, also added the tag new feature that has a pull request and it's been reviewed by one person and seems to be working.

A

Fine, so I was just thinking if we could get a eyes on that. That might be something that would be easy to get into. One point: one point: eight: if it looks like it needs considerable work, we should bump it, but because it is closed, I figured we'd, add to the list and see, and so just so you guys know.

A

I went through the some of the issue kids this morning and started trying to like reorganize things that we don't I, don't think we're going to get done in time, but the things that look like we might get time I just added to this list. That's of these two are in the second one. Module filter updates is just a usability improvement where, if you're on the modules page and you filter for something, and then you enable it when the page reloads, the filter is lost.

A

So then, if you wanted to like configure that module, you've got to type it in again, and so somebody recommended just retaining the value of that field so that when the page reloads it's already filtered to the module you just search for, which seems like fairly sensible and there's poor quest and it's a small change, so I figured get some eyes on that and see what people think.

B

Yeah, but this also does actually genis it makes it so that when you filter the module list, you enable module and you save the entire modules form, so you actually enable a new module it racists, oh, it did use just say that I thought they said when you submitted this search, not there. Oh no.

A

It meant that, like when you turn on the module, they don't search for it again to enable like configure the settings. Yeah.

B

A

B

Okay, yeah, that's a great great little great little addition yeah thanks also for starting to organize things under the 1.8, milestone, I, think having items slated into the 1.8 milestone and bumping out the ones that aren't relevant that provides an opportunity for anyone interested in getting features into 1.8 and just looking around for interesting things to work on, could take a look at the 1.8 milestone and take on any of the items that are in that list.

B

A

Particular anything that needs review should be higher priority, I think if we can get some people just kind of test things that would really help us out. We seem to have a lot of stuff that just kind of gets stuck at the need. Serbia, state, yep.

C

B

Speaking of which I should also add that we had a bunch of issues that were marked ot BC that come from the last bug fix release, so it definitely has been some really fantastic module or issue. Reviewing that's been going on. Particular Opie has just been going to town on our to be sitting issues and that's really appreciated. So thank you very much.

B

Okay, that's it for the 1.8 status update. We still have lots of work to do and clarify. Once again, we have got code freeze coming up in two weeks. September 1st is the code freeze date, that's Friday and yeah. We've got a lot of work to do.

B

So in this schedule here again we've got the 2.0 section. No real changes on the 2.0 status, I think uh probably a question.

A

So if just said on the first girls around- and we don't know anything, did we bump 2.0 to May 15th or did we bump it to January the following year.

B

Can you clarify what those two timelines really mean like? Why would.

A

I be those two.

B

A

If we're not gonna do it on time, we need to figure out what the neck like when we should next consider doing it. I don't know if that means like okay, well right now we're doing 1.8 if January 1st becomes 1.9. Does that mean that 2.0 happens at the next release, which would be the 15th or are we gonna push it a whole year and then not do it until January and you're, saying and.

B

So we would be stuck on 1.9 for a year. We.

A

I'm just wondering like what are like, if we even have a plan for like, did we push it out of here and say releases or every four years, or do we just say, release whenever we're ready, yeah.

C

I'm still I'm still of the mind that we should release 2.0 when we actually have some substances substitutive changes because, like you know, we have a lot of stuff about how our API won't break. So it doesn't break within a release, but we will make breaking changes when we go. A major release, so I feel, like explains people. Okay, we're doing a major release, but there's no breaking changes is gonna, be kind of weird.

C

A

There are Brittain unless our language becomes, our major releases only have breaking changes and even versions or something I mean I. Don't know like well.

D

A

The ability to change that language, so if it becomes clear that the language we have now is wrong, we can change it. We just don't have any plan at all right now. We just adopted Drupal's language, so.

D

I mean yeah I mean I again like like are like what does it mean to be yeah.

C

I think we should have a whole discussion about that at our summit. I.

A

Think that's a or developer conversation, not so much a summit thing. Okay,.

C

Or, like you know, I think maybe we should have a core developer agree meeting on that Sunday yeah.

A

C

The summit yeah so yeah cuz I, would I still haven't seen any compelling new feature that would require breaking changes that were, like you know, backdrop 2.0 now with blah. You know it's like I feel like we need. We need something exciting to water. A major version change do.

A

We need something exciting to encourage people to upgrade or do we need to break api's I.

C

Would say I would say it's a little bit of both that we should. We should avoid breaking api's as long as possible until they're holding us back from doing something exciting yeah.

A

Once there is something exciting that warrants breaking.

C

The api's that's when we should go and do it and I.

A

Don't think that I mean what, if we never have something exciting that warrants breaking api's.

B

It all have been eventually back.

A

Drop one at point: one six, four five 2.0 I mean I like we have a good product like right now. You know a lot of the exciting things that people want can probably be done in the one point. X cycle yeah, but I think that if we say it back up forever, we aren't gonna get as many adopters because everybody's like oh, it's still on version 1 well.

B

Yeah, it sounds a lot like have you ever heard of it. There was an old database system before sinkhole became popular called db2 and DB 1 never existed. They actually started out and called it db2, because nobody would ever trust a 1.0 product at that time, so they just called it baby. Just because that was better marketing or like.

C

B

Or something I don't know, that's your that's the same. Let's.

C

Put this way, it's worth the discussion about whether- and maybe this would be like a one-time version bump just to get the marketing gains.

C

We're gonna, bump major versions for marketing reasons that we should have some sort of marketing push around it. Yeah.

A

C

I feel like I feel, like yeah I feel like it's like. You know, we're gonna, it's gonna have to be like an actual we're gonna have to a big push if we're going to pump version, because we need to actually get it out to people, but I think that we have some sort of bit more.

C

We have more questions about like sort of the where we're going with the project and who we want to be convincing, like we're like. Let's convince people like who are those people who are going to be convinced by major version change?

C

Who are we? Who are we targeting yeah? So just basically, we I think there's more questions about that about. You know who are we trying to convince? But okay, so.

A

Maybe what we should do is say we're not going to do 2.0 in January. First, we'll know for sure on September 1st and then say have the conversation at bag camp, which is going to be before January 1st and then we'll decide a bad camper shortly thereafter, whether we should re-evaluate for the next release or push out a year and reevaluate, and hopefully we know what backdrop to means that will give us the insight to figure out how long it'll take us to get there. Yeah.

B

I think I think situation. Oh go ahead. Mike I was.

C

Just gonna say: let's plan on doing 1.10 for January, because I feel like I, feel like. If we are going to do a 2.0 push, we might want to like make it an extra big push and maybe skip one release in order to prepare like a bigger 2.0 push or something.

B

Interesting I was about to say the exact opposite, regardless of what we do. We should keep.

B

Cycle like no matter what like, even if, even if those minor releases, have hardly anything new in them because of our because of our focus long, as you point out like we shouldn't, continue delivering on that every four months cycles, so we don't ever end up in a situation of like you know, people getting frustrated because their changes are never actually released. Oh that's.

C

Fine but I meant just sort of maybe we should spend an extra development cycle concentrating on 2.0 yeah.

A

Okay, yeah, okay, so for now, let's just call it on the January 15th deadline. That's all you're, saying not wait till September first, because we need to have the conversation at bag camp, so yeah.

C

I was I was just gonna say for January. We should just have a 1 point: 10 release one.

A

C

Nine one point: nine yeah, just one point: nine yeah.

A

C

We should definitely about 1.9 release, wouldn't want to get that.

A

Okay, no, that's fine and then I'll update the website and everything so doesn't say: January 15th. So people aren't yes, yeah.

C

You know, I could also be convinced that maybe every tenth release should be a major release yeah and that we should just go go through our backlog of breaking changes. We want to make and just make them yeah, but I. Just I just feel like adoption is like still so low and there's still so few sites using backdrop and we're still hoping for so many Drupal sites that we don't want to break things. Yeah.

A

C

Leisa yeah I know yep.

A

B

Quite all agree on that, but it's like typical too soon for us to remove things like the triple compatibility layer and things of that nature. Yeah yeah, okay,.

B

That moves us into just general discussion, which is almost where we were already, but but let's roll back around to relationship handling, so continuation on the discussion in 2134. So when so, this is doing adding relationships to layouts that right now, when you have a context like a piece of content or node or a user or taxonomy term, you have the ability to do stuff like put a condition on a block.

B

That says only show this block on a certain node type or show the Fiat or pull out individual fields from a node and place them on page and that's available, because the contexts that are able on that layout relationships that make it so that you could add an author like add a relationship between the node and its author, which is a user entity and then call out fields on the user and display them like.

B

Maybe like the user's profile picture or bio information, you pull off their profile and show it in the sidebar of the piece of content that they wrote. Something like that.

B

So when I first wrote, the layout system or I should say when I ported it reported panels and made it into layouts.

B

All of the underpinnings of relationships are still in place in layout, module they're, just not really exposed like the functionalities, distant completed and the the all requests that dock will mop together in 21:34 kind of carries that to completion and what it would look like if completed, would be when you're setting up a layout the contexts get pulled in automatically as much as they can't be, and we can add a manual context.

B

If you have another URL parameter, the back trip doesn't know how to deal with, but then the pull request to make it so that you could, from the context that are there add a relationship to another context when you're setting up the layout and then when you go over to add blocks, you would have blocks and conditions from all of the relationships that you've added and all of that, the context that were there.

B

So that would be a really awesome, powerful change but the and it would match to what we had previously seen in Drupal. 7 using panels, but the one I was thinking about doing. Instead, this is where we might go down. A rabbit hole is instead of specifying relationships at the layout level. We could add relationships at the block level. So every time you added a block at the very top of the add block dialog, we would show a drop down for contextual blocks or something like that and.

A

Then that drop.

B

Down it would include like node so or content if they were node related blocks available, and if you were to select a context related to nodes, then the list of blocks would show you only the node related blocks, like all of the fields that are related to that node.

B

But at the same time, if there were any relationships supported by by that context, over the top, a second drop-down would appear, showing you a list of all relationships that you could chain off of the first context, and that would be like the the author of the node, for example, in any reference fields that you might have and then, if you selected from that drop-down, then list of locks would change to show you only the user related fields and then a second third drop-down.

B

What appeared again would let you change further, so basically you could, as you were, adding blocks, you would be able to change as many as far down as you wanted to from the add block interface and every time you selected another level in the chain. The list of add blocks would change the context. That is the the most the bottom most relationship. Basically I like that.

C

I, like that idea like, if I understand what you're saying I like handling that at the block level, because if you make, if you have a bunch of blocks that are using those and you change the relationships of the whole layouts and all the blocks would break yeah. So this is a good way to like change. What what relationship you're, using or something like that. Unlike for a lot of blocks that haven't, go back to layout, changing the whole, adding or relationship or changing relationship which could theoretically break other blocks. So.

B

And it also what makes it so. That's the connection between relationships and what relationships actually do is right in the same place, where you're actually adding blocks as opposed to putting it on the settings page where you kind of have to think ahead and be like what relationships am I going to need, because you might not know that you need the users bio field before you start placing blocks, and so it puts the functionality closer to the configuration which would be a big. A big win. I worry.

C

About it's a bit confusing, it might be potentially confusing to people who don't understand what's happening so I. Think that, like looking at the user interface and I, don't know if we want to go so far as like, maybe doing testing or asking people with to take a look and see if it makes sense with fresh eyes.

C

B

The other thing that helps a tiny bit with that problem is that if your layout doesn't have any contexts in the first place like the home page layout, this problem, like the showing of the list of contexts and relationships.

B

None of that is even a possibility because there's no context in the first place, so it kind of saves you from like it's a little bit more of a gradual introduction where the homepage and default layouts don't have these these problems or these complexities, and then it was only once you start overwriting node level, ok, like a custom, a layout at node, / %. That starts appearing okay. That.

C

Makes sense so like if someone was creating a custom, a custom page with the layouts, then it wouldn't affect that. Okay.

B

Right because there's no context in the first place.

C

Which also shows this is kind of like a marginal benefit. Is it's a heading? It's only like a certain number or small number of layouts would have this but yeah. It would say it would save a lot of a lot of like creating a views and stuff to do the relationships. Mm-Hmm yeah. So it's definitely worth adding yeah okay, unless someone has other feedback on that, does anyone have any feedback on where to put the thing or I really.

A

Like that, putting the thing at the block level- um I wonder if it if like, where the layout actually gets it, that relationship gets attached should be at the layout level or at the block level. Just for like caching regions. I know they talked a little bit about um like there being a static cache and that's nothing access to whatever it is. That was loaded.

A

But it would just be good to confirm that, like loading, a relationship like ten blocks, doing it in one perfectly did at the layout level, it would be always there for all blocks whether they used it or not, but especially since all of our code adds the level of the Lea level.

A

If we would have to change all that existing code to edit the block level or if we just need a like user interface at the block level that attaches the layout level, she's kind of trying to figure out like what the scope of the apt API change is here and how we can build a clean user interface.

A

On top of that, you guys we already have in the window X cycle or if we need not true I'm.

C

Not sure I understand what you're saying so that you're talking about the caching.

A

So to things like, the caching was my first concern like I: don't want to load the user for every block that needs a user field on a node. My second concern is with the api's we have now, because it was a part of panels. They all assume the layout is their relationship is at the layout level.

A

So layout will have a context and any number of relationships, learning of our contacts that are defined by relationships, and so then, if we're going to move that to the block level, is there gonna be any API change needed in order to make that happen? Well,.

C

Here's here's okay! This is what I wanted to get into. It's we're not talking about where to put it in the user. Interface is: where are these relationships defined like in terms of the data architecture? How do we know that a node is linked to a user and and I would say that it should not be part of the lab system at all? It should instead be part of the entity API and that entities.

C

We have the entity info array that stores all of the data about an entity, type that we should add as part of that array.

C

Basically, the relationships to other entity types so, basically, when what what.

A

If the relationship isn't it to an entity that opens.

B

What would you know yeah? The only thing we can deal with right now is I mean the only contexts that exist are all, and it is this point, but.

A

Isn't? That? Because those are all provided by core yeah.

C

But I don't know what you would connect to that's, not an entity in terms of the context. I mean.

A

C

We can think of things that we yeah.

A

Well, I would think, like anything that has a database record, could provide a context and not all things that have a database record been injured for entities right so like you could have like a unique identifier and then load whatever the thing is, and I don't want that thing available, but it does not clearly has to be an entity. Well.

C

I would I would I would say. Maybe we could create a list of examples of how that what other things we list to, like you know, I'm thinking mostly in terms of entities and I, think that we should. We should see how these entities are linked in the entity API and how we could more explicitly define the relationships between core entities and how custom entities can define it so that yeah.

A

It's not old, not only for this, but.

C

A

So there are a couple non non entity things that I've done this part with panels. Note queues and flags are two of them: I, don't know if flags and backed up or entities or not I, think flags in Drupal 8 are now an beasts, but both of them are like.

A

Oh, if you want to put a block on the page that lists like all of the other nodes and the note queue that this node is on, like you want to have note, cute relationship and no queue is not an entity, but it has a unique identifier, and you can do that for noted queues that are simple cues that have like a unique identifier or nodes keys that are sub-q. That use like a taxonomy term as an identifier and there's a lot of way that you can build relationships between things like there's.

A

A lot of kinship modules to give you relationships between things to don't have anything to do with entities, so I think you should leave entities out of it in terms of our architecture like those are the examples that we are working with, because that's what course providing but.

D

A

Think that that would be related at all to how this well.

C

It's like: we need to figure out how how we need to figure out how you define these contexts then, like you know, how would someone define a custom context for linking to the flags or something like that right.

A

Well, I think all of our all of our contexts, there's already a way to you, define like we had taxonomy terms in core long before there was a context for taxonomy terms like there's a there's already a way to do that. um Yeah.

B

Written right now, it's contexts are provided via hook, layout context and yeah yeah.

C

B

C

B

Don't know so, like you know, I was a little chip step and probably meet similar I was.

C

I would vote for context being driven and maybe not only by maybe not only by the entity API but also the field API and or maybe or let's put it this way. We.

A

Already have an API for this I. Don't I really understand why this is an issue. I mean I. Think that question was where are this like, because we have a context: I don't know need a context as an object or if it's just an array of data, whatever point it gets passed to the layout, but we already have a thing called a context and adding a relationship to a panel. Just your layout. Sorry just gives you another context.

D

A

If you're on the node, you know- and you already have a node context available- you add a relationship to the author. You know have two contexts available. One of them is the node of one of them is the author. Yes, those things can the enemies, and if those entities have fields, then we get benefits like blocks that have fields, but any kindred module could add any additional contacts. That is or is not an entity, and it can have any number of blocks that depend on that context.

A

Being present, that has anything to do with enemy or not like envy is just one of any possible options that has stuff associated with it, which is a benefit, but it shouldn't have anything to do with a context like we already have an API for defining your context. I'm.

C

Just not sure I'm, just not sure when, like so like the flag, mods or something it's just going to define the law like it's gonna, like you know, you're selecting the block type, one of those is going to be show the flags. You know I'm, not sure why flags or something like that would need to find an additional context, because it's already defining the blocks within the current context.

C

A

You might want to, for example, show all the other content that is also flagged with this flag right like there's, it's kind of anything that you have done in the past, with views using relationships could be a valid use case for using relationships on a layout. Oh.

B

Just back a little bit to give you guys a little bit more context into our current architecture. So there is a Hockley context info that deals with context and for the entities that are in court, that are, that supported node user and term term. There is a single class called entity layout context that supports all entities globally and so basically that there is a hook or hopefully a context info clip for the most part. All of them all use the same implementation, which is provided, which.

A

Is for entities.

B

Yeah and it would probably end up working the same thing same way for relationships that would be the relationships that would be provided in core word to all the entities and there would be a single class that dealt with the relationships called entities, but that would only be the one implementation bit layout: module use and.

A

That means lutely contribs add an entity would have a really easy way to hook in all of these systems. There are entities which is great right.

B

And- and the important in theory have something that's not an MD but yeah. It's like there aren't any examples of that court at porridge and really any great ideas about what those things could be. But if the possibility is there with contexts- and we probably do the same thing for relationships, yeah.

A

B

Actually, we'd almost have to do the same thing for relationships because they're really the same thing. It's.

A

The context- that's just really did right, yeah, yeah, I, don't know I.

C

Don't know I just feel like I just feel like in terms of like, because I've been obviously with the entity reference stuff been doubling it to the entity. Api and I feel like it'd, be good to more explicitly define the relationships between different entities inside O's inside of the entity API and who move move the remove the relationships, okay, min and move the relationships between core entities into the entity API into custom entity.

C

So if you were just to define the relationship in the entity, API between, like your NID like like you know, attribute or you ideas from you say, this is a reference to this other entity type more explicitly the entity API. Then maybe you don't have to define separate like layout relationship context or something like that when you're to set it up it just automatically, is handled and handled by.

C

Oh yeah, I, don't know it's just like it's just like I feel like we have all these core relationships, they're already defined in like the views right like we're like when you have all the when you're linking a node to its user interviews. Where is that relationship data stored, yeah.

B

I explicitly in views still its yeah use.

B

C

If you're creating a new entity, types of reference is another entity, type you'd need to say: okay, I'm, just sort of the relationship and views then you're like okay. Now I need to set up the same exact relationship in layout, whereas like if you're just two defines of relationship once in the entity API, then you wouldn't have to do it specifically for views and layout separately, yeah.

A

Although there is.

C

A

You don't want to have that relationship automatically added over your views earlier queries doing it really slow like what you want that no.

C

It's just it's just added. Well, it's just added as an option, because, right now, when you have, you have to define like a explicit relationship option for views like it wouldn't automatically be added. It would just be added as an option to add to your current view. Okay, that.

A

Makes more sense, it's a right now! That's all in like the hook news data, yeah.

C

A

C

This is sort of a question, and you know this might be one of those. This might be one of those backdropped 2.0 things like. Maybe we have it defined both in layout and use the relationships in those like. Maybe we just put it in the layouts module for now but, like you know as part of 2.0 move like the relationships of things into lower down in the data architecture. Well,.

A

I think, like that's, the kind of thing like in entities would be really easy to have it like the entity. Api provides all these things with like a flag just like you're, creating an entity and you can be like do you want to thread even use relationship? Yes, no, you want to try to layout relationship, yes, yeah yeah, getting on those values, those things low gear or not appear as needed, but I. Don't think that means we should like limit the API to only work with entities. Oh yeah.

C

I'm fine with that I just hadn't, considered other contexts and I'm still not convinced without the flag thing about whether it actually needs additional context.

A

But yeah I don't know if flag is a good example I'm, just thinking of like eaten panels, all of the things that I've specifically added so that they would be available like written, like custom plugins, for to do this and there's a lot of things that are not entities yeah.

C

Well: okay: well, let's, let's put this way, I'd be interested in hearing like a concrete example of a context, that's not to an entity.

C

Yeah we have like.

A

Limited use case wise to like are any relationships. This kind of limited use case and putting it in core I think is good for things like entities, because those are majority use case, but you know kicking that from chicken trip. It's also totally fine. If we have the thing like we have an hour, it's like we have this thing that works for all entities and theoretically it could work for other things too, and letting them figure out how to do. It is fine I.

C

Thought yeah anyway, so the long and short of it is I think that we have a sort of user interface user experience issue of where to define these relationships within the thing. But then I also think that we have like sort of a back-end how to store what the relationships are. Data architecture issue you.

A

Know anything I think we need to keep both.

C

In mind, right.

A

Now that all happens at the layout level yeah- and we just don't- have a UI for it. But if our UI is gonna be anything to the block level and we actually think architectural, it would better to have those be stored at the block level. Is that going to require an API change, and does that I mean we shouldn't put in layout relationships until backup.

B

So the API that we have right now is not usable, it's not functional. So, even though there's places in the layout object that has like you know how arrow relationships like there's property for relationships, there's never anything in there.

A

B

It's not possible to use it, so we're not really breaking an API, because there's nothing there to actually use its just stubbed out. Okay,.

A

So it's not there, it's not like. If you're outta control module, you can access that thing and have a leopard ship or something all the minutes.

B

Okay, it's not work right now. Okay,.

A

That gives us a little more freedom um in terms of 1.8. We have something that's kind of there, but it hasn't had any attention since the last release. Would you be interested in bumping this 21.9 and playing with the idea of removing the relationships to the block level instead of doing it at the layout level, and that would give us some time to like proof of concept that.

C

As if we're bumping it and doing that, I feel like this I feel like Nate's idea is better and I feel like. We need more time to make sure we implemented right.

B

C

Yeah sounds fair.

A

Nate, you really want this feature, but you just had a really good idea about it and it's doing yeah.

B

I know that's why I should look at things they do for soon it oh well! Well, anyway, it's an idea, and one thing definitely needs a pianist. We need to write that all down, because right now it's not reflected in the issue, so we'll continue leaving it here, and we saw that we can give it a status update next week and maybe officially bump it at that point.

B

Okay, awesome! Well! Thank you guys for the feedback. It sounds like that's in concept, kind of a good idea and we'll see or see where it leads.

B

C

A

B

Right: okay: go glitter, yeah! Thank you, everybody for watching. Thank you for being here.