 So hello everyone guys, I'm very thrilled to die today with you and I would like to talk a little bit about approach of, oh sorry, sorry for that, a little bit about leveraging well-structured themes for the project success. So I was introduced a little bit before but what needs to be added probably is that I'm a CTO in the awesome studio and also I'm a co-founder so my point of view on the creating the project is both as a developer and also someone that needs to meet you know the expectation of the business side of the you know client and so on. So I will talk about you know way of thinking how to approach the projects and also what we what we've what we are doing to accomplish the project's success. So first of all maybe so-called agenda what I will be talking about so way of thinking like I said the importance of planning ahead when we are working on the long-term projects because projects are not only you know just build a website and ship it and publish it and forget about them but it's a long long process that can take like not only a week's month or so but it might be much more longer. I will talk about a little bit about the toolset and libraries that we choose to accomplish these goals and how we are creating the project architecture just to you know meet the expectation of long-lasting project and last but not least what is important in the project is how people are working in the while doing this this project and developing it in teams and so on so let's think about and maybe define the project that succeeds so the projects that succeeds needs to meet some few bullet points which is delivered on time and within budget this is probably like the the most important thing if you are on the business side of the website development from the perspective of the developer there is there those there is very important to create the website that is back free and easy to maintain in the future so while combining this this all of those points we are really going for the client client happiness and while talking about the copy happy client the happy client is when the the website is working smoothly and for example the team of the clients like I don't know maybe marketing team is easy you know for them it's easy to you know handle the website to you know manipulate the content and so on to build like a new sub pages and easily in you know in a quick quickly time in the manner and so on and so on so basically to you know do it's right we need to put some effort in a project to meet those expectations so but let's think about what the project is and how the process of the project looks like most common project has like a few phases when you are I don't know developer probably you will be involved in like the development the maintenance for a phase of the project however before that we have like workshops in which while we are for example trying to figure out what the client really needs what are the clients expectation from the from the project and so on and normally takes some days just to you know get the feeling of what the client will expect from the website after that there comes the part in which the designer is involved and bug in the in this in this phase the graphic designer creates the user interface creates the user experience part of the project and so on and normally it takes a few weeks if we are lucky enough as developers we are probably involved in this this phase and you know we can give some I don't know give some information that hey this is doable or this is not doable because you know sometimes the designers things that they paint the website as I don't know some flee or something like that it still be working on the web but it's not like that and after that there comes those phases that probably is very interesting for us which is the development of the maintenance and if you see how long it can take you know the development of the MVP probably takes from weeks to months it really depends on the scale of the project but after that there comes the maintenance part is and it can take years especially when we are building for the enterprise and you know it's big companies cannot afford to you know rebuild their website every every year and so on so what they expect from the developers is to create the long-lasting project which they will be able to extend in the future so this is like very important thing to do so what's not to do is very it's very important not to jump into the development you know right after you receive the UI from the you know from the designer you get the figma and what what you really you are starting to doing it's better you know just to spend one one or two days just to think through the whole figma design and so on for example when we are developing the the projects we are spending some time just to know the project think about the reasonable components identify them and you know write down every single page what some something like acceptance criteria when when the project will will be successful and when the view on which we are working will be accepted as the one that should look like so what is what if we are not doing it right maybe we can in the future we can find ourselves in the situation in which you know after one year of development of the extending of the website there comes you know another change request from the client and we say that okay you want another sub page but it will take like 100 hours and why because we didn't think through it for example we built some or had coded some page templates and right now any any you know even a small change can like takes a lot of hours and it's it's building you know it's or rather it's through it's destroying our credibility in ice of the clients and it's really not not that good especially those kind of situations happens when for example companies are trying to build very very fast any website and they are going for I don't know building the website but not developing it what I mean is that they are using tons of plugins page builders and so on and so on and and they find they are finding themselves in the situation in which there is no option for further for further development of the website and basically this is literally what's happening for our clients because they are coming to us with websites that are very sluggish are working very slow and they are not able to you know build any sub pages for them so what we tried to you know do to not be that company that has that create creates those kind of projects is that we try to standardize everything so if what does it mean the standardization the standardization means that you are building a process building a process in which in which you are shipping the quality products quality products that are easy for not only are not good only for the client but also for the team that develops them and what we standardize is to how to develop components how to you know decompose the whole project and after that when we have like while working you with the rule of divide and conquer probably you know this this rule from August or something like that and then the ease of code review give us an extra boost of creating the quality software and with the proper automatization then you are like really really agile in agile way create a product so what we how we achieved it we achieved it with a set of technologies so we've built our own boilerplate while we were searching for for solution that will be right for us and we've built the juniper juniper is basically to some tool set of few libraries that are enabling us for to create very fast websites that are coming are working with the Gutenberg and they are easy to maintain in terms of CICD process and so on so we are using timber bedrock ACF blocks and also some Cypress if there is a need for the unit test on the front-end site and also page PHP code sniffer just to you know make make the cooperation a little bit easier but what was our idea behind creating the those this boilerplate because probably you've got tons of boilerplates on the market so first we had like a basic assumption which was like avoid endless functions behind PHP files which is very common in a project that are right badly and also separate UI with business logic so with this in mind we've tried to you know structure the project as good as it can be but how to do that the best way and to do that is to you know go for the basics and the basics are the design patterns probably you know or I hope you know those two books that are very important if you are an engineer working on day on regular basis with the code then probably you had a chance to to read clean code or maybe you know the uncle Bob or Bob Martin and also there is a book about it's much more heavier let's say a design patterns in a when where you can find you know some ground rules of how to build a solid object oriented object oriented project so so with this this thought that was like a ground rule for for our project we've built like a structure as in all of the boiler press so we've just split we are just splitting each every every project in good for into the blocks for the Gutenberg for the Gutenberg and also placing in a in a way that is well organized the business logic the custom post types taxonomy and so on so on just to you know have it just to make it easy to you know navigate for the for the project and to help build project in the object oriented way so as I've mentioned before design patterns are very important in the in the in the while you are thinking about the project architecture and what is in what is important that in the WordPress we have like total freedom and the freedom has also its costs so freedom the WordPress you know it they do not give us the guidance how to write good code we only can find in the codex the functions how they are declared what are the functionality of the functions that you will be using but if you will try to find like the ultimate guide how to write the code then it's very very hard to find it so what we wanted to do is to search for the you know for the for the way how to create the WordPress projects in the in you know in the way in the world of the design patterns and the closest thing that is also implementable is in the in the WordPress is MVC like pattern and it can be done by the timber so how it really looks like in the real life example let's say that we want to want to create some I don't know jobbot and so on probably you've done it like a lot of times so what what is the model for this kind of for this kind of jobbot so a model in the this the view in this pattern is a representation of the data so in the closest thing to the data implementation in the WordPress is a custom post a post type and we and when we are creating and we are thinking about the database this is the this closest thing that we can find because normally we are not we do not have the same you know records as in older frameworks PHP right frameworks but this is a little bit different in the WordPress after that we have the controller and the controller is the layer that will be working with both reviews of view and also the data model so you can while you are doing this approach there's a very you are building the unique layer of the of the logic between you know something that is being starts not only in the database but you can also use the you know files and so on so with this approach you are getting really closer to to you know separate totally different layers of the of the project itself at the end with the tweak file when we are passing the context for example to the to the views to the view we are able to you know show the and generate the HTML an easy way to you know just just to keep everything separated and what is like the final effect for for this first of all we have like cleaner architecture so we have front and back ends totally separated it's and it's like what's our first goal when we were building the the Juniper boilerplate and the something that is additional to that is that when you are decomposing the whole the whole team you are able easily to you know a separate CSS or JS for each come Gutenberg component and what do you have after that like I said before there's like tons of projects which which has built with you know the the page builders and so on and while they are built with the page builders you probably so most of them have some problems with with the speed and so on it's due to that they they you know the way how they work they I drew they are generating a lot of bloated code and so on so on so one of our projects for example that was previously build of the builder with the page builders we just we wrote we wrote the front end part and then we reduced by a lot the speed of the of the website so if you if you are trying to you know make the the project to work much more faster then it's very very good to build with proper with the proper architect and so what else do we really get not in it in a manner of you know technical stuff while we are working with the with the team and we are all using the same boiler plate then it's much more easier to you know navigate through the project if it's you know if it's a standard thing in your company so with that with that you get is much more easier code review process because you have smaller components and when you are working with a team then everyone knows how to you know approach approach it and know what's what for what backs for for example they can came search for so yeah basically this is what you get from the from the nice and clean architecture we've also used the bedrock as a you know as a base base base for our projects due to the to due to the advantages that it gives and it gives a well structured well structured project and it's not only you know changing the directories and so on but it gives like a lot of cool features that enables the whole process to work smoothly and those process is that we are much more easy with we can easy we are easily able to maintain the whole CI CD process and so on so what give us the broad bedrock bedrock are giving us the dependency management system and with the composer it gives us handling different setup of the environments like development staging production and so on and it also is quite good if you in terms of you know storing the whole project in the git repository because you are you know they are not storing all the WordPress files in the repository you are just keeping the theme only keeping the theme and the most important files so with you know making so just I just recommend usage of the bedrock are so even if you are not using any specific team or you are using your own team and at the end we what we've done or we accomplish at least is that we I hope so at least we've finally entered the war between what is better than taps or the spaces so in our CI CD CI CD process one of the one of the thing is that we are trying to trying to keep the WordPress coding standards so it's with the github actions and everything else that's much more easier and you know it's can it can speed up also or get the team work much more efficient than if you are not doing that so thank you very much for your attention if you are looking for the juniper and so how you know want to now just give a look into this then the QR code will lead you to the to our positive repository yeah thank you very much thank you again Thomas if there are any questions please raise your hand okay I imagined you had question thanks hi so you have in your sorry I can do it in the structure of the team I've seen that is an ACF JSON folder why did you choose to leave the files there instead of moving everything to the code base ACF JSON files are there because you know when we are sharing the code between developers there's always a need to synchronize all the fields so basically this is something that from my perspective needs to be there so this is why we are we have it in our theme and if you are you know just getting the code you just you know click the synchronize and everything works so okay don't you have any problems with the production website that overwrite the fields and stuff like that sometimes it's happen happens but you know it just is just a matter of good review process because if someone you know changing the is changing the database the ACF's and so on then in the review process we see what has changed and we are trying to merge it not to avoid any conflicts on the production and so on okay thank you very much thank you hi before you spoke about continuous integration and I was wondering are you continuously deploying only the theme to a WordPress website that resides for example in a VM or are you able to integrate a continuous integration system with a WordPress web website deployed on Docker or Kubernetes normally we are not using Docker on a regular basis but while we created the CI CD process we are pushing not only the theme itself but we also are trying to keep on every single on every single environment the same plugins for example so when you are updating some libraries via composer then we are pushing them also the CI CD process fine thank you hi Thomas was a really interesting piece thank you I really appreciate that I have a few questions okay okay okay I started with the first one and I am I see that you choose to put the business logic inside the team yes why put inside the team instead of putting in a in a feature plugin for example basically why we are developing the the business logic and we think about the business logic in most cases it's a one-time shot let's say for so for if we are developing a custom theme for the for the client then we are we know that it will not be something that will be reusable and this is why we are not going for the plugins and so on and also by the business logic I mean that you know the manipulation of the data before you just show it on the you know on the view so basically getting the custom post type data is also business logic in terms of you know okay so you basically use that the team like a whole application yes exactly okay okay second question okay okay in how you document and share your development practice across your team do you document do you write something how to do these we have like we do not have like a very big team so it's much more easy to you know to share the experience but what we are doing is on a regular basis we try trying to make the awesome camps let's say this is the our meetings in which we are for example sharing a knowledge between the team everyone knows and everyone knows the structure of the theme that we've created because they are on a regular basis they are doing some extra code for it so where they're working on it and basically in most cases we are just when we are starting for the projects let's say then the product the project documentation is in most cases created in the project management system so everyone has been access to that so I don't know if I answered your question but yes you're fine enough okay thank you thank you any other one was questions okay before you spoke about keeping the WordPress coding standards in Europe series but the WordPress also has fine naming standards for example that are not compliant with PSR4 so how do you manage it to keep your code in kind of compliant with WordPress but using some modern PHP features like auto-loading basically we have some workarounds that are there in the junior pair itself so I know that it's not compliant of the PSR but the what we are using the word postcandidate standards for is that you know when you are working with the team then everyone everyone can have their own setup on the on the local machine so as a setup I understand the way how you know those spaces tabs and so on are being created and if you are merging this code and everyone else like total freedom in that then while putting it on the git you will see like total you will see changes in every single line even if there was all only a space has changed on something other so basically with this we are trying to avoid differences between the environments between the people that are working on the projects thank you