 Thank you Francesca for a nice welcome words. Hello, everyone. I'm happy to be with you here. Thank you for coming My name is Anna and for the last seven years I developing websites for Android charity project in Russia I run a small web studio and from this come my experience What I would like to share with you today When developing a website is your primary activity there are number growths and time And you may work on the several projects in the same time and you may adopt new techniques And surely you would use their third parties code actively because it's open source wall And in this case you have to be sure that for each project you are working on you have the correct version of the all libraries that you are using because they are updated all the time And you have to maintain the compatibility to avoid conflict and if there is Some other people in your team, even if it's small team There is another level of complexity Because you have to be sure in the same thing for every developer and every instance or installation they are working on and Finally, there is a version control question Because generally you don't want the third parties code goes into your appers because it's Not good, especially if you are going to make it public The long story short that means that when you don't have a Formal tool to manage all these issues they quite quickly become a trouble and Today I'd like to introduce the one of possible solutions for these For this trouble. It's composer composer is a package or dependency manager for PHP It opens source itself and anybody could use it absolutely freely But I'd like to share our own experience how it could be Implemented for existing workflow of developing web WordPress based websites What is the dependency by the way It's simply the third-party code library or framework or plug-in or something like that that you are using in your own project And the concept of dependency manager management is quite popular among developers Especially if they are dealing with open source code and composer. It's just the utility which allow you allows you to Structurally a project well and to also mode the install and update process of all these codes Through all the installation that you may have in development environment and testing ones and staging and so on and so you became the the Lord of libraries because It's Became quite simple for you. You have the solid least and solid template for using in every project So let us first of all briefly discuss how the composer work itself First of all, you have to install it in your system Better to do it globally so that it could be run in every folder without any additional adjustments and Composers website provides the detailed instruction how to do it for a particular operating system So you need just follow them and you are done. There is no any difficulties and The second part of the equation for introducing the composer into your workflow is the configuration file It's the composer Jason and there you can describe your project give it a name and version and other details and options and What is the most important? Specify all the dependencies all the libraries you are going to use and where to find them When you have the proper formatted composer file For your project it could also be considered as package You can release it publicly if you want or use it internally inside team and privately in your environment But it generally could be done Where to find those compo composer compatible packages first of all there exist Composers specific repositories and registries where they could be fine and But actually any other sources for open source code like github with bucket and our Stories Would be would do the trick for you because they also could be library that Compatible with composer workflow and finally you create one package or several packages yourself and story Them and the way you like in your own reperson github or release them for public registry So all this way are a lot allowed for composer There is the packages.org. This is the central registry or official registry for composer It provides the simple search Interface through packages and even the word press core itself could be found there and use this dependency in our projects Actually in your configuration the packages.org could be omitted because composer looks through it by default We can add this libraries in our project using for example a common line commons And in this case we should add them one by one specifying their type of wrappers and address for them and the list of each Each dependency, but the most more convenient way is to specify them manually and into the configuration file list them all there and the thing to be careful on this stage is the version for each dependency for each plugin that we're going to use and as any other package managers Composer provide us with a simple and reliable syntax that allows us to Specify the range of versions that we are going to use or specify the particular version Sometimes it's more convenient to use the cave words For example to specify just the latest stable version for your project Especially in WordPress work flow is the most common approach and we use this all the time And finally we run the common composer install We became quite quickly addicted to it because it's open for door for new projects It after most the all installation process composer itself looks through specified Repositories download all dependencies and allocate them bar default and vendor folder so That's the common logic and it's very simple as you can see and anyone could use it in the general PHP application and Surely it could be implemented to WordPress also because Starting from the core itself there itself. There is a lot of third-party code that we are going to use in our projects. So Let's go through it logics Which problem we have to overcome in this case? first of all WordPress has its own tools and Has its own Métanism for installing plugins for activating or deactivating them or managing them inside WordPress dash bar dash bar directly it also has the The tools to updating them and updating the core itself but these tools are intended to be used by site owners who Intended to be not tech savvy users and not developers themselves So for them there is no this repetitive task no repetitive part and that we Meet in our everyday lives So being developers we need the automation tool and we need go for the And these solutions couldn't couldn't be helped for us that's why we are thinking about a composer but We have to take into consideration the WordPress project structure in Common WordPress website. We have the core files that save that results normally in the root folder And then we have of course the VP config file Which is specific for a particular installation Then we have the content folder that includes plugins stem languages inside and finally the uploads folder with Made a file store need and we have to consider and preserve this structure because Otherwise what press wouldn't be able to load to find and load these files but When we started to think about the introduction some new development tools and our workflow inside our team we actually Wasn't intended to use compors or something like that. We were looking for the answer for the simple question What should be under version control? It sounds simple, but it's a bit tricky and because For example, we started from comedic every File all the code into our own wrappers it mean comedic quarry files and being comedic plug-in files and so on and quite quickly we find out that it's not a proper thing to do Because your History and your merge pro process and your branching process became the mess quite quickly because if you update any Plug-in it should be Merge properly there are conflicts and there are a lot of trouble with that and When we understand that only our own code should go into Version control it drives some other questions what court hours what could should be Considered as dependency And what tool we should use and we discovered composer after that and Where composes are compatible Repositories if we're dealing with WordPress because we get used to download files from what trace dot org wrappers and for example and so on and Finally how to preserve? the structure of the folders that what present WordPress needs and What to do with vendor folders in this case? We started to explore these things from Trying to find the working examples and I would recommend at least two sources to do this job if you would like to go out past Because these sources provide us really good solutions they work and they have some advice is how The composer configuration could be adopted to to using with WordPress But we are now going to consider all these step-by-step So first what is dependencies? It's quite obvious that the most of plugins or for example language part could be considered is dependency In our team we have a convention that all our code that we write ourselves goes in the same files Despite the functionality and performs performs. It's it's made just for simplicity, but it appears to be quite good approach But the main thing to understand is that the core is dependency itself And we would like to use it as dependency also But that means that we have to tune the project structure because by default the core files are go to the root folder and the content files plug-in and terms are go inside and composer wouldn't be able to handle such Such logic, so we have to separate them We have to is a layer we have to have isolated folder for core files and Is a later folder for content files Fortunately, we're press allows us to do that quite easier. There is very good Articles in the codex about the approach how it could be done, but actually We simply need to adjust settings to show the WordPress address should contain the core folder in it Inside address should be stay intact and include only domain is value because we would like our permalinks to stay clean And then we have to add the custom path for the P content folder in the config file. We pick and pick that means that VP content would be put out of the core folder And they will be in the same level in the folder structure and this logic is very easily handled by composer then there we should find the WordPress specific wrappers to To work and to find our libraries there As I mentioned before the core itself couldn't be find in the packages.org and quite reliable source and It is updated there quite regularly. There is no problem with this source For plugins and then we have e-packages.org registry and They are all plugins and all them released in the official repository and what pres.org are mirrored So that you can find them there and just copy the name the proper name of the package and its version and list them in the Composer json for language pack there are also exist the registry maintained by community and nearly every language pack could be find there and December flow could be a repeat and Finally for some private code that is not released publicly we can use the local folder in this case Each dependency for example a plugin has to be zipped and stored there is a zipRT file the file name should contain the Package name and its version and inside goes the plugin code itself in a proper Composer json that Contained the name the version and probably some other settings When we find out all these All these sources we can list them in Composer json under the repositories Section the Composer site provides the detailed Explanation and detailed documentation for the syntax of Composer json But for repositories, we just need to specify the type and the address and After that we should deals with the vendor folder We just we need to alter repeat the path where our dependencies would go but ironically the vendor folder should be preserved because there could be internal and dependency internal plugins that composer use for its own work and They are also would be installed there For the just logical reason we used to move it under the pcontent But it could be specified under config section and there could be some extra Configuration for example the name for main WordPress folder. We call it core, but you can use any name you like And there is a drop-in path It's a plugin that allows us to have the several language packs To be installed in the same folder without Composer to overwrite them and it's quite important to multilingual features to work And finally We just can find every dependencies. We need to put them Into the config file also under require or require diff section Require diff section Intendent for plugins or for themes that we're going to use only in the development environments And finally we run the composer install and this Perform all installation process Automatically composer don't load the core files. They don't load all plugins that you're going to use and install them Into way into folders into pause. We are specified Is that simple? after that You can Work with the project we can you could easily replicate this in every installation for every branch for every person in your team and There is a mechanism that allow you to synchronize the exact version for each Case it's a composer log file where composer stores the snapshot of the particular Installation and when you need the update things for example afterward press the releasing the updates or After the plugin updates you simply run the composer update Comment inside the project folder and everything updated and that's all I hope