I think you'll be very happy. So my name's Calvin Hendricks Parker. I'm co-founder of Six Feet Up and also the CTO. But I've been involved with Plone since 2003, since the very first Plone conference in New Orleans. And then I've also helped serve on the board and do lots of things and then contribute into Plone. And actually, Lineage is something where I got some of my first contributions into Plone.

As you'll see later on, to get something like Multisite working in a large framework like Plone, it requires that the framework itself cooperates. So I hope to show you the things that it cooperates on and why Lineage works, so you have a better understanding of what's going on under the covers.

And then hopefully with that, you'll understand why it's important and why actually a solution like Lineage makes it nice for deploying potentially hundreds of sites into a single large Plone instance instead of doing many, many, many deployments of Plone itself off onto lots of servers. So Lineage itself is just an add-on for Plone.

It is enabled by some of the pieces that are already built into Plone. Specifically, Lineage leverages things like the iNavigation root and the iPossibleSite, and it provides an interface called iChildSite. So I know that was a lot of mumbo jumbo, but yesterday during Andreas' talk,

he talked about the Zope component architecture and his potential dislike of said architecture. But without that, this would be a little more difficult, I think. So these are actually interfaces, a part of the Zope interface stuff that basically, when you've got a folder inside of Plone, it can have specific interfaces that are marked on it,

and based on that, you can put browser views, you can do things like this navigation root, which actually makes the folder look like its own site by rerouting the navigation, rerouting the search, rerouting the portlets. And this is part of something we did in actually Plone 3, 3.3, something Martin had added in initially,

and then I helped kind of finish off was this addition of this full functionality of navigation roots. So what Lineage does is actually take advantage of that and give you a nice UI for enabling and disabling child sites, and then the UI is for switching between child sites, and then provides kind of a launching off framework for other people who've written some add-ons to Lineage

for things like Steam switching. So I'm gonna show you some of that as well. So the idea is you can take lots and lots and lots of what used to be potentially full Plone sites and consolidate them into a single Plone site, and then you save by basically not spinning up a whole nother catalog, spinning up a whole nother set of ACL users,

not spinning up a whole nother set of workflow tools and content type registries and all the machinery that's under the covers when you talk about doing Plone sites, you now get one copy of all that stuff and then are able to leverage it and use it across in number potentially hundreds of sites. So let's give you some nice advantages

is because the management of your sites becomes much simpler. You have one set of users. It's a lot easier to give people sharing rights in certain folders, which would be like sites in this case versus other sites. You get basically one source for groups and roles and permissions. Anytime you add an add-on or upgrade an add-on,

all of your sites then simultaneously will get those same upgrades to their sites as well. And then anytime you upgrade your version of Plone, you also get the advantage that if you had 100 sites inside of your one Plone site, they all get upgraded simultaneously. So it's almost like a software as a service, kind of a model for being able to quickly roll out

new sites ad hoc as you need them. And then you can obviously, since they're all in one giant content management system, you can share content back and forth between those subsites if you wanted to as well. So if you needed to syndicate content between departmental folders or share multiple copies of a single document, you didn't have to have that cut and paste

from site to site to site. You can actually have a canonical version of that content and multiple sites now can refer to it. You can link to it from the TinyMC editor as like a related item. That's all possible by being able to do everything inside of one copy of the whole CMS. And another obvious advantage is gonna be performance.

I'll show some numbers later, but by reducing the total number of moving parts, obviously you're gonna get a smaller footprint for all the sites altogether. So we've actually seen quite a few speed performance increases when you consider 10 clone sites versus 10 child sites inside of one clone site.

Now there may be some disadvantages. In this case, if you wanted to actually split those small sites out and do something different with them, it's a little more difficult to, you have to basically export a site out of your clone site because it's just a folder and it's not an actual full on clone site. You'll have to then do a little more work to move one site from say one clone instance

into another clone instance. If you have a large number of users, the sharing capabilities like the standard UIs for clones sharing capabilities may get a little unwieldy as you start searching through like hundreds and hundreds or thousands of users. Then there's some other tricky things with theming,

but those aren't too bad to work around. And then the other kind of disadvantage is gonna be that add-ons and properties could potentially be global to all of your sites. So this is nice if you have a lot of sites that very much share all the same add-ons and functionalities. A lot of organizations such as universities

may have a need for a faculty staff directory, they need standard content types, maybe they need a special kind of an event and that works for all their departments. So this is an optimal solution for that. If you have very wildly different sites that need very specific add-ons that one shouldn't have versus another, then lineage may not be the area you wanna go down or the road you wanna go down.

So let's actually get our hands dirty. I wanna actually show you guys how to install lineage. And then once you've got it installed, how you can actually start adding in your subsites. Also, there are quite a few lineage, like add-ons to lineage, kind of a meta things, add-on to an add-on.

But people have created ones like the lineage theme selection. So this is gonna be a popular use case, is that you have a site, but you don't want all your sites to look exactly the same. So using something like the theme switcher, you can actually install 10 diazo themes and give each sub-site their own individual theme separate from a completely other site.

So to install lineage into your build-out, you basically just go into your build-out configuration file, find your instance, add it into your eggs, so you can add in collective.lineage and for example, in this case, I added in the lineage.theme selection as well. And then you will just rerun your build-out.

That's one of the ways you can get it installed. So sometime later, you will, after waiting for a build-out to run, we'll have a demo of actually what it looks like. So let's see if I can demo that here.

Nice big resolution. Okay, so once you've actually rerun your build-out, you will go into your standard site setup and add-ons and it shows up. I'm actually showing off the lineage 2.0,

which actually released yesterday, is now inside here, gets rid of some dependence, some nasty little dependencies people didn't quite like and I didn't like either, which was the p4a-subtyper product. So 2.0 actually removes that dependency, simplifies the product. It's got a lot more enhancements and bug fixes thanks to a lot of the community who's been using the products out there.

So now that I've got lineage activated, I actually activated the theme selection add-on as well. We can go up into the root of our site. You can see nothing drastic has changed here yet, but if we go into a subfolder, for example, of our site and now in the actions menu, we'll have the option to enable a sub-site.

So now that this is enabled as a sub-site, you can see that the blog has been rerouted as its own home inside of Plone and things like the search and if I had portlets installed on the side, are all gonna respect the iNavigation root marker interface that's just been put on that folder.

So that enables this basically what looks like its own site. It can have its own virtual hosting URLs pointing to it using a virtual host monster so you can actually configure different vhosts with different names associated to each of the sub-sites inside your specific site with the same kind of style rewrite rules that are already used to for your root Plone site

and you can actually nest the Plone sites as well. So if I actually wanted to put another folder inside of here and we'll call it the subblog and if we click on actions, we can enable a sub-site here

and actually now you'll see we've got a sub-site inside of a sub-site and the little sub-site switch, there's a switcher built into Lineage basically to help you when you're first starting off to switch between the sites. Typically most people don't use that, but it's kind of nice for getting started. You can see that the blog and the sub-blog and the Plone site are all now shown up as separate,

what look like separate sites inside the sub-site switcher. Do you notice that your blog folder will still show up in the root site and a lot of times what we do there in that case is if we wanted the blog to be its own sub-site, we'll go into the standard settings and just hide from navigation or exclude from navigation and now the root site won't see

that in the main navigation part. So I'm still in the child site of the blog, but if I click back up here, you'll see that it's disappeared from the navigation part. What's nice about the hierarchical child sites is that the search box in the root site is gonna search all the content from here and below including content that will be done

inside your child sites. So if you wanted to simulate like a federated search across a lot of departments, you could structure your child sites in such a way that all of your departments were say underneath the university and as you search the main university site, you'll find content in all the departments. But if you're inside of a specific department and do a search, you only get the content from inside the specific department.

So really easy to do because we're basically relying on the fact that the hierarchical nature of Zope and Plone here really kind of helps us out here and we didn't have to write a lot, there's probably no extra code written inside of Lineage itself that does any of that stuff for you. So that actually works quite well. Now another neat thing you can do is then changing the theming for a specific sub-site.

So if we actually went into our blog site and we wanted it to look different than the other two sub-sites we've added in here, you can see now we have a theme tab inside of our child sites. So we can go into that theme tab and it gives us basically the theming control panel

but in the context of our child site. So now we set up, for example, we'll activate the SunRain theme here and if we click back on home, you'll see that this is now the blog site and if we click back on the main site, you've got still the standard Plone look and feel.

If we go back down into the sub-blog, we can actually theme this one differently from the other two as well. So we can give this one like the Oculus Lite theme and there we go, we've got a third theme. So now three sites, three themes

and it was very easy to get going with and you guys can feel free to ask any questions along the way or I'll take questions at the end, it doesn't matter to me but now you can see basically the ease of use of the lineage there. Let me get back to this.

All right, so now I wanna show you actually some cool tricks you guys can do with lineage. So as you saw, lineage items were just folders like we just went to the add dropdown,

added in a brand new folder but what would be really cool is if you can customize the behavior of that site or make something that you add from the add dropdown menu already tailored for your users as a lineage sub-site without having to go activate or change anything about the site, they just get new sub-sites whenever they create these kind of content types. So you can actually make custom content types

and as long as they're folder-ish, they'll be enabled or potential to be a lineage site. So this case I'm gonna give you kind of a little mini use case for what we did with Penn State and their eLearning group. So they had 120 plus, they're up to 140 now,

individual clone instances inside of one ZOPE server. They had a problem that every Sunday night, the classwork was due at midnight. So being the good students that the Penn State people were, I'm sure this is only a thing that happens at Penn State

is that all the students would wait until the very last minute to turn in their homework so at 11 p.m. on Sunday night, the sites would go down because everyone would hit it basically simultaneously. I asked them if they could stagger the due date, they said that wasn't a possibility and so we had to search for a way around this.

Basically when they were making new course sites, this was their new course creation button. They went into the very fancy futuristic looking CMS here called the ZMI and they would check the box and click copy and then they would paste and then they would manually update by changing the name of the clone object. They would change some of the placeholder content

and then they would add properties to the root of that site that were specific to that site. And because of all the abuse they just did to the ZOPE instance, they had to do a clear catalog and a rebuild. And as you can imagine, the catalog was very confused. So this was a lot of what was going on. Can you imagine if you'd copied and pasted a Word document

that had tracking changes on for like 10 years? Like this thing got to be a huge mess. So with Lineage, we actually were able to migrate all those individual clone instances into one clone instance with subfolders. Actually we were able to help them structure it a little nicer. We basically gave them folders per department

so they could give departmental editing privileges over certain courses. And so migrated each of those clone sites into folders underneath department sites that were easy for them to now manage. So taking the 120 plus sites and putting it into one consolidated site, they now had individual, what looked like unique sites

for each of the coursework with all the navigation rooted at that specific course. I wanna show you a little bit about how it actually works. So this is a quick demo of what's going on or behind the scenes as they're managing the new courses. So like I mentioned, you can make any custom content type become a child site very easily.

So in this case, they would go to the add dropdown and add in just a custom content type called a course. What was nice about the, okay, what's going on? They would basically add in the title of the course which is what used to be the title of the portal. They would have the ability to change summaries.

What was also nice is they had custom metadata that was specific to the courses that the creators of the courses and the managers of the courses themselves would actually have the capability now to manage on their own very easily. And they can even do things like put in custom banners right through the nice UI. And once they save, it takes a second because I'll show you what's actually going on

is in addition to creating just the course, it's actually creating all of the boilerplate content for their courses. So once a course is created, it actually makes all the blank lessons and the front page and everything they needed for a course, they were basically guided through the whole process without having to go recreate each of those bits.

Well, it should be, what's going on here? Oh, it's still going, okay. So it does take a little while. Again, what was nice about this is that they didn't have to go make a folder and activate the folder. This custom content type already had

the lineage iChildSite already loaded into it. So once you created it in the site, it was already instantly a lineage child site. So you can see there's all the boilerplate content put in place for them. All the lessons, which are all folders and then all contain lesson pages are all pre-built with basically professor, faculty person,

go fill this out and you wonderful, you've got a beautiful course now. And then you can see that there's the custom banners that got uploaded into the system and it was all really easy for them to now manage and maintain. Another nice thing is this hooks into the university-wide authentication system.

They use web access for authentication. So the students can log in, but the students can only go to the courses that they have permissions to based on the section IDs that were put in on the course creation screen. So if you knew this, so you can see right there, the section IDs, section of that editing form right there, you can limit what students can actually view your course

based on the section IDs and it would talk to their ANGEL learning management system to find out which user IDs were in what courses and pull them into Plone using the plug of authentication sources. So really showing off a lot of the full power of Plone where there's not a lot of custom add-ons in here,

but there's a lot of basically guiding people through the process of managing subsites and managing their courses in an easy way. So I mentioned and already showed the lineage theme switching product. So in addition to theme switching, there's also a registry add-on product which will allow you to do things like set the Google Analytics on a per child site basis

or set the webmaster email address or set the, if you need kind of portal properties things, you now have the ability to do those on their own per site basis. And lineage.index and then the resonate in web unity one is something that 6vf has been developing and working on.

The resonate part will probably become an open source tool here very soon. I'm gonna show you a demo of what that's actually about. So again, kind of another quick mini use case of why lineage was so important to another university. This is actually the University of Notre Dame, their College of Engineering. They had a big problem.

Their internal websites for all the departments and all the research institutes were basically going off on their own and doing all their own little things which led to inconsistent branding. There was basically a platform proliferation of, some people had a custom Java, XML, CMS thing, some people were doing static HTML and some people didn't even bother getting a site

because it was just so complicated and they just had a LinkedIn profile. They had content, they wanted to be able to promote back and forth across the sites. It was really important in this environment for them to attract new students and new faculty so they needed a way to focus or spotlight and highlight people who were in the organization so they could sell the organization. Their biggest asset is the people who are their faculty

and their research and doing all the great things they do at Notre Dame. So allowing them to promote content and promote the faculty and staff who were involved in that content was really important and they were also having trouble with the fact that people couldn't find the canonical source of the content for, if they were searching Google for innovations that Notre Dame had been doing

or some engineering thing. They wanted to be able to come up higher in SEO, for example. So one of the other things that had happened in the past is when great news had come out, they would copy and paste content between these various systems. So not only were they now ending up with duplicate content inside of Google, but if a news item got stale

or if they had to make an edit or retract something, it got very difficult. So the whole management of that process became a bottleneck on the webmaster instead of being in the hands of the actual content creators themselves. So what I want to show in this demonstration here is basically you can log in as a faculty member.

They have faculty who can now create their own news items or what they actually do is they have their graduate students create the news items on their behalf. So you can see that you've got a news item here that's actually related to the faculty person inside the site. They've got two modes. You can actually request syndication or request to move. So right now I started off in my portfolio,

but I think this content item should actually live in the wireless institute's news area because it may be a little more important and they actually want to have it live in their area. So from the standard clone workflow tools, you can actually request a move or request syndication and then come in and select where you would like that content to go to. So each of those subsites, all these lineage sites,

each have target areas for news items or event items. I think they have seminars as well. So it's predetermined by the editors of those other sites where they want incoming news to land by designating this area as a target area for news. And when the faculty person requests the move, the staff person from that other area

now gets basically a reviewer notice using standard clone workflow tools, which is really nice, that I've got something to review, somebody wants to move a piece of content into my site and publish it. So you can see here's the standard news front page, but I've got the standard clone review list. I can come in as the reviewer for that site now

and actually review the item and either accept or reject the move of the content into my site. So it gives the control back to the site managers who are at each lineage sub-site level. Again, using standard clone workflow, you'll see that there's two workflow states here. You've got the published and then you've also got the syndication workflow

that are chained together and basically they work in tandem with one another. So as soon as you accept something, it actually automatically publishes it for you. So you're not having to do two things to get something published. But now you'll see that the news item is now moved into this lineage sub-site and lives here in the wireless institute.

In this case, yeah, we want to have a canonical version of that content. So we don't actually duplicate the content. In this case, we moved the content. You can see right here, actually the portfolio for Jane faculty no longer contains that content item. It's not about sharing.

No, not in this case. Now the next thing I'm gonna show you is actually about sharing. So in this case, if you actually want to have something shown in two different or three different locations like the canonical spot and then you want to have two locations like two other sites pointing to it, you can do a syndication request which will actually then give each site their own little kind of a teaser item

that they can put in their news listing that shows still that this item came from the wireless institute but it shows their title, their abstract. They can edit the abstract on that teaser if they wanted. So you can see in this case, I selected two organizations to syndicate this content into from the wireless institute. So that was done as the faculty member again.

So they have the controls since they own the content to choose where they want to put it but that's all dependent on how you set your workflows up. So it's all workflow dependent. It uses standard again. Standard, I can't stress enough that we really wanted to work with how Plumb is supposed to work workflow wise, roles and permissions wise. Everything here works that way. So you log in as a reviewer again

and then you can see that there's two items in the review list. One for each sub-site where we requested syndication. So if we go to one of them, we'll actually end up in that site. So in this case, we syndicated one of them to the main college of engineering site and here we have the same kind of, the workflow allows us to accept

or reject that syndication request. So in this case, we'll accept. What's neat about accepting the syndication here is that the news items are aware of where they came from. Each of these sites actually have vanity URLs, like their own URLs, separate from one another. The wireless institute's a separate URL. College of engineering's a separate URL.

But this second one here where we actually, you can see here we successfully, this is the electrical engineering department. They rejected the item. And when we actually look at the main site, I'll show that to you right here. You'll see that there's the front page news from the college of engineering and you'll see that it's coming from the wireless institute.

The URL of the item actually points to the wireless institute. So things like Google SEO following all kind of works really nicely in this case because this leads you down into a deeper area of the site but then you can highlight the content at like a higher level where you want people to enter, say at the engineering site. Now you can see that if we go back into the item,

it takes us into the wireless institute. Yeah, the teasers are what gets you. You could share more and that's again more of an implementation detail. The default implementation though is sharing the teaser of the items themselves.

The next thing I want to show is that the person who created the content does have still some control over the item and they also have a port that's showing you where the item is actually syndicated to and where it's been rejected or accepted as well. So that way you don't continually bug somebody at EE when maybe they didn't want your stuff, I don't know.

But you do see the full history is all documented in the history tab of where syndication requests were made, when they were accepted, whether they were rejected, who they were by. So you have a full audit trail of everything that's ever happened to the piece of content all the way along the whole process.

So you can see there was the request moves and then also the syndication request too. So you think for people who want to track where their content's going to and been, they get a nice little UI for all that, basically in the standard Plone stuff. So as I mentioned, you want to talk about performance. I did a quick comparison.

So what I did was I actually set up a Zope instance, well, two Zope instances. I set up one with 100 Plone sites in it and one with 100 lineage sites inside of one Plone site. So as you can probably imagine, the ZODB size, this is just adding in a Plone site and a folder inside of a Plone site.

Just with 100 Plone sites alone, the ZODB goes from basically zero to almost 140 megabytes in size. That's just Plone sites that are bare, nothing in them, no content in them, no nothing. That's just the tools that are required to basically run Plone. Where with lineage, it was nine megabytes,

which is basically a Plone site with 100 folders in it. The folders are very, very small. Actually, the process of adding these was considerably different too. The processing time for adding 100 Plone sites took a couple minutes. Where adding 100 folders took 10, 15 seconds. So you can see there's a big performance difference there in kind of size on disk and then in time to add them.

The memory usage wasn't actually that different, I was surprised, but this again was with just blank instances. I'm sure in real usage, when you've got 100 catalogs all indexing all 100 sites content versus one catalog indexing 100 folders worth of content,

you're probably gonna end up with some different numbers in these cases. But there's a minimal amount of memory saved by not doing that, hmm? No? Oh, for the object cache?

Right, because you're not knocking stuff out for the cache. Yeah, actually we've seen that in practice with some of the, we have some instances with have many, many Plone sites in there like that.

And you're right, the cache size is your limiting factor and sometimes just pulling all those tools into place will kick content objects out of the ZODB cache on the back end where if you only have one copy of all those tools, you have a better chance of things staying hot in the cache. So I agree with that. So one cool thing is that Lineage

is actually Plone 5 compatible. So with the 2.0 release and our dropping of the P4A subtyper stuff, we actually are able to do Lineage on Plone 5 quite nicely. So let me show you that real quick.

So I'm going to refresh the page. This is a Plone 5, this is the latest alpha that Eric was mentioning during the keynote. You can see it's got the standard content types. This is just a plain Jane vanilla out of the box Plone site, nothing special here.

But if I go into this child folder, which is still a regular folder, the action tools have moved into this little column over here and I can enable subcite. And once I do that, I get my site switcher, shows up again with my site, my child site and the navigation reroutes

and everything is nicely working in Plone 5. So if you actually go to the Plone software center on Plone.org, we were one of the first, I may still be the first one that's saying we're Plone 5 compatible, but we're testing against Plone 5 and excited about the release of Plone 5, want to make sure that our products are ready to go for Plone 5. We're actually getting ready to re-release

easy slide show the same way for Plone 5 as well because it needs to have p4a subtyper removed. So we can all celebrate and have cake or whatever we're gonna have tonight in honor of p4a subtyper dying in our products. Thank goodness. Yay, I'm so excited.

Okay, there we go. So lineage is up on PyPi and in Plone.org slash products slash collective dash lineage. If you want to check out those live sites, the liberal arts school there, that's not the eLearning one because you have to have a login

to really see anything on those sites. And then the Notre Dame College of Engineering, you can actually go to that one and see the child sites are all underneath departments or the institutes area. Each of those is just a lineage site. They roll out new ones each week, which is awesome because they're fully capable of building and deploying. I think they've got 30, 40 sites now underneath that

and they launched about a year and a half ago. So it's been very successful. Any questions? Yes, I'll repeat it.

The reason for that is just people may not be allowed to access another department, right? Yeah, so the question is with the moving and sharing workflows that were shown inside the lineage demos, the moving one was mostly because they do want to control

who can add content aware. The faculty are all given their own portfolio area inside the site and they actually, using borg.localrole, their advisees actually all have, because they're attached to that faculty member, gain access to their portfolio as well. So there's a lot of permissions and sharing things for collaboration going on for their publishing,

but they don't have access to the main EE site or the main wireless institute site. So when they produce something that they think is worthy of being published into one of those main sites, that's why they use the move functionality.

That's the resonate piece of the project here. So it is something we've built in-house that we're gonna be open sourcing to the rest of the community that'll allow for that back and forth sharing or multiple syndication to many sites. Yeah, so there's like a proxy object as part of that add-on

that has like a title and an abstract. And what's nice is if, I didn't show it in a demonstration, but the placeholder objects are still linked back to their canonical source content. And if the source content's title changed, for example, the placeholder's proxy object's title will change. If the content curator for the site

that had accepted the proxy object wants to customize that title or customize the abstract, they can. And then if the title updates, it won't update their title. So it gives them some control over, maybe they got news listings and they want shorter titles on that site. They can do that with the proxy objects and not worry about being overwritten. Or if they don't want to

and they wanna make sure they're always getting the latest updates, they get the latest updates from the content too. Yes, so each sub-site can actually designate one folder as their news target using the actions dropdown. Kinda like you do with a lineage sub-site

where it says enable sub-site. You would actually have an option, in addition to enable sub-site, you would have an option to enable news target, enable the events target. And any other sub-site can now use that as a potential target based on the organization name. You can only have one target per lineage site. That's just how they laid this one out. I mean, this is something you could,

yeah, with a destination. So yeah, the content type has a specific destination that you'll mark inside of your site. Yes, they can.

Yeah, so the question is, can each department and each research initiative have their own URLs and if yes. And so everything is aware of the URLs. We actually had to write some additional, we had to rework like absolute URL and the get URL catalog to make sure that they knew what the mapping of URL

to lineage child site was. Yeah, so there is a mapping of lineage child site to URL. And when they get indexed, they get indexed and can be brought back out so that they know the canonical URL for that content item, even though it's a proxy someplace else will point to the right URL.

Yes, well actually we're probably doing it in the registry. Right now it's actually in the build out, but we're gonna rework it before we release it and make it a control panel that the main clone site administrator can map the URLs to the child sites. I believe so.

I'd have to go look at the implementation, but we had to change stuff in the, will work. Yeah. Right. Yeah. Mm-hmm. Yep. Any other questions? Lots of questions.

Awesome. Eric? The last part, going to sites like what?

Correct. So the question was, would there be any questions or problems with adding users or when they authenticate and the domains are different because maybe the root domain

may be a completely different domain than say like sixjeb.com and nd.edu, even though they're in the same clone host. You do need to be aware of that. You can have users log in in the context of their domain name and they'll get a cookie with that URL on it, but then they won't be logged in to one of the other domains.

They'd have to relog in. For the Notre Dame site, what we did there was all these logins redirect back to engineering.nd.edu and they get a wildcard star.nd.edu cookie and so they've chosen that all their vanity URLs will be something.nd.edu, so engineering or electrical or WI or whatever they want,

but yeah, you can't get a cookie cross-domain like that for security-wise unless you want to do some kind of additional like single sign-on technology behind the scenes that will log you in as you go to different domains. Well, it wouldn't even be able to send the cookie

to the other domain, I think. You'd have to have some single sign-on mechanism that would then redirect them back logged in if you wanted to authenticate,

so if they came to a site where they weren't authenticated but they were authenticated to one of the other sites, they would have to get bounced back to the other site or to your central authentication and then bounced back with the correct like token so they could get automatically logged in. That's what we do.

That's what we do. That's what we do right now, but you could do it with different, completely different domain names if you took into account the fact you needed to do the authentication bit again and like re-log them in maybe with a token.

Yeah, you could. You could, but for most business users, they're concerned about like their URL on the web, so we didn't want to have two copies of the same content with different URLs,

one under one domain name and one under another because Google would potentially ding you. Yeah, just for logged in users. Yeah, that's possible. Yeah, other questions? It should. There's no dependencies in here. Actually, the tool itself has been localized.

Some of the people have contributed localizations for the menu actions, for example. So the actual menu items are all, yeah, you could, but right now I don't think

you'd have to set the language. There's no way to set the language currently for the others. Right, so the question is like could you have sub-sites with different language settings on them, one in English or one in Spanish

or one in German or whatever. But right now, there's no way to set that property, I don't believe, so that it would get the right locale sent back if you switched from one sub-site to another sub-site, but it's possible.

As the language selector, well, that sounds easier.

Oh, the EN, lots of ENs.

Like a sub-path inside it. Yeah, I mean, I can see this is an area where you can build an add-on just like the theming one

where you could select the language just as a content contributor or a content manager for that area is what I would do. But yeah, it sounds like there's lots of options for that, people have already solved it. Any questions? Yeah, Adam.

In that case, I believe we're just using content rules, the built-in clone content rules, so you can customize that to catch those different events

in the system. We may have written subscribers in the Notre Dame site specifically, but again, that would work for content rules or you could, like you said, you can just use a subscriber in your, we typically write like a policy package for any customer implementation, and inside that policy package, we may put in the workflows, the specific add-ons,

and then subscribers for notifications, things like that in the central place. Yeah, you can notify on any, there's actually, for Lineage there's, even though we got rid of Subtyper, which got rid of some of the subscribers that were in Lineage, we still have events we emit in Lineage when there's a child site created

or a child site removed or I think there's four events that are associated to child sites as well, so you can actually listen for child site creations and do other things on the side if you needed to.

Yeah, so the question is that dexterity already has a iNavigation root behavior that you can add on to your content type with it. That's a good question.

Because in the end, I think for Plone 5, I've got a couple, there's gonna be a 2.1 release coming up soon, so I was gonna add in a Lineage behavior in addition to the iNavigation root one because it seemed like there was a, I don't know how to stop my habit, there was a need for still having the Lineage tools involved there. So I don't know off the top of my head

because it's just same as if you'd done the enable. But we have some of these add-ons which look for the iChild marker interface that are on top of that, so ours will basically add that additional marker to your content type right away like you saw with the course content type. That one's a dexterity type shown in the site there.

So I think it's something to do with the events and the event mechanisms we're still using behind the scenes for the sites.

Yeah, we used Transmogrifier to do all the migration because we didn't want to deal with kind of an in-place migration, so we basically pulled all the content out of each individual site. At that point when we re-imported it into the new Plone site with all the Lineage child sites, we were able to split them up by department and rearrange the content as they saw fit.

So there was a bit of rearranging that went along with that migration, but I can't recommend Transmogrifier enough. It's such a great tool for moving content from even from Plone to Plone in this case. It works very well.

It's called on a sub-item and I'll do a catalog query. Will that automatically be restricted to the next navigation route? Not necessarily. Or will it be searching the entire catalog? No, it'll search the entire catalog as it develops. So the question is how will Lineage sites look to you as a developer if you're doing a catalog search, for example?

You would need to still specify which navigation route, yeah, as a restriction in the catalog. Because if you just search the catalog, you're gonna get everything. Across all the sites. But all the stock Plone portals are aware of navigation routes and will add them in automatically for you.

Oh, per site. Yeah. Right, I forgot what that one was about. So yeah, the Lineage index one adds an index into the catalog per site too, right? Yeah. I think I'm out of time

because the next thing starts in five minutes, which is the keynote. I don't wanna miss it. I wanna thank you all for coming. If you have any questions, come find me.