 Welcome to the Drupal8 initiative session. This is a talk about how Drupal8 has changed in the past few years now, besides all the official initiatives you've heard of. So my aim is to, maybe you may see something that you know already, but maybe something you don't. So my goal is to put light on all those initiatives or all those changes that haven't been so publicized, besides the official initiatives. So before we start, I have a couple of disclaimers. The first one is that what you see here, what you're going to see here, may or not be true, is not I'm a liar or anything, is that I've been running this session for a year or so now, and I was looking to the initial set of slides, and I've probably changed all those twice or three times. So the things that I'm presenting are there, but it's not guaranteed that there may be changes or some things may not happen eventually. The second is that I'm showing code, so if you don't see it properly from the back, it's a pretty small room, I guess you will. But if you don't see it, the slides are already there, in bit.ly.slash d8 undercover. So if you want to check those, go ahead. So about me, I work in a company called Imbra. We're based in Barcelona and London. I'm in Picambra all over, and I happen to be the track chair of the Code Run Development track for this con, and the new small PHP one. So if you have any feedback about those, I mean, this is a random disclaimer, but if you have any feedback about those, just find me and I'll be happy to answer any comments. So let's get started. First of all, I want to talk about what the Drupal Laid initiatives are and how they are relevant. I have two screens here. That's great. Yeah. So this is a new way to develop Drupal Laid. We didn't have that in Drupal 7. So it sets a very specific goal, a very specific objective for the leaders of those initiatives that are appointed. And it improves the focus of the volunteers working on those initiatives. So whereas you may not have a clear idea what to work on, they do, and you can look up and ask them what their goals are, and they have the authority to make decisions. So these, if you're not familiar with the initiatives, these are the initiatives. We have the web services one, the abusing core, the CMI, the mobile one. So these are the official ones. These guys have a goal and move Drupal Laid to that goal. But a ton of things happen outside these initiatives. So I see Drupal Laid, like you get a new car, you open the hood and then you get a big snake there. You probably didn't know about it, but you probably want to do something, unless you'd really like big snakes. So this is like the graphic vision of this talk. There are really big things changing and you should be aware of it. I'm starting with a couple of things that you probably heard tons about it. First one is that we have a new WhizWeek A&Core. You didn't hear about this one, right? Yeah, okay. So we've been complaining for six years in Drupal that we don't have a WhizWeek Editor once we install. That's like the main conversation that you used to hear. And as soon as it happened, well, the first thing we did is complain, because maybe it was too much WhizWeek all around. Another thing that happened was tweak. If you haven't heard about it, there's a great session about it. I don't know when it is, but just look into it. So we had this in Drupal 7. This is how we render a block with PHP template, right? So there's a lot of PHP here and there and there and print. This is not really safe for handing over. How many of you have considered yourself developers? Okay, well, is there any themeer in the room? Well, maybe this is not really safe to handle someone that implements the design. There's a lot of security issues and things like that. This is the same file with tweak. You have nice output here. There is no PHP. Everything is sanitized. So this is a great addition. There is a new autoloader. You have probably heard about the PSR thing. And before you ask, it stands for proposal for standard request. I forget this after the talk. And this is not a code thing. It's just a standard. So it marks how the file should be organized. So Drupal 8 started with PSR 0, which means that you put the right file in the right directory and it will just load. It will autoload for you. So that means no more requires or model includes or files array or hook menus with path and file and everything. You don't need that because you put the file in the right place and it will just load. And the PSR 4 simplifies the folder structure. And this is great for a really important reason that when you download a model or when you get a piece of code, if you want to know where the menus are implemented or the forms or where the entity definitions are, with these you just know. You just go to the folder that should have them. And all the models should be implemented in these. Otherwise I would consider that broken. I suppose as getting a hook menu that defines the admin page in an admin file or just in the model or just in a folder called admin or just, you know. So you have a very, very good structure and you know what to expect. There are some things that have been gone from Drupal 8 Core. So don't bother looking for them there. So it's been strong. Core is smaller in a way. One thing is gone. I'm very happy about it and you should too. The PHP filter is gone. I feel safer already. I mean if you get handed a project, the PHP filter could be anywhere waiting just to hand you. Because, you know, it's as simple as that. And it has security and performance issues. So if you put a PHP filter, PHP code with PHP filter in a node, that invalidates cache. So that's not very good. And it solved a very specific use case in the past, but I don't think we have that anymore. So it was useful in the past, but you know. But if you're willing to take the risk that you don't, honestly, there are some country models that enable the PHP filter for those that like risk sports. When you get these slides, you have links with the history there and how things happen. Maybe useful. So these are gone as well. So we don't have the profile model. We don't have block anymore. We don't have trigger, because honestly, how many of you did actually use the trigger model of Core? Okay, one. There was a shy hand in the back. I didn't. Dashboard is gone. OpenID. You know how hard it's put a blink nowadays in HTML? Overlay is gone. Fall is gone. And no garland anymore. And that may be a sad panda thing, but we have Bartik now. And all of these are... It's not that they just wipe out the code. All of them are in country models now. It's just they are not in Drupal Core. Okay, so this is a quote from the issue queues. It says, Disabled models are broken beyond repair. I'm just being literal. That's what it says. And this is something that... I mean, a very graphical image just came to mind when I read this. And we want to share it with you. It's this. So you may have something that was great at the beginning, then got a little less great, and then, you know, over time, then someone came and tried to fix it. It was not really possible, you know. It's not that it was a matter of skills. It was just really, really impossible to do. So no more model disabled for us. And this is a very controversial part of the presentation, normally, because people say, well, I used model disabled. I think it's useful. I'm not reflecting my opinions. I'm just telling that. It has happened. So basically, in a nutshell, disabled model means disabling how it behaves with other things. Say the user, say other models, say the database. So say you disable a model and you leave it like that for a while. And you're side evolves. When you go to enable that model again, you may have a data integrity risk, because all that data got stale in a table for a while, and then you don't really know if that's going to work. In Drupal 5 and Drupal 6, you know, when building websites seem simpler, this worked very well. But in Drupal 7, we already started to notice that this wasn't a very good future plan. So everything that looked like a disabled action for models is gone. So now a model is either installed or uninstalled. So if you have a model and you enable it, install it for the first time, for getting rid of that, you need to actually completely uninstall it. And thanks to the slide we saw before about PSR4, there is a new autoloader. So if a model is installed, it's installed, the autoloader will look for the files and will load the files of that model. That makes disabling it really, really difficult, because it will be a very big overhead on the autoloader. And they might be a model for this. It's just, I mean, they just reserved the namespace. Let's see if someone figures out how to do it, but not in core. Normally the use case you have for disabled model is like I'm doing a migration and I want to just disable this thing to see if the rest are working, right? So, yeah, yeah. Yeah, I said the book tool. That's the other use case. So you have an error, and then you have to... You use a very deterministic approach of removing things and then see if it's working. I would say that you need a real debugging tool. I mean, which one is failing? I mean, you can put, like, a nice... An ass break point and then debug the whole thing. You won't be able to do this in Drupal 8 anymore. You won't be able to disable a model and just see if the site gets fixed. As I said, this happened is not my... We'll see. Don't kill the messenger. So another thing that is gone, and this may be surprising, this has happened progressively. I mean, like, it's been a progress for the last few months. It's been happening for a while. It's that we don't have a menu model anymore, but wait before running away, panic. Yeah, don't just run just away, I mean. We have a new menu system. It's not just a model. We have a new menu system. And this menu system starts for the roads. You have the roads there, and you define the starting point, like the URL or the URI. And you have a subsystem for every other menu component. And we'll see this in a little bit of more detail. But the things that we have in Drupal, and we call it a menu, are the menu items, like normal menu item that is in a hierarchy. We have actions. I mean, we have tabs, we have actions, and we have contextual links. We have typology of things we have. And actions, if someone, because I have to look this up to see what the action was, like the class, create new node type. That's an action. And then we have the custom items, those that you just create by interface. And menu is gone. So most of the things are basically part of the core libraries. So there are two new models. So for each one we kill, we get two new. We have menu UI that takes care of the interfaces, like if you disable views UI, you can't create a view. That's what it is. And menu link content that takes care of the custom items. So if you enable that, the user will be able to create new menus, new menu links inside through the interface. And this is what a menu is in Drupal 7 as for today. I'm just trying to reason why this happened. And here you see, well, here you see a number of things. The hook menu that we all love. We declare a lot of things. So if you declare a menu, you are actually creating a root. You are actually creating a page. But you're also adding a callback with wildcards and access. And what it is. And what type it is. So hook menu is clearly doing too much. And that is a big problem. So that's why the menus got replaced by this new collection of tools. And this works as this. So we have the root first. So you first need to create the entrance point, like the URL. So we have a routing system. The due defining Jammel files. We'll see a lot of Jammel stuff in this presentation. Jammel is yet another markup language. So it self defines very well. It's like JSON, but not JSON. So we have roots that map basically the path with a controller. This controller can be a method in a class. It can be leveraging the entity form system. So if you want an edit form for an entity, you need this. That's it. You have loads of examples. If you go to this track, you'll see a lot of these examples these days. But it also defines permission and access to that root. You can even put regular expressions to say this argument here is only string. Or it can only be decimal or any other crazy regular expression you can come up with. So this is like the entrance point. This is just defining the root, like the path of the page. Which actually, if you think about it, doesn't have anything to do with the actual menu, the navigation menu of the user. So if you actually want that menu as well, you need to define it in another general file, which are the node, I mean the node, the model name, the links, port, because we need something, and then the type of the menu. So we have tasks, we have action, we have item, we have many of them. And this is actually what creates the menu that the user sees, the navigation thing. And custom menu links, you can have it as a normal content entity. So when the user creates a menu, it's actually a new entity, like a node or a taxonometer or the same user shares the same thing. So the thing that you need is the root name. So I don't know how many times you've changed an application in hot mode when the URLs change. So suddenly the user wants a new URL for something. That's pretty common and has happened to me last week. And you have to basically search and replace every word you've used it, right? So with this system, with the new routing system, you have a machine name for the root. And just one place for defining the URL. Which is great. Yeah, contextual action tasks and menu links, that's it. Okay, so as I said, for every model we killed in Drupal 8, two extra, at least, appeared. So actually Drupal 8, I mean, that before was a plain lie. It's not strong at all. It's bigger than ever. And something you could say, I mean, all the hooks or many of the hooks are gone now. And we've replaced the hooks by a ton of files. Object style. And that's probably good long term. It's been a painful process. But one great thing we have in Drupal 8 is migrate. And there are sprints right now, all this week in migrate. So if you're interested in this, that's a great place to learn. So you know the update PHP URL. You have in Drupal 765 and probably earlier than that. That will be basically migrate. A migrate as in the country of migrate model. Because it really, I mean, how many of you have done client work using the update PHP? Okay, few risky hands. I mean, it wasn't really working, honestly. I mean, as soon as you have something a little more complicated than the normal use case, like the expected use case, you probably just already did migrate workflow, right? You just build a new site, import all the content, and then go. Even for Drupal to Drupal. And actually the first thing, one of the first things that got into core with the migrate model was the migrate from Drupal 6 to Drupal 8. So there are tools to migrate to Drupal 6 to Drupal 8, more or less, I mean, in a pre-vita status as everything else in core right now. And migrate for Drupal 8, I will show you some code now. It uses best practice, like, I mean, it's core now. So the quality of the code is core standard. And it's testable, and it actually has tests. So you can guarantee that something is working or not. And that's a very, very powerful tool. So you could potentially pass a sample of your data to your migration tools and see if it's working or not doing the test. This is how you define migration these days in Drupal core. As I said, this may change slightly or not in the future. So you have a jammel file, that's a surprise. And you have the name of the model, migration, and this is the machine name of it. These migrate user roles from Drupal 6 to Drupal 8. Because the other big thing with migrate in Drupal 8 is that you can actually migrate also configuration. So you can migrate both content, like nodes, and configuration, like a user role, or taxonomy characteristics, or anything that is actually configuration, or variables, all the variables have mappings already. So you can migrate your variables the same way you migrate your content. And that is a good thing. So you define a plugin name. We'll go to that in a moment. And you define a series of transformations. So you have a plugin system to your sources, meaning you're getting from a database, you're getting from an XML. How's your XML doing? I mean, is it CSV or is it an Excel file? You can have a plugin for that. You have an object that takes care of that. Then you have processors. So this thing here converts whatever string you have to a machine name to make sure that the user roles you are importing are really a machine name. And these take care that the entity name is not duplicated. So you could add processors to your migration that transform your data over the process you're doing. And at the end somewhere, sorry, I'm looking there, should look here, you have destination, and that's another plugin. So you can have a destination that is an entity, that is a variable, and you can override that. And all of these are pluggable, so you can actually extend them, you can actually provide your own, you can modify them. And this is the example of the machine name. This is a process plugin for Migrate. This is not a Migrate talk, it's just to get you in the right path. But when you do a process, what you have is a transform. It gets something and outputs something else. And this is generating a machine name. So it gets the transliteration value, it transforms to lowercase, it does a break, it replace a regular expression to just have the underscore to have a machine name, and then just return the value. That's it. So if you have another transformation, you can just go in this exact same way, actually. Wait, plugins was that? Because I've said it a lot. A plugin is just a piece of code with a specific purpose. You can say that's a very broad definition. And Drupal 8 has plugins everywhere. The block system is a plugin system. The migration is a plugin system. BU's has an incredibly lot of plugins in there. So this is just a way, a fancy way to say all your code that was in model files should be more or less that. And if you want to know more, I'm going to just, because I'm cheeky like that, I'm just recommending you sessions. There is a session in the plugin system, if you want to know more, it's going to be great with jokes in there. Highly recommended Thursday. Speaking of plugins, the action system is a plugin base as well. So as I say, how many people did actually use Trigger and Action Models in Drupal 7? I mean, you had rules at some point. So it wasn't really, really powerful. So actions are now an outdated plugin, and this is one of the other pain points of this presentation. You will see that in a minute. And we have configured actions that doesn't require a user input. And those are configuration entities, and we'll talk about that in a minute as well. So the Action Mode will be just the interface. I'm actually not sure if the Action Mode is ActionView I know. That means we have a simplified ViewsBool cooperation in core, which means that all your listings in the admin interface will become views. So if you want to provide the user with an extra field in your node listing, you can, you don't have to do anything. Really, really complicated to have that. And that is great, right? I mean, it's great. As you have the Actions API, you have a Conditions API as well, like matching. And the rules, CountryMobile will probably be based on this. So this is an example of a plugin from the Action. This is an Action plugin. So you have a configuration, and you have the form. So for example, to provide a user with a new role, that's a very classic triple Action. I have a user, I want to give him a role. So I need a UI for that. So the role you're giving him will be exposed in a form here. And then you have a normal validate and submit function. But if you want to provide a pre-configure Action, like with your installation, that the user doesn't need to actually select anything, it's just an Action. When this Action runs, I just create this role for the user. I just assign this role to the user. No selection or anything. This is a Config Entity. Have you heard before about Configuration Entities? No? Yeah? What? Configuration Entities. You know we have Content Entities. There are no taxonomic users. Those are fillable. Those are the usual entities we are used to work with. We have Configuration Entities now in Drupal 8, which share the API with the Content Entities. So you can just create them or delete them. We'll go back to that. And it uses a different storage in the active config, what it's called, instead of being in tables in the database. Well, actually they are in tables in the database. But instead of being a normal table, it will be a key value per normal. You can create these Configuration Entities just by putting a right jammel file in the right place. So you don't need to do PHP code to do that. And you can move them around between environments very easily. And not fillable. And if you have the temptation of having a Configuration Entity to add a fill to a Configuration Entity, it's probably not a Configuration Entity. It's not for that. So let's look at this example again. This is a Configuration Action. And we create it just with entity create. We don't need any other API. We create the Configuration Entities by code if we need it with this same API. Otherwise, you just provide the jammel file and you're good to go. Yeah, yeah. So I have a very important point here that is while all these other initiatives were not, and these are great, don't misunderstand me, but a huge thing has happened in the back, like the back of the room nobody was watching. The whole field system and the whole entity system is changed. Actually, it's been changed twice. And we are all talking about symphony and everything related this week, but the sea of CMS is for content, and that's where the content is. That's a really important part. And a lot of things have happened. And one of the big things that has happened, besides having a date fill from the moment you install, because you use dates, right, email, link, fields, there are simplified parts of these models. So when you install the telephone field, you don't get all the countries in the world in a dropdown. You just get a plain text. So it's a simplified version. But the great thing is the entity reference. So there is no more discussion about how you relate entities between each other. In Drupal 8, you use entity reference. It's flexible. It's extendable. It's plugin-based again. So if you want to go nuts with it, you can just provide plugins for it. And you don't need to do any hacking. And this one is great. So I don't know if you have the necessity of having a comment in something that wasn't a node. Sounds familiar to some? Okay, I know I did. Comment is now a field. So you can add comments to anything, meaning that you can add comments to comments. You know, forums. You can have several comment fields for every entity type. And you can reuse existing fields. So everything that is good about fields, you have it in comments, which is a great thing. And there will be, if there is not already, a migration path for upgrading your old comments to the new system, which is a good thing to have. This is a slide I totally stole from the Field API session. This is where Field API meets the Configuration Management Initiative. So all the... How many of you have struggled with features at some point? You know about the field config thing and the bundle settings, right? The bundle settings is one of my nightmares. Those are gone. So fields and their definitions are jammel files. They are configuration entities. So you can deploy them in environments. That's good. They're supposed to be human readable. I mean, it's a jammel file. It's a text file. So it's better than a bunch of PHP in a feature file. And it can be deployed, as I said. And in Drupal 7, when you delete a field, you got a table called field deleted and a number. It's familiar with that. And when you try to create a field that it was named the same way that you couldn't, all you could hope for is to rank around and finger cross it will the field go away, which sometimes didn't happen. Now the delete fields are kept in a state, in a state variable, so in a state storage. State is a new storage for storing key value pairs in Drupal 8. So they are not deployed. So it's like you will store there the last time the Chrome was run. And that's not something that you're interested in moving in between environments. So the delete fields are going to be stored there and you'll be good to go. That's a great addition. What we used to call fields is now called field storage. It's been renamed many times over the past months. And you define a field like this. I mean, you normally wouldn't create this yourself. You'll probably create the field by interface and then export this to a Jamf file. That would be like the normal workflow. And you have the entity type. You have a lot of things here. And the name of the Jamf file to put in your model will be like a field storage entity type because the fields are bound to an entity type. And the name of the field. And what we used to call instance is now called field. And you will end up with something like field user picture. So this is the entity type. This is the field entity type. This is the entity type. This is the bundle. And this is the name of the field. So don't put too many users there. And then you relate them with the bundle, with the entity type. And you can have dependencies there. But just yesterday, or maybe it was two days ago. Yeah, field name is not field name anymore. It's name. So these things change a lot still. And there's a Drupal 8CMI session with Matt Cheney and Dave Strauss on Wednesday. If you want to know more about CMI because that's a little out of scope. And I think this slide, I've changed it 13 times. I'm not exaggerating. So if you want to create a field, there are configuration entities. So you can use entity create for that. So you can entity create a field storage config for a node with this name, with this type. And then you can create the field config is the instance. So you can create the instance for this. Actually, this should be name. Sorry about that. Entity type and bundle. That's how you would create a field. You can put tons of settings there, but that's the basic thing to create a field in Drupal 8 by PHP. You can put the Jamel file and it will import the configuration. And you can just change things like this. You can change the field config, change the cardinality and then call save. As if it were another entity, which it is. And then you have a limited set of hooks that have survived the hook destruction. Some of them are still there. So you can hook there if you really want. This is just the last node. Widgets, formatters and field types are now plugins as well. So we'll see how to define those. So this is something I struggled with Drupal 7 for a lot of time. That if you want a formatter for a field that is similar to another formatter that you already have, but not quite, you have to just duplicate the whole thing. Well, now these are plugins, so you have inheritance and you can just override just the parts that you're interested in. And if the other thing changes, you just carry on the changes. And this is the thing, annotated plugins. What's that? That's the other pain point of this. This is not a comment. This is the PHP way of supporting annotations inside columns. So you have the field widget. You put an ID, label, and then the field types. This piece of here is what replace hooks, like hook-fields-info, or hook-field-widget-info in this case. The same goes with, well, this is the implementation of the widgets. So for a widget, you have the setting form, the form element. You have an error element. And my favorite name of function of Drupal 8, massage form values, which is like a pre-validation thing. You massage the data. Formatters are the same thing. You have a setting form. You have the summary for the listing. You have a preview, a pre-preview, sorry. And the definition of both widgets, formatters, and field types is similar to this one, to the annotations. So you put the plugin file in the right place with the right annotation, and you will get a new field type. Be careful with this, because if you screw with this, like you put a comma where you shouldn't, or you don't put a comma where you should, like a formatting thing, you will get an incredibly awful doc-trying error in your page, which leaves you very clueless. So if you get that, it's probably one annotation that is not properly formatted. Wait, there's one more. I totally recommend it, because the field system may be rewritten in these two days while we wait. There is a session with the field API and the entity field API by the guys that made it. And that's it. Oh, yeah, and this is like a thank slide, because without these guys, the undercover initiatives, all these things happen that were really necessary and really, really useful. These are many more are not responsible, and most of them are here. So say thanks or something. You see them? Oh, and final, final notice. There are sprints the whole week, but on Friday there is a dedicated sprint and all these things and more. So find information there if you are interested. And that's it. Thank you. Please, please, please, please rate the session. We have two ways to rate any session. One is if you go to Slash's schedule in the Drupalcon website, but we also are trying to do ratings in joining. So if you go to Bitly Rate D8 Undercover, I will much appreciate that. I don't know if we have time for questions. Yeah? You have any questions? Just there's a mic there. Otherwise I'll be sticking around for a while. So thank you for coming.