 Hi, everyone. Welcome to DrupalCon Vienna. I hope you are having a good time and that you are in the right room. Let me introduce myself. I'm Deepak Yadav. I'm from Pune, India. I work as a software developer for Vidushi Infotech. Wait, let me make it full screen. And I work as a Drupal consultant for Rotary International. You can find me by my username Deepak. I'm mostly active on Twitter, Drupal.org and GitHub. And that's my website. Today I'll be talking about symphony in Drupal 8, how much and what does Drupal inherit from symphony. And while that will mostly involve talking about symphony components and how they are used in Drupal 8, it won't be limited to that. We'll also look into other cool stuff that Drupal inherits and how it has changed Drupal, how it has made Drupal a more modern tool and how it has brought us closer to the rest of PHP world. But before that, let's talk about who are you. And a show of hands here, please. You are a Drupal 7 developer. That means you have done some custom coding in Drupal 7. Okay, that's good. You are a Drupal 8 beginner. You have just started learning Drupal 8. Okay. You want to learn about symphony? That's good. I think it's all the same people. And you understand object oriented basics. So you should be familiar with concept of classes, object and all those things. That's not a requirement, but that will be helpful to understand what I'm speaking during most of the session. I'll be using those terms quite frequently. This is an overview of session. We'll be first looking into status of Drupal development before Drupal 8 and why we needed Drupal 8 or symphony. Then we have a brief introduction to symphony. And the third part, which is symphony components in Drupal 8, will be spending most of the time during that. And it's the most boring part of the session. So if I find someone sleeping, I might throw stuff at them. So please bear with that. In the end, I'll be sharing my personal thoughts about what I like, about symphony, stuff that Drupal has inherited and some of the things that I want to see in future. So let's begin. We'll start with status of Drupal development before Drupal 8. Again, a question. How many here have just started learning about symphony? And how many of you have felt like this? Oh, very few people. Oh, that's interesting to know. Okay. Second question. Do we have any symphony developer here who has worked with Drupal 7? Okay. So question for you. Did you have feeling like this when you looked into Drupal 7? Somewhat. Okay. No problem. I have, sorry. Okay. I have few symphony developers, friends. And when I talked to them, they mentioned that from switching to symphony to Drupal, it was a strange experience from them. And it's actually much harder, switching from working for Drupal 7 when you are a symphony developer, than working for other frameworks. For example, Laravel, Yee, Zen, or et cetera. Why? What's the reason for that? Because Drupal is different. Drupal has a different way of doing things. That's Drupal in middle. And fun, sorry, one, Drupal is procedural and all other frameworks like symphony, Laravel, they are object oriented. So inherently, Drupal 7's way of doing things that design patterns are different than those other projects. And a major part of Drupal development was done during PHP 4 era. The time when PHP does not have a very good object oriented support. And I think it was unless PHP 5.3, that PHP had a very good object oriented support. And because of that, Drupal chose to stuck with procedural programming. And that made it a little harder for Drupal to immediately make a switch to Drupal, sorry, to object oriented PHP. Also, in software world, and especially in open source, when solving a problem, we look for existing solutions so that we don't have to reinvent the wheels. But that was not something Drupal was doing. For example, Drupal 7 solves a lot of problem that symphony also solves, but in much better ways. And Drupal 7 was not able to use that because of the points that we talked about. It was object oriented, symphony was object oriented, Drupal was not. And because of being written in entirely different programming paradigm, it was difficult for Drupal to inherit those things. And because of this, Drupal was blamed that it had this philosophy of not invented here, where there was a resistance in Drupal to use this existing solution. One more term that is frequently used is Drupal 7 was living on its own island, away from PHP, mainland because it was doing everything in a different way. But this started changing with Drupal 8. To keep Drupal modern and up to date with PHP, frequently or fastly developing PHP, Drupal 8 was rebuilt using modern PHP, object oriented and everything. And instead of building everything from scratch, this time Drupal 8 decided to use existing solutions provided by other projects. Drupal decided to call this proudly invented elsewhere. Everybody else called it proudly found elsewhere, but since that is an acronym for pi, something you ate, Drupal did that. Don't ask me the reason. I don't know why. Drupal now uses code from a number of different projects to name some of them, doc train, PHP unit, Gazzal, twig and symphony. And out of these, the one framework that has influenced Drupal the most is symphony. And that is what most of you are here about, so let's start with that. Symphony, this is official definition from symphony's website. Symphony is a set of PHP components, a web application framework, a philosophy and a community all working together in harmony. Now, for a newcomer who is new to symphony, the philosophy and community part will be easier to understand. But it's the first two, symphony is a set of PHP components and a web application framework that might be confusing. Someone might think, does Drupal has this multiple personality, sorry, symphony has this multiple personality disorder. I can, it'd be two things at once. And that is a major reason for a major confusion in Drupal community. When I was working for this session, I talked to people, I was told and I also experienced that. People did not know what is the difference here. And it's especially relevant when the question comes, do you need to learn symphony to learn Drupal 8? And to answer that question, let's look into these two parts separately. Symphony components and the symphony framework. Symphony component is a fancy term used by symphony to refer to a PHP library. It's just a directory with some PHP files that can be used. That's as simple as that. Most of these symphony components are independent or very loosely coupled. They can be used separately from each other. And these components are reusable in any PHP application. In fact, you can use these components in Drupal 7 as well. Some examples of these components are, there are actually more than 54, 50 components if you look on symphony's website, when I counted it was 54. Some of these components are a config for creating and using configuration of any kind, a form component that allows you to create and process form easily so that you don't have to create everything from scratch. STTP foundation, which is the most basic symphony component for handling the request response flow in a PHP application. And Drupal 8 uses many of these PHP components, sorry, these symphony components. Drupal 8 does not use symphony framework. Let's see what symphony framework is. Just like Drupal 8 is built on some symphony components, symphony framework is also based on these components, actually 35 of them. And symphony framework also has code from other PHP libraries like twig and Swiftmailer. Symphony framework in itself is a fully functional application when you install it, and it is meant to be a starting point for your web application. To see the difference between Drupal 8 and symphony, Drupal is a full-fledged CMS with lots of ready-made and built-in features. Whereas symphony framework, it is meant to be customized and extended from ground up. And the differentiation between the framework and component, the question that I raised earlier, do we need to learn symphony to learn Drupal 8? If we are talking about symphony framework, the answer is no, you do not. And if we are talking about symphony components, answer is yes, but the only ones that Drupal 8 uses. So I hope I helped in resolving the confusion if someone had it here. We will quickly look into symphony community, and this is the part I have included, because I also wanted to talk about the stuff that Drupal has inherited apart from code. So symphony community, just like Drupal symphony has a huge community, more than 2,000 contributors, more than 3,000 developers, and just like Drupal symphony also organizes events, these are some of the past and upcoming events. And Drupal has inherited a part of symphony component as well. You are in this session, and this session is a part of symphony track, and that is because Drupal now uses symphony. And we also have in past, and we had this prominent member from symphony community who have spoken as this Drupal con. Ryan Weaver from Kenpe University, Nicholas Grecoz, he had a session this morning. He is from Blackfire and previously from Sensio Lab. And yesterday we had a wonderful session from Michelle Sanver about her experience working with PHP and symphony community. Now to the boring part, symphony components in Drupal 8, and these are the components that we will be looking into. First five, they form the core pipeline of Drupal 8. And if you are doing Drupal 8 development, it's quite possible that you will be using code that is influenced by these components. Rest four are also heavily used by Drupal, but at a much lower programming level. And if you are, you might not come into contact with those code, but learning about them will be helpful. And we'll see how in later part of this slide. Let's start with HTTP foundation. Almost every web application, all the communication on worldwide web, it happens using HTTP. What's HTTP? A web client sends a request to server and server sends a response back. That's as simple as that. And most, how do we handle this HTTP communication? Most web framework, they implement a design pattern called as front controller, which take the request, sends the control to application, application must send a response back, which the front controller then sends to the web client. And front controller maintains the control of request response flow. And Drupal has its own front controller, both in Drupal 7 and Drupal 8. It's index.php. All the requests are routed through it. So let's see how front controller works in Drupal 7. This is index.php code for Drupal 7. And we'll be looking at the last line. This function, many execute active handler, it passes the control to it, identify which function, which callback function should be used to process current request and passes the control to that. And then that function has the responsibility of handling request and response. So in Drupal 7, actually, index.php does not have full control over the request response flow as it ideally should be with the front controller. This changes with Drupal 8. This is Drupal 8's index.php and we'll be looking into these three lines. If you look, first line is we create a request object. In second line, the handle function is used to pass the control to appropriate handler. But that handler must return a response back. And in the next line, that response is sent to the server. So this is how the flow of it looks. You will see that front controller index.php, it maintains the control over request response flow. It receives the request from a web client and sends the response back. This has been made possible by HTTP foundation component of Symphony. It provides us with these two classes, request and response. Request class or request object gathers request data from all these PHP globals like dollar get, dollar post, dollar server or dollar cookie functions and puts them in a single request object which is dollar request here. And response object allows us to set content for the page, the status code for the response and response headers. And it allows us to send the response back using this send function. Sorry. Also, if you look into it, Drupal 7, it was built as a web CMS and it was built to handle responses from a request from a web browser. And because of that, it was mainly built to handle get request. But that's not what HTTP has. HTTP has other methods like post, put, delete. And Drupal 7 had poor support for handling that. And because of that, Drupal had very poor support for creating restful APIs. And we had to depend on modules like services and restful web services for that. That changes with Drupal 8. Drupal 8 is now API first. It supports all these methods. And it has been made possible by combination of this HTTP foundation and the routing component which we'll be looking into next. So anyone new to routing? Routing is a process to match a request path to a function in Drupal 7 and a controller in object oriented or Drupal 8 that then processes that request. And a route is this map from path to controller. Let's see how this was done in Drupal 7. In Drupal 7, we used hook menu to define a route. So in this case, my awesome path is routed to my awesome callback function. And the way Drupal 7 did it behind the scenes is using same menu execute active handler function. And this was also a negative of Drupal 7. The same, I would say, system was responsible for both request response flow and routing. And ideally, these two should be kept separate. So menu execute active handler function used to call menu get item to get that path or get that route and then identify the callback and then process that callback. This is how routing happened in Drupal 7. In Drupal 8, the routing component of symphony allows us to create a route in routing.yml file. So in this case, the path again, my awesome path is mapped to this controller awesome controller object and its awesome action method. Sorry. And this is the code again, the same three lines. But you will notice here, the handle function is actually the one that is passing the control to routing. So the flow looks like this. Request is sent to handle, which sends the routing process to routing component, which sends the response back. And to see the basic of routing, symphony provides us with these three objects. These three objects are needed to do the basic routing. First is route collection. It is the object that gathers all the routes from all the routing.yml file, whether defined in core, in contrary module or your own custom module. So it has list of all the routes. So we can see first, second, third, all those are routes. And then we have a request context object, which has information about the current request. So what path has been requested, what method for that path has been requested, and other parameters like base URL or host and all those things. And matcher is the object that actually matches that particular request to appropriate route and execute that routes controller. So we talked about API and we can see here that this routing component allows us to create a path that can be handled by different controller for different methods. So in this example, awesome path can be handled by get action, post action and delete action based on what method has been requested. So for this current request, which is a post method for awesome path, the post controller will be used because matcher will be matching to that. And this allows us to create powerful crowd APIs. And we don't have to, I would say, this provides a very powerful support for creating those crowd APIs, whereas in Drupal 7 we had to use very different modules. That's about the routing component. Next, we'll be looking into event dispatcher and any web application, in fact, any application has various parts or various subsystems that often need to communicate with each other. And in Drupal, example of such subsystems would be node system and a command system. And I knew that this could turn out to be boring, so I included these bros. So in this case, the example of one such communication will be node system is trying to delete a node and it needs to communicate that to command system so that command can delete node on that particular node that is being deleted. Any guesses how this is done in Drupal 7? Yes, you are right. So actually it's not the communication that was happening between node and command system, it's the communication happening between this node delete function and the hook node delete implementation written by command system, command node delete. And behind the scene, this is how it happens, node delete calls the module invoke all function, which gathers all the implementation for that node delete hook and then executes them. So in this case, module invoke all will be executing command node delete to make, to do the communication with that command subsystem. In Drupal 8, this communication is facilitated by event dispatcher component of symphony. And event dispatcher component introduces the concept of events. So an event is any action that an object needs to communicate to other objects. And since everything in Drupal 8 is object, Drupal 8 being object oriented, it's the communication, the communication happens between these objects. So node deletion will again be an example of an event. So how this event dispatcher component, it actually introduces this event dispatcher object, the central one, and that's big bro, it's not wearing a cowboy head, it's just a bro with two caps. So event dispatcher creates this, gives us this central event dispatcher object, which acts as the mediator between the objects that are communicating. So in this case, comment and translation are, and I'm oversimplifying this, comment and translation are objects that needs to be communicated the event of node deletion. So they will register themselves as listeners, because they will be listening to that event, and they will register themselves as listener to event dispatcher. And this is the code of it. So if you find this code in Drupal, that means listener is being added to event dispatcher. Next, the object that is taking the action that is executing that event informs that to event dispatcher, and I have thrown some pirate lingo as well because why not? And event dispatcher then communicates that action to the comment and translation, so to the listener. And this action of telling the listeners that event is executing is called dispatching the event. To those of you who do not like my creative drawings, this is the boring diagram. So in this case, delete, save and update, those are the events. Comment, translation and taxonomy, they are the listeners. So first thing that happens is in code, using that dotted lines, these listeners will register themselves to dispatcher. And when that event is executed, through those blue lines, the dispatcher will tell these objects about the event happening and then the listener can take appropriate action. So in case of node deletion, a comment will be deleting nodes on, comments on that nodes, translation will be deleting translation and taxonomy will be deleting terms and so on. Now, here's the catch, the example that I gave, it was just for the sake of being an example, node deletion is not happening that way. I just considered, showed it here as example. These are some of the actual example of events that are in Drupal 8. So migrate module, it has this pre and post import events that can be communicated to other objects. Config object has this save and delete. And similarly, we have create and delete events when an entity type is being created. So that can be communicated to other objects and they can do whatever they want with that event. Now, Drupal 8, I said that the communication in Drupal 8 happens using events. That does not mean hooks are gone. Hooks are still there. And it might look like that since Drupal 8 has both hooks and delete events, that it is best of both worlds. But I disagree, actually, sorry. These hooks are the thing that are keeping Drupal 8 from being totally object oriented. And some of the majority of the hooks that are still in Drupal 8, they are alter hooks. And I actually talked about this topic with some of the people who are involved in this development of including event dispatcher in Drupal 8. And when I asked why do we currently have hooks and I mainly talked about the alter hooks, I was told that Drupal 8, Drupal and symphony are very different tools. So for example, Drupal 8 is a tool that comes prebuilt with a lot of features. So for example, it already has these forms that we can use to create nodes. Whereas in symphony, symphony is mainly focused for developers and we built everything from scratch. So things like alter hooks are needed in Drupal because we already have an existing functionality that we want to edit. So in this case, adding a form element to the edit form. But in symphony, we actually go and edit the actual code which we can't do in Drupal because that is a part of code and we should not change the code. And because of this difference in philosophy, even dispatcher is not very, I would say, naturally suited for alter functionality. And Drupal community is still trying to figure out a way where we can use this even dispatcher or modify it to suit the alter hooks and replace them. So yeah, that's it about even dispatcher. Next component that I would like to look into is dependency injection. And actually, this is one of the most difficult one to grasp. So if you are not satisfied with what I am explaining, we have a dependency injection session later this evening in same room, the last session today, so please attend that. Dependency injection introduces these three major concepts in Drupal. Services, service container and dependency injection. And I have actually prepared script for this particular part because it is hard to explain and I might deviate off so I will be reading from that. We will look into these one by one services. As I have repeatedly said, Drupal is now object oriented. And being object oriented, Drupal 8 has lots of objects. And some of these objects are useful throughout the application. So one example will be database object. It can be needed anywhere. So service is just a fancy term used by Symphony to call these objects. So in this case, a database object will be a service. It's still a simple object, but that's what Symphony and now Drupal 8 calls. And any object, if you are writing a module in Drupal 8, you will be creating various objects in various PHP files. So if you want those objects to be available throughout the application, you can register them as a service in this service.yml file. This is the syntax for it. Service name, which class should be used to create that service, that is that object. And if any arguments needed to be passed to that constructor. This is the basic syntax. We have a lot of other arguments and properties. But yeah, this is the basic. Sorry. The example of services that are already in Drupal 8 are, for example, a form builder services that allows these get form and build form functions to process, to create a build form. User authentication object to authenticate a user, a DB log object with this log function, DB log now replaces watchdog function. And then current user object that is for the current logged in user and available throughout the application. Next, service container. Service container is a special object. So another object that allows us to create and get the services that we talked about previously. So that is the syntax that we use container object, get and pass the service name to it. And we get that object, which we can then use in our application. Service container when it is created, when it is created, it gathers the list of all services that are defined from all the services.yml file. Again, just like writing that YML, these can be defined by Drupal core, Drupal contry module or your own custom modules. And service container then uses the info from those service.yml file to create these services. So for example, in this example, we have this service, we have class and arguments names. So this information is used by service container to create those services. Next, and this is the, I would say, one of the most difficult concept to grasp because of the way it is named. It's actually quite simple. So I'll try to cover it. Now we have talked about services as useful objects. But when we also said that almost everything in Drupal is an object. So most of the time it will be an object using these services. That is, an object using another object, which means first object is dependent on the second object. So this second object becomes the dependency. And what dependency injection says that an object should not create a dependency. So in this example, this code, instead, it should be passed the dependency as an argument. Dependence injection is as simple as that. Why dependence injection is needed? Because of these two major reasons, it facilitates encapsulation. And what that means is if we are creating an object instead of passing it or injecting it as a dependency, we need to be concerned about all the details of creating those objects. So this is a very simple example, but there might be a case where we might need to pass multiple parameters to create that object. And if we do not inject the object, we might have to initialize those parameters and do various kind of processing here only. So that is something that dependency injection allows us to do. This object would not be needed to be concerned with how dependency is created because it is being passed to it. Another reason is it helps with unit testing. And okay, how many of us here actually write unit test have written? Okay, not a good amount, but I can sympathize because I also haven't written a unit test in my life. So this is something you should recheck because, yeah, I don't have an experience with. But yeah, it does help with unit testing because in unit testing, we have this concept of mocking where we create mock objects so that we can test the functionality. And creating mock object is helped by the concept of dependency injection. Now, service container that we talked about, it is actually the object that helps with this dependency injection because it takes off creating these services and then passing them as dependency to other object. And that is the reason service container is also called as dependency injection container. So if you read these terms, they are interchangeable in Drupal, service container and dependency injection container. Now, I said that if you remember, I said almost everything in Drupal is an object, which means some things are not. Example of such things are hooks and other procedural code. So dependency injection container is actually useless in those cases. So what's the solution provided by Drupal 8? It now has two service containers. One is for objects to be used with object, which is dependency injection container, and it is the preferred and recommended one. Another is static Drupal legacy container, also called as static container, which is for non-object-oriented part. And actually this morning, I was part of the, sorry, sprints, and I heard this term where one person was stopping. This guy was supposed to die, but it's, I think he'll live for another two years. And they were actually talking about this static service container. And I was a little surprised by that. Static service container is used for object, procedural code, and it is the one that should be avoided. And this is the syntax. We use global object, which is the service container, legacy service container. We use it static service method, pass the service name to it, and it returns that service. And it is used with hooks and other procedural code, and like I said, it should be avoided if possible. Next component that we'll be looking into is HTTP kernel. We talked about all these individual parts, dependency injection, even dispatcher, and routing and HTTP, sorry, HTTP foundation. Those are quite independent with each other, and it's HTTP kernel, or in Drupal case, Drupal's implementation of HTTP kernel interface, that is Drupal kernel, that brings all these things together. Drupal kernel is the core of Drupal, and it is actually extended from this HTTP kernel interface, provided by HTTP kernel component of symphony. Drupal kernel is the first object that is created in Drupal 8, so this is Drupal 8's index.php. I thought the other code will be slightly visible, it is not, but yeah, this is the first object that is created in Drupal 8. And among other things, it creates the service container that we talked about, this is the code. It adds services to these containers by scanning through all those services.yml file and instantiating them, and it passes the control to actual request handler, so in Drupal 8 case, it will be the routing system. So those four were the, those five were the core of Drupal 8, and the parts that you will mostly be working with if you do custom module development in Drupal 8. Next four components are also heavily used, but you might not come in direct contact with them, so we'll just be quickly breezing through that. Serializer is another component that Drupal 8 uses. Serializer allows us to do serialization, and what serialization is, it's a process of translating data structures to a format that can be easily stored and translated, and vice versa. In Drupal 8, it is mostly used for serialization of object and arrays. Serialization is facilitated by serializer component, and it is actually heavily used in Drupal 8 APIs. So in Drupal 7, we had to depend on this serialization and restful web services modules, but in Drupal 8, we used this serialization, a serializer component that encodes the objects, so for example, a node object or a user object, to JSON and XML, which can then be passed over to a web client through the, sorry, through the APIs that we have created. So one example will be if you are creating an Android app, and Drupal 8 is the backend for that, and you have created your own APIs. So Drupal 8 uses serializer component to actually convert the objects, user objects or any node object, to convert to JSON or XML format that is often needed by these mobile applications. Next component is validator component. Validator component is used to validate values based on some rules, and in symphony it is generally, or in Drupal 8, it is generally used for form validation. So two things that validator component allows us to do is create constraints. So constraints are rules based on which you validate a value. So in this case, an email field is something that you need to validate, and you might need to check its length, its form, whether it is, I would say, confirming to the email format and all those things. So you will create these constraints for length or for email. And validators are the object which uses these constraints to allow, actually, sorry, validators are objects that acts on basis of the values following this or violating these constraints. So that's how validator component is, what it allows us to do. And again, like I mentioned, validator in Drupal 8 is used to create constraints for form fields and various types. So when working with Drupal, if you find this term in code constraint, so validator component is probably being used there. Next, YML component of symphony. YML stands for YML in markup language. And it is, again, a human-readable serialization language. So we talked about serialization, so YML is related to that. YML is commonly used to store configuration. And YML component of symphony allows us to parse or dump YML files. So, again, serialization is used here. And we get the values from YML file and convert them to objects or arrays. Or we can, if we are exporting the configuration, we can use, convert our objects or arrays to a YML format and write that to a YML file. YML in Drupal 8 is present throughout the system. So you will see, for example, info file, which was .info and was using Drupal's own, I would say, syntax in Drupal 7. It is now written in YML. So module.info .info.YML or .info.YML, then we saw routing and services. We defined them as well in YML. And in Drupal 8, views are now configuration. And if you have worked on exporting views in Drupal 7, when you do the export, it's most of the time, sorry, most of the time, it's always PHP code that is being exported. But in Drupal 8, when you export views, all the data, all the rules of views, they are exported in YML file or YML format that then you can use in another Drupal installation to import those files. So again, the serialization of YML happens there, object to YML in first Drupal installation and YML to object in second Drupal installation. Next console. Okay. How many of you have worked with Drush? Okay, good. So Drush is a command line tool that we can use with Drupal 7 and 8 both. And it allows us to communicate with Drupal. So among various sections that we can do is clear cache, install and uninstall modules and all those things. So symphony has this console component which allows to communicate with the symphony installation. And Drupal extends this console component of symphony and now Drupal has its own console which is optimized for Drupal. And in its current status, it is mostly used for debugging and generating skeleton code. We'll see some commands about that. Now, Drupal console, it does not come bundled with Drupal installation. So if you download Drupal from Drupal.org, you won't find the console component in that. We need to install it separately and it can be done using Composer. Okay. I think everyone is familiar with Composer here. Okay, good. So Composer allows us to do that. Some example commands that Drupal console provides are these generate command for module controller and form and debug command which lists so for example debug container allows us to list all the services that are available, debug permission lists all the permission and debug update lists all the updates, all the available updates for Drupal. And one thing I love about generate commands is it takes us through this command line and it takes us through the Drupal file system. And it takes us through the Drupal file system. So for example, if I do Drupal console generate module, it asks what the name of your module should be, its description and in that module do you want to create a form or a controller and all those things. So it takes you through and it creates, it's write those file in Drupal file system and you don't have to start from Drupal, you can write a powerful tool, I would say, for developers especially. And in Drupal 8, we have both Drush and console and at the current stage, I think both of them should be used at the same time because Drush is still much more powerful than, sorry, Drupal console is much more powerful than Drupal console because a lot of modules have already written code in that and it allows us a lot of things, allows us to do a lot of things that Drupal console does not. But in future, and I believe this, Drupal console will be replacing Drush and reason for that is Drupal console is built from symphony console and symphony console has very good support for programming and for symphony components which are object oriented and Drush is still procedural code and as Drupal develop, Drupal 8 develops, it will, the object orientation or object oriented programming will grow strongly and Drush will be, I would say, will be falling behind because it won't be supporting those components and those things much. So I believe in future, Drupal console will be completely replacing Drush, maybe not anytime soon, Drupal 9 or Drupal 10, but yeah, that's what I think. Okay, so that's all the components that I wanted to cover now. As I promised at the beginning, we will also be talking about some other stuff that Drupal inherits and these are my personal thoughts, some of the symphonies philosophy that Drupal now has and that makes Drupal much better tool. So first thing is easier upgrades. So how many of us have worked on Drupal upgrade from 6 to 7 or 7 to 8? Okay, so it is a quite painful process if you agree with me, right? Okay. And the reason for that is Drupal upgrades in past have been very challenging between the major version that is 6 to 7 and 7 to 8 because of these two reasons. The learning curve was quite steep and there was no easy upgrade path and that was because the Drupal was rebuilt from 6 to 7 and 7 to 8. It was a complete rebuild of application and that's what we had to do with our own installation of Drupal as well. But starting with Drupal 8 that changes, Drupal 8 now provides two different kind of upgrades, minor and major. Minor upgrades are the one from, for example, 8.1 to 2 and 8.2 to 8.3 and so on. And these upgrades happen every 6 month. We have new features in this so you might have some experimental modules in core, some modules that are promoted from experimental to stable status and the changes during these upgrades, sorry, are backward compatible. But we also deprecate old stuff. So one example would be if we want to rename a function, we won't be deleting the old function and just using the new one. We will be keeping the old function and the new one as well. But the old one will be marked as deprecated and whenever that is used it will throw a deprecated PHP warning. And Drupal 8 major upgrades, these will include no new features. So for example, if we consider Drupal 8.15 to be the last version of Drupal 8 and Drupal 9.0 to be the first version. So there will be no extra features in Drupal 9. It will be similar to Drupal 8.15. But all the deprecated stuff from Drupal 8.15 will be removed and Drupal 9 will be Drupal 8.15 minus the deprecated stuff. And advantage of this is, advantage of this new philosophy is we get the new features periodically instead of waiting for years to wait, sorry, instead of waiting for years. So for example, if we want, we have been waiting for views to come in Drupal core and we had to wait for I think five years now after Drupal 7. In Drupal 8, if there is a module that is in Contrib and there is strong demand from community, it might be done in 8.5 and 8.6, so just in matter of six months. And the biggest advantage that I think is this new upgrade philosophy, it allows us to shed deprecated stuff for major release and we are not surprised by the major release. So we are using Drupal 8 from 8.1 to 8.15 in the example that I gave. So as we are writing our code, we know what stuff is deprecated because we will be getting the warnings. So over the time, we will have time to remove those deprecated stuff and use the new one that is supported by Drupal 9. So when Drupal 9 comes, we just need to remove the, change the deprecated part, shift it to new part and we will be ready to go. It won't be a painful process. And this philosophy is actually inherited from Symphony. This is what Symphony does between its version. Symphony also follows this minor major release pattern and that's something Drupal has inherited and I think it's for the best. Next is Drupal is now more standard compliance because of inheriting stuff from Symphony and other projects. So have you heard about PHP FIG? PHP FIG is like United Nations of PHP Framework. So PHP FIG is an organization which has representatives from various PHP projects. So Symphony, Drupal, then Zend Framework. PHP FIG has representatives from then and they come together to discuss what's going on in PHP world and how can they standardize things so that there is an interoperability between these frameworks and that's the reason it has been named so Framework Interoperability Group. And they discuss how they can use the solutions that are provided by other frameworks in their own without reinventing the wheel. So they come together and release these standards which are usually PHP interfaces that these projects should implement so that if Drupal, one example I would take is Drupal currently uses routing component of Symphony. And sorry, that's a bad example because there is no interface for routing, sorry. Drupal uses this logging from Symphony and it implements this logger interface which is a standard released by PHP FIG. So in future if there is another Framework which provides a better logging functionality, Drupal won't have to rewrite it completely because Drupal implements that interface. It can easily switch to another one because that framework would also be implementing this interface. And these interfaces are released as PHP standard recommendation or PSR. Some of the PSR that Drupal currently implements are PSR4 for autoloading. It uses a combination of Composer and its own functionality to autoload classes. Another is PSR3 which is the logging interface that I talked about. You can read more about PSR and PHP FIG on PHP FIG's official website and that is actually a quite helpful concept. And if you are writing your own framework then I would recommend that follow those guidelines so your code will be usable by other frameworks and for you it will be easier to use code from other frameworks. Now things that I want in Drupal and these are the things that I personally feel and I got to know from other members of Drupal community as well. First thing is symphony's philosophy of loosely coupled independent part. So we saw that Drupal, sorry, symphony has these 50 to 55 components and all of them are loosely coupled. And because of that reason Drupal is able to use some of them, just nine of them. What I want to see in Drupal in future is Drupal also becomes a set of these loosely independent parts. So for example, if I'm writing a web application using Zend or symphony and I just want to use one of the Drupal part for example views from Drupal or just the taxonomy. How wonderful it would be if they are available separately instead of me needing to shift from that symphony or Zend framework to Drupal completely. And that's something I would love to see in Drupal that all this part, menu system, taxonomy system, entity and nodes, they are available as loosely coupled parts that I can use in other projects. Next is I would love to see more standard compliance. So if you work with Drupal and other framework and if you work simultaneously on both of them in same text editor or ID, you might have noticed that Drupal has different way of code styling and those other frameworks are different. And sometimes personally when I first time I was looking through symphony code, I was like why is this opening brace on the next line and why do they use four spaces for tabs. And I was like they are crazy and then I realized no, they are following the PSR guidelines. Drupal is not. And I would love to see Drupal following more of these PSR guidelines. So PSR one and PSR two are for code styling but there are others as well that I would love to see in Drupal so that Drupal is more in line with and much more closer to rest of the PHP world. Okay. I think that's all I had. These are some of the take aways. Drupal now uses symphony components, not symphony framework. That is the one differentiation I really wanted to make. We also saw that our STDP foundation and routing now helped Drupal become a better API, more support for creating APIs. And there is actually a sentence that was used by Larry Galfield. He said that Drupal is a first-class CMS and he wanted Drupal to become a first-class API framework with a first-class CMS on top of that. And that has been made possible by this STDP foundation routing component from symphony. And we also saw how these components, these five components formed the core of Drupal 8 and how symphony has changed Drupal. So I think that's all I had. Any questions or discussions? Thank you. I was really hoping for that. Yes? Hi. Thanks for a great presentation. Thank you. Thank you very much. Glad to know. I have just some information regarding your thoughts about Drush. Okay. The Drush maintainers have recognized the weakness of their code base. Okay. And there will be an upcoming Drush version 9, which is available today, which will be a complete rewrite of the Drush code base based on symphony components. Oh. So using console and YAML and all these things, using YAML configuration, for example. Oh, that's good to know. Sorry. Drush will get an own code generation tool, Drush generate module, service or whatever. So it's on the way to feature parity with Drupal console. Okay. This race is funny. I have no idea why there are two concurrent tools doing nearly the same thing, but it's the state at the moment. Okay. And this new Drush version 9 will be needed to build Drupal 8.4 upwards sites if you use Composer. Okay, that's good. Drupal 8.4 based on Composer will not be able to use Drush 8.3 Oh. Cause, no, not Drush 8.3, Drush 8. Okay. Cause the Drupal core 8.4 is based on symphony 3. Okay. And Drush 8 is based on symphony 2.2. 2.8, okay. Okay. Sorry, your name? My name is Boris. Boris. Also called Drup. Okay, okay. So one thing that I was wrong about and Boris pointed that out. I mentioned that Drupal 8 might be replaced, sorry, Drush might be replaced by Drupal console, but that's not actually the case. And I talked that Drush has poor support for the symphony components, but Boris pointed that out that new version of Drush, that is Drush 9, is going to have better support. He and I are equally confused why we have these two tools, but yeah, that's how things are. Any more questions? Okay. Thank you. Please read this session. It will be really helpful for me. And thank you very much.