 Let's get started. Welcome to Philips API is that long live entity, Philips API. So this is the last session of the DrupalCon Amsterdam. We have a lot to tell, so please bear with us for the last hour. But after that, you can go to Amsterdam and have a good, nice beer. So my name is Christoph. I'm Swental on Drupal.org. Also on Twitter, I'm a co-maintainer for the field system. I'm also the original creator of this place suite. We've got two presenters as well here. On the left, there is Wolfgang Ziegler, the real Fago on Twitter, Fago on Drupal.org. He is the lead maintainer of Entity API, and he also maintains rules. And next sitting to him is Yves Chetma, white chat on Twitter, Drupal.org. And he is the maintainer of Field API since ages. So we might sound like a little broken record. In that sense, this is probably the fourth or the fifth time that we have given this session already. One of the annoying things was that after a week, maybe after we gave this session, everything was obsolete because we kept changing so much during the Drupal 8 cycle. So this is going to be better right now. We have a better release of Drupal, which is great. So that was the good news for this session. Don't hold down here from that. So basically, the APIs are frozen, which means that normally there should be no more changes, hopefully. We know there are still some areas where little things might change. But basically, if you want to start working with the Entity Field API, you will be pretty OK now. And the slides will not be obsolete next week or in a month or whatever. But the original plan, actually, for Drupal 8 cycle, especially for Yves, was to basically go on vacation. I mean, Field API was in Drupal 7, right? It worked and had its quirks now and then. But Yves wanted to go away for a long time. But that didn't really happen. Our colleague core developers basically just rewrote all the things in Drupal Core. And we were like, oh, this is interesting. Maybe we can use that as well. So we did that. But that's for the third time. I mean, if you know a little bit of Drupal history, Yves has been working on CCK. Then Dries asked him to put CCK in Drupal 7. So then Field API started. And now during the Drupal 8 cycle, we rewrote it again. So really fun times. So let's start with some sidebuilding features. Really nice stuff that has been added to Drupal Core. We've added a lot of new field types to Drupal Core. It allows more power for sidebuilders. They're not always the full ports of the Drupal 7 modules that existed. And sometimes they don't even modules anymore. Modules like number, email, I think. I don't know whether we've moved another to core or not. It's still in progress. OK, it's still in progress. But some modules don't really exist anymore. But they're there as field types or widgets or formatters, which is really, really great. So we added entity reference to core, which is really, really nice. A lot of work went in there by Andre Amatoescu and Amitabu. Really, really great stuff. We also added date and daytime to core. So you can actually now create event website and things like that. Some stuff from the date repeat features are still going to remain in contrip. I'm actually not sure if anyone is working on that. But if anyone is interested in helping out, we still need that for Drupal 8, of course. We also have a link field, which is relatively basic. We also have an email field, which has input validation. There's no spam support out of the box. We don't do that in Drupal Core. We also have a telephone field that does not turn your Drupal website in a telephone. It's just a formatter, basically, more or less. I'm still wondering why we committed that. But we still have a telephone module in core, which I personally find like, yeah, telephone module. Yeah, that doesn't make any sense. Just enable it. It's enabled in the standard profile. The nice thing about it is that it all integrates really nicely with in-place editing. So if you look at your node, everything on that page is editable, even the title. It took a long time to get the title editable. But that really works nowadays. So a lot of great work there from Wim Lears. He suffered sometimes when we did changes, but he made it. We also have fieldable blocks, which more or less is beans in core. You can add fields to blocks and do whatever you want. Really, really nice. We also added something that is called formodes. So in Drupal 7, if you go to manage display, you have those local tasks, like that says default, teaser, full mode, stuff like that. We've added that kind of concept as well to forms, which means, for instance, if you wanted to have different fields on the registration for users, if you wanted to hide stuff or whatever, then you needed to do some form alters. We also had this little checkbox in field API that says show this field on the registration page and things like that. It was a horrible hack. We removed that completely. You can also now hide fields on forms, which is really nice. So what's the impact on in field UI? There is a new tab, which is called manage form display. You can reorder fields. You can hide fields. And that's also the place where you're going to select the widgets. And you can change the widgets, which is really nice. So you can see here, this is an example of the user. Manage form display. You have default and the register form mode. So you can really adjust it to your likings. Overview UI is now just listing all the fields that you have in your installation. And common is also now a field. So the field itself stores the settings. It does not store the comments itself. We still have a comments entity type. The nice thing is that you now finally can have comments on any entity type that exists in Drupal Core. And you can have comments on comments and comments on comments and things like that. So really, really nice work. It was a hard one to get that in as well. Really nice work by Laurel and Andy Post. Really, really great. So we'll get to APIs now. One nice thing is that there is a cheat sheet. We didn't make it. It was made by Eric Stilster, Stutterson. The link is over here. It helps you figuring out what's new in entity field API. You can also work with the entity query. So I advise you to download it and just put it next to you if you're working with the entity field API. So we're now going to entities. And Wolfgang is going to talk about that a little bit. Hi. So as entities are the foundation for all the fields, let's have a short look at all the changes we made to the entity API in Drupal 8. And good news, I think, is we actually have a solid entity API in Drupal 8 now. So entities really have grown up. So we have a full grad supported entity API in Drupal Core. So it's totally built up in class objects. So no standard class objects or anything like that anymore. And we have interfaces and methods on them. So that's really a solid foundation that we achieved in Drupal 8 pretty fast, actually. And we have done a lot more. But let's get started with the basic. So the entity query in Drupal 8, it has all the functionality that we could expect. So you can load, save, delete, create. So let's get started with create. You have an helper on each entity type class. So on the node entity class, you have a static grade method which you can use to create a new node. You just parse an array of values. And you get a new entity object. The entity object that you get is actually not yet saved. So you still have to call save to permanently save the newly graded entity. And also really important for all of those entities which have bundles like nodes, which have node types, you have to parse the value for the node type when you create the entity. So next thing you might wanna do is load an entity. So they have also an aesthetic helper on each node entity class just to load things. It's really just a shortcut you can use. And once you have loaded an entity, you can delete them. Interfaces, as said, we have entities built up in interfaces. We have an entity interface in core which holds all the common methods. So it makes sure all the loading, saving, deleting and everything and some more of that is available on every entity. And in addition to that, we have entity type specific, more specialized interfaces like node interface. So every entity type in Drupal Core also has its own interface which just extends the regular entity interface to add more specialized methods. So what are some of those methods which are now on every entity which are on entity interface or some related interfaces? So you can just use them like the very common things to get the label of an entity, to get the ID or bundle, the URL of an entity or you have the two array method that you can use to just get an array of all the values which are in the entity. We also have like integration with validation API in the entity system. So it's actually it's built up in the symphony validator component. So if you call entity validate, it will fire up symphony validator and do some validation which is totally decoupled from form validation. And you'll get back an array of violations or hopefully no violations. That was huge for REST APIs because you can post entities via REST call and it will be validated even if it has not been submitted to a form which was like a requirement to be able to do REST things. Yeah, and then there also like a shortcut stack to check access control on entity. So we have an access method which you can call to check entity access in a generic manner. Yeah, but I said we also have specialized entity type specific interfaces in Drupal Core like the node interface. And we tried for Drupal 8 to add methods to all of those entity types that we have in Drupal 8 which are specific to the entity type and just provide you with all the functionality that's related to the entity type and that you probably wanna gonna use. So if you're working with nodes you likely want to check whether a node is published or change with a node is published. So for all of that stuff we have methods now. So in that code example you can see you can check whether the node is published with a method and you can set the published value right just as the node title. And obviously a node is an entity so it gets all the entity related methods like saving as well. So for providing an entity type in Drupal 8 Core you have to define a class and put an annotation on it. So it's actually working very similar to all the plugins we have in Core. So this example is a snippet of the node class. It actually has to be located in the right folder as well. So it's, starting from your module folder it has to be located at the source entity subfolder. And you might wanna, you should also add an interface for it and just extend entity interface and also then implement your own interface in your own class. We also have like handy base classes which you can just extend from like a content entity basis at the base class you would like to use. And then you have to put the annotation on top of the class so that the system is actually really discovering also the entity and it's working as expected. The annotation is actually what was in Drupal 7 entity info. So it replaces all that information. So you specify the machine name, the ID of the entity type, it's label and then also a bunch of handlers. So handlers basically are like additional objects which allow you to control certain aspects of your entity type. So there are multiple types of handlers already defined in Drupal Core. And those types also come like with its own interfaces but more important they also come like with useful and out of the box working default implementations. So for example, for storage, there's a storage handler class in Core which you can just specify and it's working. But the handler system then in addition allows modules like the node modules which wanna customize some aspects of the entity type to extend those provided classes and put your own classes in place instead. So as notice has just quite some custom functionality on top of the entity system, it overrides a bunch of handlers which Drupal Core provides to add in all the node type specific functionality. So the important types of handlers, I would say in interpolate core storage for all that graph functionality, the view builder which is used to render entity access or checking access, views data for views integration or also forms which basically generate forms for your entity type. So the default form is basically the edit form of your entity but they're also like classes which you can just specify for additional operations like for deletion, for deleting an entity we have on as well. Then to leverage those handlers, basically you always have to go by the entity manager. So the entity manager really is the central service from the entity API in Drupalate Core. You can get it by calling the entity manager method on the static tuple class but in regular object oriented code when you're writing a plugin or something that's the class you would like to inject in your class. So then from the entity manager you can fetch all those handy handler objects and there are some methods which allow you to get them easier from the manager like we have get storage to get the storage or get form object to get a form object and so on. Yeah, then in addition to that we have a generic get handler method which basically can work with any kind of handler and that is because the types of handlers that the entity API works with is not restricted. So core comes with a bunch of types of handlers which are useful in core but every content module can come in and provide an additional handler to the entity system which then the entity types can make use of for example, for integrating you with the module. As it's done for the fuse module in Drupal Core we have now the fuse data handler which basically provides solid out-of-the-box functionality to integrate the entity type with the fuse module but then you might wanna override that functionality for your entity type so you can just extend the handler and override it and by module leveraging that approach it allows every entity type to customize all its behavior in just the same way. Yeah, then to fetch information about an entity type you also get it from the manager there's a get definition method on it you just pass it on the entity type with the and you get back an object it's Drupal 8 so instead of having an array that's entity information we have an entity type object which is based on the entity type interface method and it just has some useful methods on it like a method to get it to D to check when entity type is revisionable also to get the certain entity keys like a D revision, a D bundle or something. A really nice feature about the Drupal 8 entity APIs or the built-in translation support. So every entity type can be translatable and you have basically a simple API to fetch translations for existing entities so when you have an entity object you can call getTranslation, pass it on language code and you get a new translation object and that translation object is just a different entity object it's based up in the same class and it implements the same interfaces but it holds different set of values it just holds the set of values for the different language so that's very neat as you can continue to use the same API so you can continue to use like entity type specific methods like node getTitle and of course you can also ask the object in which language are you in by calling the language method and if you wanna make sure you have the original untranslated entity object you can always call the getUntranslated method on an entity object and you will get the entity in the original language as the user has inserted the entity. Yeah, so really great improvements but we figured for Drupal 8 everything should be an entity because everything that's durable and loadable really it belongs to be implemented in our Cloud API the entity API in Drupal 8 is our Cloud API so we're doing exactly that so everything that's in Drupal 8 and mostly everything that you can store and load in Drupal 8 is an entity and for that to work out properly we basically like divided the API in two flavors so we have content, so we have content entities in Drupal 8 and in addition to that we have like configuration entities which behave a little bit different but they're still built up in the common foundation the entity Cloud API and all the common foundational API. So for that to work out we have two specialized interfaces we have a content entity interface and we have a config entity interface which just take care of all the specialized functionality which builds on top of the common foundation. So for example when we look at configuration entities those are different as they are stored to the configuration management system so you can properly deploy stuff and the actual objects will be just simple entity objects with plain entity properties and we have those examples of that in Drupal Core but some examples you probably know of would be like node types of views, image size those are all examples of config entities. Configuration, sorry content entities what you probably typically would think of an entity in Drupal 7, so they are field able they are also revision able and they are translatable so content entities combine all those capabilities of the entity API and typically are stored in some sort of database so examples would be like nodes, users, commands and all of that. Yeah content entities as at a field so let's have a closer look at the field system. So yeah during the D8 cycle the one of the taglines of the work we were doing is that the objective is everything is a field. Okay so Fago just said everything is an entity so maybe I need to be more specific. Everything in a content entity is a field meaning what you usually have on your nodes say node title it's a field item list interface we'll come to the exact meaning of these interfaces later if you look at node body it's the same interface if you look at a custom field added through the UI it's a field item list interface it's the same objects for the runtime entity that you manipulate whether it's a base field of your entity type like the node title well the node class is based upon the assumption that nodes they do have titles the node body it's being added to call it's a configurable field but like we automatically create it for you when you create a new node type because it's handy but you can still remove it. All of those things are for the runtime system the same thing. So of course there are different kinds of fields we have the base fields which is what in D7 we called like entity properties so yeah node title node need node author well UID the base field is something that is defined in code it's defined in code because the entity type module assumes it's going to be there it's like for the business logic of what is your entity type what does it do what it needs in order to require it so that there is some code somewhere that assumes that nodes have a need that nodes have titles and that the title is a string and that the need is a number so it's defined in code because code does assumption on that and we have configurable fields which was what in D7 we called fields created through the field UI so the node body we created automatically but it's a configurable field you can remove it if you don't want a body in that specific node type the tags, taxonomy fields typically are configurable fields or any other custom field you might want to add to a bundle in your entity type it's defined in configuration it's defined by an admin in a UI and it offers as opposed to base fields which provide the like really the business logic of your entity type it allows cited means to do flexible data modeling without rating code so all of those different kinds of fields since they are all using the same interfaces we've been able to generalize a series of features that work across all of those type of fields translation the whole of a content entity is natively translatable while like in D7 you could translate a custom field but no title was difficult to translate okay great field access logic adding constraint logic on your field and validation logic supporting rest operations like get and post using widgets and formators and that is nice you can use widgets and formators for anything within your entity type including your base fields we'll come back to that later support for in place editing you define your entity type you define your base fields you get free support for in place editing without coding anything at all and that is a nice feature to get for free entity field query all of those fields whether it's base fields or configurable fields they work the same way when you try to write an entity query on those field cache which they all in D7 you have a field cache meaning all the values of your configurable fields are cache and we don't query all those tables each time you try to load a node since all of them are fields now well we had our entity cache and that is something that we've been working on for like years it's in place now and probably some other generic features that I forgot on that slide so how do you work with those field values in an entity that you load or that you create just as a quick reminder this is the Drupal 7 syntax lovely we've all learned to appreciate that working with those kind of but well okay fields were translatable there are potentially multi-valued and within a field value you can have several components in D7 we call it like field columns so yeah the full-fledged syntax it's that so the entity module in Contrib tried to like introduce some smarter logic to make it easier to access the value in your fields this was like enhanced and put in core as the original the main way to interact with your field values in the entity so just for a recap so you have an entity say a node it implements entity interface node body it's an object that implements field item list interface it's a list of field values because fields can have multiple values of that you can get the first value delta 0 it's a field item interface meaning an item in a field item list we do allow an array syntax to access an item in that list because the field item list interface they implement array access so you can still use a square bracket syntax and inside of that oh that's wrong it's not a field item interface it's like when you access the value property it's like 42 or hello world or whatever the slide is wrong here as a shortcut when you want to access a property in the first value in the first delta of your field you can just say node body value so it's slightly easier than the D7 syntax of course this is still iterable meaning you can still mostly work with a field item list interface as if it was an array you can for which on that so that's little drawback is that while for base fields you could in D7 just say node title well the full syntax for that is now node title value as a mitigation if it is a base field you're supposed to provide an interface for your entity type meaning you are supposed to provide a get title method another thing about working with field values is that yeah there are objects meaning we can add some smart behavior on top of that instead of previously in D7 those were just arrays so you can do much with an array except reading values that are in there so if for some reason at some point of your code what you are handed is a field item for instance because you receive it as a parameter in a function you can still get to the parent entity you can ask the item for a what language are you in you can even from the item get its field definition meaning that it allows you to build simple code and simpler APIs for instance this is the signature of the hook field widget form in D7 meaning the function you need to implement as a widget to provide the form structure for a editing a field value the signature you had to receive an array of items the field definition the instant definition the language for the items because you might want to do specific language behavior the element that will and then and then the arguments that are specific to the job you are currently building so building an element the whole form and the form state because you're building a form in D8 this all scales down to just receiving an item because all of the other information the field, the instance, the line quote you can get by asking the item so it makes like APIs look a little simpler another nice thing with that the fact that field items are objects is that we can add some magic behavior and have some computed properties so if you look at the node tags field it's taxonomy reference field it can it typically has several values if you look at the target ID property well this is what is stored in the database it's the ID of the reference entity but if you ask for the entity property this automatically loads the entity for you and you get what you get is a taxonomy term so you can do stuff like term equals node tag entity and you get your turn this does the entity load for you and you of course you can chain method calls from there from the node field reference entity you can get access to the value of a field on that reference item just by chaining code another thing is that the classes of those values objects the item list and the item classes are actually per field type meaning each field time cap can provide its own classes that both that all extend from the base classes meaning they can provide meaningful business methods that pertain to the fact of for instance being an entity reference field so node tags node tags the actual class is not field item list its entity reference item list which has a get referenced entities method meaning you can load all the entities at once using entity multiple load which is of course more efficient just by calling that method okay so now how you define those fields how you make those fields come into existence interval seven the the the definition structures try to go quick on that one suppose you you're more or less familiar with that they we have a split uh... uh... definition structure it's you have the field and you have the field instance and both of those were raised like the rapy pattern we've been trying to move away from uh... like undocumented properties and you need to remember the exact property names or your code is broken and so the dollar field was basically uh... what defines the fields wherever it appears and the instance was okay how these field appears in the node type in the node page content type as opposed to how these field appears in the node article content type for flexibility most of the actual settings are placed on the instance level because it means you can set you can make your field act differently on page and on article which de facto means that what the field was about was about defining some storage locations somewhere and the fact that you reuse the same field for several field instances uh... the main use case was just to be able to query this field across several bundles be able to write a view that selects all the nodes whatever the node type that are tagged with the term drupal gun for that to work the field needs to be able needs to be stored in one single location in storage or else you can't query across bundles so the the field it was actually the definition of of uh... uh... a data bucket somewhere in storage that you can query and what we called instance was actually what was an actual field on an actual entity so what we did in drupal eight was to put the terminologies straight uh... and so what we called field in uh... drupal seven is now called a field storage and what we called instance is now actually called a field we were kind of hesitant to make that change because like it's the worst kind of rename you can fine what was named something in the previous version is now now designate something different in at some point we were kind of forced to make that change because dpi just didn't make sense so we went for okay let's have something that makes sense for people that come to drupal eight instead of carrying the legacy bad names the other thing we did is uh... move from array uh... definitions to objects with actual interfaces so that you can we can document what you can actually specify in a storage definition or in a field definition but it's basically the same kind of things you could find in drupal seven in field and instance meaning the storage you said the field name you said the field type you said the cardinality a couple settings that might be specific to the field type and on the field side meaning the field as it appears in a specific bundle you can assign uh... a specific label you can decide whether the field is required or not set a default value set a couple settings and you can also access the field storage definition that is associated with that so you can once you have the field you can easily get the field storage finding the the field definitions this is like the equivalent api for what what uh... what in the seven was like field info field field info instances and stuff like that in dh you go through the entity manager and you just ask the entity manager give me the field definitions for that entity type and bundle or give me the storage definitions for that entity type since the storage definitions are across bundles but you can also when what you have in your uh... code scope is an entity if you're working on a specific entity you can ask the entity for its own fields what are your fields give me your field definitions or give me the definition of your body field uh... or you can ask the do you have that field is that feel present on on on on that entity if you if what you are working with at this point in your code is a an item a value an item or an item list you can also add the item of the item list for its field definition just makes code easier to write because you can more easily navigates between the thing you're working working with and getting the definitions so the takeaway is that whenever you had you have to write some code does something with the field in an entity basically you need to work with for interfaces for the definition you have the field and you have the field storage for the values you have the field and the field item list that's it and uh... if you so if you write some feature that supports those interface you defect to support basefields and configure fields alike okay so specifically how do you define configurable fields uh... what were the fields uh... in the seven this api has has changed a little bit so just a quick recap on on the cmi initiative in d eight uh... config entities uh... art so configuration is it's stored in yaml files it's deployable uh... between uh... different environments like between staging and production uh... modules can easily ship those uh... yaml files in a specific uh... folder and the corresponding uh... configuration will be automatically installed uh... when the module installed profiles uh... can do the same yes there are entities there are config entities how do you do your field create field field create instance that was the seven api well the date shape is so you define a storage field storage config create you need to specify a couple properties like you specify energy type of field name and the type of your field this map to the end so we have fields in d eight our entities they can't have fields which is good for the sanity of a of us all because they're config entities but yes fields are entities deal with it the entity type is in storage config and you can find their yaml files in field storage blah blah yaml and so yeah you use them as any other entity you assign values for them you save them same thing for the the entity type field config you can find in them in field field yaml and of course field storage config config implements field storage definition interface and field config is the config entity that implements field definition interface you can also easily load them like the config load by name you just give the no type the bundle and the field name and it will find that field for you in the configuration but you should in the eight rarely have a use case for those like rare there are there should be rare use case where what you want to do is specifically and explicitly work on configurable fields most code will work on fields they will work on the interfaces not the specific field storage config or field config implementations it shouldn't matter whether a field is a base field or a configurable field just to give a a a visual a visual visualization of what you can find in one of those yaml files well here is a field storage definition so again it's what we called dollar field in in in in the seven this is basically the same thing it's a field name entity type it has a field type some settings uh... whether it's locked with what is cardinality whether it's translatable basic stuff and on the field site uh... you attach it to a specific model you say in that bundle what is label is uh... whether it's required blah blah default value okay base fields now base fields are other real new thing in in in the eight uh... how does an entity type say yeah my the the entities of my entity type will have those fields no matter what uh... so in your entity type class the class that fagot showed that you implement to provide your entity type you can you define a is there is a static method base field definitions where you return an array the definitions of the base fields you want in your entity type so basically you call base field definition create you'd give in the field type you want you said label you said whether it's required you said whether it has settings you can set the default value as well you can set validation constraints in there and your uh... field exists in your in your entity so base field definition it's actually a bit special it implements both interfaces meaning uh... well so it's definition interface and field definition interface meaning a base field definition can be seen as a field storage plus a field definition all on all the bundles of that entity type base fields are fields that are present no matter what on all the bundles of your entity type in addition we have a hook where other modules can add base fields to your entity type because uh... other modules don't have access to your entity type class you're the one defining it uh... but there is a hook in which they can add more base fields to your entity type and that this is what makes entity types extendable so there is a way that you can define in code feel a base of well code define fields that only appear in that specific bond that specific bundle and not the others we won't get into there in that presentation with it's doable as well so great thing you can use widgets and for matters on on on your base fields how do you do that well in that same method in that same definition you can set display options for for the field so that when this field is viewed it's going to use the string for matter and it's going to use those settings and on the form side you can say that it will use the string widget and assign what's the default weight is and again give some uh... form for a widget settings if needed you can also uh... specify that those display options that you mentioned are only defaults and that they can be changed in the ui meaning your base fields can be configured in field ui manage display and manage forms uh... so this gives uh... this this lets you remove all the custom code you had to write to support the forms and and the viewing of your base fields which is what entity types had to do in the seven you had piles of custom code to define the note form while now in the eight most of it it's just reusing existing widgets and it it gives you the power to reuse the uh... rich widgets that might exist in core or in contrib and just use them for your base field types so we don't have that split where uh... base fields i had had a frozen form existence that was completely not configurable while configurable fields had that rich collection of widgets and for matters where you could do crazy crazy crazy things now it's all one and the same a couple words about storage so uh... okay we say we have base fields we have configurable fields how is that stored in in in in in the database so in the seven the field api had a a sub api to allow storage to be swappable kind of it was filled but filled by field like you could have an entity type whose body field was stored in in an SQL table but whose other field was stored in mongo or didn't really really worked i mean we had we do have a mongo driver i'm not sure it's been widely used yet it was kind of a mess because this api was only for configurable fields leaving the base fields which are the meat of your entity type on their own uh... in the seven as fago explains storing an entity is the job of the uh... entity storage and learn meaning the entities are stored as a whole whatever in is in that entity the entity type the entity storage will store it and will load it and which makes is of course easier to swap out a different logic for instance a mongo storage because the job of of that class is to receive the full entity and to store it just loaded uh... it should make a mongo storage viable at least uh... in the eight uh... and the core default of course we store in SQL uh... we have a an SQL content entity storage base class that your entity types can simply reuse and it gives you for free uh... support for revisions uh... translations fields that have that have multiple values fields that have well multiple properties meaning the storage of that field takes more than one column in a database uh... you get that for free for your base fields for your entity types which really really removes a lot of work uh... for custom entity types being revisionable by default just by turning a switch is kind of a big deal uh... schema-wise well it's kind of we haven't seen things haven't changed much since since the seven uh... it's you have base tables you can have several base tables uh... depending on whether your entity type is revisionable or not translatable or not you can have one two or three base tables they receive all the fields all all the base fields that are mono value because we can't stored we can't store in a shared table fields that can have several values SQL is not good at that so you have one base table that receives all the base fields like in the seven plus we have one table for base fields that can hold several values plus like in seven you have one table uh... per configurable field uh... one thing we stopped uh... creating revision tables for entity types that are not revisionable so we should reduce the total amount of tables created in there and the great news and very recent news is that uh... all of those tables are created for you automatically by the default SQL container storage meaning you don't have to care about defining the schema for your uh... uh... entity type tables it's taken care of for you and updated automatically for you that's uh... great uh... uh... job that was done by pleasure for gents awesome so there's more we're we're almost at the end of our presentation is a lot that we have told today i will probably go quickly through this slide so we have also converted a lot of stuff that is in triple seven uh... like four matters widgets and field types this is triple seven four matters hooks they were not really hooked there were kind of magic callbacks and they were kind of working to work with especially if you wanted to overwrite them or if you wanted to have different ways of viewing of value you had to switch dance and it could get really ugly really really fast uh... and those functions were lost uh... in your model file and we moved that on so we have now plugins uh... we have a plugin system in triple eight i will not dive into the plugin system because that is with another hour or two or three maybe i don't know so quickly some examples we have uh... field for matter plugins they have interfaces they're now object classes we provided some helper base uh... classes for you uh... if you're a country module developer and you have uh... four matters usually will probably usually just extend from the four matter base class uh... because it does a lot of stuff for you for free just use it so no more info hooks uh... you use annotations like every single plugin that exist in uh... triple eight uh... this is an example so we have the annotation field for matter annotation you have an idea you have a label and then you specify the field types where it works on so really easy and it extends on the four matter base uh... just use it it's really really handy uh... since we have classes we can have inheritance uh... which is way much easier and much nicer to look at uh... then in triple seven so this is uh... how it is for the number for matter in court there's a default number for matter which implement some methods uh... but then there's some little differences you just extend on it and you override that method and you're done so really really really easy to work with then in triple seven and then you also had field types uh... i also i should also just mention uh... this is the same for widgets and we have a widget base class uh... if you have if you want to provide widgets just extend from it it's really really easy uh... the same thing happened from field types uh... we just moved them to field type plugin type uh... this is an example of uh... field for matters field types and widgets on the right uh... the interfaces field item interface which is really nice you can probably explain it a little bit better than me yeah so the thing is that the class that you implement in order to code a new field type that class needs to implement field item interface meaning the class that you code is that truly the class of the values of that field type so what you code is a uh... an object that is a field value for your field type coding its own behavior that's uh... the logic it's slightly easier to to to view it that way so this is the field item interface one nice thing that we've added really recently is uh... the nice function generate sample value it more or less means that we have developed generate in triple core eight now so really nice uh... to use this is an example of the link item uh... field type as again you use annotations you describe uh... what their default widgets are going to be the default for matters and also the constraints and things like that going really fast because we're more or less at the end of our session i think uh... we have entity displays in triple eight now so entity displays uh... if you look at the definition of a field instance in triple seven uh... that instance hold all the information how a field was rendered in your entity so there was a lot of a raise there again it was kind of annoying as well uh... for instance for display suite and field groups we had no way to reuse something in triple core and we had to use our own storage and so a lot of stuff was loaded at runtime and memory more or less exploded so in triple eight we have the entity display we have an entity view display and we have an entity form display so that it's a config entity and it stores how your entity is going to be rendered for a certain bundle and view mode so it lists all the components in there like say a title or the body with the settings for that certain bundle and view mode uh... this is an example so if you look at the content uh... in the array you have a body field image and then also the lang code so it only stores what actually needs to be rendered that was kind of a problem in the seven because we had no clue who needed to be rendered so we loaded everything and then a lot of memory so this is a new addition it has a really nice api so you can just say uh... give me the display for node article teaser and you can add or remove components and add settings to them uh... one nice thing is that we're probably going to add a new uh... we're going to add an api addition here that will allow to inject any kind of in there we need a new name for that i think yeah the components the components are basically all the entries that you will find in the render array for an entity you will find an entry per field that is being rendered but we also have like third-party modules like display suite field groups typically they add and they reshuffle things in your entity render array and so the the the whole metaphor for the entity view display things was that it's supposed to be the full recipe for where how an entity is going to be displayed meaning it needs to be able to accept uh... components from uh... contrib like a field group component that has a parent or that knows it has children in there so we need to we still need to make that extendable but the thing is that yeah that object is contains everything there is to know about how to render that entity so how you work with it if if entity view is called then it will load the relevant display for you uh... you can implement alter hooks so you get the display recipe for you and then you can just call at components or a set components or remove components at runtime it's way easier to mess with the display in triple eight and it was in triple seven you had to implement a lot of hooks there and was not fun to work with so it's all available uh... so like i said we have the same for entity form displays they are the recipe for how your form looks like uh... and it allows us to have four modes that's it thank you so if you have any questions you can go up to the mic over there and then we'll try to answer hi uh... my name is jibran uh... i maintain a dynamic entity reference in duple eight contry uh... first of all i want to thank you all on working on revamping the entity appear it's been you know player working with uh... all the revamp things and stuff uh... it's been really easy for me to you know create a new entity new field type with all the changes one thing i struggle with is the schema of formaters types and widgets so how can i generate automatically or you know uh... how can i work with that is there any advice from you guys i'm not sure i understood the question sorry so schema api i have to implement the schema for widgets and uh... for field types and for matters you need to provide the schema for your field type but that's it widgets and formaters are not involved in there the settings i have to provide the schema as well no it's a schema uh... translation schema api config schema? sorry config schema yeah right so i am struggling to write config schema for my okay so to provide some context all of those uh... say yeah you implement a field type that field type defines a collection of settings that are specifically relevant for that field type and that would make no sense for another field type so those the value of those settings are stored for each field definition each configurable field definition that they are stored in a yaml file and the config system requires uh... it has a a schema api to be able to figure out the the parts which is what and what is what is of what type within a yaml file so yeah you have this part of the of the field config schema yaml file whose content depends on the field type so it's hard to provide is the field api cannot provide a generic schema for this piece in the uh... in in in the field schema record so the it's it's the the field type that needs to provide it and there's yeah there's an api for that it's not completely easy uh... it's it it's doable it probably needs some explanation but it's doable won't explain that here but thank you and it works it works exactly the same way for every config entity so as soon as you have something that stores configuration you have to attach to that schema just exactly the same for the configurable field types so hello uh... another question what's going on with bundles because i've noticed that uh... it's not required for some entities and some of this doesn't have bundles bundled property with null value that's why lots of crunch inside of court what are the decision to allow not bondable values entities uh... so it's been a polemical topic i mean within the the the the team we weren't uh... yeah entity types without bundles uh... large parts of the api's assumed that well uh... rely on the fact that you can speak about the entity type and bundle of an entity some some code especially storage needs to know the bundle of an entity so uh... in the seven like an entity type without bundles say user all the entities at the same bolder bundle which is the same name as the entity type and yeah it did that there are a couple issues with that i did this this area might might still change a bit in drupal aid because we're not completely sure how we're going to uh... deal with those it's a bit complex because an entity type could start out without any bundle a country module could start adding bundles to it so the fact that an entity type does not have any any bundles is not really constituent of that entity type this might change in time so you will uh... next entity code uh... this entity type is cloned into the bundle uh... bundle value and i'm wondering why isn't entity type and that's already the case and it's working basically like that we just have to solve like the extension problem like when you then a module like adds additional bundles to that later on that you make sure that it stays consistent and like the original automatically graded bundle is still there thanks uh... this one is for uh... when you uh... define the field storage definition uh... you have to set an entity type i noticed on the slides uh... in drupal seven when you define well a field then it was reusable across all entity types so what's up with that right so the case good catch and good question chose not to delve in that in the slides but yes so one of the changes that were made that actually is is a consequences is one of the consequences of uh... storing an entity is the job of the storage handler but the storage handler is defined by the entity type and different entity types might have different storages one entity type could be stored in sql and the other could be stored in mongo so in d seven you could actually use the same field across different entity types this actually made no sense because using the same field across various places is only ever uh... useful if you want to query across those different kind of things and you can only query within a given entity type you cannot write a query that retrieves users and nodes you can only select all the notes that blah blah blah but so it actually made no real sense and it was we turned out that it was actually an anti-feature it was more painful than useful it was painful because when you created a field you could never ever be sure that some other random module would not create a field a completely unrelated field with the same name on another entity type and so de facto it had you had to adopt a practice of prefixing your field names with your entity type if you wanted to be sure that you would avoid clashes and so what happened in the eight is that like we clustered you what happens regarding the fields within an entity type has no relationship at all with what happens with the field within an another entity type meaning you can have a you can add a field with the same name to node and to users they don't have anything in common it's just a different field it's basically namespaced by entity type so yeah talking about a field storage it always relates to a specific entity type then one more small question for Wolfgang in entity API in Drupal 7 you had a UI controller which defines some paths for you automatically I missed that in the slides is that still the case or not? no actually the UI controller I think is right now the only thing of entity API module that has still no Drupal 8 variant but there's actually like auto-generated routes for your entity type already in Drupal 8 what means like you get like a page to view your entity and stuff like that but there's still no like feature-complete UI which you can get like with the UI controller in Drupal 8 so that's still something that has to be reported and implemented for Drupal 8 okay thanks hi just from a developer point of view okay I'm minding if we will be still able to use a function from the devil module like DPM with the Krumo interface I mean we use developing we used to inspect objects like nodes and values and whatever with DPM function will list object properties no like properties and also values of the areas but these seems to in this case in Drupal 8 seems that we are getting these values mostly as a methods of the classes I mean with DPM function will still work and print the values in the same way or some matters about this so the regular DPM function doesn't work with Drupal 8 entities also because they contain like cyclic references what makes it break but what I would expect it is that an improved version like comes up which just integrates with entities and lists all the data that is an entity because all the API is there to fetch the data and to visualize it so it's just a matter of integrating it with the entity API and of course you can still like use tools like X debug in your IDE to look at it what I would say is to me is the most convenient but I would expect tools like DPM short so DPM of entity won't work but DPM of entity to array will just print out the values as an array and same thing for if what you want to DPM is a field item list or a field item I think DPM on those will just fail but you can use the to array method to downcast that to an array and see what's inside so it will list the values yes it's kind of a consequence of the the nice easy syntax that we showed it's it relies on magic getters and setters it's what you have is not an object which has the actual properties like body, title etc they don't exist as object properties it's more complicated than that so debugging is slightly more difficult but the to array if you want to see what's in there what are the values to array will work for that and the entity-filled metadata wrap the entity-metadata wrap will not exist anymore will be I mean in bundled you know is a native sort of wrapping yeah you don't need the entity-metadata wrap anymore because it's like the built-in API is exactly the same improved API provided in Drupal 7 so it's built in basically thank you so much really great work Hi so my question is about entity form modes but these were only briefly mentioned in the talk and so I can think of lots of really interesting uses for entity form modes uh... for example if I was implementing workflow I might want to have a a different uh... show a different entity form uh... each stage of the workflow and just present the fields that were relevant to that that workflow step or something or or um... or base it on the role of the user who's there so if I was looking at uh... but my question is how do I actually use a different one uh... if it was the view modes there's a handy hook uh... for hook entity view mode alter where I can just change the name but that doesn't say I hate that hook I mean it's it's great but it's painful to support so um... there doesn't seem to be an easy equivalent for form modes I had a look around and I've seen form mode names uh... for say like user dot register is in the in the routine uh... yaml files so how do I intercept that and decide to use a different form mode do I go into routine subscribers or what yeah I would say yeah you write your own route and just call a form with a new form mode so instead of like intercepting somewhere you you do know your own form and call it that way and pass the right form mode okay so just make a new entity form control a class and say but it will use this form mode as it's but then again like it wouldn't work for us if that form is displayed for instance in a block you could have a side block that is a short form for an entity and then yeah we probably probably miss an extension point to let you switch the form mode of an entity form before it's displayed way yeah it's very possible that we're missing that at the moment please file an issue hi first of all i'd like to say thanks for the great uh... great stuff uh... my question is to uh... concerns itself with the carnalities of fields uh... in one of our old websites on group seven we uh... we several times had the uh... experience we wanted to use the same field across several uh... content types but in different carnalities in effect we had to create a new field each time and prefix it or something to to discern that this was the single value field and this was you know multi-value field uh... what's the situation now in group late i saw you still had the carnalities on your field storage so it's really the same yeah basically the cardinality affects affects the storage because uh... so it was it's it's been kind of of the back and forth in cck d6 cck did all kind of crazy stuff to move your data around whenever you change a setting that required a change in in the in the storage layout and it was kind of it was yeah it was it was kind of scary like we're taking your data and we're putting them in another column in a table usually it works fine but then if you happen to have like millions of records in there we're not actually sure we're able to manipulate that safely within a single uh... atomic operation that won't break it it was kind and it it it pissed it pissed everyone off like where is my field stored we didn't have an entity field query back then meaning you could that people tended to write direct SQL queries tables in the database that would just break the moment someone switched the cardinality or did something else and and you had code you had white pages uh... so in d7 what was done was like everything every field in its own table that's it we have a field cache there and and we we like we don't care about base fields because it makes sense for them all of them to be in the same table because it's way more efficient but like the configurable fields in a sense they can change over on us so we we are like cautious and we store them uh... each in in its own table back in the eight uh... well we the storage needs to take care of both so we're back in a situation where some uh... fields are stored in a base table and some fields are stored in in its own table in their own table and we still want to remain cautious about how do we move from one to the other and uh... the fact that a a base field is multiple means it's going to be stored in a separate table if the base field is single is going to be stored in it has to be the same for all it it has to be a store property of the storage yeah it's not going to change uh... it's just uh... you know typically you would want to have the other single or multi that's really sorry come again uh... it's just that it's typically we won't need to to divide them into uh... cardinality of two or three and four but just single or multi what could be done and we it would be doable we just didn't have the time to to to get to it that like you set a cardinality on the storage and then you can set a lower cardinality on on the field site and that might work just didn't got to it hi also thanks for all the work i think it's a question for us when to uh... on the view modes for forms or or for display what's the the current recommended approach to get some layouts or i don't know what the correct terminology is now or designs in there like a tree column design for your form or something like that there is a cooperation with panels because i think your display suite are there plans there or do you use templates or something like that or uh... there are plans we'd be like for instance display suite at this point is already completely ported for triple eight so we as well as you said we are going to try and release it by the end of the year there are talks to introduce we had a layout module at some point in court and then we've been removed it uh... we are are discussing whether to introduce it again and have like a base display class in court so that both panels and display suite can use it that's that's the idea right now i have no clue but when it might get in uh... but that's the idea and it would be handy because it's kind of annoying that panels has their own classes and we use them panel seems to be splitting up everything into page manager yeah yeah display module or whatever so so yeah there are hangouts um... and we there are some notes somewhere in groups of triple or dark about the situation right now so um... yet there will happen something but i can't really tell when and why so what's the correct term and look for it it's the the layout module you call it yeah i think yeah layouts in court again thanks hello uh... i tried to play a bit with the field so to create a custom field and i also that uh... after the field is created i couldn't disable actually the model so is there any possibility to i mean to not search for all the fields what i created and to delete manually and just disabled the model and uh... delete everything what i so yeah this is something it's a yeah it's a complex like a really painful area we had we had to at that behavior at some point in in the seven early in the after said seven dot oh i think but it was like late in the cycle uh... that they have you can't remove a a a module that provides a field type if there are still fields of that type around because then it's just data that sits in your database that we can't do anything about because we don't even know what they are uh... because we have lost the code that knows how to deal with those with those that uh... so and it was like you know they were weird cases where uh... you could uh... disabled a module re-enable it and and and meanwhile if you have if you have loaded and saved an entity or that is basically like screwed uh... so we there was no way to ensure data integrity while uh... uh... allowing that so we had you know we had to forbid uh... prevent the disappearance of the field type while while there are still fields of that type uh... house of things being any better yeah if you want if you want to remove a module that provides a field type unit room to delete all the fields first uh... and we have a purge process that happens on crown we need to wait that all this the the values that are stored in the database uh... that we had an opportunity to remove them cleanly and react to the fact that they are being removed uh... before you can you can remove that uh... that uh... module it's yes it's a bit of pain point and we don't have much better to offer i think part of the problem is that we still need to unify the purging process and that the plan actually that once we unified the purging process we can also like clean the data for all of the base fields where the field type has been used and then we can actually provide you with the functionality that does it uh... like when you uninstall that you collect confirmation this is going to delete quite some data but it could be done automatically and easy and easy just no one did it an easy way out kind of of this would be like just to provide a ui for a batch progress bar to leave you want to remove that module okay we're going to clean up all your data that might take a while but do you want to do it now and then you stare at a progress bar uh... for as long as it takes if you're lucky like you do you're not doing it on a on a huge database at least not in production and and uh... and then it's done like you don't have to wait for a couple days that enough cron runs have happened and and check really regularly it's okay can i remove it now no not yet come back tomorrow maybe that would we'd be one way to address it but it and it would be easy just no one took the time to write it so what i was thinking that uh... okay i'm playing with the code so i can easily uh... call a function which will return uh... to which entity or entities the field belongs to so i can do it easily but let's say if i'm a side builder i will activate the model so i will add to several entities and uh... then actually i want to disable and i have no information about the field where it belongs to so i have to search in the back office that's why i asked and uh... one more question yesterday it was a session about also uh... uh... about the fields and translation and uh... there was a interesting uh... feedback that if you want to change the properties of the fields i mean the information then actually you have to go to the uh... status page and you have to run the uh... rebuild or update for the database right so there's a option and uh... the problem was that you can't uh... change uh... the information if you already have contents and that's uh... it painful right because if you have already content and you want just to add one more information why we don't have uh... fallback for example okay we already have contents but uh... let's say the the value is null