 Yes, okay. Thank you for coming to my session. So I believe some of you here actually interested about how we can leverage with the configuration management in Drupal. So just a bit to know about you guys. If you guys done anything with Drupal 7 before, raise your hand. Okay. And how about just recently discovered something in, I mean recently touched something on with Drupal 8. Okay. Yeah. So, okay. So we're going to, this is the topics that we are going to talk about regarding with the configuration management. So one of it just a bit quick introductions of what is the configuration management in Drupal 8. And then some of the use case actually, this is just so happen that is also happening in our company's website. So we have some certain case that why is the use, make use of the configuration management along with like a configuration split and also configuration ignore is actually quite useful. And yeah, probably a bit about, explain a bit about what is the configuration ignore and what is it and how to, how to configure it. And then also with the configuration split as well. And then the summary of it. And oh, well, maybe a bit demo, but we'll see how it goes. If we have time then create section after that. Okay. So first thing first, who am I? Okay. My name is, that's my full name, Pratam Adianto. I'm actually a Indonesians, but working quite a while, staying quite a while in Singapore for a few years, quite long. Now I'm working in Gobert. We will go into that, we will go into that what is Gobert is, but am I working in Gobert just recently actually on, I started on November last year, working as a senior Drupal engineer. But most of the time before I joined Gobert, I do a lot of things with the developments with Drupal. I started Drupal from, I think I managed to touch like 4.6. I've even, we're all, when we create like a content type using custom modules, that's like a so-called golden age. And then Drupal 5, then after that, move back to the Drupal 6 and Drupal 7 as well. A lot of things that I've developed using Drupal 7, but I think Drupal 7 is actually, I mean, that time back then is something that I really love with Drupal, but then now it's coming to Drupal 8, which is actually a totally different beast. But yeah, that's, if you want to contact me to my Twitter, but there's nothing else there, then that's my Facebook. I forgot to put my email address, but anyway. And this is the company I work for. It's a Gobert. So what is a Gobert actually? Gobert is actually a meta-search engine for insurance and financial products. It was founded based on the simple premise that a consumer should find freedom and ease in choosing complex financial products like insurance, credit cards, and loans. And founded in Singapore since, I think, early 2015. So we already have established in six countries, Singapore, definitely, Vietnam, Thailand, Malaysia, and Hong Kong, and Vietnam. And we also recently just doing some soft launch in Indonesia. So I think that's the next thing that we are trying to focus. So yeah, I mean, as one of the fastest growing fintech startup in Asia, Gobert is trying to leading the way to democratizing financial shopping experience with unbiased and personalized comparisons process. So it's a Gobert's users-oriented platforms, neither aggregates nor sell products. But it's actually simply offers consumers a free and transparent comparisons process based on their financial needs and not influenced by service providers or commission or advertising. So that's what Gobert is. So that's about the company. So this is a configuration management. So if one of you guys managed to do some work with Drupal 7. So in the past, I think Drupal 6 also has, I forgot. But in Drupal 7, we usually use this module called Features. So what is, I mean, if some of you actually still not quite sure what is a configuration management is, is basically to modules that I can actually deploy a set of configurations from one side into the another. So it's actually a good for deployment process and also it's easily to configure and easily to customize things. So this is basically of how the configurations management work, especially in Drupal 8. So if you guys are already familiar with the one in Drupal 7, I think it's kind of the same even though in Drupal 8 itself there's another module called Features. But I've actually never used that. But this one is actually already in a core already in the Drupal 8 itself. So when you install, you will get these features directly in your installations. So what it does is all the configurations like basic settings, then like a performance like a CS aggregates, all the permissions, whatever, it's all configurable in Drupal. But sometimes there's a news that we also need to, we want that kind of a configuration that we already set to deploy to another environment, to another, yeah, different environment. But of course within the same exact website itself. So what it does is actually those kind of configurations were actually export as a YAML file. Those YAML files actually is the one that contains all the configurations is basically just deploy to another environment. In this case, we can actually use the like a revision control, versioning control like a git. I mean that's what the standard practice is. And then once we move it to another website in another environment, what we just need is just to synchronize it against the active configuration in Drupal. So it's actually the website that the one in the new environment is actually is trying to synchronize the new configurations to one in YAML file, then save it into the database. In this case, it's become active. Then all the configurations of the websites in the new environments is will be exactly, well, I mean most of the time it will be exactly the same like the one that you already set up in other environments. In this case, it's a development environment. So yeah, that's about it. Is there any questions until here? Is all premise pretty clear so far? Okay. So yeah, I mean this is what it does. So actually in Drupal itself, there's a feature where you can actually see the difference before you confirm that the changes of the configuration is already suitable based on your needs or what you expected. You can actually see the difference first. So the configuration management actually provides a user interface. You can actually just try to see the comparison of it. Like from what it is that already still active with the one that against with the configuration that we want to change. So why of course, I mean the configuration management itself is actually is a very crucial feature in terms of deployment in our company's website. But there's a case where we actually need to think of there's some configuration that actually we don't want to get over right because in Drupal essentially all the configuration, I mean since all the settings are configurable, but sometimes there's a certain configurations that we don't want to change. We want to still preserve the configurations just for the sake of the to maintain the quality of the website. So like for example, like some of the, like we have a certain roles in our website, in this case we can just call it web managers. So there's some, sometimes our web managers doesn't want, wants to change some titles or some other settings, but just don't want to get over right when we deploy something. So we have to think about on how to do that. And then the next case will be we actually using quite heavily with the module called web forms. So web forms actually is the modules where we can create any kind of forms to collect any kind of data from any kind of users. And we even use web form for like a use for the CPL page and use for other integrating it with the excellent API. But we, in this case for the content managers, actually they, we do provide training, right, some sharing the knowledge on how to create a web form to the content managers, then it's up for the content managers to set up their own web forms. But again, I mean the, the configuration of the web form itself by default is actually, is always being configurable in Drupal. And if it, and sometimes when we deploy some things, all the, the, the web form that already been made by content managers in production, sometimes it gets overridden or it does get lost because it's always get overridden with the, with the configuration management that we, that we want to deploy. So that's one case. And we all, we also have a SEO managers that, that managing the, the, the meta tag, all, all kind of tags related with the SEO. So we make use this module called meta tag. But some, this is also something that the SEO managers need to manage by themselves. And since we have, also have a multi-sites implementations, right? So the content, the SEO managers have to change the meta tag according to the needs based on the, on the different website or based on, in the, in a different country. And also, I mean, there's a, of course, just for the sake of trying to follow the best practice of development. So we want to like isolate or trying to separate all the kind of modules that related with the developments. We just don't want to get accidentally activate or enable in the productions. So that's also one of the things that we need to figure out. And then, there's also another case, like, as I mentioned before, I mean, we, our website is actually configured as a multi-sites. So I'm going to say that we have a one source of a code base, but actually with the different database, I mean, that represent for each country. So like, there's a certain configuration that actually we want to have, we just set one configurations, but it will apply globally. So, so this, this is also another case that we want to try to solve. Okay. And also, like the same thing like meta tags. So like, if we want to create a new content types and also make use the paragraph module. So in case if you, some of you don't know what is the paragraph, paragraph module is actually is a modules where you can actually configure to make the fields to be nested into, into other fields. So like, for example, if you want to create, like for example, a set of header, for example, consists of fields description and so on like that, then you can make a group of, of its own field, then you can also, it's also, it's also modules where you can actually able to add that group of fields into other content types. So that's what paragraph do. So along with, with the content types configurations, we, we, we want to have such a way, we want to configure the content types just one time and also paragraph along with it. But when we want to deploy to other environments, we want to apply globally without updating it into each different folders for each country. So configuration ignore. So what is it actually? Yeah, so as I mentioned, there's a, there's some, there's some configurations that actually we don't want to get overridden. So that's why the, we're using this configuration ignore. Basically the configuration ignore is, is, yeah. So by using the configuration ignore modules, we actually able need to tell which actually it is the modules that doesn't get override whenever we want to deploy the new configurations into other environment. So if you look at the, at the, at the diagram over there. So when we use code ignore, we actually decide on which kind of a configuration that gets ignored. And only on the active configuration is, is the one that gets export. Then after that, once it gets exported into the configurations table, then we deploy to the other environments. Then after that, it will be applied by itself in the other environments. Any questions so far? Nope. So in, this is how we basically the UI of the, how the configuration ignore being configured. So yeah, actually this literally from our site. So as you can see, we actually, we have some, some, some settings that actually don't want to get overridden. So like most of the, most of the things is actually like a web forms. So if you, if you can take a look in the, the best thing about the configuration ignore is actually you can, you can able to specify what kind of, what kind of exactly the configuration that we want to ignore, but also able to, to set all kind of a similar configurations by using aesthetics like one of the sample on my slide. As you can see, actually I'm ignoring all the web forms except some of the web forms over there were like using the tilt, which means is to negate, which means all those, those kind of a web form is the one that don't get ignored. It has to be still being configured. And then the other one is like, yeah, I mean, we have some certain requirements like, like the My Mail and Swift Mailer and also some of the system size, the one I mentioned to you is like a basic settings. It's also we need to, we, it's something that we need to ignore. And also there's some, some of like our custom block. I mean, is actually it's meant for the, the one that makes up the, the, some of the menu that represent by block. So we just don't want to get off right by a deployment of the configurations. So, so yeah, that's this thing. And then, so the next step is configuration split. So as I mentioned, in our, in our website, we actually configure our websites into become a multisites meaning to say that we are using again, as I mentioned before, we are actually using one source code base, but we using a different database for, for each country. So there's some, there's some modules that actually we want to have. I'm sorry. There's some, there's some configuration that actually we want to make it such a way as I mentioned, like if we want to have a this kind of a configurations that needs to be applied to certain websites, we can do so using configuration splits. And then, and also there's some, some configuration that also unique per country. We can also able to do so in the using this module configuration split. So this is one of the sample of how the configuration split works. So, so from the, from the diagram actually, we can actually able to, to customize of what kind of things that we want to split on the, on the, in terms of the configurations and then on and for which modules that actually, for which side that we want actually the configurations to be, to be applied. So as you can see from the diagram, it's a different website denotes by the, by the color scheme. It's actually, it's a, it's a, it's a different website, but it's, it's getting all the configurations that coming from the one source, which is, in this case, it's a development environment. So far, any questions? Yes. Ah, yeah. I mean the configuration split itself is actually it's a modules, it's an extension from the configuration management. So when the, the requirement is when you want to split, you need to create a sub another directory. So in my case, we have a directory that called global, global, and then another one is, is a, is a normal config directory. Okay. So this configuration split, I mean, sorry, this global directory is actually is the, all the, is the directory the one that going to store all the configurations that actually that applies to all the websites globally. And then, and then the other normal config directory is actually is the one that unique per country. So let me just go to the slides. So in, in the UI, in the UI itself, so we can actually able to set what kind of configurations. So in this case, I, it's like from the sample, I actually simply create a config that actually meant for the productions. And the other one is actually, sorry, production, but it's a meant for the global, the one that is going to be applies to, to, to all countries. And then the other one is actually is a, is a dev, but dev config that, but meant for the, for all the, for the, all the websites global. So then, then after that, we need to choose the the, the what kind of configurations that actually we want to split. So in this case, let's say for the global product config, right, then if we click edit on it, it will go into this kind of a UI using the place where we can actually either we want to choose the modules entirely or we want to choose the, the exact configurations file in this case. I mean, I'm more, I don't know, I'm, I'm, I'm more comfortable, more, more confidence if I choose the, the, the exact configuration file like this. So I actually configure that. I choose some of the configurations in the, in the configuration items, right? Then after that, I click save. Then, then after that, I click save. Okay, then that module of the configuration split is also, is, is going to be export into a YAML file. And this YAML file is also something that you need to export into the other websites, into other environments. And for the case of the, of the multi sites, the same configuration file for the configuration split, you also need to deploy to other, to other environments. So is that, am I answering your questions? Yeah, sorry. Is there any questions? If there's any, no? Okay, so I guess that's actually it. So in summary, so the configurations management is standard practice for Drupal deployment. So you need to master this if you have a, you want to deploy changes under your configurations into the other environment. And then if you want to have a isolate configurations based on the certain environment, you can do so by using config split in this case. And then when you use config ignore, you can actually have a flexibility on preserving on what kind of certain configurations that, that, that needs to be, that's, I mean, yeah, that needs to be preserved in the, in that, in the specific environment. So I guess that's all. This is just some reference that I got for creating this, for these sessions. So, so any other questions maybe? Yes. Since let me try to answer that. Since the configurations file wide, in this case is YAML file is also something that can be put into the versioning control. So I guess, I don't know. I mean, it's, it maybe have some, some, I don't know, some, some mistake on the, on the deployment of, anyone can answer that? In my opinion, it's probably more manageable because you can actually like configure it directly from the Drupal admin UI. So you know which one is actually the, the differences rather than you don't know, like, like, scrolling around in the, in the, in the git codes, then, then, I don't know, then maybe there was a case that you also need to realize on fixing it manually if it's have a conflict branch process. I mean, it's, it's more manageable using this way. I mean, if you convenient using git, then, yeah, I mean, I, I don't mind, but this one is, I mean, at least more manageable than you will see that the obvious which one is actually a different and which one is not. So I think that's, thanks a lot, by the way. Thank you. Thank you for the questions. So I don't know, any other questions maybe? No. I think that's the whole point of the configuration management, actually. I mean, and also that's the purpose of, correct me if I'm wrong, if, if my question is wrong. That's the purpose of why we have a conflict ignore. I mean, if we know, if, if, you know, there's some conflict that actually don't want to change, then what we need to do, right? So that's why by using the conflict, it's, it's, it's going to solve the problem. Yes. Yeah. I mean, the, the same, I mean, the conflict, you know, itself, it actually will be exported into YAML, right? Then this YAML itself is also something that you have to deploy as well to the, to the environment, to your production environment. So just to tell that which one actually is the conflict that actually that, that, that don't want to get overridden when the deployment just comes. Is that answering your question? Okay. Yeah. Try any, any, any other, maybe no. Okay. If, if that's the case, then thank, thank you for, yeah. Oh, yeah. Okay. All right, guys. So I just remember