 So welcome to our session. We're going to be talking about the Al Jazeera Media Network's Drupal 8 platform. So glad to have you here. My name is Mai Ayri. I'm a software architect at Phase 2. And I worked as one of the leading developers on this platform. Hi, all. My name is Tian. I am a head of product at Al Jazeera Media Network. I mostly manage a lot of the digital initiatives outside of the broadcast. So welcome to our talk. We will be going over a lot of the kind of business forces driving our decision to switch CMS. Obviously, changing CMS is not a small and trivial project. And we spend a lot of time preparing and looking into what's needed for a long-term successful transition. Let's see. First, a quick overview of where we stand. I can barely see the background there. But we started out, obviously, as a live news network. We currently now have seven live broadcast channels and over 80 bureaus worldwide doing collecting reports. A few years back, we switched over to focus more on the digital aspects. And now we are at about a lot of monthly page views, a lot of monthly active users, over 50 digital products across a number of platforms, and many, many languages, as you can imagine. So over time, it became apparent that more and more digital platforms are going to be growing and popping up. And our budget isn't kind of scaling at the same rate as users and platforms are. So we needed to begin to figure out how to do more with less. And that really kind of kicked off an internal ADO initiative. And that is a lot of corporate speak for basically trying to figure out ways to optimize how we spend our investments on specific technology and how those technologies can support multiple processes that support a lot of the people doing the work of getting the news and writing the news and putting out the news. More specifically on the ADO tracks are probably nine major buckets. At the top there, you'll see more consumer-facing tracks from video and live streaming, mobility platforms, form social engagements, and then all of the analytics behind that to support video monitoring, asset management is obviously going to be a very large piece of that. And then behind the scenes, kind of more infrastructural pieces like our content management system and the service buses and APIs across multiple departments and systems to support that. And then there's this last one that we just call assessment services. Mostly it's kind of like an internal consulting group from time to time looks at how we're performing and how our investments are doing over time. But for this talk, it's mostly on the content management track. So because we grew up from a broadcast world, each channel basically had their own website. So we had an Arabic website, we had an English website, we at one point had an American website. And they were all custom-built systems, internal. They each had their own different workflows. And you can imagine that over time, we had to constantly add more and more things to all of these systems. So RSS support, responsive, mobile pages, different types of security. And each of them have their different workflows to support the news gathering and publishing process for each channel. So someone working in one property cannot easily switch over and help out on a different property to write a story or to put out a story or do some investigative piece because the tools were very, very different. And add to that, you have your overhead for your support, your product management, both for the consumer-facing side, which are you guys, and then the client-facing, which are our editorial teams and the different UI looks. And that is a kind of high-level overview of all the problems that we talked about. Add to this that if we wanted to pick up a new initiative, let's say I wanted to do AMP mobile pages, I would have to basically do that five different times or six different times for every single property I would have to add that functionality in. And obviously that doesn't scale as we look ahead. So what do you do to kind of start gathering all of these problems together and figuring out where to go from there? We looked at the end-to-end kind of content lifecycle from how we capture content all the way to how we publish it out and review it and see how it's performing. We did a ton of interviews internally. We talked to a lot of groups and figured out what their needs were. And came up with a fairly complex set of requirements. I think that requirement stock came out to somewhere in the range of, I don't know, 200-some-odd pages. It was not an easy afternoon read. But I think high-level takeaways are that we needed a very flexible platform to support the different types of workflows, highly configurable, control over all content streams, architecture accommodates different types of structure, content, and interface to support content editors in different languages. And that's kind of... When you take all those requirements into consideration, there aren't many products out in the market that can do all of that. Drupal became very quickly a short list for us. And when you really kind of dig down into what's really enterprise-ready, highly customizable, strong, multiple-language support, being able to have a multi-tenant, multi-site configuration on a single rollout platform, you run out of... You start crossing off the available options very quickly. So Drupal really was a very natural choice for us when looking at what was available. And really, Drupal ate because, I mean... I think we didn't want to go down with a large investment and then have to consider down the road to have to do a fairly significant site upgrade to Drupal 8. And really, I think... At the time that we started our investment initiative to kick off this project, Drupal 8 kind of showed a lot of maturity beyond what was available in Drupal 7. And so that's where we ended up. So I'm going to go over some of the key features of the platform. I'm going to talk about the lightning distribution, internationalization, asset and content lifecycle management, and then we're going to end with how we handled content distribution. So the lightning distribution was incredibly useful in expediting our platform implementation. So we used lightning as a springboard for developing because it came with a lot of the required functionality out of the box, which definitely cut down on time and cost of development for AlgeZera. So what is lightning? So lightning is a lightweight Drupal distribution. It's maintained by Acquia. It's intended to cover the kind of 20% of a typical use cases of a site. So it's serving as a starting point that you're building on top of. So these kind of things are like page layout, previewing your content before publishing it, content workflow and approvals, and managing assets. So if you look at the distributions that are out there in the ecosystem, so lightning is sitting somewhere in the middle of a framework type distribution like Panopoly, and a full kind of out-of-the-box product distribution like Berda's Thunder. So we chose lightning because it had these great baseline features that matched well with AlgeZera's requirements. So specifically these things were like using panelizer for page layouts, content workflow and media management. It had a reliable and transparent roadmap that's linked there, and they hit the milestones that they set out. So that's very important, right, for our planning of this project. Just a side note, the general lease for lightning was July 19th of this year in case you're interested. The maintainers are also quite active in the Drupal-Lightning IRC channel. Big thanks to John Kennedy, Adam Balsama, Adam Globus Honing right there for their support. So if you choose lightning, there are kind of like three approaches to building on top of this functionality. The approach we went with for this platform is the third one. So you're using a patch that is allowing an install profile to inherit from a parent profile. So now I'm going to talk about like the next, we're going to go into the next feature here, which is internationalization. And Tien, it's going to talk about the importance of this quite core requirement. Yeah, internationalization, super important, super, super important. We have 80 bureaus. We work in five different languages and supporting over 80, excuse me, 50 different digital products. And more specifically, I think if you think about internationalization, if you only consider things like Spanish, French, English, it's fine. But we have the added complexity of doing a right to left language like Arabic. And when you introduce that, it actually adds a lot of other UX impacts that you have to take into consideration. Where do you even place icons? The way that people naturally read dates or naturally read when they think about searching in their mind what their taxonomy is, because that's the language that they default to think of. So it adds quite a number of other considerations. And when we set out to do Drupal, we wanted to make sure that there was a very robust set of modules available for us to extend on. Mai will go into those details. So how many of you guys have known the pain of configuring a D7 multilingual site? Yeah, there are a lot of pain points here. So I'm just going to highlight a couple real quick here. So first being you probably needed to stitch together a lot of modules that may or may not have had the same kind of technical approach, and you're including some patches in the mix. The administration UI was kind of complicated. Their settings sprinkled everywhere. And there's kind of like a manual process for updating your locales. So if this was the past, right, like today's awesomeness brings a lot to the table with just core alone, thanks to all of the efforts of the D8 multilingual initiative and the whole idea, the concept of putting language first, right? So the needs for Al Jazeera's baseline platform was more focused on internationalization as opposed to content translation. So these requirements were covered by enabling and configuring two core modules, language and interface translation. So there are a ton of features from D8MI. I'm just going to highlight a few here. The first being language handling, right? Which allows us to natively install in 94 languages. Very important for Al Jazeera's platform because they needed to support, as Tien was saying, non-English language as a system default language, as well as that right to left orientation. So the interface translation module also kind of revamps that whole administration experience. So there's less intuitive clicks, unintuitive clicks for editing your string overrides and the locale updates are using the same process as the update module for handling updates. Other cool features include field-level configurability for your content and views is integrated. So that's super awesome, right? So what's really cool is that all your configuration is translatable. So if you have a foreign language installed, you can create configuration in that language. The same thing applies, like if you know you're adding additional languages later. So as Kristin pulls quote illustrates, we have a significant reduction in the complexity of supporting multilingual concerns in D8. So there's two other modules that I didn't mention that are coming from core, mostly because they're talking about this translation piece versus configuration translation. So that's allowing you to... allowing blocks and menus and views to be translatable. So it's kind of similar to the internationalization module in D7. And the other is content translation. So making things like nodes or comments, taxonomy terms, translatable. So bringing in some of that functionality that was existing in the entity translation module in D7. So I'm definitely posting these slides to the session node and also treating them out so you can explore more of these resources. I highly recommend it. Big thanks to over 1200 contributors who have gotten us this far. It's amazing. So the next section that we're going to go into is media management. So one of the core requirements was this internationalization piece, right? We're talking about a media company. So asset management is super crucial. So Tien is going to speak to that for a second. Yeah. It's kind of what we do, media management. And I need to review my notes because there's a lot there. Being able to kind of manage media in a not crazy fashion is really important to maintaining our sanity for all of our editors. We wanted to make sure that we had a single hub where all of this content from various networks can get into and make sure that that has access for all of our editors. It also streamlines a lot of things like rights management, clearance, reusability. It also helps us optimize storage. And more importantly than that, it's just critical for making sure that the left hand knows what the right hand is doing. If somebody's working on a particular story, if somebody's working on a, I don't know, a breaking news piece, the other editors should know that this is happening. And sometimes the reverse is important as well, which is if you're working on a very sensitive investigative piece, you don't want the rest of the network to know that that's happening and making sure that you have the right kind of barriers around your work project is very, very important. So I'm going to pass that over to Mai, who's actually going to talk about a bunch of Drupal-specific pieces like file entity, media entity, entity browsers, and entity embeds, which I know nothing of. So this section might be a little intense. I kind of wanted to go into a little bit detail here because we're dealing with configuration entities a little bit in this piece, so don't worry. It's going to be fine if you weren't prepared for this. But first, I kind of wanted to talk about some background information on media management in D7, since it's going to be relevant here. So a lot of you are familiar probably with the media module in D7, seeing a lot of head nodding. Cool. So the goal of this whole effort was to kind of deal with the chaos of D6 media management. It was bringing to the table this, like, two-tiered API. Maybe you also use Skald or Asset Media Box, but I'm going to focus on media module here for a bit because I want to talk about the file entity piece. So we've got this two-tiered API, a resource manager that's creating this unified media storage and this extensible browser for editors. So, you know, this is kind of dealing with, you know, you're managing your files, your assets, regardless of whether you're uploading them locally or they're a reference to a remote file like a YouTube video. So if we take a look at this stack here from D7, we've got Drupal 7 core is bringing this file entity, right? And the file entity is extending that API to make them fieldable and provide view modes. And then on top, like, not on top, but like bringing those four layers underneath is the media module and it's providing that extensible media browser. It's integrating views. It's bringing WYSIWYG integration in here. And the reason why I'm talking about this stack is because the file entity module exists in DA. And there's also this media entity module. And Lightning is using media entity, by the way. But, you know, these are basically two different solutions for media storage in Contrib and I wanted to cover this because it took me a little bit to kind of understand the difference here. So I'm going to just cover this real quick. So these are two different entities that exist. Both of these storage solutions work with the other components in the media ecosystem. So like the whole idea is to have these decoupled components as opposed to a monolithic solution. So both of them generally work okay with entity browser, which I'll talk about more in detail in a second, an entity in bed. And so yeah, what is file entity? So just like 7, we're extending from the cores file entity. And it's basically kind of like treating everything like a file. At high level, media entity is bringing a new entity type called media. And it's not necessarily assuming that every asset they're adding is a file. Lightning media is using the media entity. So it comes with support. This media feature comes with support for documents, images, Instagram and beds, tweet and beds and also video. So our stack look like this. We've got our feature module kind of extending from what the distribution is offering. And then as I said before, it's got a dependency on media entity and it's bringing these different bundles into the picture. We also had a requirement for audio, so that's why we brought that in and these other kind of video dependencies. So let's take an example of like, what is this media bundle? Let's explore. So I'm going to walk through the configuration of a tweet media bundle that's provided by Lightning, just as an example. So first off, where is it? It's under structure media bundles. You can have, you know, you see all your bundles available. We're going to look at the tweet one. And then we can see the type provider is Twitter and we've got this field here, tweet. So what is this field? We can see that this is just a plain long text field and it's going to be containing the tweet embed code. And then if we check out the manage display tab, we can see the tweet field is using this Twitter embed format that's provided by the media entity Twitter module. So we just talked about the setup of this example bundle here. Let's talk about how we would use it. So we can browse or add these kind of media assets to our system using something like entity browser and we can kind of connect this entity browser so that we can embed them, you know, in a rich text field by using something like entity embed. So first off, let's unpack entity browser. So this is a flexible and generic browser and selection tool for entities. Note I'm saying entity, so this is not media specific. So remember in the media module you have the media browser so it's kind of like that but it's for generic entities. Whereas it's under admin content authoring entity browser. You can create multiple entity browsers. So we're going to walk through light names, media browser setup. So when you create and edit an entity browser, you're kind of taken through this multi-step configuration form. It's really intense so I'm going to kind of go through it. So first off, an entity browser is a configuration entity. It's bringing in all these different plugins that we're going to explore together. And the first plugin is this browser display. This is controlling how the browser is appearing to the editor. So you can see lightning media browser is using the iframe but other options are modal, standalone form. So, you know, some example use cases here if you're rolling out your own entity browser. Maybe your WYSIWYG button, like your entity embed button, might want to use a modal display. Or you could use iframe. But, you know, here's some examples. If you have a field widget, you could use an iframe display. If you have a system that's pushing content to a third-party system, a standalone form might be useful. Next, we've got this entity selector widget. So this is controlling how the editor is accessing these different ways to kind of select or reference their entities. So some options are tab, drop-down, buttons. And then you have the option to configure the entity selection display. So this is handling the display and logic around currently selected entities. Lightning is keeping it simple. They don't have a selection display set. However, if you had a more complicated workflow for editors where they need to, like, create a bunch of entities, reference some entities, kind of, like, have that last step where they're reviewing everything that they've selected and want to reference, then you might want to configure this selection display plugin. So the next step in this form is just some additional configuration for your browser display plugin. In this case, since no selection display was set for the entity selection display, we don't have anything to configure here for the widget selector or the selection display. And now the last screen is the fun part, the browser widget. So these are different ways you can create or reference your entities. So say you want to kind of browse what is existing on the system and then select a bunch of them. Maybe you want to use a view for that. Say you're uploading images to the system, right? A file upload widget. There's also other options like an inline entity form. Lightning media brings, I'm sorry, Lightning brings a custom embed code widget here that you see in the bottom. And it's got this kind of logic in the background that allows an editor to drop in a tweet embed code, Instagram embed code, and there's logic in the background to figure out which media bundle to assign it to. Okay, so after you set up your entity browser, you might want to connect it to a nice little WYSIWYG button so that you can embed these entities in your WYSIWYG editor. So entity embed is the module you would look at. So where is it? Configuration, content authoring, and text editor embed buttons. When you add a new entity embed button, you're going to select the entity type. If you give it a name. And once you select the entity type, it's probably an embed type. Sorry, you're going to select entity. You can select which type of entity. Here I'm selecting file, given options for the display plugins. Here is where you're connecting the entity browser. And then here I'm just showing how to connect it to your text format. So we're going to add it to the basic HTML text format. Dragging this E. This is just the initial setup. If you add an icon, it will show an icon here. You're going to drag it to your active toolbar. And then, yeah, add some trouble there. Then you're going to make sure that display embedded entities filter is checked. And then also make sure that you're allowing those tags for the entity embed. So this is kind of what Lightning looks like out of the box. So we've got those tabs. I'm just going through, because we went through so much configuration, we kind of want to see it in action, right? Here are my cats. They're lovely. Pancake and ketchup. It's a pretty streamlined kind of setup. Here is the embed code piece that I was talking about. So I'm grabbing a little tween embed code. What's nice is this save to my media library piece. And then we can see the results, right? As it's rendered. So another kind of requirement of the platform was to support video. And I said that Lightning comes with support for video. But this was more like YouTube videos and things like that. We had a specific requirement for BrightCode videos. So we use the BrightCode video connect module. So if you think about like an editor's workflow here. So Drupal is serving as the front end for BrightCodes API. So an editor would go in, upload their video in Drupal, right? And then eventually it would be synced back to BrightCode. You can also add additional metadata or moderation states and have this synced back to BrightCode. So I just want to give a shout out to Provenx and Kristoff because we had some great conversations with them when we were looking at this BrightCode module. Specifically, I want to point out this really cool tutorial that kind of steps you through all of the configuration. You need to like know about to use this. So now we're going to go to our next section here about editorial workflow. So I'm going to hand it off to Tien who's going to turn on his mic. And then he's going to tell you all about the business. Yeah, editorial workflow doesn't really get more important to this. Don't pay attention to the other two pieces. This is really important. We're kind of in the business of telling stories and I mentioned that we have editors working in various different products and each team kind of like a developer. Today I'm working with team A, tomorrow I'm working with team B and they all have their different kind of flows and processes to get a story out. So we really need a system that can have a large degree of flexibility where we can configure different workflows and kind of reproduce steps and just give the minimum number of steps necessary to get a story out correctly. But we also need to add in the right amount of rigidness so that their senior editors can fact check and make sure that we don't get anything wrong and if we do make a mistake and publish something out, we can retract it quickly. All of that is to say that none of this should stand in the way of allowing our editors to tell the story properly and making sure that our audiences get the news. So really kind of a do or die type of vertical, I would say. How do we address these requirements in the time frame that we had? Once again, we're leveraging the baseline functionality coming from lightning, specifically the lightning workflow feature. And this is what this stack kind of looks like. Again, we have our custom feature module that's extending what lightning workflow is bringing to the table which has a dependency on workbench moderation. So lightning comes with draft, needs review, publish, and archive out of the box. We had additional kind of transitions that needed to be added as well as another state called recalled. So this is just a diagram illustrating Al Jazeera content moderation states. We also implemented a tab that displays a history of the moderation states for a given note. So the idea behind this was to allow editors to easily see approvals and rejections of content before publishing it. And this is a view that is using a contextual filter of the revision ID to display this information. We also determined that given the timeline and scope, content moderation and user permissions were two key areas that would definitely benefit from some automated testing since it's kind of like a tedious experience for quality assurance as we are adding more and more functionality to the system. So luckily lightning comes with a whole host of BEAT tests. So for those of you who aren't familiar with what BEAT is, BEAT is a behavioral driven automated testing framework. So in English, you're writing your testing steps in plain English and you would kind of describe these steps in a similar way to how you would test it manually. And then there's logic and PHP that's supporting these steps using this BEAT framework. Okay, so now we're going to talk about the final component of the platform, content distribution. To start, Tien is going to cover the goals of this portion. Yeah, content distribution. Everything we invested in earlier doesn't mean Jack if we can't get it out the door. So super duper important to us. Really, this is kind of making sure that we can get the content, like I said, out the door and reaching our customers and then better understanding how it's doing and how it's performing and then customizing that down the road. Your typical questions that are going to come up here are what was published, when was it published, where was it published to, which platforms did they include, who did it, how did it perform, and how do we get better next time. It really is kind of that last three buckets there that distribute, engage, and review in our content lifecycle. And we'll touch up on, I think Mai is going to touch up on some previously talked about topics like the content hub, which plays another important role here, making sure that depending on which property you publish out on, you can still access the same content hub and reference the same content and make sure that any changes you make on one gets propagated out to the other places. So Mai? Okay. So Aljazeera required multiple CMSs to connect to a basic content hub as part of this platform. Additionally, in order to support kind of this editor collaboration and visibility that Tien was just talking about, we also developed an editor discovery dashboard, which was set up on each of these CMS instances. So this was kind of mentioned earlier in the media discussion, but I'm going to go into depth, more into depth in this piece here. So, you know, on a CMS, we've got a few blocks here. First of all, as an editor, I should see what recent content has been added to the instance that I'm logged into. I should also be able to see my recent content that's on the instance that I've been logged into. And additionally, I need to see the recent content that's been pushed to this content repository. And so, you know, these are the three blocks. This is on a panel page, so using a panelizer. And let me go into the content repository piece here. So we have CMS instances pushing content on content creation, edit, deletion to this repository instance. And then, you know, we have that custom block that's showing the recent content on the repository on these connected CMS instances. So how did that come about? So, you know, this custom block is basically leveraging CoreS API. And we've got, on the repository, a view that's using the REST export. And we, like, added a little, we altered a little bit to include this basic off so we could kind of protect that connection. So content repository in these connected instances, how do we kind of, like, manage this? So we're using deploy, multi-version, replication, and relaxed web services to kind of push the content from the target to the source. So what is deploy? So deploy has been rewritten from its D7 version to just kind of provide this UI on top of Workspace and Replication Modules, which I'll talk about in a second. But this UI, if you're thinking about it, is, like, allowing you to manage this content deployment between Workspaces on a single site and AlgaeZero's case. We're doing a cross-site deployment. So from WorkSite, from CMSA to the content repository. And we had to, you know, add some additional alter, implement alter hooks so that we could, like, do this on Node, Update, and Delete, et cetera. That part doesn't come out of deploy, like, out of the box. So let me give you a brief overview of the pieces of the deploy suite that I mentioned on that, like, icon slide. So first off, we have multi-version. So this module is doing three things. It's adding revision support to all your content entities. It's introducing this concept of parent revisions so you can kind of create these different branches of content. And then it's tracking the conflicts in your revision tree so, like, when two revisions are sharing the same parent. So you're thinking about, like, get revision kind of history. It's kind of, like, in that kind of mindset. So on top of multi-version, we've got the replication module. So this is a lightweight module that's using that, it's reading this revision information that's, like, being produced by multi-version. And it's using that to determine which revisions are missing from, you know, a given location, and it's allowing you to, like, replicate this content between your source and your target. So, all right, so in the real world, like a real-world example, so a writer who is working on multiple properties, like a news site, an opinion site, you know, maybe they're, you know, doing humans rights page. This kind of architecture and the setup and including the relaxed kind of stuff that I'm going to talk about in the next slide. It means that they can kind of shift in working in different teams but still be able to access their full portfolio of work wherever whichever instance they're logging into. So then we've got this concept of workspace. This is, you know, allowing you to have content staging and full site previews. So we're using this. We're just having single workspaces on Algebra Zero's platform. And we're using relaxed web services to serve the bridge between the connected instances. So relaxed web services is bringing, like, a more extensive REST API. So it's supporting UUIDs, translations, file attachments, parent revisions. So it's, you know, allowing that connection. So, you know, why do we choose deploy? So, no. This is another kind of great baseline solution that we needed to build on top of. We had the ability to restore deleted content. It gave us the ability to kind of, like, get ready to, you know, push changes from these connected CMS instances to the target content repository. And very interestingly, like, a lot of these pieces are, you know, being considered for moving into core as part of this workflow initiative. Also, things like multi-version, replication in the workspace are also being planned for inclusion in a future Lightning release to support more content, you know, previews, staging, kind of archiving your site's dates. So that's kind of interesting as well, I think. So to just recap here, so we went through all the stacks. So we've got CMSA, we've got this multi-version, working with replication, dealing with a single workspace, relaxed web services, providing that bridge, and we've got a similar stack on the content repository. So I mentioned earlier about, like, this workflow initiative. So what is... So the idea is to improve content workflow and preview and content staging by kind of extending the entity API, kind of taking these pieces from these different modules, also like workbench moderation. The roadmap is pretty humongous. It is quite an ambitious initiative. They've done a ton of work already on it. One thing that, you know, when I went to the workflow initiative session yesterday, I saw that they are creating this module called content moderation as an experimental module as part of CORE. Kind of... First of all, it rewrote a little bit of the workbench moderation, so I was allowing it to be uninstallable and folding in these kind of revisioning pieces. So that's pretty interesting and cool. So there's some more information here. When you look at the initiative, you will be like, wow, there are so many phases hitting all the way to 8.5 as a target. But I highly encourage you to check out Dree's blog post, kind of talking about why we're thinking about this. This is an extremely hard problem to deal with, especially as part of folding into CORE is very difficult when you get into this whole revisioning business. But anyway, check these resources out if you're interested. And yeah. So now we're just going to kind of start wrapping up here. And Tian is going to talk about some of the platform features that are planned for future iterations. Thank you. Yeah, a lot to go through. I think each of these topics that we've covered, even that this is a one-star discussion, we kind of flew through a lot of content. And I think each of them deserve a full deep dive conversation in the future. But looking ahead, we still have to migrate our existing content from all of our CMSs over to this new Drupal platform that we're building with Phase 2. So there will be a need for a taxonomy manager to change the structured data that's stored in one database into Drupal-style content. We still have to do the data migration aspects of it. There are going to be future mobile-specific features that we haven't included as this baseline development. And we haven't even touched up on personalization yet, which is it's a very, very deep rabbit hole. So there's that. And so far, it's been very productive working with Phase 2. I think what we've developed so far is definitely in the right direction. It is a very, very large project, as you can imagine. And we're still learning a lot as we go along. Things like working on an open-source platform, referring to the community modules list. We're working on Docker. Drupal-8 is new, I think, just in general. And then not to mention all of the other performance issues and scalability issues that we're going to hit once we start rolling it out live. Yeah, and just some... Yeah, I'm going to add to this. Just like some other kind of perspectives, lessons learned pieces. So one of the things that I think, coming from a developer side, one of the things that we did with this project is we had a lot of open communication. We had these things called sprint reviews. And the sprint reviews also had the demo. And it's okay. I just want to, when I was first thinking about this, I was like, oh my God, I got to demo this. I'm not ready. I got to say it wasn't pushed to the dev instances or whatever. I had to demo it locally. As a developer, you're taking a moment to stop and make sure you're set up for the demo. But one of the things that I learned from this experience is that really was quite key because we were able to get immediate feedback and everybody was on the same page. Nobody's having different assumptions on what's being worked on. We could kind of surface any kind of doubts or things that we're thinking about for a particular feature and talk through it. So I think that was really, really important as part of this project process. Even though it's like anxiety producing to kind of demo. And another thing, as you're developing these custom modules, yes, we have these annotations and all these comments everywhere. But I think it's also really key and I've seen this for other projects that I've been working on to have a read me file in your custom module to kind of give the next developer who's going to come along the gist so that they don't have to read through everything. And also highlight anything that's like, okay, this is the reason why and why this is being done custom and what are some key points, like we're creating this plugin and it's doing this. So I feel like adding that additional documentation as part of handoff is really key. I appreciate it as a developer and I'm sure you appreciate it. When you look at contrib modules that have that extra information in the read me, you're like, oh, thank God. So that's just something that I wanted to mention. So, you know, before we go to questions, I just wanted to highlight that there are these contributions sprints happening all day, but also especially on Friday so you can make it. There's the first time sprinter workshop, there's mentored core sprints, and then general sprints for whatever kind of a topic that you're interested in, but definitely encourage you to get involved. And, you know, please evaluate this session. Your honest feedback is most, most appreciated and valued. So I beg, I ask that you, you know, review our session. So I guess, you know, we have about 10 minutes or so. I guess we'll open it up for some Q&A. And please use the mic. It's in the middle. Thank you. What are your plans for front page editing, article sorting, and stuff like that? Front page editing. Sure. What are your plans? Where I come from in Norway, the, you know, using a whistle-wiggish front page editing tool is critical, you know. Sorry, so I don't think we wanted so much to whistle-wiggish. I mean, there are specific templates that are outlined for our home page that you want to promote, over time you want to promote muscle memory of where certain menu options are going to be and where certain aspects are, you know, top stories are always going to be on the right side or on the left side or whatever that is, right? So we don't want to make major layout changes. That being said, there are, you know, top-level templates that we use. So if it's a breaking news day, there are certain, there's a very specific layout for, if a plane got shot down, that's terrible. But whatever it is, we do use those major type of templates so that you can have, let's say, a lead story and then maybe two or three analysis pieces around that. Or if it's just a regular news day, you would have maybe, you would weight it more equally along with some multimedia content. Does that answer your question? Yeah, sure. So it means you won't really be able to, like, edit a node title on the front page or, like, remove the teaser and make the image bigger, stuff like that. It's a fine balance between, you know, you don't want the editor to kind of run away with the general layout of the site and the general look and feel of the site, right? We have designers that spend a lot of time in UX folks and doing user research to figure out what kind of fonts work, where certain elements need to lie on the page to get the right type of attention. So we don't want to prevent the editor to make important changes as needed, but at the same time, it has to have an overall structure in terms of conveying information over time. Are you asking about edit in place? Is that what you're asking about on the front page? Not really. With our media customers, we have built an Angular application on top of Drupal at Handon, so that so you can drag in articles and sort of stuff like that. And what we see is that all, at least in Scandinavia, all the big news sites, they allow for, you know, making the promos for articles very different from the actual articles. So you change the titles, you change the images, you tweak the font sizes, and tweak the layouts and stuff like that. So I guess what I'm saying is if you came to a news site page and every day it looked completely different, it would be an awful user experience. And we have to balance that with, I think, highlighting important pieces that do come out and making sure that the platform has flexibility to do that. So I think it is a core requirement of that capability, but we certainly don't want editors to just willy-nilly go in and start changing things on the fly. Thank you. Yeah. Hello. My question is about the distribution. Since you're lightning, say if you want to put your own stuff on top of it, how did you fork lightning or use all of the box and... So, let me go back to the slide here. Sorry. I came a little bit late. I might have missed something. Yeah. No problem. Try to find the slides. I think these are all recorded as well. Sorry. It's many slides back. So there are three approaches for how you would kind of build on top of it. And I'm trying to find it. Here we go. So one would be to build on top of it like you would for a product distribution. Another would be to use the extend.yaml file. And, you know, these slides will be posted. So you can access these links. But there's an example kind of implementation where you kind of use the yaml file to say, okay, I want these kind of enabled. The method that we used for this platform was using this patch that allows us to inherit from a base, like a parent profile. And is your code like open source? Is it public or is it not really? No. And say if they put new functionalities on the lightning, something that you know once. Sorry. I just want to say, generally speaking, no. But where it makes sense to contribute back to the community, we are actively looking into places to open source it. Yeah. But this particular distribution. I think my question is more like to see your setup. What's that? To see how you put everything together. Of course, I guess no. So say if they put new functionalities on the lightning that you don't want. How do you do that? Because you're going to inherit all that stuff, right? Yeah. So I mean, if you're creating your own, like, install profile, you can, like, control what's enabled. So you can, like... I mean, even if you're, like, kind of spinning, lightening up, like, on simply test me, right? If you're going through the install screen, you can see that these things like lightning media or lightning workflow, those features are optional to install. So you can have the same approach in your install profile setup. Maybe I'm missing something here. So you have your own install profile? Yeah. So we created, right? Install profile. Based on lightning. That is using... So in, for example, like open atrium, right? Like in D7. We are using, like, for projects that are using that, we're using a similar kind of patch. It was for seven to kind of say, like, okay, I want open atrium to be my, kind of, like parent-based profile. But then I want to kind of extend what's coming out from that. And I want to build on top of that. So in my install profile, I'm choosing which modules to be enabled when it's installed. And then, you know, in seven, you know, you have these other things, like feature overrides and things like that. But, like, here, you know, we added, you know, our own feature modules that are like, yeah, I have a dependency on lightning media feature, for example. So it's all those pieces kind of stitched together. But yeah, it's in here in install profile. Nice things. Yeah. Hello, my name is André Bonmayer. I'm currently working for Burda. And we are having a similar stack using Thunder. And I got a particular question regarding what tools you use. Are you currently moving everything on top of Drupal, or are you still implementing and using third parties or third-party softwares, like media managing, solution, media distribution stuff in that direction for video images, for videos, for instance? Was it all in Drupal? So the video, for example, like, is, like, these videos are break-out videos, right? So we're using a module to, the break-out video connect module to provide that interface. So yeah, that part, like the media part is being handled in Drupal. Okay. Do you, is it live already? Are you using it, or are you still in the rollout process? Still in development. Okay. Yeah. How long are you working on this? Oh, a long time. I don't want to say, but it's... Oh, the planning phase? Yeah, I mean, there's a lot there. Like I said, we started out with something like a 200-page document of just high-level requirements. So it was, there's a lot to go through. Okay. And one last question regarding the Content Hub. Is it, like, every instance of your page has all the content it displayed completely in it, including all the revisions and all the media assets, or is it still saved in the Content Hub in just reference to it, also for the distribution part? Like, is an image distributed to an instance and then displayed there, and do you have cache and varnish and whatever there goes on that stuff, or is it in the Content Hub in reference to there? We don't have a caching layer set up right now because it's a baseline platform that's currently being built on and sites are in progress for building on top of that. So the revisioning piece... All right, so it's not like we're having multiple copies of snapshots of each node, right? So it's just like the changes that have happened for each revision. Those are being pushed and stored like the revision kind of tree and all the stuff, the UUID. Business is being pushed to the Content Repository. That includes, like, well, there's no translations here, but that includes the media piece as well, media references. Okay, cool. Thanks. Hello. My question is about the channel pages. Channel pages. Yes, channel pages. The first part of the question will be of how much automation is important to you. Of course, assume that most part of the channel pages are generated automatically. But about the manual part, how important was it to you to improve the use experience for the editors so they could place stories on specific positions? Do you have some specific drag-and-drop in place or live preview in place for those channel pages? Yeah, I mean, we do want to do live preview and... Sorry, repeat the first part because I'm not familiar with what the scope of a child page is in Drupal World. So a channel page to me is, well, the landing page, obviously, or politics, or, I don't know, sports. Those are channel pages. Channel pages, yes, channel pages. Okay. And how much of those are automated and assume some part is manual? Or decision, what story goes where is partly done manually? So as a general workflow kind of principle, we want to allow manual override for everything but automate the actual placement of things. So if we, say, just put the latest ones or the highest ranked ones or the most popular ones, it'll automatically move them into place. But at any point, a user can come by and shift that out and say, I want to give more precedence to a different story. Does that answer your question? Yes. And how much effort did you put into improving the user experience for users who do that by live preview or drag and drop or features like this? Paralysation. So some people can work on upper part of a channel page and some people in the lower part. Very rarely will you see that...