 Thank you, so probably too many screens at the moment. My name is Oliver and today I'm going to be talking about Drushmake and Composer. I did have an alternative slide for this, which is Drushmake is Dead, Long lived composer. When I first started submitting this talk for Drupal conferences a couple of years ago, this statement wasn't technically accurate. I don't know it is. We were talking... === Dripwl Is anybody here using Dripall at the moment for things? Quite a few people, I'm cool. A few people, Peter is using Dripall 8 phones OK, cool. Also we were talking about composer, I guess most of us here are used to using composer. I've given this talk that had Dripall camps and group before... Composer for us was quite a new thing ond mae'r ddweud yn ymgyrch yn ysgolwyr, y cwmpôr erbyn i'n mynd i gyd? I'n mynd i'r gwaith o'r llwyddiadau, rydyn ni'n gwybod i'r ddweud yn ymgyrch. Ond Yrwyr Rhaglen 8 wedi'u llwyddiadau. Felly, rwy'n dechrau'n ddweud hynny. I'n cyfle i gyfferciwch wedi'i ymddangos Yrwyr Rhaglen 8. Rwy'n bach yn gwneud yr Yrwyr Rhaglen 8. Rwy'n bach yn ymgyrch yn ymgyrch yn y mwyfyrdd. gan bod i wneud y gwaelio'r gwaed rai'r cynnig gan y sym fan iawn, a roedd y gwaelio'r gweld Laravel. Rwy'n credu'r gweld federmeig yn gyfar environ garaed y gweld ychynig'u'u cyffredinol sydd wedi flynydda ni i ddweud eich gweithio'r ddweud a yw'r gwaelio'r gwaelio. Dwi'n gwneud fel rhywbeth ffraith yn cyfar fan rai'r cymdeithasol ar gael. Roedd yn gilydd ar y gwaelio'r gwaelio'r gweld i Laravel, amgarwch drwy cael hyn i gael gweithio'r gwaelio. I've used quite a few Symphony components that have not made it for Drupal at that time, and a big proponent of using now of our collections in my code as well. So I'm one of the lead developers at a company called Microsoft. We're a Drupal specialist agency based in Bristol, and we're one of the largest specialist Drupal companies in the UK. Acria certified Drupal 8 Grandmaster, which sounds pretty cool. I've contributed to Drupal 7 and Drupal 8 core, and I maintain a number of Drupal modules and PHP libraries as well. I also co-organised the PHP Southwest user group in Bristol, also the Drupal Bristol user group, as well as the Drupal camp that we're doing in Bristol every year as well. So there's two goals, I guess, coming out of this talk. The first one comes from when I was doing this at Drupal events. If you're a Drupal person not using Composer, hopefully I can think of something in this talk that you should be doing it. But also if you're a PHP person, just to generalise a little bit too much, and you've maybe looked at Drupal maybe a couple of years ago, maybe you're not considering it for projects right now, hopefully you can change your mind on that as well. And either consider Drupal for your project or reconsider if you've decided not to use it at some point. So just in case people aren't familiar, I'm going to just cover a little bit about what Drupal is. So it's a PHP content management framework. So I don't necessarily tend to use the term CMS or content management system. I tend to refer to it as a content management framework because it's a tool for essentially building your own CMS. So everything is in your control. You can build your own content types, your own entities, your own fields, your own data structure, your own list pages. You're not locked in to a sort of a standard set of those things. It's completely flexible. It's completely up to you as the site builder to build what you want to use. It's open source. So all of the Drupal code is hosting on Drupal.org as well as all of the contributing modules and themes and distributions. Cafiat, most of them are hosted on there. That's sort of the official place. Some of them are hosted on GitHub primarily or other places. And again, most cases, those are sort of mirrored back to Drupal.org and people are pushing commits back and forth. But DDo is where like all the issue queues are and like that type of thing. All our contribution system is all hosted. It's modular. So you download core. Core gives you extra functionality out of the box. But if you want commerce, for example, I mentioned commerce quite a few times during this talk, you can download extra modules, install them, and that gives you more stuff. So essentially symphony bundles. It's the same sort of analogy. Distributions. So you can download Drupal core. When you install Drupal the first time, some of you will probably remember this, that you can see two options and you see minimal and you see standard and you pick which version you want to install. These are distributions. So you can install the minimal distribution and get the minimal amount of stuff and you build it all up from scratch or you choose the standard distribution and it gives you more out of the box, gives you your articles, content type, your pages, and some sort of same defaults and maybe nine times out of ten projects you can want to use. There are other distributions. So if you're building a social network, if you're building a magazine website, if you're building anything like that, various things that are pre-packaged versions you can use that already have modules that you'll need installed and pre-configured already for you. Again, we'll talk about those a little bit more as well. Prior to Drupal 8, the code was mostly procedural. So I think Drupal 6 on my side involved everything's procedural. So very word-pressy, I guess if I can say that. Drupal 7 started using object-oriented code in places. So the database abstraction layer was object-orientated, the migration modules were operated. Whereas in Drupal 8 we've gone very much in all-in on object-oriented code. So we got off the island, I guess it's the phrase that we use tend to use for Drupal 8. And we've adopted the principle of probably found elsewhere rather than not invented here. So we've been bringing in third-party code and using them as part of Drupal rather than writing everything ourselves. And likewise in the tooling that we use, so all of our issue queues are built using Drupal. Drushmake, which we're going to talk a lot about in a minute, is obviously primarily based for Drupal. And those things are sort of now being phased out and best practice energy standard tools sort of coming in. SimpleTest is another example. Should we get to it? Yes, Drupal 8 is awesome. So I do a slightly more Drupal sales pitch. Because of the tools that we've been using, it's object-orientated code, symphony code, composer, guzzle, PHP unit, we're using part of Zend, we're using parts of Doctrine, we're using Stack, we're using modern libraries rather than writing everything ourselves, which is pretty awesome. At the last count, according to the symphony project page, 16 symphony components used in Drupal 8, which is again pretty awesome. Again, if you know those components, you can then pick them up and then reuse them in Drupal. So reusable knowledge for me is a big, I think, almost side effect of us moving to object-orientated code. There's an example recently, a story. I sat with one of our developers the other week and we're implementing a feature in a Drupal 8 site where a user logs in. We check if they've accepted the terms and conditions of the website. If they have, we can just redirect them off to the home page or wherever we need to redirect them to. If they hadn't, we have to take them to the terms and conditions page for them to accept before we can proceed. So we had a checkbox, a boolean field onto the user object. That was what we were checking when they logged in. So what we ended up implementing was the first version was very sort of Drupal 7-ish. We then refactored it to be more modern using a service class, which we call a terms enforcer. That was responsible for all of our figuring out, do they have the box checked, do all that logic is encapsulated there, and then we just referenced that from the three or four entry points where we had to reference it from. So when they log in, when they register, I think there were two or three others as well. So using a service class or our service class approach, this is reusable because then I was working on some symphony code that night, took my laptop in to work the next day and said, this is what I've been doing in symphony. This is using exactly the same approach using service classes. So it's a slight difference as we're calling it from Drupal hooks rather than from within a controller, but the principle was exactly the same. I think it's that reusable knowledge now we're not just learning Drupal 7 like we would have been before, and learning about hooks and Drupal specific things. We're learning about techniques that can be reused across other projects and other frameworks. I think that's why we're seeing traditional sort of Drupal agencies now expanding and working with symphony and Laravel and other frameworks as well, and also vice versa. So I think that's pretty awesome. Drush. If anyone's not familiar with Drush, Drush is essentially the Drupal CLI. So it's the command line interface for Drupal. So if you're thinking of being a console for symphony or artisan for Laravel, the slight difference being it's not included with Drupal core, so it's hosted on GitHub rather than on Drupal.org. It's got its own release cycle. It's a sort of separate project. I think it was first released for Drupal 5 back in 2007, so even since before I was involved with the project at home. So there's a few different ways we can go by setting up Drupal projects, so I'm going to cover sort of all three of them. The first is download all the things, and I think this is how I started out, and I think most others do as well. It's just to go to Drupal.org, find the Drupal project page or the module page for the module that you want to install. You get options for zip files or target zip files, and you download them, you copy and put them into the right place in your repository, and that's how you install your modules. Drush does offer a DL command, so a download command, which sort of does the same thing for you, so you do Drush DL, path auto, and it sort of automates that step, and then you just commit everything into your one big repository and push it, and that's fine. That's great. It's probably the easiest way to set up, get set up initially, but I think in the long term probably more difficult to maintain. If you want to then update a module, you have to delete the whole files, and then you need to download the new files from scratch. You have to copy and paste and replace the existing files. So that can be quite time consuming and a little bit tedious. Another downside to this is then you've got Drupal core, you've got or you can trip codes or your extra modules and themes into your project repository as well, and vendor code as well if you're using Composer in that set up. Option two is Drushmake. Drushmake is a tool or technically an extension for Drush, which allows you to define your project as code. So the first version used sort of an INI, any style syntax. There's now a YAML version as well. So you can use it to create your own projects, or you can use it to create reasonable distributions. So those distributions I mentioned before, like commerce kickstart for example, is using a Drushmake file to say which modules that distribution includes. So this is an example, so this is using the INI syntax. We call the file myprojectsomething.make. We start by defining the API version and version of core. So this is from Drupal 7, and we can start listing our projects. So the first thing we want to list is Drupal itself. We can define it as being core, and then specify the version, so in this case we're using 751. We can expand on that and then pull in additional projects. So path-automodule allows for automatically generating human readable paths. So we can install that. We can install version 1.3. And if for example the best practice, at least the way I prefer to do things, is to put all my contrib modules in a directory called contrib, and then likewise my custom modules in a directory called custom. So we can do that by specifying subdo, and also if we want to apply patches, we can apply patches using the patch key. Then once you've got that, we can then run drushmake, far name, output directory. So build dribblebrussel.make and then output that into a directory called build. And it gives you this output, so it tells you that it's running, then just lists the files that it downloads for you. This is great until you try to rebuild it. So you add another module, or you add a new theme, or you update something. You think, okay, I'll just run drushmake again, and it tells you that the path already exists, and then exits with an error code. This is not great. So a few limitations of drushmake. It's dribble specific, so this was fine. I mean this was a great solution for a few years ago before composer really joined the party. I prefer to use composer, use the modern sort of tooling. You need to use multiple repositories, or at least I have been when I've used this setup before. So by drushmake file lives in one Git repository, my custom modules go into another repository, custom themes likewise, and everything else. And then once it's actually built, I go into another repository. So we've now got three or four things depending on how complex your project is, which is technical debt, I guess, in a way, but just hard to maintain going forward. It kind of dates existing build. You just saw that. That's quite annoying. And you need to run an extra sort of step, as I compile it, so you maybe have to use Jenkins as some sort of CI tool. When you push an update to your make file, it pulls your other modules in, and it downloads everything again, pushes it to another repository, and that's the one that gets deployed. And also you need to define specific versions. So if you recall, we're saying install Drupal 7.54, or path auto 1.3 is going to be very specific, and then that's the version it installs. If you want to install the next version, you have to increase the number by one and rerun to the whole process again, which is not great. So Drushmake is not a dependency manager. It's just a tool that passes your file and just automates the downloading of things. So I'm not quite sure who actually said this quote. I recall it from somewhere. I think it was Ryan from Commerce Guys, but I might be wrong. But somebody said if you're not using a dependency manager, you're the dependency manager. So it's up to me or whoever's building the site to figure out which versions work with which other versions and make sure everything fits together. And I don't want that responsibility, really. Okay. I've got a very short video for Drushmake. Let's see if we can get this to work. We are going to see. There we are. I think this is a bad idea. So we're going to start just by cutting out the make file. So in this case it's called myproject.make. We've got the same content in that we had before. We can then run Drushmake project, name the directory. It's just going to start to begin the project, download the things that we want to tell it to download, and we can just open it in an editor and see what it's done. That's pretty much what it does. So let me find my speaker notes again. There we are. It doesn't matter. Okay. So the point that makes this talk a little bit more relevant again is the Drushmake extension was removed in Drush9, so it's no longer there, and it's been deprecated in favour of Composer. Actually, you want to look through the commit logs for Drush, and it says, don't replace Drushmake with Composer. So option three is Composer. Again, Drupal 8 loves Composer. So again, I'm still going to put a slide in and explain a little bit what Composer is in case it doesn't know, which is fine. So it's a dependency manager for PHP, so we specify which versions we want to use or minimum versions of. Composer then figures out which versions are compatible based on what we give it. So we don't need to figure that out. Composer can do that for us. Downloads packages into a vendor directory. Not 100% true. We'll get to that in a minute, but that usually does. It downloads packages from one or more repositories, so this is pretty important for this setup. Obviously, the main repository, the default repository is Packagist. Drupal.org exposes its own endpoints. There was a Drupal Packagist, which is a separate repository that was around for a while. That was then deprecated once the actual Composer package was put in place on Drupal.org, so we can add more than one repository, which we'll see in a minute. The cool thing is that we can actually ignore Drupal core entirely because we can install it as a dependency. We can remove all of our contrib code, so we don't need to put all of our contributory modules into our repository, and all of our vendor code also can be ignored. So we have less files in our repository, which means we can clone it faster, which is great. If we're doing code reviews, then we get smaller code reviews because we don't get a commit that says updated core and then we get 1,000 files or so changed, however many GitLab can show us. That also means that the team will spend less time in code reviewing because there's less to code review. We can not have to work around the files we want to ignore because they're not there. The team then can be more focused on just reviewing what we need to review, so i.e., all the custom code that we've written. We're able to provide minimum-required versions, so rather than dresch-make, we have to install 1.3. We can say with Composer we want to install 1.3 plus, and then every time we want to run a Composer install or an update, it's going to then figure out for us which the versions that fit together. So there's less of a maintenance cost involved here because we don't have to manually update 1.3 to 1.4, so Composer figures that out for us, which is nice. So it's an example of using Composer to require Sylex because, again, once we did this at a triple cam, people hadn't seen this before. Again, I'm assuming this is familiar to most people. We can say Composer requires Sylex and because Sylex depends on Pimple, installs that as well. So again, dresch-make because it's not a dependency manager, you could say install path auto and it would just download path auto. Path auto has dependencies, but dresch-make doesn't know that, so you have to be specific and give it every module that you want to install. Composer doesn't. That's in our Composer JSON file. This is what we get by running the command. I think we all know this already. So Composer in Drupal specifically. Drupal 8 uses Composer for all this dependency management. As I mentioned, we're pulling code from symphony, Zend, Stack, Doctrine, etc. This is all done using Composer and also also loading. It's all done through Composer. So the first versions of Drupal 8, so Drupal 8.0.0, something, still had the vendor directory in call. It's no longer there, which is awesome. We figured out that also loading problem. So Drupal 7, which is still around, still supportive, still stable and will be for some time, does not use Composer at all because there's no need for it at the moment. I guess so we're not pulling in aids of dependencies from third parties really, or if we are, we're using modules like Composer Manager or X Auto Load, which gives you sort of PSR4 level auto loading, all modules like libraries, which sort of tries to do what Composer does, but you reference libraries explicitly and it's still up to you to put them into the right place and sort of manage them. So now we sort of had a crash course or crash reminder on Composer. How do we use code to build Drupal? So there's two ways we could do this. There's a package called Drupal Drupal, which is available on Packagist, which is just call. There's also a Drupal Composer, Drupal Composer Drupal project, which is not maintained by the core maintainers. It's a separate project, by some of the core maintainers, but it's not an official Drupal project. And that includes core as a dependency. I'll talk about that in a moment. So both of these we can install with Composer Create Project because they're both on Packagist, so we can require Drupal Drupal. We can say we're going to require at least 8.4, so we're on 8.4.4, I believe, right now. Or we can use Composer Create Project and we can use Drupal Composer Drupal project. Try saying that 10 times really fast. Again, give it a site name and set the stability level, et cetera. So let's just compare those two. So Drupal Drupal is, let's say, minimal, like just core. So no extras or anything in there. And you get core at the root level of that project. The Drupal Composer project is different and it uses its own Composer JSON and rather than... It's right. So the original one is going to install core as the root of the center of your project. The Drupal Composer Drupal project doesn't. It requires core as a dependency of that project and then all of your extra ones are dependencies of that. So rather than us altering core's Composer JSON file, but altering our project's Composer JSON file, which to me seems a lot more sensible. So this is sort of similar to Symphony's Gallatin, I guess, in some way. The other big advantage is the Drupal Composer Drupal project is available for Drupal 8 and also for Drupal 7. So again, Composer natively in core is only for Drupal 8, not Drupal 7, but if you want to go down this route, we can do Drupal 7 with Composer and pulling all dependencies that way, which is great. So imagine there's dependencies. As I said, we can install Drupal.org where all the modules are hosted and the themes are hosted, exposes an endpoint. So there's a subdirectory called packages.drupal.org. We can install that as a repository into our Composer JSON file. The Drupal Composer Drupal project does this for us, but we can also do it manually if you want to go down the other path. And then we get this in our Composer JSON file again. Obviously, this is for Drupal 8, because it's Slash 8. If you want to see this for Drupal 7, it would be Slash 7. So configuring paths. So traditionally, all of your libraries and you saw things by Composer go into a vendor directory. Awesome. This uses a plug-in called Composer Installers, and it means that we can put things where we want to put them, and also where Drupal expects them to be. So if you're installing a contributed module, Drupal will expect or Drupal 8, at least in respect of that to being the modules directory. If you're doing it in a Drupal 7 project, it'll be sites slash something slash modules. And again, sort of best practice will say if it's a contrib module, so one that's available on Drupal.org, it goes modules contrib module name. If it's a custom module, modules custom or modules sites slash modules custom. Likewise for themes, themes contrib, themes custom. And again, profiles that we're going to install, commerce kickstart as a profile or any others. We can install that into the profiles directory. And it does this using the type key. So within each module to compose a JSON file, there's a type, and the type can be Drupal module or Drupal profile Drupal theme. And because of that, it's put into the right directory, and Drupal can find it. Which is awesome. So once you've got that in place, we can use Composer to require Drupal modules and themes. So we've now got the Drupal slash namespace available. So again, it's not from packages, it's coming from Drupal.org. Because we've added the repository, we can then pull this in. So in this case, we can say we've gone to install the path-automodule again. We can install at least 1.0, because this is a slightly old slide. And then, yeah, this is going to install the path-automodule. But as I said, path-autom has dependencies. So path-autom relies on token, and path-autom relies on C-tools. And because we're using Composer now, Composer knows that and downloads us for us. Oh, that's hanged. So we've removed two lines on our file, essentially. But less mental overhead for us, because Composer knows these things. Awesome. Also, Drupal modules may have dependencies that are not other Drupal modules. So commerce is, again, a very good example of this. Commerce, guys, is one of the big drivers, I guess, of Composer. So when they started to rewrite Drupal commerce for Drupal 8, they started literally from scratch. But then, rather than keeping all of their business logic for writing things like addresses and tax, keeping that within all of the Drupal modules, they decided to write php-libraries that they could then reuse so that their modules now are very small and they're just referencing the libraries they've already written, which are available on packages using the commerce, guys, namespace, which is great for them, because then we can then reuse those libraries in Drupal and, I think, Foxy Cart and Magento and other commerce projects. But, yes, this is great. So by requiring the Drupal address module, it knows that we need to pull in the commerce guys addressing library, and it will just do that for us. Adding themes. So we can have, if you want us to decide to look nice, to install a theme. We do that exactly the same way. So in this case, we're going to install a theme called omega, and it's going to be this omega-5 patching. So occasionally, we have to patch things. We can do this by installing the composer patches plugin. Excuse me. And then within our composer JSON file, within the extra key, we can just define patches. Start by just telling it which project we're going to make a patch. So Drupal-Drupal, in case of core, we give it a short description and then a link to the patch that we want to pull in. So this one's coming from an issue queue on Drupal.org. So it's node 1543, et cetera, which is cool. But we can also pull in local patches, which I found quite recently. So if you're working on a project and you need to patch something that's only specific for you, you can keep that patches directory in your repository and pull them in that way, which is great. Updating. So again, I think this is a lot of people here should sort of know this, I guess. So we can use composer install to update local code. Oh, that's the wrong one. So we can compose install to update the versions then composer.lock, and then we can use composer install to install them from the lock file. Yeah, those are backwards. That's not good. It's great. So it just means to install our Drupal, to update our Drupal project, we can just then use compose update command. And then also, I think with dependencies is default, but I tend to include it anyway. This will go through our whole project and just update everything. And then once we've done that, we can then just use composer install to install everything. Okay, another demo. Let's see if I can remember to do this this time. Composer. We can see that. Okay, so in this case, we're going to install a Drupal 8 site completely from scratch. So we're going to use the composer create project command, pull in the Drupal composer Drupal project project. We're going to call it myDrupal site and set the stability as we were doing before. Cool. So in a second, you can see that it's installing everything. It's created that myDrupal site directory. It's pulling in all of our packages, all the symphony projects, guzzle, as we see in there, twig, defydev, PHP documenter, PHP unit for unit testing now, behat, Zen framework, doctrine, cache, Drupal core itself. That one takes a few seconds. I didn't do that for dramatic pause. I want to just done that. And there's another project called Drupal scaffold, which we'll create, if you can see at the bottom here, create a sites default settings.php and also a sites default files directory. So these are files that we need to create in order for Drupal to sort of run, I guess. And then the settings of PHP is where you put your database credentials and everything if people don't know. So Drupal scaffold does that for us. That runs by using a composer script on post install, which is great. Cool. So once that's run, I can see it into that directory. And I think we're going to open this up first in Sublime to see what's going on. We can see that it's created this whole directory structure for us. So it's kept, so it's installed Drush as part of its dependencies as well, which is awesome. We have some composer scripts. We have a vendor directory where it's installed all the vendor packages. This is also great because it's outside of the doc route, which is great for security as well. Drupal lives within the web directory. And we can see that this probably have no contrib modules at all because we haven't installed any. So what we'll do next, we'll try to open this up in a browser. And any second now, we should have a Drupal 8 site pop up. Any second now. There we go. So this is the Drupal 8 install page. This is Drupal 8 for 4. We can choose our language because Drupal 8 is really awesome for multilingual as well. These are the standard installation profiles, so we're going to use standard in this case. We're going to put in our database credentials. I've got re-secure credentials for this one. It's all done within Docker containers, so I can just set them to Drupal Drupal. But also I'm running it with a DB container, so I need to set that as the host. And a second is Drupal's going to install. Fast hold a little bit there. Takes a few minutes to run normally. 40 modules are sold in the standard profile, so that takes a few minutes. And then once this is running, we can start configuring the site. Give it our site name of admin. I wouldn't suggest using admin on production, but locally it's fine. Put in my passwords and configure our time zones and then just go ahead and continue. Any second now, right. Today we have Drupal 8 installed. Awesome. So, yeah, we haven't, all we've had to run to do this is just run one command, which was composed of a require Drupal project. Awesome. We can click on the extend button in the navbar. These are our modules that we've got installed. Currently we've only got core modules if we search for path also we don't have one and we haven't told it to install it. But what we can do is run composer require Drupal slash path auto. Like you've already seen, this will go to Drupal.org, trying to download path auto. Also install the dependencies for path auto. So we should see C tools and we should see token. Any second now. Okay, so we can see token and we can see C tools and we can see path auto. Awesome. So, yeah, if we go back to splime, we go into our web directory, modules, we have a new contrib directory and we get our three modules. We go back to our Drupal site and we can refresh the page and search again, search for path auto. We don't have path auto. We can go ahead and enable it. We can install it. Awesome. We have a Drupal site. So, real examples. So, the Drupal Bristol websites of the Drupal Bristol user group all hosted on GitHub. This is, we use the Drupal composer Drupal project to maintain our website so we can go there and check by there. So, yeah, I guess in summary, Drupal is awesome. Composer is also awesome. Use them both together. More modules and more distributions are moving to composer. So, as I said, commerce is a very big proponent composer because of their own, they're pulling out their own libraries. Other modules, so MailChimp comes to mind, pulls in the MailChimp API for PHP from ThinkChimp and city API Solar will pull in the Solarium, I'm saying that right, library, there are others. It's a definite trend of Drupal modules doing less and Drupal PHP libraries doing more and those being pulled into Drupal. Distributions, so, as I said, Drupal DrushMake is the default way or has been for defining our distributions to install. This also is changing because Drush has gone away, DrushMake has gone away in Drush9. And we're seeing distributions like AcryLightning, a hosted on GitHub because Drupal.org doesn't yet support composer-based distributions. But AcryLightning is one of the new hotnesses at the moment, is hosted on GitHub and used as packageist and is available on packageist within the AcryLightning space. This is a definite trend of that being happening more and more. I guess, in my opinion, using composer enforces best practice, so we don't have to go and just have taken over projects before and then update module X and module X has been hacked because they want to change the ordering of something and then updating the module breaks everything. So, we can't do that anymore if you don't have that in what I would do. People generally can't do that anymore because that module doesn't exist in the repository. So, we have to then start writing patches for those modules and I guess a bi-project of that would increase contribution. So, again, big open source thing around Drupal and contributing to core and modules. If you've written a patch to fix a problem already, then why not just submit that patch to Drupal.org and back to the whole project. There's quite the interesting thing recently about Drupal.org issue queues is that if you're working on issues on behalf of a company, you can tag both yourself and the company that you work for and also clients that you work for if they're on those organisations and everybody gets credit for doing that and then one of the bi-projects of that is there's a marketplace listing and the marketplace listing is ordered by how much contribution people have done. So, the company, I think the company, the companies will get better exposure in place like that marketplace because they're contributing more as well as deaf happiness, et cetera, et cetera. So, yes, huge composer. Some resources, so obviously get composer is where we get composer. Symphony.com projects Drupal. This is Drupal's project based on Symphony where it outlines the components that we're currently using. This documentation page is on Drupal.org that explains how to do more or less what I've just already shown. This is the GitHub link to the Drupal composer project.