 Hi, maenai Cameron. I'm the track chair for coding and development, Drupalcom Pride, and it's my absolute honour to introduce one of the featured speakers in my track, Alex Pott. Those of you who attended Driz's keynote this morning would have had a bit of an intro to Alex when Driz thanked him, but for those who weren't, Alex is one of only five Drupal 8 core committers and the most recently appointed I think in April. So a core committer is someone in a very privative position, being one of the few people who can accept changes to the core of Drupal itself. So for Drupal 8 we've only got Angie Byron, Nathaniel Catchpole, Jennifer Hodgdon and the docs team, Driz, of course, and Alex who can commit code. So since April he's already done more than 1,200 commits, which is a blistering pace, I think Driz had 50 a week this morning. And to put that in perspective I think until then there was only about 2,000 commits on the Drupal 8 trunk. So came to core development through his work on the configuration management initiative, which some of you may know about, which he became interested in when he was working as lead developer on the Royal Mail project. Talked to Greg Dunlop, became part of that initiative and then was invited by Driz to be a core committed. He's now working full-time in London on Drupal 8 and he's an absolutely lovely guy. It's really my honour to introduce him. So the theme of the conference is one to many. Alex is going to talk about how Drupal 8 has incorporated ideas, technologies and indeed libraries from the wider PHP community and what that means for Drupal now and in the future. So Alex, take it away. Good afternoon everyone. So as the Prime Minister said I'm here to talk about the Drupal 8 story, how we've gone from not invented here to proudly found elsewhere and we're looking for ideas from outside of the Drupal community, outside of PHP on how to make Drupal better. So that's who I am. He's introduced me so that slide is rather redundant. So we'll move on to who are you. I'm hoping that most of you are Drupal developers who are new to Drupal 8 and that I'm going to talk to you about why we're making the changes that we've made to Drupal 8, how to talk in Drupal 8 so that when you come to issues and you look at the way that the code's written, you understand what it's trying to do and I'm going to talk about some of the advantages about the changes that we've made from a developer perspective. So in order to talk about why we've made the changes to Drupal 8 we have to go back in time. So I don't know how many of you know how Drupal started but Drupal was started in a dorm at a university by user one sitting there going, hey I want to make a slash dot for my dorm. And so that's what he set out to do. He made the drop.org and him and his friends posted messages and started to share the software. This has impacts on the way that Drupal is written and the way that the internet was in 1999 also has impacts. Google was in beta, everyone was using Internet Explorer 5. There were some advanced things going on on the internet like SETI at home but it was all bespoke software and the internet was full of tables and it just was a different world. And people were using these to access the internet and these to make phone calls. We're not in that world anymore. So looking at what we have today we have a Drupal that's sitting at the heart of the internet getting requests from iPhones, from kiosk applications, from desktops of course, from all sorts of other frameworks and systems. Yet at the moment Drupal 7 assumes the moment it's making a response to a request that it's this desktop. That's what it does. And in Drupal 7 in order to get around this services module does all sorts of evil things like just exiting straight from Cota and anything you've got that's going to fire at the end of a response on termination, that won't fire. That's Drupal 7 for HTML. So at the beginning of the cycle for Drupal 8 Larry Garfield said that Drupal basically needs to evolve and quickly from the first-class web CMS into a first-class REST server that includes the first-class web CMS. And this has a fundamental impact on the way in which we have to architect Drupal to work. And so I'm going to talk about what that is. At the same time the tools on which we've built Drupal have been changing. So PHP is no longer PHP 4 that it was back in 1999. It's embraced concepts and techniques such as OO namespaces and anonymous functions that we need to embrace because that's PHP. That's the fundamental language that we're using. So Drupal 8 is object-orientated because PHP is object-orientated. So if you don't get classes, objects and interfaces then now's the time to start to learn. So I'm going to show you why that's important in quite simple numbers. Drupal 7 has 380 classes. Basically it's all the DB layer. Drupal 8 at the moment has 2,816 classes and it's only going to grow. So if you want to develop on Drupal 8 getting comfortable with OO code is going to be mandatory. So one of the key things that was introduced in PHP 5.3 which Drupal 8 is the lowest version that Drupal 8 is going to work on is namespaces. And what namespaces allow us to do is to use classes with the same name, like database, but take them from different places. So with PHP 5.3 and its new object orientation and namespaces, people were sitting around saying well actually this now allows us to share code between our projects. So in 2009, some people came together under the framework interoperability group so-called PHP FIG and proposed PSR0 which is a way in which projects can share their classes and share objects and share functionality so that we don't all have to do the same thing. Which basically says that if we're going to have an object we're going to namespace it like this. We're going to have a vendor name, Drupal a namespace, database and a class name, connection for example. And so what this allows us to do in code is to use our objects like this. So at the top of our code we write use, Drupal, user, entity, role and then in my code I can create a new role just by going new role. Then automatically PHP will be able to include the role file in your directory structure which at the moment is buried quite deep because it's PSR0 and it will load this file automatically for you when it needs the class. So we have autoloading and we have namespaces but the next bit that really meant that PHP projects could start to share code was the advent of Composer. And what this is is it's a dependency management tool for projects. So it allows us to say that my Drupal project needs code from symphony, it needs code from Zend or any framework or any part of PHP that we want we can pull in in a way that allows the autoloader to load those classes for us. So at the moment Drupal 8 is relying on 11 or so symphony components but it's not just symphony as I was saying we're using doctrine for parsing annotations we're using easy RDF for managing our RDF stuff we're using guzzle for making HTTP requests we're using the Zend framework to manage RSS aggregation and we're using twig for templating so we're pulling in all this extra code to handle problems that we don't need to solve problems that other people have solved for us. So now with vendor we actually have over 5,000 objects in Drupal 8 that you can instantiate and use to solve your problems. So we have all these new objects and we have the new PHP ecosystem built around object orientation, namespaces and autoloading but that means that we now need to use some new words to talk about the way Drupal 8 works and I think language is a really important thing if we use different words to talk about the same things then we end up with confusion and I think that we need to use a model based language a language where the words represent things that we can all think about and share and understanding in so that we can come together and create a great Drupal 8 and great websites and products built off it so I'm going to go through some of the words that you'll hear a lot in Drupal 8 and then show you the code that creates these things. So services what services are are basically global objects that provide functionality to your code so a classic service would be something like a cash back end the mailer or the module handler which will allow you to not care about how it does it but just get the database connection install a module you can go create I have the module handler just install and services have to live somewhere in Drupal 8 and so services live on the container and so the container is the collection of all of the global objects that you can access and the advantage of using a container and specifically the symphony container is that it means that we can inject the dependencies into the services what that allows us to do is to remove the assumptions that your code is making about what it needs so it allows us to remove all of the hard coded dependencies and then it makes it possible to change them so if we want to swap out the HTTP client currently in core we can and then your code just because having the HTTP client injected can just use the new one because you know that it's going to implement the same interface and this allows us to write clutter free and testable code because the less your code actually knows about the rest of the application the more reusable it is by others and by yourself so in Drupal 8 to set up a service all we do is we declare stuff in our well we can declare stuff in core.services.yaml which is basically this is saying okay I've got my config factory service it's going to instantiate this class and it's going to have the storage and the context injected in which are other services here's the database service it creates a connection and in order to create that connection it uses a factory and the arguments are the default settings these are the default settings from your settings.php you don't have to just use yaml to register services you can programmatically register them in PHP and what this allows us to do is to swap things out at different times so when we're installing Drupal the module handler isn't the cached module handler but when it's in runtime we're using the cached module handler so it's really flexible and we can now change things at different states and the impact of this is amazing in terms of what we can do with now the upgrade path the updater has a completely alternate module handler that prevents you from firing hooks so we've told you in Drupal 5 and 6 and 7 don't fire hooks from your upgrade path it's actually now impossible to fire hooks from your upgrade path and this is a big win because it means that we've broken it before it's more robust you're going to hear a lot about requests and responses these are symphony objects that we've used to model the way in which Drupal works so a request is made and a response is returned to the browser when a request is made we discover a route if you're American or root if you're English and the root is there what controller to use in order to create the response and again the routes are declared in YAML so here is the user-autocomplete route so slash user-autocomplete here is the controller to use and here is what permission it requires it's declarative this is the equivalent of the routing part of hook menu in Drupal 7 and here is the controller we see dependency injection in action we inject the user-autocomplete service into the controller and then the controller just calls get matches so that means in order to test the user-autocomplete service which is there is the declaration in the services YAML file we actually don't need a request or we can mock the request so our our auto-completion for users is now divorced from our request handling in Drupal 7 in order to test this code you would have needed to fire up a web browser now we don't, now this is testable in other ways you're going to hear a lot about plugins and all plugins are is a group of similar objects that can be used in a part of Drupal so a good example is blocks so not every block does the same thing but when you place a block on a page it provides a view a view as in as in some HTML to put on the page and the thing that's special about plugins is that they are discovered so we have discovery mechanisms and what discovery mechanisms in Drupal 7 basically you replace is all of the hook something info so hook entity info, hook field format info, hook field widget info hook image toolkits they're all gone in favour of a common discovery method or we have two at the moment and one of them is annotations which we've borrowed from doctrines so I'm going to show you some of an annotation I'm going to show you a block and try and show you why this is really really nice so in Drupal 7 we have our system block view and at the moment as a developer I'm wanting to work on the power by block I have to read all this code it's going into a switch and I'm going oh yeah that's great, there's my theme Drupal 8 we don't need that the hook view we don't need the hook block info all we have is the annotation in the same place as we're telling it how to render the block so we have an app plugin here's the ID that appears in the admin interface and here's the function that just returns the theme block and so in order to create a block you can just copy this file change the ID the admin label do what you want on the output and then the system will automatically discover it for you another big change in Drupal 8 is entities and basically everything is an entity that has a life cycle that can be created and then deleted at some point or kept around and the important thing about an entity is that it's uniquely identifiable so we have content entities which are pretty similar to Drupal 7 there's obviously nodes, users, comments but we've also now got contact messages and menu items but we also have configuration entities like views, vocabularies contact categories fields, menus and roles and what's nice about configuration entities is that they use the CMI system in order to be managed so we have the user authenticated role looking like this so it's really easy to read this file and see what permissions it has and we can copy that file up to production into a staging directory import it and make the changes and it's also nice about using the entity system to manage things like roles is that we can then put helpful methods on the role entity so we can implement has permission so you create your role or you load up the role the authenticated role and you ask it does it have a permission and this actually helps us fix bugs at the moment this code reads the code for should I search comments depending on whether the authenticated or anonymous user has access to comments now looks like this and it's much easier to read this role does it have this permission has the permission access comments and if the role IDs are this I can't index comments because the authenticated user doesn't have access to comments but the anonymous does and Drupal 7 the code was like this we carried straight out the database and we made we loaded up a huge array the array key is going to be the permission name and then we're going to see if the role ID has it and when we moved to Drupal 8 we changed what these constants were and we ended up introducing a bug that if you created a role like administrator that was less than authenticated user it would actually fall in here you'd never be able to index your comments so by having interfaces which declare helpful methods on your entities we're able to actually make the code more readable and easier to debug so everything is different in Drupal 8 but that also is getting us some other wins a lot of people say that Drupal 8 is more complicated but I'm going to make an argument that it's actually less complexity I've shown you that the blocks are less complex I've shown that it's possible with config entities to manage configuration in a less complex way but I also think it's measurably less complex so if we have a look at how we can measure complexity there's a measure in computing called cyclomatic complexity which basically just measures the numbers of decision points in code so this function here has four decision points the decision to call the function each if or else if so if we have a look at what that would mean for a function 1 to 4 cyclomatic complexity is low complexity that didn't look very complex 5 to 7 moderate complexity 8 to 10 high complexity more than 11 it's just very very complex if we have a look at but we can move this measure to actually every line of code in a project and so generally there's been some studies and it shows that here are the the kind of measures that we would look for so you know Drupal's not going to be a low complex application never has been but it would be nice if we were in the moderate complexity range so if we have a look at Drupal 6 actually Drupal 6 was very complex lots of functions did an awful lot lots and lots of features and abilities to do different things and so when you were trying to work out what does that function do you have to reload a code and you weren't always sure what it's going to do Drupal 7 we got better we got a lot better and now in Drupal 8 we're actually in the sweet spot of measurable complexity where you're looking at most functions that they're just doing a single thing they're not doing lots and lots of different things but actually you know what you would say here is the number of lines of code has gone up by 300,000 so what does this really mean we've actually got a lot more decision points and what's really really interesting and you couldn't make this up is that Drupal 6 is actually 77% less complex in this measure of numbers of decisions than Drupal 7 and Drupal 8 is 77% more complex than Drupal 7 so how am I losing my argument well maybe not because actually if I take Drupal 7 and I remove the modules that have been removed like blog, dashboard, open id, poll, profile, php but I add in views, email, link telephone features entity reference C tools and Wiggy's Wig which is just a selection of some of the functionality that you would have to bring into core to have the same feature set as Drupal 8 we actually get to a point where the number of decision points is more in Drupal 7 so I think that in order to achieve Drupal 8's functionality in Drupal 7 you're going to have a more complex site and so just to really focus in on one of the changes that we made in Drupal 8 and how we've benefited from going and using other libraries we can have a look at this function which is really hard to change it has a cyclomatic complexity of 41 which is over that 10 measure but also there was an issue that was studded in 2004 took 12 years and over 400 comments to actually get a commit into Drupal 8 it was fixed for Drupal 8 but we now we don't even have the function in Drupal 8 we just use guzzle and what's amazing is that in order to actually test that code ourselves we would actually have to write 25 billion tests to actually fully test Drupal H2 request it's not possible and what's even more funny is that that issue is now broken we can't actually use proxies in core but in order to use proxies in core we actually only require this code so we can actually take the guzzle HP client modify it, just add the proxy settings whatever we want straight on there and because we're using dependency injection everywhere to inject the HP client into every service that needs it we just benefit so issues that took 12 years of arguing can be solved in 5 lines of code in Drupal 8 I think that's pretty cool another thing that we've done is we brought in PHP unit and so we finally have a way of testing our code in ways that doesn't rely on the simple test browser and what's really good about that is that we're testing all of our code and all of our functionality on a browser that no one ever uses that doesn't really make sense and we're trying to make it test things that we don't need to have all of that we're not isolating what we're actually testing and it's slow so PHP unit to actually run all the tests at the moment takes 4 seconds to make nearly 2,000 assertions simple test takes an hour and a half on test spots to make 50,000 assertions so it's a big improvement if we can move much more of our testing to PHP unit we're going to benefit we're going to benefit in other ways because it's not just about speed we get more information back on what we're testing so it's possible in PHP unit to produce coverage reports so here's the datetime plus class and I know that we've got all of these methods in there and I know that this method 80% of the lines are being hit by my test so I can actually look and say hey, we're missing test coverage for this format class because there's only 33% of the lines actually tested it's brilliant and it's really lovely and I can say that in the tests for crate from array we've got nothing that's testing that we throw this exception correctly because that line is red and all the other lines are green so they're being hit by my tests so I've spent a lot of time talking about what we've brought in from PHP but it's not just about PHP what Drupal 8 has changed you heard this morning what Dries was talking about we have 6 new front-end libraries Modernizer which wasn't mentioned and we've got massive efforts to clean up front-end performance one of my favourite facts about Drupal 8 which is not PHP related is that in order to do a request in Drupal 7 just install and request a node you'll actually make 24 requests for different assets in Drupal 8 that's now only 13 it's a lot of work that people have done on that so if I wanted to know more about some of the things I've been talking about I can't recommend PHP the right way .com enough to have a look at how PHP has changed in the past 3 or 4 years to embrace object orientation and new design patterns if you want to see about how to create a framework like the way that Drupal 8 has used symphony then FABPOP framework will bring up an amazing series of tutorials on using symphony components and talking about the way that we use language Eric Evans' domain-driven design is a great book so also now I'm on stage I would like to thank everyone who's contributed to my get-tip because I don't know how many of you actually know about how I'm funded and only work on Drupal 8 but it's my own money and contributions from the community so thank you everyone for giving me money because it's just cool Last but not least come to the sprints on Friday we need more help there's lots to do in Drupal 8 there's going to be big decisions made and we're going to produce an amazing project and I would really like you all to be a part of it so yeah thank you everyone any questions so Eddie it's just asked me what do you think the biggest remaining challenges are to tackle with Drupal 8 so from my perspective it's finishing CMI I really want to see that finished I think that there are challenges around the upgrade path making sure that it works in all situations we've done a lot to improve the testing on upgrade paths but there's always more work to be done because most people don't have a Drupal 7 site there's just Drupal 7 core they've got contrary modules they've got everything there so we have to do work so I think those are the two big challenges for me personally but for Drupal as a whole this morning he laid out that we have challenges around complexity and DX and we really really want to improve that as well Angie so Angie asked me what things get me the most excited I think for me the most exciting thing is the consistency handling different things that are similar within the Drupal universe so how we handle role configuration and how we handle views and the methods are the same so if I want to know what's the UUID of a view I call the UUID method if I want to know what the UUID of the role is because they're both config entities they have the same methods and this is nice because it answers a little bit more obtuse than it needs to be because if you look at nodes and users in order to get their ID in Drupal 7 land you go node arrow UUID for the user node arrow NID for the node and user arrow UUID for the user but in Drupal 8 you just call the ID method and it will return your ID you have to know less and if you have an IDE that autocompletes that ID method is there so once you know it once you've learnt it for nodes you know it for users you know it for views you know it for everything so I think there's a consistency there that we haven't had before so the question is Drupal versions prior to Drupal 8 were largely procedural and Drupal versions and Drupal 8 and the future might be largely OO which was as a site builder I was building sites for a university I wanted a tool that I could click together stuff I didn't have a comparison of different things I was like oh Drupal looks good at that point I had not looked at the code I didn't know whether it was procedural or I didn't care what I cared is that I had this amazing ability to create content types and click it together in a way that just worked and it was solving my problems then I got to this point where I was like oh it's not solving my problems anymore I need to change something and then I was like oh this is procedural code okay that's fine but I don't think that changes if you're a site builder and you get into coding and it's now oh you're not going to sit there and go oh I wish it was procedural you're going to say okay this is the paradigm so I'm not sure that it changes that much so the question is do I think that other projects will join to use Drupal components and yeah if we get it right if we provide valuable things back to the PH community sure in fact in the last month or so the Drupal 8 initiative lead for blocks has been doing a lot of work on plugins and symphony and he's been talking a lot in the symphony channels and they're very interested in our plugin system because they don't have an equivalent system so yeah I think that if we don't give code back to the wider PHV community we've kind of failed it's not a one-way street well thank you everyone thanks for coming