 All right, Rick is ready to go, and so am I. So let's get started. Good morning or good afternoon depending on where you are. My name is Rolando Scott. I am currently a development manager at Teori, which is a DC Drupal-based creative firm. I manage a backend team of a credible and awesome devs. I've been a Drupal enthusiast since Drupal 6, more than a decade ago. So like I mentioned before, I'm currently based in San Jose, Costa Rica, and I'm also a volunteer for firefighting. So I fight Drupal fires by day and real fires by night, sometimes the other way around. This session is directed to developers, project managers, anyone who interacts with the admin interface of Drupal. And while most of what I'm saying will definitely apply to Drupal 9, it is focused to Drupal 9. So word of caution there, right? So what brings us here today? What is configuration management and why does it cause a lot of frustration to a lot of folks out there? I'm tempted to use that voice that always comes on on these silly infomercials. You guys know the one, right? It's do you have constant issues changing settings on the production side? Do you or changes suddenly disappear when somebody else connects code? Is there even any hope for me? Well, I've got good news for you. In reality, this guy seems like someone who's trying to manually synchronize three different environments by recreating each single change. It's either that or someone who just learned how to use their arms recently. But it can feel like that. Having a site that has different instances that aren't connected in any way is hard to maintain. Configuration management is what helps us keep them in sync. So let's start defining what it is. Configuration is the collection of admin settings that determine how the site functions as opposed to the content of the site. Configuration will typically include things such as site name, the content types, fields, taxonomy, vocabulary, views, and so on. We'll get into what exactly is configuration in a minute. So in practice, this means that we can import an expert configuration of a site into another site and have a clone of how that site works without having to copy the database, precinct the content in any way, right? We can, with confidence, test new features on a development environment and know that if it works there, it works on the long side, right? And again, since the settings get saved to files, we can add them to our version. That means we can have a comprehensive history of what change was made by whom and when. Basically, we know who to blame when the site is. Hopefully it doesn't, but yeah, it's all part of it. One of the most common questions and frustrations that derive from the fact is that we don't always know or understand what constitutes a configuration change and what doesn't, right? So let's start with the easiness. Any content type and fields is configuration change. Any change made in the configuration screen of the admin, which can vary depending on the modules and functionality that you have on your site. Any web form, any menu, views, display modes, all of that is configuration change. Some easy ones that aren't are any content, right? That's added through a content type. Any block page, any home page, any basic page, et cetera. Any web form submission is not configuration. Any file, any type of media, and the menu needs, right? So these are two are very simple, right? To understand which one is a configuration, which ones aren't. But there are some that are iffy, right? For example, tixonomy vocabulary are, but the tixonomy terms are not. So this sometimes creates issues on sites that use tixonomy terms as structural building blocks instead of just ways to categorize content. So for example, let's say you have a product, right? And the product has colors, red, green, and blue. And then that is the tixonomy vocabulary. You can filter, you can filter through that color. You can add that product and select green, red, and blue, perfectly fine. You don't have an issue. But if you create your site in a way where, I don't know, red is a whole section of the site, right? And that displays content underneath and that has custom functionality assigned to it. When you're importing the configuration, if that color doesn't exist already, right? It may become an issue because then your other custom modules are kind of waiting or looking for that term and it doesn't exist, right? So that's one of the parts where it gets iffy. And the other one, like Rick has mentioned right now, and it is a very common one. I think we've all, at some moment or another, had seen this error is that content blocks, the content setting is configuration, but the content block isn't, right? So what that means is if I, on my local, create a block, right? Create a custom block and I add some text in it and I place it on the header, right? And I export configuration. When I'm importing a configuration to the destination site, Frupa's gonna say, oh, okay, great. There is a block that needs to go into the header of the site. The problem is I don't have it because the content of the block isn't there, right? I don't have that block. I know there's a block that needs to go in there. I just don't have that block. So what it does, it throws this error. And like Eric just says, it's sometimes not very straightforward to understand why that's happening. Why wouldn't I import a block? Why doesn't it just appear, right? Like is it configuration? Is it content? So there's ways to mitigate that, which we'll talk in a little bit. As a little history, back in the good old days, and I say that kind of sarcastically because Frupa has definitely gotten better with each version change, we used to use a module called features to export bundles of changes from one instance to another. So while this was effective, it had a bunch of downsides. First of all, it wasn't enforced, right? So you could use it if you wanted, but another developer could come in and not use it with Scottish issues, right? Secondly, it wasn't supposed to be used site one. So you could only do it in small bundles of configuration without it getting too messy and hard to manage. And the most important downside is that it wasn't made for this purpose. Features was great for creating bundles of configuration to replicate on another site. For example, I created a blog, I added some fields, I added some display modes, I can add an image, I can add a date, I can do all that. And I say, wow, this is really good. I don't wanna have to do this on every single site. Let me bundle this up as a feature and import that into another site. And that was it, that was the one-time thing, right? On the other site, another developer could come in and add more features to change anything that they wanted to. So it was just a one-time thing. So that would obviously cause issues when trying to maintain sites synced up. Thankfully, configuration management became a thing in good way. So we keep talking about configuration files, but let's dive deeper in what's in one of those files. What exactly is it that gets exported? A configuration file is a YAML file, right? The YAML file is a human readable data serialization language. Every single YAML file starts with a universal unique identifier at the top. It basically means that you can create a, let's say it's a content type of a configuration, one way. And it's exactly the same way as some, in another site. It's created exactly the same way in another site. It still doesn't have the unique ID. So Drupal knows that this file specifically is for my site and not for any other site. It's specifically for my site, even if certain parts or all of it is exactly the same as another site, right? Inside the files, there's IDs, language options, statuses, labels, dependencies, which is always important, right? If I need something to be able to run this part of the site, what is it exactly that I need? And Drupal needs to figure out that both things are installed and working correctly. It's basically, in the short term, it's basically everything that Drupal needs to run in that specific configuration or section of the site. When you install a new module, these modules bring additional configuration files to your site. So the bigger your site, the more functionality it has, the more configuration files your site has. During the installation, the site grabs those configuration files as building blocks for that section. But when you export that configuration, the config files become part of your site. So the configuration is owned by the site and not by the new modules. All right, so now we know what the configuration files are and what's in them and what changes on the site can be seen as configuration. Let's learn how to work with them, right? The first crucial thing we need to understand is that when creating a configuration change on the site, that does not automatically create a configuration file. You need to manually force the site to do this. You need to tell Drupal, hey, I need the configuration, the current configuration in files. This is important to note because issues arise when your team doesn't have a workflow in place. Although workflows can vary depending on the team and the project, there are definitely two main approaches to using configuration management, right? So the first one is using the Drupal admin user interface, right? The Drupal configuration management unit and user interface has three main sections. The first section is the overview page. It can tell you if all your configuration is in sync with what is staged in the files. Like I just mentioned, creating a setting on the site does not automatically create any configuration file. When that happens, we call that the configuration is not in sync. The overview page will tell you exactly what section isn't in sync and can even tell you the difference between what's live on the site and what's staged on the file, right? You can click on the little button that says new differences and it will tell you, hey, on the file, it says that this should have this title, but on the current life side it has this title, for example. With the press of the button, we can reset the site to match what the files say the site's configuration should be and wipe out any change that's been done on the site completely. It's important to note that as in most things in Drupal, there isn't a back or an undo button, right? So pressing that button can definitely be very disruptive if you can. Literally take hours of work and just completely add them as if they were never there. The other sections of the UI allow you to export the site's current configuration. This includes any changes that are not in sync. So basically it grabs the files that already exist, it grabs anything you've done and it packages it all up and gives you a tar file. This process is useful, again, for grabbing all these configuration files and maybe pushing them to another instance of the site or adding them to your repo, depending on what you're using. So that way the code gets changed, I'm sorry, the changes get saved into the code of your website. After clicking the button, you get prompted to download that tar file and it has all the configuration files in that one main file. The import section can import that tar file that you just exported, but depending on how your site is configured and the hosting you might use, you might not be able to use the input directly. Some hosting providers don't allow you to do changes to the site without actually making a change to the repo. So they won't allow you to import files directly. Again, it depends on your workflow then where you have your site configured. So if you're looking for some, oh, and both options, the export and import functions, allow you to see a single item as well. So if you're, for some reason, wanting to look at, I don't know, one of your sites and say, this is weird, I wanna know how this specific section is configured, you can look at the single file that you're looking for and see that line chain and say, okay, right, I understand what this is now. So you can look at one single file at a time or you can export all of them directly. The other option is using Dress. For those who might not know, Dress is a command line shell and scripting interface for people. It basically allows developers to do several actions directly in our terminal windows versus clicking buttons on the UI. We can flush the cache, we can make database backups, we can run Cron and many other things. And this also includes importing and exporting configuration, right? So using Dress, we have two commands. We can import and export. There's the full version, that's the first thing on the left that says Dress config export and there's the short-handed version or at ADS version, which is just fresh CEX, which is what we develop and normally use. When you run these commands, it will tell you exactly what it is you're importing or you're exporting and give you a chance to confirm just to make sure that you want to overwrite the files or you want to import this into the site. They end up working very similar to using DUI. It's just one of those things where, it might be more comfortable using a terminal window than using the user interface or the other way around, right? With that being said, I want to talk a little bit of how the workflow works in DOD, how we manage it, right? So we as developers have a local instance of the website. We create our changes locally. Let's say we create a constant type, right? We add some fields, we add whatever configuration that's needed for that. We export that configuration via Dress. So we're telling Drupal that all the changes that we just did, we want to make sure there's files to, you know, for the configuration files for those changes actually exist, right? So we export the configuration, we commit and push the files up. And then we use a continuous integration tool called CircleCI that grabs those files, grabs the commit and rebuild the site on our dev instance and imports the configuration automatically. So that means dev always has the latest files and the configuration is imported automatically each time we push to dev, right? And this is important to consider regarding workflows, right? If a website setting is changed, but the sync configuration and that configuration setting isn't there, Drupal will delete that setting, right? So using a real world example, if you go into, let's say, the prod environment and create a web form, right? And you add some fields and add other settings. If the configuration files of that web form aren't exported and saved, the next time someone imports that configuration, all that work that was done on a web form will be wiped out when syncing anything that isn't in the files gets wiped out. And it seems kind of weird, but it actually serves a great purpose because for example, let's say we have a site and we created a content type and then, you know, clients will be clients and they say, oh, no, we don't need that content type anymore, perfect, we'll just take it out, right? So the configuration files for that content type are no longer in there. So when I import that configuration in another instance of the site, Drupal's gonna say, hey, okay, so I have this content type here, there's no longer files supporting it and configuring it, great, I'm just gonna delete it, right? So it makes sense for things that aren't in configuration to be deleted, but you don't always want that, right? You don't always want everything that the current site settings have to be currently deleted, right? So the ability for configuration to completely wipe out sections, if you're not careful, can create issues. So let's talk about these issues and things we need to consider, right? So the number one issue that happens is when changes are made directly to the different environments without exporting, right? That is definitely the number one issues, we see it, we try to teach everybody about it, we try to make sure it doesn't happen, but, you know, sometimes it doesn't. So I'll go in and do a quick change for the title because I find one and I didn't want to go through the whole process of changing the code and exporting and doing all that. So I just changed it directly on the admin interface. When somebody else syncs code, right? They, if they're not careful, when they sync the code and since my change isn't in code, right? It'll get wiped out, that's what you're talking about. And then another issue that sometimes happens is that configurations actually never synchronize. So the different instances are not consistent. We had a client that had three building environments, in Acre, right? Dev, Tostan, I think they call it Proc, right? And the developers that created that tip for them never used configuration management, I'm sorry. They did a change on test, the client would approve it, they would then manually do the change again on test. The client would approve that and then they would manually do it again on the live site. Obviously, after a while, that methodology is very error-prone, right? It's really hard to remember exactly what you did on Dev and recreate that manually by clicking all the backend sections and then again do it online, right? So the client, when they came to us, one of the very first things they said is, our site is kind of weird because certain things work well on test but they don't work well on live or the other way around, right? That it works well on live but when I try to test something on Dev, it doesn't work. So it's just all wonky, right? It's all weird and it's not in sync. And of course, I went into the configuration management speed of the first thing I did and there were like 467 items that were different. And that basically means that the configuration was never sync, right? So these issues that would have been really easy to not have them by the other clients that, by the other development company that created the site, if they had just used configuration management, right? If they had actually used what Drupal 8 provides, remember? The incredibly hard part for us was we wanted to do things right, right? So we wanted to start doing configuration management but we couldn't just grab what was on live and use that as an example because the client was very specific that there were certain things that they'd like to work on test and there are certain things that they like how they work on Dev. So we kind of had to cherry pick parts of configuration here and there to be able to get the site on Dev, test and prod to be exactly synced up. Let's talk a little bit about things that you shouldn't, right? So again, avoid making configuration changes on the live Drupal site, right? Another thing to consider are clients, right? And they will do things. And at the end of the day, it is their site. They will, you know, if you give them the option of being able to create a form of being able to change some of the settings on their site, you need to prepare for that. You need to make sure that any time you are going to push the latest code up to live, you already took a look at the configuration screen and said, hey, is this blank? If it's blank, then you're great. That means that configuration is in sync with what it is in files and your push is not going to do anything that. It's not going to destroy anything. But if there are differences, you're going to need to see if you recreate those or what is going on, right? There might be differences that, you know, it might not matter. Maybe you just, you know, find, change something that they didn't really even want in there. It wasn't really important or it might be something really big. So before you synchronize the code on the live site, you need to see those changes and add them into your code to make sure that when you synchronize, it includes whatever the client had done or anybody else had done on the live site. That is one of the things. The other thing that we shouldn't do, there are certain instances where it might make sense, but for the most part, don't make any changes to the configuration files directly. Drupal knows exactly, you know, the correct formatting, the spacing, the titles, et cetera, that needs to go in there. Any change that needs to be done to the configuration files should be done in the Drupal backend as a best practice, right? So I'm going to briefly touch on the different hosting providers because even though every Drupal site 8 works the same, depending on the hosting provider, you have your site on, the way configuration works might change a bit. So again, not going to go down specifically on the changes in each one, but do you know that your workflow and the way you synchronize configuration might change depending on where your sites are hosted on? Panthen, which is what we use at Daotie, is very easy to use. There's only one configuration folder by default and one of the configuration that's on Dev is on test, it's on live, right? It's the same folder. Aquia, I know that it has a different way of having two different folders, right? For configuration and there's specific commands to synchronize configuration one way or the other, and so does platform usage, right? They're very straightforward. So it's very important for your team, not only to develop this, but the project managers and basically anybody that's at the site to know and understand where your site is hosted and the differences, right, that concept. One of the things I wanted to get into as well is that configuration management on its own is great, but it might not solve every issue you might have with it, right, or want to extend it. So there are some great contributed modules that can extend the functionality of configuration management. First one is configuration read-only mode. This module is a little bit draconian, right, because what it does is basically it knocks the site in a way where there can't be any configuration or any setting change that would trigger a configuration file, right? So you would never have the example I talked about earlier, right, about, oh, the client came in and made some changes and the configurations that I was saying, it won't allow the client to do that, right? They will only be allowed to add content, they will only be allowed to change menu links and stuff like that, but they will never be allowed to actually change any setting that could make a configuration change. Again, you know, it's iffy, right? Because at the end of the day, you have to understand that these are clients, right, at least for an agency like themselves, right? If you guys own the site, completely different to you, but if for an agency that we work with several different clients, it's hard to tell a client, hey, here's your site, this is yours, but you can't really do a lot with it, just except adding code, right? I'm sorry, adding content. You can't really change how it works or do any type of setting. Kind of defeats the purpose of having ACMS in the first place, right? But it's up to you guys. Configuration split is another great module because there are times where you wanna have certain configuration work in dev and in test, but not in prompt, right? I'm sure, yeah, there's development modules, for example, that you want them to run in dev and test, but not in product environment, and you don't wanna have to synchronize your code and then turn them off each single time. So configuration split basically allows you to have different sets of configuration for different environments. It's a very useful module, which I recommend to everybody. There's another module called recreate lock content, which basically solves the issue we talked about before. What it does is when you import a block, it actually creates the block for you. It's empty, right? Because the content is something that you need to do, but it creates the block, right? So you will never get that error of, hey, the block, I have settings for a block, but I don't have the actual block content. Here's an error. What it does is just creates that block automatically for you so you can just go in and copy the content from wherever you were importing and just add your content or whatever, but it solves that issue. That's also a great module. Configuration ignore is something similar to configuration split. It allows you to ignore certain configuration files, depending on your environment. For an easy example, for example, if I want my dev and test environments to have, for the site to have a certain title, for example, but I don't want that to move up once I hit prod, then I can have that. So we know that the prod environment is just gonna completely ignore that configuration file and will always have whatever setting is currently hanging out at the live site. Another great module is configuration menu link. Like I mentioned before, menus, the actual menu, the creation of the menu, the existence of the menu is a configuration file, right? But the links aren't, right? Links aren't. And a lot of times it happens that links on those menus are also an integral part of your site that we have sites that have 200 links. Maybe we don't wanna change those, right? Or we don't wanna make it in a way where, some of those links have to exist, right? So we can add them to the configuration. So when we push those up, those links always exist and they're saved into the code. So that's one of the modules that can help. And the last one is structure sync, which is one, which should also kind of help with the issue. I talked about it where taxonomy isn't used as a way to filter content, but it's actually used as a building block of the site and added functionality. Structure sync allows you between other things to actually sync the taxonomy terms along with the taxonomy of the capillary, right? It does both things. It's just like the menu link, but it syncs the taxonomy terms as well. So those get saved into the code and you can make sure that once you push the taxonomy of the capillary, the terms also exist and you won't have any issues with anything that depends on a specific taxonomy term. So let's just talk about some key takeaways from this session. Configuration management is a great thing to have, right? It should be a must use if your site is used. If your site has more than one instance, which should almost always be the case, right? And I know that there's some people that like to live on the edge, right? And have one single instance of the live site and that's it. But for most people and agencies and any type of environment, you should have a development version of your site just to play around with and make sure things work correctly. And if you do, then you should use configuration management to make sure that an instance and a live instance is in sync. And now that we know, understand how to import and export and why changes get wiped out, we can avoid having the issues, right? We can avoid having the repetitive issues that, hey, I made a change and it's all under there or hey, the client made a change and it disappeared, basically. So with that being said, I think I'm just in time. Any questions? I saw a couple of questions. I'm gonna go up through the chat and see if I can find any questions along. Let's see. Thank you, Rick. Costa Rica is pretty beautiful. If you guys ever wanna come down here, please do. It's pretty good. It's very friendly for Americans. Well, I don't see everybody speaks English. You can pay with dollars everywhere, it's great. And you can ping me and I'll make sure we can go grab a beer or something. Okay, so Charles saying there was a sound drop. Oh, James kind of answered it already, but no, there is no undo button to import. If for some reason you don't have that configuration saved in your repo and you're just doing changes, the client made changes and you're gonna think the changes that you have until now, there is no undo button. Okay, if you do that, they're basically lost and you have to maybe take a look at a backup or some other way to restore what the client did or kind of bite the bullet and say, hey, whatever you had done, you kind of have to do that again. Yeah, let's see. Any other questions around here? Oh, back says, okay, so there is a case where there was a reason to edit the demo file directly. There has to be a better way, right? The fact that you had to do that means that ECK needs to make sure that every setting it provides is actually something that you can edit through the UI. I mean, I think that makes sense for the most part. Maybe not every setting, but most settings should be. You should be able to change everything through the UI, right? So you don't specifically have to do that because again, it can lead to errors. All right, so Charles, okay, great. So configuration batch export. Okay, that's, okay, that's the Julie. Julie's talking about a configuration batch export module where I'm guessing her current configuration folder is massive, so the site doesn't time out. It uses batches to import and synchronize configuration. That's a great module, Julie, thank you. Yep, Max is saying that Structure Sync created some issues. Kevin also said that configuration menu link had some issues, bank exports. I think so, you know, the general things to watch out whenever you're using a contributed module, right? Maker, yeah, sure. I will post the link to the slides in the back camp slack if that is something. Or let me just put my email right here. If you guys send an email to me, this is my email, I'll be more than happy to present those, give you guys the slides and answer any other additional question that you guys might have in terms of configuration. If you're following best practices, you should never have to export your entire configuration from your product buyer person. Question, can you walk through the steps to do an export and generate the files to be able to check into your repo? Sure, let's see you, what should we do? Julie, just as a thing for me to know, would you be using the UI to export the configuration or would you be using Dresch? Well, I think that's, I mean, it's either one or the other and the process varies a little bit, but let's say you're using the UI, right? So over here where it says export, right? You click on that tab, it gives you a button to download, right? That button that downloads a tar file, which is like a zip file, right? It's a compressed file that has a bunch of configuration files in them. Generate the files to be able to check into, okay, great. So what you do is you grab that file, you uncompress it, unzip it, whatever you wanna call it, and you get to the folder that actually has all those files, right? What you can do then is just you grab those files and you copy and paste that into the configuration folder of the site that you're working on, right? If you're 100% sure that your local environment where you have the files is in sync with the version that you're working on, then you can just go ahead and empty the site configuration folder and just copy all your files in there just to make sure every change that you do gets put in. That whatever you had on, let's say, depth and you push the configuration files out of there, you exported the files out of there to make sure that what you're gonna add to your repo is exactly that and you would go in and delete everything in your configuration file and add the files from the export. When you're committing those files into the code base, it will tell you the differences, right? It will say, hey, this file is new. Hey, this file is modified or if you deleted something on the depth side, right? And when you're exported the files, it'll say, hey, this file is missing as well, right? And that way you will know that the changes you made are gonna go into the code repo. Now, what happens after that depends on the workflow that you guys have, right? When you push that change up to a master or whatever environment you guys have, then you might need to, well, you won't have to synchronize if you're coming from there, right? Because what you just pushed to code is exactly what's on the Dev environment, let's say. But I mean, it all depends afterwards on what you need to do on your current workflow and when using the UI, you have to manage, extract and copy the files with the correct photos, monitor rank, yeah, exactly, right? Exactly. Or, yeah, I mean, that is one thing, like, right? So there's two things, right? Yesterday, you do have to do that. One of the main takeaways from this is that doing a change in setting does not automatically generate that response, right? You have to tell Drupal, hey, please generate a configuration file for all the changes that are done, configuration files. So yeah, you grab those and put those into the code. And yes, Kristin, you can do that as long as you have that local version of your site running on your site, right? Because there's times where you only have the repo and you have the files, but you're actually running the site locally, right? You just have the repo. So it happens to me where sometimes I have to make a change on a site that I don't usually work on. So I don't wanna go through all the trouble of actually getting that site to work on my local. I just wanna do it quick and easy. So I make the change on dev. I export those changes and then I just add them to the file repo. So I don't have a UI to put that tar file in, right? If you do, that's great. But I just put them in the files and the repo files and push them up and know that now my changes that I did on dev are now part of the files and once that gets pushed to test and live, it'll go up there with you. Will Drush put them in the right place? Yes, that is correct. When you export configuration using Drush, it pushes them to, I mean, unless you have something weird or really wonky, but by default, it will definitely put those in the right place. So you export using Drush and then you're able to commit right away those files that will be in the right place. Good point, now the box config does go into site mode, which is an idea you have to customize. Yep, that is, Rick has a great point. We, as a Teori, we have the configuration files, one level above the Drupal site files. So there are never, you can access them directly and yeah, there's one level above root, which is exactly what Rick is saying. That is a great way to do it. That is something you need to specify. But again, it's part of the workflows that your team needs to decide, right? It's a good thing to do. It's not necessary to do, but it's something that you need to specify. Yes, exactly in the settings file, that is correct. Thank you, Kristen. Question, any best practices is considering for where to keep the demo? All right, we just talked about this. Nice to look in. Yep, yep, that is perfect, yep. So yeah, it's like, that's what we do. I think that makes a lot of sense. I don't particularly think those files should be accessible via web browser, right? Drupal doesn't need them to be. And just keeping them one level above root like Rick said is definitely ideal, that's something we do. Now, the reason I would think that Drupal doesn't do that by default is that not every single environment has access to a level above root, right? There's some very simple hosting environments that you basically get where the site files are, that's all you get. So, you know, forcing that would cause issues for those type of users. So it's better to have that where a hundred percent sure it works for everybody and then specific user cases like ours, we just know that. Great, Julie. I appreciate that so much. I put my email there, feel free to ask any questions. If you want the slides, it should be an email. I would love to get them to you. One thing I did want to mention real quick is that Teori is looking, we're looking for new developers. So if you're looking for a new backend and you're looking for a new backend or a frontend job, it's a hundred percent remote all the time, not just now in the pandemic. So, yeah, if you're looking for a change of pace then just go ahead and check Teori. The last things I will say now that we're done, thank you again very much. These are the next sessions that are coming up both at noon to noon, 12.30, if I'd meet and greet with Ann and Jen. There's also a part two of living wisely, maintaining balance and meeting under modern conditions and one PM, the Contribution Lounge. And these are the next sessions coming up. You have them right there. Hope you guys continue enjoying Bad Camp. It's been a pleasure and an honor for me to talk to you guys. Please stay in touch and thank you very much again. Thank you very much.