 Great, let's get started. If I don't make eye contact during this presentation, it's because I'm staring into this light, so nothing personal. I'm gonna take a picture, so either y'all know if you don't want me to, or duck your head down if you don't wanna be in a picture. Signing DrupalCon presentation for me, hopefully for you. Okay, this is Drupal 8 Module Development, mad with power. So my name's Ted Bowman. I work at the office of the CTO at Acquia. I'm Ted Bow on Twitter and Drupal.org. Probably best way to get in touch with me. Drupal related stuff or otherwise. I'm a core developer, so Acquia pays me to work on the API First Initiative for Drupal 8 and UX initiatives. I'm the maintainer of the Settings Tray Module. Mostly work with core rest and core serialization. I'm also working on a new distribution called Reservoir, which is decoupled distribution, which if anybody is interested, can ask me about afterwards. So who are you guys? Who are module developers? Okay. Who is new to Drupal 8? So a lot of people. Who's new to Drupal altogether? Some people. Who's coming from Symphony? I've got a Symphony experience outside of Drupal. A few people. Who's new to object-oriented programming? Okay, cool. Just trying to get a kind of idea. So this is not really like an intro to Drupal 8 Module Programming. This is kind of, so Drupal 8 is pretty different from Drupal 7. I come from a Java background, so I really like a lot of this stuff because there's a lot of stuff in Drupal 7, or actually I came to Drupal in Drupal 5 and there was a lot of stuff that was like, what's going on? I hate this. Why do I have to name this function exactly the same way? And so now in Drupal 8, I got used to it and then Drupal 8 came around and I was like, oh yeah, this is getting rid of all the stuff I hated about Drupal that I forgot I hated. So for me, it's really nice. It's a big change, but I think I'm mostly for the better. So today's examples are going to be, I think, powerful, sort of new things that you either couldn't do in Drupal 8, sorry, Drupal 7, or were kind of hard to do or hard to figure out. I think they're cool. I think they're hard to figure out. A lot of these things took me a while to figure out. So I'm not gonna go through how to make routes and stuff like that. There's a lot of tutorials for that. There's hopefully some basic Drupal 8 sessions here this week. So there's a Git repo. You could probably just Google GitHub, Tedbo and find it, but it's github.com, Tedbo, Drupal 8 Power and so all of the modules that I'm presenting are in this one repo just so it's easier for presentation. So if you want to look at them, you could look at them now or but if you want to see them, don't worry if I go through the code. Am I just the wrong height or something? Just really bad. So if I go through the code, example's too fast. I mean, definitely ask me questions, but also realize you'll be able to see all these code later. So today we're gonna go over the importance of object-oriented programming, importance of having an IDE. And I think some people I've talked to after this talk when I've done it other times if I get no other message across to you that Drupal 8 is much, much easier if you're using an IDE, so an integrated development environment. I use PHP Storm, but there's other really good ones also. I'm sure I used to use Eclipse, it was good. Gonna talk about base classes, base fields, extending classes, creating condition plugins, and then just to emphasize again, importance of an IDE. An IDE and object-oriented programming. So Drupal 8 is object-oriented. It is more complicated, but it's more encapsulated. I feel like it's more self-documenting. You can look at the code and kind of figure out what's going on more than I could in Drupal 7. I think especially if you're not coming from Drupal 7, if you're coming from other frameworks, you might find it a lot easier. Because it's self-documenting, I find it a lot easier to learn. And again, all of these things, the whole self-documenting and being easier to learn kind of depends on you using an IDE. So we're gonna have examples of each module sort of talk about if they're object-oriented, how an IDE helps us, and they're gonna stop and demo. Okay, so first concept I wanna talk about is base fields. And base fields are not the fields that you see on the managed fields page. These are fields that Drupal has made for you, either core or another module. So these aren't fields typically that you can add or remove just from the UI. So examples on the node, entity type, we have author, created date, the change date, and the content type itself of a particular node. These are all base fields. On the user, we have the name, mail, password, and roles are all base fields. So these are things in Drupal 7 that weren't, they were called properties in Drupal 7, but in Drupal 8, it's all using the same field system, which we're gonna see, we get a lot of advantage of that. So base fields use field widgets and field formatters much like the fields that you add do. Some of them are configurable, some of them aren't configurable. You can actually add new base fields through codes and you can alter existing base fields. So base fields examples is the node author field, is an entity reference to the user, so we see it down here. It is form configurable, meaning you can change instead of say auto-complete, you could actually change it to a dropdown, though if you have more than five users on your site, I probably wouldn't recommend that. So it can use the entity reference widget. So any widget that you can use on, say, the tags field you could potentially use on the author field. It is not display configurable, so you're not gonna see it here display the author or not. I think I'm sure there's probably a module to do that. It, yeah, so it's not view configurable, so you won't see it on the manage display tab. So another base field is user roles. So in Drupal 7, I guess this was a property, but this is actually an entity reference to a role, which is a configuration entity. So in Drupal 8, you have the concept of content entities, which is usually stuff that you're going to somehow enter through the UI. Well, configuration entities you would enter through the UI also, but configuration entities you would export through configuration. Usually the main difference is, or one way to tell, so if you have a lot of them, they're usually content entities. So the user roles is a configuration an entity to, any reference to a role configuration entity. So you can use a lot of the same formatters, but not all, you can use widgets. It's not configurable by the form by default, so you can't say, well, I want to change the, I think it's a checkbox by default, I want to change this to an autocomplete. It's not gonna give you that ability. And it's not view configurable, so you can't say, I want to display the roles and I want to display them as links to roles or whatever. So let's look at an example module. This module is called real author. So it tracks who really wrote the content. So often you'll have a site where people are signing in and they're filling out content, but they're filling it on behalf of another user, or maybe somebody who's actually only represented by content on your site. So if you maybe run a blog for a famous author, maybe they don't even sign in. So it separates the Drupal user from the author. So an example would be we have the node entity type, we have the author, which is a user entity reference field, and this is what core provides. Oh, all right, all right. Let me know if that happens again because I probably won't see it. And then our module, the real author, would actually create another field that's also a user entity reference field, and this would, we'd call it real author, but same thing, it's basically sort of on the same level. So real author removes, this module's actually gonna remove editing configuration from the author field, so if we're gonna track who's the real author by having somebody enter in another user, we want to use the core field to just say, whoever signed in is automatically just the core author. So the author's always gonna be the signed in user. So we're gonna do this by implementing one hook, entity base field info alter, and we're gonna add a new field, and we're gonna use another hook, entity base field info alter, and we're gonna remove access to the author field. So that is gonna give us on the manage forms page another field that is real author, and we can change to whatever auto complete or drop down whatever we want. And we're not gonna see this on the manage fields page again, so even though we're adding this through our module, it's like core's author field, we can't take it away via the UI. One of the real big benefits of this is it actually shows up on the table, I think it's called no data table, but basically where all of the other, what would have been properties in Drupal 7 are on the table, so they're not connected by a field table where you have to do a join, it actually is on the base node data table itself. So we have our real author right next to the node ID, right next to the type or the UID, which is the core author. And of course this would have a lot of performance implications because you're not doing a SQL join. So is it object oriented? So not exactly in the fact that we're using an old school like Drupal 7 hook, but it does benefit from Drupal 8 classes and let's take a look at how that works. So before this little clip to avoid me doing all live demos, but so if we see this up at the top, it's we're implementing hook entity base field info. So basically this is where we can add new fields if we want to. We're basically checking to see if it's a node entity type and if it is, we're creating a new base field that's an entity reference and we're going to build other author. I guess I left to put this twice. We're gonna create the real author field and then once we start to create a new field, once we start typing because I'm using an IDE and it knows what real author is, it actually can tell me all the methods that are available and easily lets me fill them in. So I did label, description, cardinality, meaning only one of these fields. You could have two obviously if you want two authors. I type is required which is wrong because that's telling me if it's required. I want to set that it's required. Again in IDE, you'll see that pops up and tells me hey, it's expecting a Boolean here. And then I want to set display configurable on the view. I want to say yes, it's displayable on the basically managed display tab. If I wanted to know what it is, I can just sort of look in here and because I'm using an IDE, I can go to the help and it can say oh, it's expecting either viewer form and then a Boolean field. So in Drupal 7, instead of actually methods on an object, how would you do something like this usually? An array, a big array probably. So in Drupal 8, we did have hooks so it's similar in that we have hooks but I don't have to send back a big array of like configuration for the field. I actually forgot what the hook was in Drupal 7 for this but you can pretty much be a safe bet that somehow in Drupal 7 it would have evolved a big nested array. So I like this way better because, one, I don't have to memorize what the keys for the array and the values are. The fact that when I start typing my IDE can say hey, you can set the label here. And then if I didn't know, say for set display configurable what that actually means, it's gonna easily pop up help and tell me what it might mean. Whereas in Drupal 7, I was always going to the API pages on Drupal.org to say, what am I supposed to put in this big array? So there's still some big arrays so don't worry, especially in the render system. The other code in, let me just look at this in my IDE. Try to make this much bigger. Real, oh, wrong place. So this is basically what we've set here. The other one that we are doing here is the hook entity base info alter. And here, again, I'm looking to see if it's the node entity type. And I grab the UID field and here I want to display configurable. And I want to say by default you can configure on the form. The, you can actually change the author from say auto complete to a dropdown. I want to actually take it away from the form, the managed forms place page all together. And then I also want to set the display options none, meaning it's never going to show up on the form. So I'm basically taking away the regular author field. So how that sort of looks, what I showed in that video is because my IDE knows this is a field, then as soon as I type the arrow here it's going to tell me all of the things. So I don't know. Does anybody prefer big arrays over this? Okay. And the other thing, nice thing about this is if I hit in my case F1, I can see if I didn't know what display configurable was. I could do that. Also, it's really easy to jump to the actual where this is defined if I wanted to see what's going on. I really recommend also in Drupal 7, but in Drupal 8 especially when you're sort of calling these functions if you have time, just click on them, open them up and see what they're doing. I think learning from Core and other modules is a really great way to learn sort of how Drupal works, but also really good code examples. Check my time, 12.15, doing great. Okay. All right. Okay. So other ideas for base fields. You could use a term reference for your main site categories. So instead of adding a field, a term reference field, you could actually have it in code so when you turned on a module, nodes just got a term reference field directly on their node table. That would provide better performance and also you wouldn't have to configure it each site. Another idea for a way to use base fields and modules is you could potentially put a entity reference to a user on the term entity type so you could actually implement a sort of authorship type for terms. So for date time base fields, Drupal has created and changed timestamps but not a first publish date. So you could actually add a base fields that's first published. Of course, you'd actually have to write implementations to say, okay, once I've created this field, I want, when it's first published, I'll save the date. The other one is a user block date. So if you block users, maybe you want to have an idea how long they've been blocked for. So but there's not a field on the user for that. So you could actually add it via the base field to be on the base table and say, okay, this user's been blocked for one year. Maybe I should just kick him off or maybe that's long enough to block him. You could do an original import ID on any entity type so you're migrating them in. You could actually add a base field that says, hey, for this legacy system that we brought it in, I want to always remember no matter what the ID. And maybe you don't want that to be display configurable or form configurable. For safety, you just want to have it for whatever reason. So remove access to the published date. So you can maybe take that away so people actually can't configure on the form. You could take away the form widget altogether for in just published date would always be the default value, which is when it's actually published or created, I guess in this case. You could make the roles widget configurable if you have tons of roles on your site instead of the checkboxes, you could do an autocomplete because again, roles is just an entity reference. So any of the widgets you can use on any reference, you could use that. So the next module I want to talk about is the show user fields module. So this basically makes hidden base fields viewable and configurable. So if we look at the user type, we have fields roles, last login, last access. And these roles, these fields, you don't actually see them on the form where you can configure them. And we're gonna implement the hook entity base field info alter and we're gonna change the fields to be display configurable. So you can actually display them in the managed display and say, okay, this person has XYZ role so everybody can see it or this person last access the site on June 23rd. Is it object-oriented? So in the same way as the previous module, it's not object-oriented in the sense that we're using hooks. But it does benefit from Drupal 8 classes. So let's take a look at that. So again, in this module, we're still only gonna have a .module file because we're just implementing hooks and we're going to, that's not the help hook. So we are gonna implement hook entity base field info alter. And again, we're gonna check to see the entity type as user, then we're gonna have a list of fields and we're gonna say, for these fields, we want to loop around and do something with them. So we're gonna make sure that it's actually there, make sure some other module didn't remove it. And then we're going to set the, then we're going to set the display configurable to true. So this by default is false. So basically, when you go to the managed display page for users, you don't see the ability to say, show me when this user was last accessed the site so everybody could see it. One thing I do want to show about tonight, this is PHPStorm but I'm pretty sure other IDEs use this. Right now, if I take this field, I again can have all the information about all the methods. But by default, if I actually messed up this line before, now the ID has no idea like what field is. So it's basically saying, I don't know what this is. You can invoke methods but I'm not gonna help you here. So what's happening here is in the previous example, the module actually was, the field was a return value of a function of a method that the ID knew about. So it knew like, oh, you're returning it from this method. I can look at this method. I know it returns a field definition. So I'm gonna give you all the information about it. But in this case, I'm just grabbing it from an array. So it doesn't actually know what's stored in that array. So it's gonna say, well, you know, it's something but I have no idea what it is. You can give your IDE hints. So I'm saying, hey, the variable field is of this particular class here. So as soon as I do that, and I start typing, it's gonna say, hey, I know what, actually I see what it is. It's a base field definition. So it's gonna say, I know exactly the methods that are on a base field definition. So sometimes you actually have to go through, which I'm not gonna go through in this talk, but you maybe have to use it a bugger sometimes. You could var dump it to see what it actually is. I do step debugging. So you might not know right out of the back that that's a base field definition, but you could say get class, print it out the screen, and then update your code like that. The other thing that's really nice about me doing that is it's gonna tell me, hey, DF is not a function here. It's not a method on this object. And presumably if you've heard of the policy from, upgrade policy from Drupal 8 to Drupal 9, we're gonna remove deprecated functions. If something like set display, or set description here, was deprecated in Drupal 9, the IDE would tell me like, hey, you're using deprecated functions. So I could use the inspection to look at all of my custom code base and say, telling me all the deprecated functions I'm using. Drupal 9's coming someday, so it'll help you out. But we're adding features to Drupal 8, so it's not that important. Okay, all right. So we set display configurable. Let's go back to the PowerPoint. So again, it's not object going in in the way that you've heard about plugins for Drupal 8 in their classes, but it still benefits from the fact that we're using object oriented in Drupal 8 and benefits from a really good IDE. This is the code I just showed you. And then here, last on them, I can actually display last access, last log in. I can display also the roles here. And they show up on the managed display like any other field. So I mean, sort of the main, sort of get the takeaway from the last two modules is base fields are in a lot of ways just like other fields. It's just you have to implement them through code, either adding your own or taking stuff, taking away or changing existing ones. So the next module is the no access entity reference label. It's a very succinctly named module, I think. So this allows reference entity labels to view the labels without actually having entity view access. So basically where I got this idea is if you look at a node and you see the author but you don't actually have permissions to view profiles, you still see the name of the author, but there's no link to click, right? But that's not true if for other entity reference. So again, the author on a node is just an entity reference. So if I have another entity reference that is to content, by default, it's not going to show me what the labels are. Again, the label for a node is the same as the label for a user, it's the same concept, because I don't have access to see it. So I want a field formatter for entity references that show me the title but only show me the link if I actually have access to it. So it makes these, the viewable entities will actually be links. So again, it acts like the author label for other references. And this one actually implements no hooks. So, this is an example here. We have linked content which is an entity reference field. We have this art2a node which is a link and then we have another node that's called you cannot view me and we still can see the label but it is not a link. So is it object-oriented program? Yes, it's object-oriented, we have a class. We're gonna create a new plugin and it's called the no access entity reference label formatter and it extends the entity reference label formatter and we're just gonna override two methods. So let's take a look. So I don't know if I can, I can't zoom in here but so we have the folder name, no access reference label. There's no .module file in here so Drupal 8 modules don't need .module files if you're not implementing hooks. We have a source directory and then under that source directory or SRC directory we have plugin, field, and field formatter. So all your plugins generally are under the plugin folder and then the particular type. We have the directory here. So if we look at this class, okay. Right here we have an annotation. So basically when you have a plugin in Drupal 8 we use these annotations in the comments. Ooh, that's not indented correctly. We have these annotations in the comments that actually mean something. And this is, if you're familiar with Drupal 7 this often replaces an info hook. So I think there was like hook, field, info or something like that in Drupal or this would be hook, formatter, info something like that in Drupal 7 where you basically again would return a big array. This may be not so much better in that yeah, we're just creating an array except in an annotation. But it's better performance the way it scans this. So I'm saying hey, this annotation is for field formatter. I'm telling you my ID, telling you a label, description and I'm saying hey, it can be used on entity reference fields. And again, I am extending the entity reference label formatter. So if I really wanted to know what that did I could go here and I'd say okay, I can see all the code in here. So basically making this mileage I looked at what the original formatter did and I said okay, I only wanna change like one or two things so I'm only gonna override one or two methods. So the methods that we're gonna override are make sure I get this right. Get any views. Are view elements. So basically like what happens when you're viewing those labels and by default again, the regular any reference is gonna say hey, if you don't have access to view the actual entity I'm not gonna show you the label at all. We don't want that to happen. And the other thing that I'm gonna override is the get entities to view because basically that is what's gonna determine which entities we view. So I'm not gonna go exactly to what it does but those are the two ones that I have to implement in order to override. So basically a lot of times when you're either creating a new field type or a field formatter or a widget, a good way to start is if you see something in core or contribute and you need something like that but a little more custom is to take that class for that formatter, that field type or that widget and say I'm gonna extend this and I'm going to only override maybe the view or the access or something like that. Okay. So usually yeah, when you're trying to implement a plugin potentially you could overwrite a particular plugin so find one that's similar. So if you have a field formatter like in my case the regular entity reference formatter or label formatter did everything I wanted except for the small thing. And then I would try to extend it. If I couldn't extend it if I looked at the entity reference label formatter and said you know this I would just end up wiping out everything in there. I want it to be different. I would look up to its parent and if it's parent which is like a sort of generic entity reference formatter I could then start from there. So if I look let's just sort of crawl down see how that would look. So if I started off with the entity reference formatter you know I would look here and I'd say oh you know this use basically displays a label for an entity reference. If that's not what I wanted I would actually click up here to the formatter base. So now I'm at the entity reference formatter base. This is an abstract class meaning I can never actually use this. This is not gonna provide a formatter but it's gonna be the parent for all my other entity reference formatters. So if I look here and now I highlight this and I go to navigate type hierarchy it's gonna tell me all the other formatters that go from there. So the way core does this is we have this formatter base which is for all fields. Little more specific is the entity reference formatter base and then underneath there is all of the ones that core provides. We have the entity reference entity formatter meaning I want to display the whole entity the whole node or the whole user or the label formatter. I just want to display the label. And then we have one here entity reference taxonomy term RSS formatter. You can guess what that does. I've actually never used it. Then we have the ones that I implemented myself here which is the entity reference. Oh so if we look at the entity reference label formatter we could go down further and see oh okay here's the one that I actually made myself. So that's sort of a good way if you're looking at a particular plugin and you want to see what it does or what other ones similar like it would do I would go up the chain then look back down see what's there. If I want to go even more general just keep going up the chain then look at its children and then dive back down. So yeah this is just sort of saying actually this is sort of saying how the ID would actually help me find a plugin. So if I knew like hey there's any reference on the site and I know I can see them and I know there's the concept of formatters I could just do this in this case it's a shift command but basically I would say I want an entity and then I know it's a reference and then I know it's a formatter and now it's sort of narrated down to all the formatters for entity references. So that's sort of one of the things I really like about Drupal eight versus Drupal seven is this encapsulating it into separate files makes it really easy for me to find the things. So it doesn't in Drupal seven say if I wanted to find all of the formatters that work for entity reference fields I would actually have to look at all the hooks for fields and then look at what they returned did they return something that work with entity reference. So the fact that they're all in their separate classes and I can easily search their classes by name for me really helps it be a lot simpler. So in some ways the complexity of having more files because they all have separate responsibilities actually makes it easier for me to learn ID for the win that's sort of the whole one of the whole things about this presentation. Other ideas for extending field plugins actually that's usually the question when it's a smaller group but we can talk about that in the question answer. So now the other concept I'd like to talk about is condition plugins. So condition plugins are unified system that really just simply evaluate to true or false. In core they're used to determine block visibility. So when you go to add a block and it says hey show this block at a particular path or show this block for a particular content type that is a condition plugin. That's how they're used in core but in contrib and Drupal 8 stuff like panels I think context is now ported to Drupal 8 I have a module block visibility groups, rules they all use the same condition plugins. So in Drupal 7 basically we had a bunch of sort of conditional systems in core and contrib but none of them used actually the same thing. So if you had a condition on rules that you thought oh this would be a really cool thing to use on panels, you couldn't do it unless you install this module that had sort of rule access control for panels which then gave you a lot of complications. So the fact that we're using sort of the same condition system all across core and contrib has a lot of advantages. So the example module and look at is author conditions. So the condition is a node author has certain roles and we're gonna say so usually the roles condition in Drupal core is actually like who's looking at this? Like I will show this block to people who are administrators but we're gonna create a condition plugin that says show this block if the main node on the page the author is an administrator. So maybe or maybe probably more reasonable example is if this is a premium member show this extra information in a block. So this is gonna extend the core user role condition and again no hooks. Oh wait, so now we're gonna go to the IDE. What did I say it was called? Author condition, author role condition. Okay, okay. So again we have a module that has no dot module file it has a SRC directory again with a plugin directory but this time we have a condition folder so we're saying this module implements or this plugin is of the condition type. And again if we look here we have the author role condition and it's going to extend the user role condition so I've actually want to see tabs for the win. Okay so if I want to see what the actual role condition does I could look through here. And again plugins have these annotations so I have to say hey I'm annotating something that is a condition. I have to do a few things for Drupal to pick it up I have to put it in the right folder structure I have to use the right namespace and then I have to tell it hey this is a condition so I'm going to give you information again in the comment. And if I don't get this right Drupal will I think when I clear cache it will show me an error hopefully the errors got better it used to be not so helpful when it was parsing a condition and it got it wrong. The other thing here I'm telling is I'm saying hey this condition has a context so this is not context like the context module again this is a nice sort of unification thing in Drupal 8 is this context is the same thing that panels in Drupal 8 is going to the same concept that it's going to use to determine when to display certain panels but I'm going to say hey I need an entity that is a node and it is a required context so basically if I'm not displaying a node on the main page then this condition should not be evaluated. Again I have to just implement this function called evaluate and so let's actually see if I didn't know what I needed to do if I just had the user role here and I know that user role condition does a whole bunch of things and I want to change certain things so what I would do is so I would say I want to override the methods and it's going to tell me okay here's all the methods that you can override I probably don't want to go down like way down here to object but I do see the user role and I know that how I'm going to evaluate whether a block should show up should be different from the core user role because that's basically saying if the user who's looking this role I want to say the user who is the author of the node is going to say yeah I want to evaluate author so I've actually already done it up here so I'll delete that one I would get configuration here so basically we're going to have a configuration form for these condition plugins the other thing that you will notice here is that I actually don't have anything in this class that does the configuration form the reason I can get away with that is because even though my functionality is different from user roles as far as how it's evaluated my form is exactly the same because I just want to show a bunch of roles that you can click checkboxes so one of the benefits of me extending that class is all the functionality from the base class that I don't want to override then I don't have to put in my class so if core found a bug with how the checkboxes are made for roles I would automatically get that so I have my configuration so if I say if I don't have any roles checked then just return true basically meaning if you didn't check anything in this condition then just don't worry about it otherwise I'm going to get the context of node and again because we're using classes if I didn't know like how do I how do I get that node that I told it I need I can just start typing I know it's a context so I'll just start typing context and then it's going to tell me a bunch of things so cache context no that's not what I want get context is probably what I want so I could confirm that it's what I want by looking at the help but I happen to know it's what I want the other thing here is I'm saying get context of node so at this point Drupal actually doesn't know that it's a node or my ID doesn't know that it's a node so again I'm using this comment here to say hey by the way this is a node so that allows me to do let me get this right wrong node okay yeah so this allows me now to grab a bunch of things I think author might be one get revision author get yeah that would actually give me it so I could say hey get me the author and because that's going to return it knows it returns a user so I could actually do I would actually have to get UID say on here so again your ID is going to know what type of object certain methods return and then you can get more stuff from there but I'm basically going to say hey get me the author entity if the roles for the author entity intersect somehow with the roles that are checked then return true I had to change the cache context but if you look at the github you can see the explanation for that I won't get into that right now and I think that is the last module I had to show I talked about that no hooks so questions yeah I think you spoke good Mike so that the recording can hear it yeah I think you maybe have to go out there in the hi in the first example where you create a new base fields for the node that base update for the creation of the yes on clear I think it would we have to write as in Drupal 7 no because it's saying that the hook user fields will actually add that field because you're telling it hey this is a new base field in the entity type and a lot of Drupal 8 is abstracting the database away from you so you're not actually saying actually it's even sort of extracting the idea of the schema away from you you're saying this is a field and Drupal should handle however it handles fields you could potentially have a different type of database and it would create that too any other questions yep that was quite valuable session and quite beneficial I'm a beginner for Drupal 8 and I'm still learning but what happens is most of the times I see a module who's doing something very similar to my requirements but it doesn't exactly do what I want yeah so at that time how can I like find what point at which function or class I should extend or like modify to get the things done my way so yeah so like one way that I use when I have no idea where something is coming from I often look for a string in the user interface so if we look at let me see if I can find an example but if we look at the structure content types these are articles managed fields actually let me do it on the node add page so if I was adding an article and I thought let's say this was I don't have any contrab on the site but let's say I wanted to say where is this authoring information coming from like how is it making that I mean usually what I would do is I would copy that I would look in my IDE I would search all of Drupal core but if you just installed a module you would work look in that module folder I don't want it to be case sensitive authoring information so actually at this point there's only four instances of that string in Drupal core so it's actually on the node form page and potentially I would look for when it wasn't a node but you'd see similar cases if it was like a field formatter and there was a special label on that field formatter and I wanted to know where that class comes from I mean obviously like learning the general principles about plugins and stuff like that but if you're completely lost oftentimes taking something out of the UI and searching say the module you knew it came from that string look at the class there and then sort of go up from there any other questions so the evaluation I forgot to put a slide but if you go to the session there's an evaluation link for the survey and definitely let them know how I did any other questions all crystal clear is there a threshold for using base fields compared to performance impacts? I wouldn't use them all the time and I mean most of the time if you're not worried, like you're not crazy worried about performance I wouldn't use them I more often find that I'm altering them than adding them all together because oftentimes there's a base field that's not viewable or it's configurable in the form that you want it to be configurable so I would say a base field is really only if you're really worried about performance or if you want to change the fundamental functionality of a certain entity type that's often provided by contrib and it doesn't make sense to ask for that feature in contrib because what you are doing is very different from how most people would use that module then I would consider adding a base field I did some base fields earlier and notice when I changed them and had already existing entities entity update didn't work anymore because it's given notice that there are entities with values are there good examples of update hooks or I was sort of talking about stuff at the beginning I'm trying to think I know there's a field or two that's been added to core I don't think what they are right now but I would look at the core change law maybe the node module I think the node module may have something I know there's something in d8 that was added afterwards and they had to do an update thank you very much do you have any recommendations for creating the whole skeleton you need to find the right namespace you have to write the correct annotations etc you can have a lot of titles do I use templates what do you use for debugging I use xdebug but for a skeleton if you don't know how to make a plugin Drupal console is really good for that you can go through and say I forget the exact commands I want to make a new plugin what type of plugin do you want what's the label the other thing is sort of copying files and then just renaming the namespace sort of looking at a plugin that maybe doesn't do what you want but is in the same type just sort of copy it over and change namespace and stuff like that what's the question about more the question what happens what do I do if it doesn't work maybe I have a type or something yeah I think I think whatever effort it takes you to get step debugging to work how many tutorials it takes you to get to run through it will be worth it if you're planning on being in Drupal for any length of time or any object during the programming it's like you have to learn for me I personally had to learn step debugging I learned it in Drupal 7 but it was much more user friendly in Drupal 8 and sort of setting breakpoints to actually get here that's what I've done you can var dump stuff out there I think the plugin managers there's a concept of plugin managers in Drupal 8 and those are actually really interesting to look at so if you can actually if you have a field type if you have say a plugin that's a field type and yours is never showing up you can actually put a breakpoint in the plugin manager for fields and say hey stop here and then I'm just going to get through and see why my plugin is not loading you actually learn a lot about Drupal 8 that way I mean it'll take a while but you learn a lot about Drupal 8 and you figure out sort of why it's not loading often it's not loading because of annotation purposes and that again I think is you know an IDE that's aware of the concept of PHP annotations is really helpful because it'll give you even though it's not code per se it does give you warnings say hey you didn't close this properly or whatever so it's really really easy and mistake to make is because it's not code you don't get as you're not necessarily going to get a hard failure in your annotations you're not going to get a white screen of death if it's not there it just won't be picked up okay thank you any other questions alright great thanks so don't forget about the survey it's really helpful to me it's also really helpful for DrupalCon in general as far as selecting sessions and you know good or bad surveys are good good is good but bad is helpful also