August 31st, 2021
Length: 49 min
Creating the perfect flow for your WP apps
Learn how to create a high-performing delivery workflow for your WordPress websites with Buddy and Kinsta WP hosting. Brought to you by Osom Studio.
Who is this webinar for:
WordPress Agencies and Freelancers
Learn how to speed up and refine your deployment flow to faster release websites to your clients.
Learn how to configure a CI/CD pipeline that will build, test and deploy your WP projects – and seamlessly migrate them between environments.
Learn how to automate repetitive tasks to maximize the efficiency of your developers and never miss a deadline.
Stop losing money on inefficient tools. Get everybody involved with the latest tech that will help your team adapt DevOps up to 87% faster.
What you're going to learn:
- Using DevKinsta as a local development environment
- How to create WordPress related Pipelines
- How to automate moving files and databases between environments
- How to run basic tests after each deployment to check the website quality
02:10 Osom Studios Tech Stack
10:43 Creating local environment with DevKinsta
19:45 Deploying files and DB to Kinsta with Buddy
Hello and welcome, everyone. Welcome to today's webinar about creating the perfect flow for your WordPress application. Today, in this quiet rainy day in Poland together with me I have Bartek Nowak from Polish Agency called Osom studio Bartek tell us a few words about yourself and the company you work at.
And I call everybody. So as Maciek mentioned, I'm a Technical Lead at Osom studio, which is an agency based in Poland. And I'm working there since 2018. And as a technical lead for about four months. I'm working as WordPress developers since 2013. So I guess that we will show you today some magic about creating the perfect flow. Okay, WP apps.
Yes, and tell me in, in which that's Osom Studio specialised do you make mostly themes plugins?
Okay, so we got clients all over the world and we are specialising in creating fully customizable themes for our clients. We are also making plugins, and etc, everything connected with with WordPress.
Osom Studio's Tech Stack
Okay, thanks. And I am Maciek masky. I work as a WordPress ambassador here at Buddy. And I think that's all about me, because I am not the star of today's webinars. So before we we continue. If anyone has some questions, feel free to ask them either using youtube comments or using Facebook comments, because we are broadcasting on both channels this time. So with this out of the way Bartek let's start with Osom studios technological stack. Let me guess You are not this type of company that just instals Vanilla WordPress, and then just downloads Elementor and clicks the whole website.
Yeah, we are not using vanilla WordPress, as you said, we are using bedrock. And bedrock is a tool used to change file structure. And to use composer to pull files from a remote repository. So this approach allows us to have our GitHub repository really small, and our developers can clone this repository quite easily when they are joining joining the project. So if you want to see how it works, maybe I will share screen with you of course and as you can see here in my PHP storm. This is completely other file structure than vanilla WordPress. So we do not have a WP config php file or definitions are being set up in that and file. So whether you could
show us the example because I know that the your father password so
yes, so we can enter a DB name here. Of course, everything that needs to be entered as in WP config. You can define ACF procaine as well. So ACF will be updated and downloaded with your composer then. So as I mentioned, we got composer json file here, which is required to pull all plugins and the core of WordPress as you can see here we got WordPress in version 5.8 And it's being downloaded here to web directory and WP so we can update it with composer etc. all plugins are being downloaded from WordPress Packagist which is quite fun to in my opinion as well. Because the only thing that you need to do maybe I will show you how it works as well. It's open waters Packagist site and enter slug of plugin that you want to download. For example, let's search for worker which is which is a manage WP Plugin and helps you doing backups. Same managing plugins from from there. And as you can see here, a worker has a few versions here. And two, if we want the latest one, just select the 499, copy this line and paste it right here. So after typing composer installed in your terminal, the plugin will be downloaded and moved directly to your app plugins. So it will be available in your WordPress.
Okay, so as I understand thanks to bedrock, you can have a new developer can create working environment of the project in a matter of minutes, right?
Yeah, the store. They don't need even to type this in terminal, we created a basket for this. So it's it's only running the bash script to download everything that that is required.
Yeah, so as everybody knows, developers are are lazy. So this is one of the perfect example how we can use this laziness to to make everything work better. Okay, so what else apart from bedrock are you using?
Okay, so we are using timber as well, which allows us to use twig templates. And that approach gives us possibility to separate logic apart of views files. So front end developers and the back end developers can work as synchronously and create applications much faster.
Okay, so maybe could you show us some some example of okay,
I got one here. So for example, this is how I look single case study, which is our CPT in our WordPress. So as you can see, here, a timber is rendering a view that we have here, and we can pass PHP variables with adding them to the context, which is then passed here and it using render method here. So if you will pass for example, ideal light or colour background, it will be available right here. So
yes, yes, and we can see that timber is using a bit different syntax doesn't use the typical PHP syntax about using this moustache moustache one. Yes, I think this is this is much clearer. And it's quite similar to the syntax we can see in few other templating languages that are available not only in PHP, so. So this is also kind of a more universal approach. And tell me, what about Gutenberg? Are you afraid of Gutenberg? Or did you decided that well, is Gutenberg and you will uninstall classic editor ever? Yeah.
So we are not the type of agency that are installing What You See Is What You Get editor every everywhere. We are trying to use Gutenberg, of course, to use it and to create a new blocks, we are using ACF timber blocks library, which you will probably know. And that's, that's quite easy, because you can create new block with just a few lines of comments. And let me show you how it looks like. So it looks like that. So probably the only line that you will need is the title here and all files or tweak files created in views blocks that got this title, comment line will appear in your Gutenberg editor in WordPress dashboard. So of course, if client wants to have a classic editor, we can start about we will recommend to use Gutenberg in this case.
Okay, I also I must admit that it's really nice to see when when the guests of your webinar is showing the library that you run by by yourself. It's really nice and I'm really happy that someone is using it. So So yes, probably I will keep on updating it even for for some studios sake. So you can have Yes. Okay, and when we are talking about technological stack, I will have one more small question. And what do you think about the WP CLI? Like it?
Yeah, all of our developers are having WP CLI installed locally. And we are using it for search replace, doing search replace in database. This these two does it quite quite good. We are using it as well. For exporting and importing databases to specific environments, and that's quite powerful tool. So you can, for example, wipe all the posts or instal or uninstall plugins. So, so that's quite, quite fine.
Creating local environment with DevKinsta
Yes, yes, I really liked the power of wiping out everything, it was quite useful to do I'd say restart some some WordPress. And that's something again and again. Okay, so I think we know a bit about your technological stack. And let me just repeat that if you want to ask Bartek any questions, feel free, you can use it, either YouTube or Facebook commands. It's up to you. And it depends. Where are you watching us? Okay, so let's go to the next step. Because, yes, we know your tech stack, tech stack, but we don't know how are you using it? So what is your local environment? local development environment, right.
Okay, so we are using dev Kinsta, because a lot of our our clients are hosted by Kinsta. So in our case, that's the best idea because we are sure that everything that we have on our localhost will look the same on production. Kinsta offers as well, quite fine tools on their hosting. But let's focus for now on def Kinsta. And maybe I will show you how it how it works.
Of course, I'm showing your screen. There we go.
So that's the main dashboard of DEF Kinsta. And you can set up a new site with just one click here. And it will download the latest version of WordPress and do all the magic for you. I created the site for us for today's webinar. And let's go there. As you can see, it's using Nginx. Because home dev Kinsta is using Docker so. So it's using Nginx. And you can change PHP version here. To check compatibility between plugins or themes with just one click on here to select just one option from the drop down. And you need to restart nginx then, but it's really easy. Here, you can enable or disable HTTPS, if you want to check HTTPS and blinking of your page on localhost. And you can enable or disable WP D back here. But it won't work in our case, because we are using bedrock. So we are using dot and file so so we need to omit this one. And as you can see here, we got database manager as well. So if you click here, and a miner will pop up in in your browser, and you can edit everything here, so so that's cool stuff.
All right. So yes, this this looks rather interesting, and it covers a lot of things. And so let me guess if you are using def kingstar, for your local environment, probably can start will be your hosting of choice, right?
Yeah, we are recommending it for everybody. And that because we got fine tools there. For example, Search and Replace, we don't need to go to SS H agent and, and type on WP CLI search, replace etc. You can do it directly on Kingston's page. Of course, you can do it because you can start installing WP CLI for all of things. Another cool stuff is CDN. So all static files will be provided very fast for the end user. So CSS js and images will be provided by Kinsta. CDN. The cool stuff is also backups. So you don't need to worry about having some files corrupted or something like that. And the last last thing is probably support, which is available 24 hours, seven days a week. So. So that's important for the client.
Yes. And okay, so we have your local environment, we have your production environment and staging, too. And how do you migrate files between those environments?
Yeah, so as I said, we are using GitHub. So every new developer, who is joining the project needs to clone the repository from from the remote repository. And then he's sure using git checkout to checkout master branch and then creating a new branch from from the master branch. And after doing some fixes or creating new features, he needs to push it to origin. And then he is creating pull request to master branch. And after everything is checked by the central developer is being merged to master and it's being pushed to production.
Okay, and how are we? How are the files migrated from the environment to environment? Let me guess you're not using FTP buy in the money? Well,
yeah, using CI/CD, of course. And we are using Buddy works. So I will show you my our pipeline in a while. But maybe let's first do some tests and create some back.
Okay, so let's imagine I am your client, right? And your client, I imagine because I found a bug. So what should i What should I do?
Okay, so first thing you need to do is to create a ticket in your Basecamp project, and assign it to our project manager, which is assigned to this project. Then project manager is looking for the first available developer, and he's assigning the task for him. And then the developer is cloning the whole repository to his localhost, he's taking a database from from production. And after everything is done, he may start working on this project on his localhost. So let's imagine that screen right? Yes, we got the problem here. So the closing tag is missing here. So the comment is being pulled to opening body tag. And let's have a look how it looks like on our local environment and how it looks like on our staging environment. So let's refresh the page to be sure that it will appear there as well.
So for those who are wondering this strange light and language, you can say it's polish. Yeah,
we can change it to English, of course. So let's let's move to English to not bother anybody. Okay, so we should have the same problem here on the English version of the site. And as you can see, here, the closing sign is missing here. So the first thing that we need to do is to check that we are on master branch. Everything is up to date. It's up to date. Okay, so we need to create a branch here. It's going to be fix slash missing of the sign for the fact it's going to be wrong. But
yes, this is quite quite a long, long branching. But it will also ask you about this, this fixed prefix in a while, but first, let's because it's not working. Okay,
so we are currently now on our branch, I guess. Yeah. So let's close the stack and check how it will look like on our local environment. As you can see, everything is correct now, so we can push this branch to the remote Git status. That's okay, so everything is now on origin there. And let's have a look. How are we it works in our GitHub repository. Okay, so we can compare and pull request here. So we are comparing our branch to the master branch, of course, here is the title of our merge request. And we should paste base component here and add some short description for the senior developer to be sure what we are doing here. And let's create a pull request. And as you can see, the only one file change this the base tweak, which is used by all of our templates, and let's merge this pull request. Let's imagine that we have senior developers everything is fine. And let's merge it to to the master branch. Let's delete this branch because we do not want to have a mess on our repository.
Deploying files and DB to Kinsta with Buddy
That's a perfect approach that I know underlined.
Okay, and let's go to about the works. And you can see our pipeline here.
And we have something in red. So something
that means that two new commits since last round appeared here, and we can go there and check our actions. So the only actions that we have enabled is upload files to FTP, visual tests, and like how tests, maybe let's run the pipeline and I will talk a bit about each of these actions. Okay. So, first action is generating that endpoint that htaccess files, which is used only once in our case, because we are not changing DB details or any htaccess details. So that's the only thing that is creating that and files for our environment. The next thing is PHP instal and update plugins, which covers our composer instal and composer update. It is downloading the newest workers version, or the one that you will decide in composer json, and updating other plugins. Because we are not starting getting our GitHub repository. As I mentioned before, the next thing is compiling CSS and J. S files and compressing images, maybe let's go there. And let's have a look how it looks like here. Okay, so we are changing directory to our team directory, we are installing all required packages. And we are using npm run build here. We are using Gulp for for doing this. And let's check the environment because cool stuff here is that we can change the version of note here. And we can fully customise environments that we are using here. So we can download globally gulp grunt CLI so so that's the cool stuff here.
Yes, this is very useful, especially when we are working with either legacy legacy projects or cutting edge projects where when we have to set a specific specific version of, of some library. So this this is perfect, in some cases, case, yeah.
So let's go to our pipeline once again, and to other actions, or actions is that we are uploading files to our staging environment. The next step is visual tests between current screenshot and screenshot from the pipeline that was wrong before. And the lighthouse tests in the perfect pipeline and the production pipeline, we will have upload files to FTP of production at the last step as the last step.
So in short, first, you run everything upload to staging, do testing on staging. And if everything is alright, then you are free to go to upload automatically to production.
Push everything to production. Yeah. So as you can see, currently, we got some pink Approval button here. So let's click Approve. And we will check what's what's the difference? So as you can see, yeah, difference is the right image, which is not the image to be honest. It's the animation. So as you can see, the first screenshot was taken in the other frame of this animation. So everything looks fine. Containers look fine. And I guess that we can approve this and move forward.
Yeah, so even if there is no, if there is a difference, this is an acceptable one. And it was something that we had to check manually to be sure that it's not an error.
Okay, so last step here is Lighthouse test, because we are checking it on and on to be sure that our scores didn't fall fall down. And that's important for our clients, because ours our position in Google depends on score of Google speed insights. So let's check how how it looks like. So we asked Google API to check performance accessibility and best practices and SEO and everything looks fine performance might be better but we will work on it for sure in a while. Okay, so this is how it looks like if everything went fine. Here we will have upload files to FTP of production as well. So
yeah, so So let's check if everything went alright.
Okay, so let's check our staging version of the site and we got the
sign here so yeah, so I can close my I can close my ticket everything is alright now. And okay, I have I have some questions about because installing runs running composer and stuff is something obvious but Got about about all those tests. So first, let's start with the visual test, how hard is to is to set up them.
Okay, so visual tests are being set up only with with the one input field. So let me go there. And the only thing that you need to paste this URL of your website that you want to test, you can add multiple ones. So quite, quite fine thing here.
Yes. All right. And you.
Same thing is about lighthouse, because the only thing you need to do is to paste website URL that you want to test and type some score values that will. Yeah, if something went wrong,
okay, why are you testing the lighthouse score as a process? Because most of the time, I think that many companies just do this once in a week in a mouth. And you're doing this every time with every everyone's smallest change?
Yeah, so we are trying to do Lighthouse testing as often as possible, because Google rules are changing every week. So we are trying to cover all needs of our clients, and we are testing them on and on to be sure that nothing was changed. And of course, if something will, will change, we will work on having the scores higher, accordingly.
Okay, so I think that that will cover it, but atomic I can we can we test something else? Yes, do take some time.
Sometimes we are using for for tests as well. So let me ask this, I'm not sure how, okay, it's validator. So the only thing you need to do here is as well take the link and paste it in here in URL input. And let's set up that to be zero because it will take a while it needs to go through all pages that are linked on specific page. So let's go with that. 00. And let's add this action. Let's remove turn off these actions to to have it faster and just run this pipeline. So it will show us some problems with 404. If we will have some
Yes, this is this. I mean, if I remember there was one plugin for for WordPress that was doing this. But many hosting companies has always marked it as as a big no, no, because it was really heavy on the resources. And even here, you can see that it takes quite a while we are just testing one page. But with this approach, we don't have to worry about our hosting being being mad at us. So let's let's wait a little moment. But yes, I think this like this, for sure makes our deployments much more stable. We can be much more confident with the with the result of our of our changes because we don't have to, after after deployment, check out everything manually. Oh, and he was
we got success here. So everything looks fine. And we are sure that nothing collapse here.
Okay, so So I think that that we got it covered. I I think you unravelled some magic behind Osom studio. Awesome deployments. Right? Yeah. And let's go back to one thing because it was kind of interesting for me, when you are creating the, the new the new branch is the prefix prefix fix. Could you tell us a bit more about your let's call it GitFlow.
Yeah, that's simplified info and we are using two prefixes one is fix and another one is feature. So, if something is something done in feature added by the client and client wants some new functionality, we are marking it as a feature. And if of course there is some back we are marking it as a fix. This will let the central developer who is doing merge requests and accepting them or rejecting them. Take the higher priority on fixing issues than implementing the new features so it will help The senior developers in in this way.
Yeah. So we are avoiding conflicts in our emerging. Yeah.
Of course. Next thing, we learned that you're not afraid of new technologies, and you are? You're using Guttenberg, which is just like that. Very cool. Because I'm, I'm a really, really big Gutenberg fan, too. And we also talked a bit about WP CLI, but it was easy to guess because as you mentioned about writing down those bash scripts. So using WP CLI and connecting those it with with some bash scripts, it's it's a really perfect, perfect solution in your case, if I can get it right. Yeah. Yes. Next thing, stable, a local host environment, which is the Kinsta in your case. And you're using it not only because it's stable, and it's working. It's also compatible with most of your clients hosting, which is Kinsta. NT you're using Kinsta. Because it's stable, it's fast, and it gives access to many interesting tools. Yes. And also, I see that you didn't use it, but they have the really great, it's still in beta. A really cool tool for for benchmarking, slow actions. It's really it's really tremendous. I played played a bit with it. And it's really, it's really great. And, okay, so we have this end, in the end, you connect everything using body. you automate whatever you can, you don't only automate builds, but you only you also added some some tests to make all the deployments more stable. And you can just deploy everything in a more confident way. Did I miss something?
Now, I guess that recovers everything that I said. Yeah. Yeah.
So as you see, creating perfect flow, it's not just about using CI/CD. It's there is a lot of elements. Oh, we forgot about one thing. We also forgot about the whole flow between project managers clients. This is also the part of of the perfect flow for our, our applications. Okay, so it's time for for some questions. First, we will start with the questions that were that are submitted to us with the registration. So let's start with the With a question from Drew Douglas, how do you handle multiple Wordpress databases on developers local machines and turning them into one proper database on a staging site?
Okay, so handling multiple Wordpress databases is probably programme for of agencies and of developers because there is no such two as git for for databases. So the only thing that we can do is to use WP migrate DB plugin to pull database from production, which will in our case be the single source of truth and to import it locally. And then after some changes are made locally, we need to do them once again on production. Unfortunately, there is no other way for now, as far as I know, the only thing that we are making, I guess faster is exporting JSON files of our ACF field groups. And we are pushing them with GitHub, to GitHub, of course, and then we are synchronising them on production director and production, they are being pushed to production FTP, and they are being synchronised on production. So we do not have to go there. And at all field groups, they're separated.
Okay, and you mentioned WP migrate. So it was created. This plugin was created by Lucia brains. And at some point, they even tried to create, let's call it a git repository for the for database for WordPress. And even with their tremendous experience, they just failed. They failed. They say it's at this point, it's impossible in the corporate environment. So. So yeah, I think that the the project barding described is one of the most of the most popular when it comes to migrating database in some way. Okay, so let's see what we have. What we have next questions from Carlos, why is timber instead of sage is tweaked down the reason.
So, maybe I will try to explain that all of our developers know twig last week, and we are mainly using twig because of that. And the other reason is that sage is using blade templates. And twig is more strict here. So we are not able to use the whole PHP parts in in timber. And we can do it in sage sage, in this case in blade. So in my opinion, that's the only reason why we are using timber instead of sage.
Yeah, also, I can, like, drop a few cents here because I was the one because I worked at home studio at some point. And I was the one that who convinced the company to use to use timber. And yes, the fact of strictness was was one of the reasons I mean, there's nothing bad in light play, this is also really cool. And the only thing is how to tell it. I was never a person who trust other people. So if we, if if timber was more strict, it was it was the better approach, especially at the time.
Yeah, we are building applications in Laravel is well in Osom studio. But we decided to use use timber for for WordPress applications here.
Okay. Okay, so, let's see now something What else do we have? Okay, now we have a question from Sam Hogan. What is the future for WordPress development? And its competition.
Okay, so WordPress currently holds nearly 50% I guess, of CMS market here. So in my opinion, there is no competition here. WordPress is is the most popular CMS for sure. And I hope that the whole community will grow, grow and keep growing. So in my opinion, there is no competition for WordPress in this case. And what's the future in for web development here? In my opinion, there are two ways. The first way is to use headless WordPress. So I guess that we will agree with that, that that word is okay for clients. And it's quite user friendly. So we will let clients to do their job in in dashboard. And we will push it then with REST API or Graph QL. API to to front end, which will be probably some Jas framework, for example, next Jas or something like that. So So that's, that's the first way another way might be generating static files as you do on your project, WP O's, which makes the site more much lighter and much faster for sure. Because we are not asking DB on and on so. So in my opinion, there are two ways of of this.
And it's much it's much deeper. This was the reason why I went into it was just you. Okay, at now, yes. Hi, Patrick. I knew you would come up with something like this. How do you handle core plugins themes update and if by using composer update, how do you handle WP plugins update flow the activate plugins before update because composer didn't do it by itself.
Okay, so we are not only using composer. To do that, we are also using manage WP, which allows us to do backup for our staging environment, for example, right before updating the plugin, so it will do a backup before updating the plugin. It's called Safe update. It's updating the plugin then it's creating the dentist pushing the plugin to the staging version of the site. And you can compare screenshots as well. And if something went wrong, you can revert to the previous version or check if everything works fine on on staging environment. And if we are sure that everything works fine, there we are updating it in composer doing the same flow and then pushing it to production. And that's all change log to be sure that nothing major change there. So
okay, so you want to tell me that you are one of those company that that really does this because we for every update, we can read in almost every plugin, make a backup backup before updating cried and I never saw a person that was doing it. And this worked. Well. That is impressive. Okay. And here is a question from Mike. What is the difference between WP engines local and the Kinsta?
Okay, so to be honest, I didn't have chance to familiar familiarise with WP Engine local. We choose def Kinsta. Because a lot of our clients, as I said, is hosted in in in Kinsta. Only a few of them is hosted by WP Engine. And probably they're using the same thing. So probably they're using Docker. I'm not sure. So I don't want to mislead you. But in my opinion, they are working in the same quite same way. Here.
Okay, and here comes the last question is from silvium. How should you generate a static version of your website during the workflow?
That's probably a question for you because you're generating your own project to a static version. So
yes. Okay. Thank you. Thank you. Yes. So, overall, there are three approaches to this. First of all, we're in the WordPress territory. So yes, there is a plugin for this. Personally, I am a big fan of WP to static plugin. It's it's really nice. It works. It just works. It just works with without any problems together with WP CLI and Buddy. This is the approach I'm using for for my newsletter WP hours. And I think that if you are a control freak, this is really a great tool to use because you have full control over the process. So this is this is interesting. The second one, we can think about using a service that we haven't had a webinar together with Nate Finch from Stradic about how to connect body with Stradic. So if you don't, if you aren't a control freak and you just don't care how the static site is generated. I think that services like Stradic are a really great way to go. And of course, if you are not a big fan of, of PHP and there are lots of static site generators, you can use Gatsby you can use next. Jas, of course by connecting them with with WordPress and connecting them with WordPress through either REST API or Graph QL API. So. So those are three ways you can achieve this every every way, can incorporate Buddy on its way. So you can run tests, you can add some staging sites before. It's really up to you.
Right. So that's Mario szatkowski said that you can also use WP CLI that would be dB import export for database integration. Yes, we are using it mostly, in this case. Yes. So we are using search replace, and we are exporting and importing databases with with this command. We are also turning off turning on some plugins, etc. So we are using the Ruby CLI in our agency. It's also built in Kinsta. So you can use just to go to the client, SS H client and WP CLI is already there. So let's go stuff.
And this is for me. Thanks, Margaret. Do you could you provide a default WP setup library for a perfect git Git flow, for example, GitHub master to the environment. So this is I think that I already have it set up you can find my repository, it's called WP Sasquatch, is its bedrock together with, with timber and so on. You just have to fill out the environment. And that's all I throw a composer of course, and it will work. It's it's really simple as that. Okay, so I think we have we we are out of, we're running out of time. But I know that there were some more questions, we will try to create an article soon. And we will try to respond to them all because they are really, really interesting. So keep an eye on this. Thank you very much, everyone. Thank you, Bartek. For for spending some time with us. Do you have something to add? Before we we wrap this up? Yeah,
thank you for having me here. And the only thing I want to add is that we are looking for web developers. So if you want to join us, join our team, feel free to go to auto studio.com And send us your CV and we will stay in touch for sure.
Okay, from from my end, I can say that I like I mentioned I had the chance to work there for a while. And so if you if you'd like timber if you like bedrock and you are not afraid of Gutenberg, it's a really nice place place to work. So thank you all very much. It was it was a pleasure meeting you of course in a in a digital way I saw that we had people from really around the world or even so someone from Mexico so so really we are we are very happy that we that this webinar was so worldwide and what can I say? Thank you and I hope that we will see each other soon because we are already working on on the new webinars so so follow us on Twitter, on Facebook and on other social media. And when it when the time comes, we will inform you about the new webinar. So thank you everyone and have a nice day. Bye Bye