 Thank you Mario. So hello everyone. First of all, I'd like to start with two excuses. One is I've caught a cold while here in London, so you might hear me sniffling on every once in a while. The second one is, in case you've just read the title of the talk and are here for visual composer, I'm afraid that's not what I'm going to be talking about. It's not about page builders, just wanted to make it this clear, so to avoid people spending too much time trying to find out what's going on here. So a quick introduction to composer. Composer is by now the defector standard for PHP dependency management, for PHP package management. In WordPress space, this is something that has not quite yet caught on as well as in the rest of the PHP space. It manages the dependencies of your project. This means that when you want to rely on other people's code, instead of copy pasting it inside of your own project and then with time the code growing stale and getting out of date, you can just reference other people's code and composer will just make it magically happen so that your dependencies are always up to date. You get notified when there are updates. You get notified when there are conflicts. You get even notified when there are security issues. Composer can automate all of this for you so that you can concentrate on only writing your own code and all the libraries you depend on, they just work out of the box with composer. It generates optimized autoloaders to make this happen. So when you include a library as a composer dependency, it is automatically active as soon as you trigger the composer autoloader. So at that point, you don't need to manually include any files, require them just so they are present. As soon as you're dealing with composer, you can just assume that everything you have stated as a dependency, it just exists in your project space and you can just use it. Composer also can pull in the packages from very diverse decentralized repositories. So the default is a packages which is one that composer checks automatically, but you can just as well host your own packages on GitHub, on Bitbucket, on your own self-hosted GitLab system or whatever else you might need. And last but not least with the PHP FIC, PHP FIC initiative, which is the PHP framework interoperability group. Composer and the PHP FIC have pretty much completely changed the PHP landscape and it has changed from being a space where everyone cooks down solutions to the problems to a space where all the frameworks, all the libraries, they cooperate and for every problem you want to solve, there's ready-made solutions you can just pull in and use and you can deal with the actual business requirements you want to solve. So this is the link to Composer, getcomposer.org. Everyone who has not yet tried to use Composer, it is a very useful tool and it can drastically change how you work with bigger projects. Composer's role in the PHP project is very central. It takes care of the project's life cycle. So it basically provides an entry point to your project and this entry point then is a place where you can attach everything that has to deal with project life cycles. So that is all in one space. It provides separate production and development environment which is important because we all know that what you need for development are different tools and different setups in the different environment than what you need on your production server. So Composer allows you for example to pull in something like PHP unit as a development requirement and if you compile your project for production this is just gone. This does not take up any space, this does not provide any possibility to introduce bugs through side effects and so on. But Composer basically makes your projects self-contained. So if you need PHP unit around your unit tests, if you have PHP CSS to control the code style you can pull in everything through Composer and use Composer's version of it. So everyone that uses this project will then have the exact same tools at the exact same versions with the exact same settings all of a sudden and not deal with their own local installations and global tools etc. For every project it's basically you do a git clone with the project name to fetch the project's repository, head into that folder and then to get started with Composer it's Composer install and that's it. What happens at the Composer install step is what I want to talk about today because Composer is very extensible and it, you can do much more than just manager dependencies. There's two extensibility mechanisms in Composer that work a bit differently. There's the scripts and there's the plugins. They use the same hooks. So for example for when you do Composer install there's a hook to act on the install action and do something after that install action has completed and the hooks are pretty much the same just in a different syntax for both approaches to extensibility. However the scripts are meant to automate your project and they only run for the root package and not for the dependencies of a given project. Whereas when you're using plugins they always are active even in the dependencies of your project not only in your root package and they are meant to extend Composer itself, to extend Composer's functionality. The Composer script is the file where you configure Composer, the Composer setup for one given project and here you can see that we have a specific name for a package. We have a development requirement which is PHP unit in this case to run the unit tests and then we provided scripts. One script acts on an update action to clear the cache and we provided even this functionality of clearing the cache inside of this Composer script file. The Composer plugin however it's basically created through code so you still need to hook it up to the Composer script which we do by requiring basically the plugin API and then letting it know what plugin class to execute. But then the rest of it is done in PHP code. This makes it much more powerful than a simple shell script and it allows you to use whatever other code you have in your PHP space to combine it with Composer's functionality. You might have a project that always needs to run a specific operation when you're running updates of your dependencies and you already provided the PHP code to do that so you can do a simple Composer plugin to hook this up to Composer and just run it. I will now go through five specific use cases of going beyond simple dependency management of going beyond what Composer does out of the box. For the first one let's imagine that you want to include library in your code in your project and that library contains a bug. You've produced an issue on GitHub to let the maintainer of the project know, yeah well I cannot use your library right now. There's a bug that is blocking for me. You may be introduced a pull request to hopefully get it merged soon but if that project is not very active, if that library is not often maintained, it might take a long while for this pull request to be merged or it might never be merged at all. So in general when you're dealing with this problem the usual approach is to fork the library and use your own fork as a dependency instead. However this comes with a few problems. So forking basically means that you have a copy and this copy does not get any updates anymore. Also as you have a fork the name of the project changed, the name of the library changed that you pulled in as a dependency. This means that Composer when some other library tries to also require this as a dependency, Composer will have a conflict because it has two types of code that try to solve the same requirement and it will break. So you need to use a hack called branch alias to let it know well the code that I have here it's actually meant to be this code so every code that requires this dependency will be satisfied with this code instead. But there's only a hack inside of Composer to make this work and it often introduces other problems. With patching, patching is a way of applying a random change to existing code. With patching you can basically use the existing library just use it as is and when you pull it in apply a patch that makes the change that you need and you can automate this with Composer. This is much cleaner. It can be self-documenting because you can provide a specific explanation of why you're pulling in the specific patch. The patch itself it's very clear. Everyone can just open the patch. It's probably three lines of code that lets everyone know what is happening in there. So in general that's a much cleaner approach. There's a library you can use for this. It's called Composer patches. I've provided a link on the slides. This is how this will look like. So let's imagine because WordPress is perfect, of course, let's imagine we want to patch Drupal instead. With Drupal there's a problem for the startup configuration when you depending on which environment you run it in. So a lot of people need to always do the same patch because it's an ongoing issue that hasn't been resolved yet. So basically you can just pull in this patch and attach it to the Drupal dependency and every time you pull an update or a version of Drupal, the patch will get applied automatically. And as soon as that patch applies cleanly, this just works magically in the background. You don't need to care about this. But when the patch doesn't apply cleanly anymore, you will get an immediate error from Composer. Composer will let you know there's something wrong. We need manual intervention. You can just update your patch. Oftentimes it's just merge latest master changes and you're good to go again. A quick tip. Any commit on GitHub can be turned into patch by taking the URL of the commit on GitHub and just adding .diff as an extension in the URL. So it will return that commit as a Diff file. And so you can just basically for any commit on GitHub, you can use that URL, put it to the patch system and it just works. Okay, second use case. This might point to a problem where WordPress might not be that perfect after all. When you have Composer manage your dependencies in a central location, it can take care of everything, verify everything, and it is able to identify conflicts. So I think I'm standing in front of the slide. Sorry about that. If you let Composer verify all the dependencies, it can of course detect all the conflicts. In WordPress base, when you install the WordPress site, the problem is that WordPress core itself does not use Composer by default. So if you write a plugin for WordPress and want to use Composer, that plugin's Composer setup is only active in a specific place in the bootstrap code of WordPress. It does not start at the root of WordPress and it is not aware of the WordPress core code and it is not aware of all the other plugins that you might be running. So let's assume that you want to include a specific dependency and there's someone else's plugin that includes the same dependency. As long as you're using the same version, it's not a big of a deal. But if you're using version one and the other plugin uses version two, you have a conflict and Composer will not be able to see it and let you know that there's a conflict. So the behavior that will effectively be executed is undefined. It's just a matter of whatever code happens to be triggered first, that code will use its own outer loader and the other code will never be triggered. So for Composer, there's a way of using a system to prefix your namespace for your own plugin. So even though you cannot guarantee that there's no conflict with another library, you can guarantee that you can always run your own version of your own code. Because PHP does not allow a given class to exist in the same namespace twice. Prefixing the namespace makes it possible to scope your own version of the library, scope it to your plugin so that your plugin runs with one version of the dependency and the other plugins can run with a different version of the dependency. This project is by Cohen Jacobs. It's called Mozart. There are several libraries that do this. This one is the one that was specifically built for WordPress to solve this problem with plugins. So it's probably the easiest to use in WordPress space. And what it does, sorry, what it does is basically it lets you configure a namespace prefix for a given dependency. And then with the command line tool lets you regenerate the code of that dependency with all the namespaces prefixed. So as you can see here, it uses the dependency Pimple, which has a very nice name for a service container. And it basically prefixes that library with the plugins own namespace prefix. So when another plugin uses Pimple as well, which is a pretty popular package, which is a problem you can easily run into, then this will still work. As you can see, it properly prefixed the namespace, it probably prefixed all the imports that the code did. The third use case, keeping data up to date. So I had in a specific project, we had a requirement where we wanted to map specific IP addresses to a specific country to add logic that is country specific. There are databases online that give you this mapping where you have huge databases of IP addresses and how they relate to specific countries. But just pulling in this data in some form means that you set yourself up to be responsible for maintaining the data, for keeping it up to date. And I'm a very lazy person as a developer, so generally I try to avoid making myself responsible for things I don't care much about all the boring stuff. So I tried to hook this up into Composer, which you can actually do very easily. So basically I created a Composer plugin that downloaded the database and produced PHP config file out of that database that the project can just pull in. And now the state of the database, the versioning of the database is coupled to Composer lifecycle. So it's directly versioned with Composer. The database is updated every time I do a Composer update. It just works automatically. In case there's a problem with downloading it, I get an immediate error with Composer, which is better than for some systems that just one in the background updating every time and in case they fail, nobody even notices. It's always preferable to have hard errors when something is off. So in this case it will probably update on Composer update the database and if any error occurs, you'll get a Composer error during development time, not an error at runtime on your production server that happens randomly. This is how this project again looks like. So basically we require the it's called geolite2 country that is the database that we happen to use in that case. And you will notice that it contains, let me, it contains code that fetches that country database verifies the integrity and turns it into a proper file to include. Now here in this animation you see I'm entering a debugger to play with the code and I can verify that I can indeed instantiate the reader class for the database and query it for a given your IP address and I get the country in return. So here this is the reader class that is provided by the database provider that provides the set. So you can see we read the country for a given IP address. I think this is set up a bit slow. And now if we echo the country's name, we get the lovely United Kingdom. Another use case, commit hooks. Maybe some of you already work in teams where you try to get all the team on the same page when it comes to things like code style for example, whether you use tabs or spaces or emojis to line out your code, whether you want to use records in front or in a new line, et cetera. So normally this stuff is best solved by automating it away by using tooling to just not need to bother about it so there's no discussion anymore about it and you can enforce this with commit hooks, et cetera. The problem with these git hooks is that you don't need to enforce everyone to actually activate the git hooks because you cannot just add them to the project itself. You need to provide some way for every single developer to run some actions so that the git hooks become active. So again I wanted to just get rid of the entire problem automatically and tie it to Composer. So I worked on a framework to manage git hooks through Composer packages, through Composer plugins. This offers several nice advantages. First of all, the git hooks are treated as development dependency. They are active on your development setup in your development environment but you don't need to care about the production environment. They are completely gone. Also, as they are now part of the Composer workflow, they become active immediately after your Composer install step. That one step that every PHP project is forced to do, the Composer install step, is the one that takes care of also enforcing the git hooks. And then of course you can use PHP code in your git hooks, which is also nice. There's all sorts of libraries you can use to develop the logic of your git hooks, et cetera. And I even added a way to provide multiple hooks on the same git action and you can prioritize them. Because generally git hooks work by putting a file somewhere with a given name and if you want to add two separate hooks on the same git action, you'll have a conflict because you need to merge this file because you cannot have the same file twice. The name of the project is called PHP Composer because after I've excluded all the variations that already existed, for the clever names I had, this was the silly one I ended up with. Here's how this works. We basically have a way in our Composer JSON file to configure the hooks we want to use and we pull these hooks in as requirements. Sorry, this is the slide about how to actually create hooks. To create the hooks, it's basically you can define what action to run. It can contain a priority and then you have PHP code that can define what happens on your pre-commit hook. And here's actually how you use it. So in this case I'm using a pre-commit hook to enforce PSR2, which is a PHP code style standard. And the first example here you can see that I'm adding a file and trying to commit it and it will just be accepted even though the formatting is questionable. After this, I require the PSR2 commit hook for Composer as a development requirement. So there's the dash, dash, dash. Composer pulls in the logic and now if I do the same thing for second file and add this file and commit this file, you will see that PHPCS will immediately complain because what we've written there is not PSR2 valid code. So Ed, I'm talking too fast. All my videos are so slow. So as you can see, it now produced errors and I didn't need to introduce any manual step of making the hooks active. It's just a matter of doing a Composer install for the project and they are active for every developer. They need to actually do additional effort to get rid of them. The last, no, the fourth use case, it's about something that was bothering me. I tend to create a lot of small modular packages and it's always a lot of hassle to set them up, creating the read me file, the change log file, the git in your file, etc. There's a lot of opportunity to forget something. So I created a system to use Composer to get quickly up and running and produce all the boilerplate code. So basically I can just define some basic setup that matches my own workflow and then use Composer's built-in create project functionality to clone a package, create a new folder out of that package, and then run all the Composer plugin functionality. And in that plugin functionality, I have code to ask questions and then later replace placeholders based on the result of these questions. Again, a quick demonstration of how this works. So basically the Composer create project is a way of creating a new project out of an existing repository, out of an existing Composer package. In this case, it's my boilerplate package, actually. And once I run the Composer install, you can see that it asks questions, where I can either accept the defaults that are set up for my own packages or I can overwrite them with custom settings. And as soon as this is all run through, it will take the template files that it has and replace the placeholders inside of these template files. And it even does a quick run of PHP unit to make sure that everything that it created is actually in a proper state. And as you can see here now, I have a properly set up package with all the files I need, change log license, et cetera. And this process now takes me, I'd say, 20 seconds to get up and running with a new project and be ready to start writing the actual code. Last example is to show you how flexible Composer actually is. It's about embedding Composer to use it for something that's related, but actually something completely else. In this case, when you embed Composer, you can use all of the functionalities it has to pull in repositories. You can use its file system abstraction. You can use all of the hooks, the hooking system, it provides the flexible plugin system and basically use this from within code instead of as a command line utility. There's an active implementation of this that a lot of you might already have used. Composer is actually embedded into WPCLI as the package manager that it provides. So WPCLI allows you to install third-party commands that you can get from GitHub, from within a private repository, et cetera. And basically, this package manager is nothing more than embedding the source code of Composer into the actual package command that we have. And in this way, not only do we get a lot of functionality for free that we didn't need to implement and most of all don't need to maintain in the long-term, but more importantly, this now plays very well with Composer itself because WPCLI just stores a Composer JSON file in a hidden folder in your user's home folder and you can even manage this with the direct Composer tool outside of the WPCLI package manager. So the functionality works with a regular Composer as well, just as it works when you use Composer to manage your project and WPCLI happens to just be a dependency. Everything just works automatically because we've been using that mature package management system. Yeah, so this talk was meant to give you a brief glimpse of what is possible with Composer by it simply having a very flexible extensibility system. And I hope I could give you a lot of ideas of hooking everything into your own projects and I can't wait to see what you're coming up with and I'm always open to chat about new possibilities to extend it. Thank you very much. Can you give me a couple of questions? I hope you have some. Be concise in asking the questions. Anyone? It's just a simple question. Do you usually commit your log file? Yes, it's a simple question but also a good question which has led to a lot of debate. And generally you should commit your log file for root packages. So if you create a project, your project should include a log file because if you don't commit your log file, you can't reproduce a specific version of your project because the next developer will probably get different versions of the dependencies and thus will get different possible bugs. Is there an easy way to just say I want the exact version rather than commit the log file? Could you just say we have to use these exact versions in Composer JSON? You could do this but basically then setting yourself up to do the update step manually every time because if you provide ranges and do a Composer install and commit the log file, then your versions are being stored and as long as everything works, you can just keep these versions but a simple Composer update will take the latest available versions within the range that you specified. So it is much less work to deal with this. You should not commit the log file though for libraries that are meant to only be used for dependencies because in the end the log file will never be used except for your own development purposes because the library when it is being included as a dependency, it is not the root package and thus the log file is ignored. That's all really good. I've just started using Composer myself for WordPress based projects. One question I've got in the case of WPCLI using Composer, it seems to be, I don't know whether it's just the size of WPCLI, but it seems to have a huge dependency tree. So if I try and install a package on my local machine, it usually runs out of memory after temporarily increased PHP's memory to like one gigabyte before it will install the package. Is there a reason for that? Is that just the size of it or is there something not quite right with WPCLI? No, thank you for the question. There's actually a reason for that. Right now the package structure of WPCLI is not ideal yet. So we're working on, because it started out as one single repository. We're starting out to spread everything out. And right now you have the framework of WPCLI and the bundle that comes with all the commands that are part of the standard installation. They are actually the same package. So if you, for example, if you just want to pull in one command, this command will require WPCLI, the framework, but it will pull in the actual bundle and pull in all the commands as well. We're working on refactoring this and the next version, V2, will contain some breaking changes but also some restructuring so that the framework and the bundle are two separate entities and the framework does not contain many dependencies at all. Most dependencies that are pulled in are either for testing or for the package manager because Composer actually has a lot of dependencies. You mean how to automatically test, to detect conflicts between several packages or I'm not trying to. Do you want to build a product? Do you want to make sure it was built? Yes, so. That project has no errors in it, basically validate that the build worked correctly. Yes, so generally you should build tests for everything and your deployment should be a build step, then a test step and then actually deploy step. So normally you try to achieve a system where basically you're building your new code on the architecture that it will need to run, then run the tests to make sure that the build actually compiled properly and all the tests are still passing and then through something like a switching around a symbolic link, you make atomic change in version of your deploy production side. So in that way either you will run through everything successfully and then with one switch you get to the new version or it will fail at some point and it will never deploy. For the questions, what do you think? Thanks very much. I was just wanting to check that I was doing something right actually with Composer. So I use Composer for creating plugins to then include dependencies for the plugins. But I use a lot of the same dependencies for different plugins and that obviously means that the same things are being included multiple times. Is there a way to stop that so that there's not such an overhead? Not within WordPress right now. So basically WordPress itself is lacking any mechanism of dependency management which would be needed for any project like this. And right now WordPress is lacking this dependency management so the problem you're facing is one of WordPress not giving you the tools you need instead of you doing it wrong. There's no right way right now to do it. There's only several different dirty compromises to still use it within the WordPress space. One of the main issues with WordPress that it doesn't have a dependency management right now is that generally dependency management is about throwing errors as soon as possible and making them very hard and loud errors. There is a conflict here. You need to deal with this because otherwise you might get subtle bugs that are hard to diagnose later. So please immediately deal with the conflict. And WordPress has a different philosophy. Basically WordPress never wants to forward any development errors to users. And the user is the one who decides how to combine the plugins. So dependency management across plugins would in the end always need to throw errors at the users and WordPress does not want to do that. So it's a problem you cannot properly solve right now not within the current constraints. So it shouldn't be too important to do very different jobs. Please. No, they actually do pretty much the exact same job just in a different ecosystem. So NPM is the package manager and dependency manager for Node.js which produces JavaScript packages just as Composer does the same in PHP space. But they practically do the same job. They have a few technical differences mainly due to language changes but other than that it's the same principle just as you have the Composer JSON file for Composer you have the package JSON file for NPM for example. I think that was the last question now. Yes, thank you very much for all the 10 questions. Thank you very much. Thank you.