 Well, good morning. Everybody feeling like all charged up here? Anybody have a little partying last night? Saw a few people out there, looked pretty relaxed. Thinking that we're going to talk about the Alice in Wonderland World of Fields and Entities today and I was thinking that a couple more drinks might be really nice about now because this is a really crazy subject, but we're going to have to deal with it without that. The best analogy I could come up with for what's going on in Drupal 7 in Fields and Entities was the story of Alice in Wonderland. This is the story where Alice jumps into this world where nothing's normal, everything's crazy, anything is possible. So a little background about me. For those of you who don't know me, I'm Karen Stevenson. I'm a maintainer of CCK and Date and Calendar and some other modules. I was a member of the team that got Fields into Core. We had a lot of sprints and did a lot of work to make that happen. I'm a Lullabot and if you know anything about Lullabot, you know we're pretty passionate about what we do whether that is making, having parties or writing code or creating modules. So here we are. Before we get into this, I want to tell you that I'm going to talk about a lot of modules, a lot of projects. Not all of them are recommended. Not all of them are production ready. Don't say just because you saw this module in here that I should go slap it on my production site. Don't come and talk to me if things blow up. But there are some crazy and really interesting things going on and I thought it was worth sort of exploring the universe of the modules that are out there and some of the things that they're doing. So let's go ahead and dive right into this topsy turvy, crazy, upside down Alice in Wonderland world of fields and entities in Drupal 7. So I'm going to start with what I call everything as a node take one. If you've been around Drupal for any length of time, you've heard the everything as a node. We've been doing everything as a node mantra. In the very beginning, which is not all the way back, but back a little ways, there was a story module. So if we go into Drupal 4.5, we had in Drupal Core the page module and the story module. And there were two modules and they did very specific things. There was a module that created a page content type and it had a title and it had a text field. And then there was another module and it was the module that created the story content type and it had a title and it had a text field. And if you wanted some other fields or you wanted some other content types, go write some code. And in fact, the instructions were take the story module, copy it, change every place where it says story and change it to the name of whatever it is you want it to be. And that's how you do it. So in Drupal 4.6, we still got the page module and the story module. And then we had an interesting experiment called FlexiNode. And this was, John Bob started this and this was kind of going down the path of saying, wouldn't it be nice if we could let people create their own fields? You know, have some flexibility in the way that they create fields. So he kind of did it as an experiment and he threw some ideas out there and put some code out there and it just took off. He really had no idea it was going to be as popular as it turned out to be. And in fact, it turned out that it wasn't written in a way that it scaled or anything else. I mean, he really wasn't expecting it to go where it went. And so he and some other guys kind of went into a room at one of the Drupal cons around that time and they said, all right, looks like this is something people want. Let's figure out how to do it right. And they kind of put their heads together and came up with a whole new idea in Drupal 4.7. In Drupal Core, we still got the page module and the story module, but now we have Content Construction Kit. And the Content Construction Kit did two things. It allowed you to create custom content types and allowed you to create custom fields. And you could do the whole thing in the UI. You didn't have to write any code to do this. You could have a nice UI, well, a UI. I won't go that far. But a UI. And you could create custom content, any number of custom content types, and you can create any number of custom fields. Well, this is pretty darn exciting. And so pretty soon we're saying, hey, you know, this really opens up all kinds of possibilities. You know, maybe nodes now are really powerful because nodes were the things that you could do all these things. You can create all these new node types, and you can create all these new fields on nodes. And then we started all these discussions about maybe everything should be a node. We'd like to have some fields on users, and we'd like to have fields on comments. Maybe everything should be a node. Maybe that's the answer. So now we go into Drupal 5 and 6, and we started saying, OK, well, this Content Construction Kit is pretty useful. We should get some of this stuff into Core. And we wanted to be able to get custom fields into Core. We didn't quite make it, but we did get custom content types into Core, and bye-bye page module and story module. And now in Core, instead of creating or having two modules that did one specific thing, the page module and the story module, Core has the code that creates custom content types, and it provided two custom content types out of the box, the page module or the page content type and the story content type. So CCK is still the place where the custom fields are. We didn't get that into Core for Drupal 5. We still didn't get that into Core for Drupal 6. So more talk. Talk, talk, talk, talk, talk. We did lots of talking. And everybody said, you know, it's not necessarily that everything needs to be a node, but everything should have fields. It would be really, really nice if we could put fields on anything. We should be able to put fields on users. We should be able to put fields on comments. Let's put fields on everything, and let's put it into Core. So in Drupal 7, here we are. We've got our custom content types. Now we've got custom fields. And CCK, bye-bye. Done with you. The only thing we really need CCK for in Drupal 7 is to migrate the old D6-style stuff to Drupal 7. So an interesting thing happened in the process of trying to figure out how we're going to put fields on anything. That actually, that was sort of thrown out. Why don't we put fields on anything? We were going to put fields in Core, but then this idea of saying fields in Core on anything kind of came out of that whole process. We said, well, yeah, we should do that. And then we started looking at it. And, you know, the way that nodes and users work in Drupal 6 is not the same. They don't look the same. They don't have the same hooks. They don't behave the same way. And it turned out to be a little bit complicated to figure out how you're going to get fields on users and nodes. And we said, you know, the way things really are now, we're going to end up writing a whole bunch of crazy custom code to make this work on every possible type of entity. What we really need is we need a layer over the top of things that's consistent and that we can rely on. And then we're going to attach fields in a consistent way to something. And initially there were objects and then somewhere along the line the word got changed to entities. But basically the idea was kind of a global name for things to which you could attach fields. So a node is an entity and a user is an entity. And so let's talk about what is an entity. You know, only the Cheshire cat knows. I've heard that question quite a bit at this conference. What the heck is an entity? I don't know that I'm going to answer the question. I'm going to tell you about entities and hopefully at the end you'll sort of get the idea. So we had all kinds of discussions about the fact that we needed standardization. We need a consistent standardized way to deal with the things that we are going to attach fields to. So we had all kinds of issues about this. There are some components to entities and a lot of these are the things that we see in nodes but they're things that potentially might be in other types of entities. They have a key. So a node has an NID and a user has a UID and a term has a TID. They've got some sort of a label. A node has a title and a user has a name. They have a base table. They actually don't have to be stored in the database although all the core ones and I think all the contrived ones that I know are stored in the database. But if they're going to store their data in the database they have to communicate what is the table where they're storing their data. They may have properties and properties are not fields. Properties are things that are very hard coded specific to that. So in the case of a node a property would be something like the status field or the author field. In the case of a user be something like the email field and the properties are actually stored in the base table. And then they have the possibility of having field integration. Now we created entities so that we could attach fields but in fact entities don't have to have fields. They can say I am fieldable or I'm not fieldable. But if an entity is fieldable then you can attach fields to it. We realized that we have to have some concept of what caching is. So the entity has to be able to say can I be cached? An entity might have the concept of bundles. So content nodes have content types. So content has bundles. Users don't use bundles. They don't have to use bundles. They might use bundles. Users might have revisions. And again nodes have revisions. Users don't have revisions. And then we have to have some consistent ways that we can say where is this thing located? What's the path to it? How do you load it? How do you view it? And how do you get to the edit form? So we had to have a way that we could declare what are the callbacks? What are the functions that are going to take care of these things? And then we might have view modes. Nodes have like a teaser view mode and a full view mode and other kinds of entities might have their own kinds of view modes. And we might have translation handlers. So that's the stuff that goes into entities. We got a whole bunch of new APIs. Now we knew all along we were going to have a field API. That was the whole point of the work that was being done. We picked up an entity API. That was new. That was not initially something that we were going to do. And for those of you who are not developers or not coders and you say what the heck is an API, if you want to visualize that you've got a shiny new car and you want to drive that car, you've got to have some keys. Without the keys you can't drive the car. So an API is just the keys that go with it so that people can use these things. And then there was something else that came out in this that was kind of late in the cycle in this entity field query. What happened was now we've got data in all these new different places and it became a little confusing to figure out how are you going to retrieve all this data. And so this entity field query is a new API in core that you can use to retrieve the value of a specific field. And it will do things like it's smart about what language should it retrieve, what value, where's the field stored, all those kinds of things. A lot of the things that we needed to do to be able to use entities in a consistent way didn't quite make it into core and so there is a contrib module called entity API and that module actually is being used by an awful lot of the contrib modules that are doing anything with entities. So if you're not a developer you're probably not going to do anything with that module directly but you're almost certainly going to find that it's required for a lot of the things that you want to do. So we ended up here. We ended up with some entities that made it into core. We got an entity node user term comment. All of those were things that existed in core but now they are quote entities and as entities they are fieldable which means you can now put fields on all those things. There are some other kinds of entities that either didn't make it into core or didn't belong in core and so for instance the idea of a file as an entity did not make it into core but there's a module that does that. Blocks as entity we had a big discussion about trying to get that into core didn't make it into core but there are contrib modules to do that. Profiles as entities, user profiles didn't make it into core but there's contrib modules that deal with it and group like organic group is another example of a contributed entity. So one of the questions is why do we care about entities? What the difference does it make? Well the thing is that this entity system that we have created makes it really really easy to manipulate and manage data. So we can use the entity API to handle all the stuff that goes along with the base table. How do you store it? How do you retrieve values? How do you load values? The field API does all the same thing for the fields. There's automatic integration with views and a whole lot of other modules that come with it and so what happens is potentially this idea of creating custom entities is potentially useful for any module that needs to store data basically. We have a lot of modules that had their own ways of storing data. They weren't a part of the field system, they weren't nodes but if you use the entity in the field API now these modules can take advantage of all that and they can have a whole lot of work already taken care of and they just have to layer on top of that, you know, their special sauce. And in particular if you have data of your own and you want to allow users to dynamically add additional information to that, you know, this is particularly interesting because the entity API then allows you to create fieldable entities. So here we are, we're in this Mad Hatter's world. We've got new APIs, we have new entities, we have new fields, we have fields on anything. You can put terms on terms. You can. Entities that do things with other entities, entities that do things with fields, fields that do things with entities, fields that are entities, entities that are fields, fieldable fields, wow. All right. Jumping down the rabbit, Alice in Wonderland? I think so. Okay, jumping down the rabbit hole. So like I said, kind of the basis for a lot of the stuff that's being done in Contrib is this entity API module. Again, if you don't write code, you're probably never going to have any idea what's in here. Just all you got to do is install it. It's going to be a requirement for a lot of things that you do. One of the things that we had to do was start thinking about blocks. Again, there was some hope early on that we would actually make blocks into entities in core. That didn't happen. So a lot of kind of experimental stuff was going on in Contrib. There was a block 2.0 and an entity block and a block API. A lot of people playing around with the idea of how could you make blocks into entities and make them fieldable. And it looks to me like the one that's sort of emerging that has legs is the bean module. And the bean module lets you create little blocks in the same way that you create content types. So you can actually create block types in the same way that you can create content types. And then each type of block can have fields attached to it. And you can say this type of block has an image field and that type of block has two text fields and who knows what else. So you can do all those things. And it adds a tab. So when you go to the screen where you see all your content, in addition to the node content that you see now, you'll have a tab to see your block content. So that's kind of cool. Another thing that we're doing is we're kind of rethinking the idea of user profiles and what the heck is going on with user profiles. So in Core, we've always had this profile module, or this has been a part of Core for a really long time. It allows you to put fields, attach fields to users, but it doesn't use the field system. It's got its own really funky way of storing fields and it's not a good way and there was a lot of effort made to try and switch that over and actually change it so that we had profiles that used fields using the field API and that all that would be in the Core, but that got into a whole big debate about profiles and what should be in profiles and should those fields be attached to the user or should they be attached to the profile and should there be a different thing and it didn't make it. So as it stands right now in Core, you can attach fields directly to users and there still is a profile module and I exited out here because basically we don't want anybody to start using it who isn't already using it. So we've got sites that are coming up from Drupal 6 or whatever that may have been using the profile module in the past that's not the recommended path forward. It's not going to be broken. They can still use it in D7. It's still there, but basically if there's not data in it, I believe that it's either if there's not data in it or if you hadn't had the module enabled, it's just not going to show up at all. So if you're building a new site, you won't even see an option to use it. You're not supposed to see an option to use it. We're trying to find a path out of that for probably Drupal 8. In Contrib, we've got a couple of projects. We have a profile 2 and a profile light. They've taken a couple of different approaches to how to handle fields on users. Profile light says, let's go ahead and attach the fields directly to the user. That's fine, but we need some ways to categorize it. So let's add categories, and that was one of the things that the profile module did for us. Profile 2 takes a little bit different approach. Profile 2 takes a more complex approach. And it says let's create, let's let people create as many profiles as they want, and a profile is another entity that is connected to the user. So you could put fields directly on the user, or you could put fields on the profile, and the profile is attached to the user. And the reason why that might be of interest, well, first of all, is you could create, like, various profiles for various purposes that all have different kinds of fields attached to them. And also, that way, you're not necessarily loading all those, if you have a lot of fields, you're not necessarily loading all those fields every time you do a user load. You're only loading those fields if you are looking at the profile. So that is something that's going on. We've got all kinds of modules that are, you know, have built whole subsystems around entities. And I'm not going to talk about any of these in any detail. I think there have been sessions about all of these at the conference. And if you missed the sessions, you can go back and try and see the videos. If you know what UberCart was in Drupal 6, Drupal Commerce is like a complete head-ground-up rewrite of the whole idea of doing commerce using the whole entity and field system. Organic groups, again, existed in Drupal 6, but it was allowing you to make groups out of nodes, so you could designate a node as the group and then add other nodes to that group as content. In Drupal 7, complete ground-up rewrite to say this is all about entities and any entity can be the group and any entity can be added to the group. Media is like a complete ground-up look at reworking the way that file handling is done using the entity system. And we have more entities. So the file entity, this kind of came out of the media module... Yeah, the media module initially was doing a whole lot of things with files, and they've split the file entity out, and it's actually a separate project that you can use with or without. But again, it's the idea of letting you attach fields to files, so you could, for instance, add a lot of metadata about your files. Panels came out with the idea of... There's a module called fieldable panel panes. And so if you've used panels in the past, you know that there were these little custom content, which was sort of like a block. It was just a title and a body, and that was a little panel pane that you could use in panels in various ways. So the fieldable panel panes is the same idea, only it's a little entity, and since it's an entity, it can have fields attached to it, so you can have a little entity that has image field, and that can be a pane that you can use in panels. The message module has written a whole messaging system that uses entities as the messages, and again, since the messages are entities, they can have fields attached to them, so you can control what kinds of data you can collect in your entity. This one's really interesting. There's entity forms, create forms that are fieldable entities, and the idea, it's sort of an alternative to the web form module. I don't know if it's a good idea or a bad idea, but it's an interesting idea, and the idea is then, the form submission then creates new entities. Oh, entities, entities. So you start loading up all these new entities, and you see we've got lots of things here, even if you aren't creating your own custom entities, and one of the things that's really confusing is where the heck do you manage all these? The manage field screen for all these things is all over the place, so some of them are putting them in the structure area, and some of them are putting them in the configuration area, and some of them are two or three levels deep. As I've been trying out different ones of these modules, you know, like I spend the first five minutes trying to figure out where the heck I configure them, because they're all over the place. Another thing that we're doing is we're rethinking the whole idea of references. So old school references, Drupal 6 and earlier, you had node references and you had user references. Node reference says I'm connected to node 6, and that's it. User references, I'm connected to user 5 or whatever. Initially, that's what we had in Drupal 7 as well. So in Drupal 7, we had created the references module, which was kind of an outgrowth of CCK, and it basically moved that same old node reference, user reference stuff into Drupal 7. Lots of people are using it. It's out there. It's fine. But as we created all these new kinds of entities, said, you know, we really want some way of referencing every kind of an entity. So finally, the entity reference module was created, saying, you know, rather than trying to think of all the possible entities that we might want to create, let's do it in a really generic way, and say we can reference any kind of entity. So that is the new school way of doing it, and if you're starting a new site and you've got a choice between using the old school or the new school, go with the new school, because that's where all the cool kids are. And if you go back and look at the project page for references, you'll see that it says the goal is to deprecate it in favor of entity reference because we like the more modular approach of entity reference. At this point, there's so many people using those that they can't be pulled. But if you're making decisions about what to do going forward, you should be going with entity reference. So this is the entity reference module, and it also provides nice things like if you use it in views, it's got not just references, but reverse references, which is nice. Another thing that's interesting and kind of illustrates what's going on in all of this is organic groups came out really, really early in the Drupal 7 cycle. And like I said, they created this whole entity system for doing groups on any kind of entity. And initially, at the time entity reference didn't exist. And they initially created fields, organic group fields that were used for connecting the group content to the group, whatever the group was. And they were just custom fields that he had created. And they turned out to be kind of weak copies of node reference and user reference. They actually didn't have all the functionality that we wanted them to have. And so then there were some issues with functionality to them. And then finally the issues went around and by this time the entity reference had come out and said, you know, we want it to be like entity reference. And then finally he said, you know, maybe it should just be entity reference. And he actually, that was the original organic groups was 7.1. There was a 7.2 version of organic groups where he threw out the custom fields and he's going completely over to using the entity reference field. Now one of the things that he ran into didn't have some of the flexibility that he needed and he became a co-maintainer of the entity reference module and added the functionality he needed for organic groups to work, which means it's also additional functionality that might be useful to other modules. So I just think it's a really interesting exercise in what people have done. So, sorry about that. Okay, so we can go beyond references. So we have this module called Relation. So Relation is another kind of reference. It's sort of references on steroids. The Relation module says, not only do I want to connect this item to that item, but I want to know what kind of connection they have. I want to be able to say they are sisters or one of them belongs to the other. I want to be able to, you know, I want to have some additional information about the relationship itself. So what the Relation module does is it creates an entity for the relation. So the relation itself is an entity and then that relation is used to connect to other entities and allows you to do things like belongs to sister or parent of that kind of thing. The registration module is really interesting. So in earlier versions of Drupal and in fact they have Drupal 7 versions, there was a sign-up module and a CCK sign-up module that you could use to sign up for an event. They're both specific to signing up for nodes and that's great. The registration module is one that came in and said, why don't we take a step back from all that and say what if we could just register for any kind of entity. Forget whether it's a node, any kind of an entity, any kind of a registration. So basically it has created a registration which is an entity and it's a fieldable entity which means you could have a type of registration that requires an email address and a file attachment in three text fields and another type of registration that has different kind of data that goes along with it and then you can use those registrations on any type of entity and it adds these tabs. On the edit tab it allows you to say I want to enable this entity for registration and then it has a manage registration so that if anybody registers you've got a list of all the people that have registered for this entity but it's a really interesting idea of kind of stepping back and getting out of the node centric way of looking at things. This is just an interesting module. I think this is totally broken. I tried to use it and I couldn't get it working at all but it's an interesting concept. So this is embeddables, the idea of trying to create a module to plug anything into anything else. So I want to embed a node in a node or I want to embed a block in a user or whatever. Interesting idea. Then we've got a whole bunch of utility modules. Now one thing that I should mention and anyone who's trying to use Drupal 7 should be aware of this is all this stuff that we do to build these fancy entities with the fields is very expensive and we need to cache them and it's designed to be and built to be cached and the goal all along has been that if you have any concerns about performance you are going to want to cache them but what happened was core doesn't automatically do that caching. It puts all the things in place that allow caching to happen but it doesn't automatically happen. So there's a module called entity cache you don't have to do anything but enable the module and it will take care of the caching for you. If you have bigger sites and you have more performance issues there's a couple other modules that are really interesting one is entity cache flush to give you some control over when the entity cache is flush and then there's a cache warmer to give you some control over slowly refilling the cache after you flush it instead of having it all just hit at one time. Entity translation. So this is bringing entities to the world of translation and multilingual sites. So in Drupal 6 the way that we did multilingual sites was we actually created other nodes. So if I wanted to have a French version of something and a German version of something I actually create two different nodes and I have here's all the French text over here and here's all the German text over here. The entity translation and that's got disadvantages because now you've got two nodes instead of one node and what if you want to do things like registrations or references or something like that it doesn't make sense. So what the entity translation module does is it basically hooks into it doesn't actually create entities but kind of hooks into the entity system to do what it does and it allows it allows each field on the node to become translatable. So instead of having a French node and a German node you have a single node that has French fields and German fields. Interesting module that I had never seen before but it was kind of interesting this is a module running around with different ways to list entities so views is one way that you can create a list but it's also got options to use things like the entity field query and entity reference fields and other things as sources of those lists that you might create. So all this entity stuff looks pretty exciting maybe you want to create some entities well there's a couple of ways you can create entities there is an entity construction kit kind of like content construction kit I don't know where you came up with that name but anyway there's an entity construction kit and it allows you to use the UI to create custom entities if you're a developer and you would rather do this in code there is a module called model and model is if you think back to story module page module that we talked about earlier it's the same kind of an idea it is basically just example code and you copy it and you rename everything and you've got all the stuff you need to build a new entity without figuring it all out yourself you might want to copy entities so now there's a module called bundle switcher and you can create an entity of one type of bundle and you can say you know I started with this as a page and I want it to be a story and let you do that kind of thing bundle copy is kind of the equivalent of what we had in Drupal 6 we had content copy where you could export you know export and import the stuff that you had on a piece of content and that's what bundle copy does in Drupal 7 and then there's another one called attach existing fields but these are all about different ways of copying data from one to another this is not technically about the entity system but the entity system is all built on classes and uses the registry and if you are playing around with some of these new entities and then you disable them you may find that funny things happen like suddenly you have these fatal errors about missing ink files and you can't get anywhere on your site and you don't know why everything blew up what happens is the information about all these classes is stored in a registry and that registry didn't get cleared out properly and this is happening frequently enough that there's a module for this and this is not a normal module this is a module that you download and you run from the command line or you can use a drush command the instructions are on there and I'm just bringing it up because if you are going to try and install and try out some of these things and then get rid of them you are probably going to run into this there's an interesting module called restful web services so this module is designed to create a rest endpoint for any type of entity so if you want to create a service from your entity you can use there's a module called drush entity and this adds some drush commands to actually load and read and get value grab values off of entities entity autocomplete so you know we have autocomplete for nodes and users and some of our standard kinds of entities and those are really handy you can't have an autocomplete without having an autocomplete path somebody has to create the autocomplete path the autocomplete so entity autocomplete is about the idea of creating a way to do an autocomplete path for any kind of entity entity label in Drupal 6 we had automatic node titles which was a way if you had a node or a content type and you didn't want people to actually physically enter the title you wanted to control what the title was going to be you could use something called automatic node titles which let you use something like tokens to create a pattern for what the title would be automatic entity label does the same thing for entities kind of in a generic way entity view mode modal this brings up a modal window that uses a view mode which just kind of blew my mind taxonomy entity index this actually creates a physical index an actual table of index for taxonomy terms and this was around some problems that people were having with revision content and being able to make sure that taxonomy worked on revision content entity dependency this came out of the deploy module and so we got potentially we do entity relationships you know we got an entity reference which references something else which references something else and if I pull an entity I need to pull all the things that are related to it and so this entity dependency API is about finding you know and finding all the things that are related and pulling them all back and also pulling them back in the right order so that the bottom level dependencies are first okay alright fields we got all kinds of stuff going on about fields we had we've been talking about fieldable fields for a long time I've sort of a pet thing of mine for a long time was doing fieldable field because we knew you could we knew it was possible and the example for when you would want something like this is something like a recipe for instance so you say a recipe has an amount and a description and maybe a picture for an ingredient and then you want to have several of those and you don't want like three amounts and then three ingredients and then three pictures because they have to maintain their relationship to each other so what you really need is you need like a combo field you need a field that contains those three elements and then you need to be able to add as many of those as you need to and treat it that way so that's what the idea of fieldable field because a field anything can be a field can be an entity and an entity can be a field and an entity can have fields so we can have fieldable entities so there was a micro project and there was a field entity project and I think those sort of died down there's a field collection project and I think that's kind of where most of the activity seems to be and so this is a field that you can attach to any entity and you can attach fields to it so you can create your little sub thing and then you can attach that to pieces of content and then there's a growing collection of modules around that to display it in different ways and to make the views work better and various other things so this is field collection then there's field group and field group is pretty much the same as what it was in Drupal 6 except it's a little more powerful because you can do like nested field groups now and this is not physically moving things around this is just grouping them on the forms I thought this was kind of mind blowing so we had entity references and we had user references and we have node references this is a field reference so this is referencing one field from another interesting idea okay field utility module one of the things that didn't make it into core was the ability to control format or settings of other modules you know if a module has format or settings and you want to alter them too bad you really can't do that so this is a module designed to try and make that more possible field permissions this is pulled out the field permission system so that if you need to have field by field permissions this would be the way that you do it this is a module to add field validation to each instance so it allows you to create some custom validation roles field tools module is just kind of the beginning of something right now but the idea is to create a collection of tools for working with fields and manipulating fields format or field this one is format or if you work with if you go into the display field screen you're setting like for a content type you're saying I want to see this format for this field and this format for that field format or field is saying what if you need it more specific than that what if you need to have different format or settings on individual pieces of content so now we're kind of coming remember we did this like everything is a node thing and we said the only thing we really want from nodes is the ability to be fieldable but it turns out we actually want some other things from nodes there's a whole bunch of things that are properties and this line between what are properties and what are fields which things do we really want is really getting fuzzy so what exactly makes a node a node we should think about that well nodes have fields they have view modes they have access control which turns out to be really important they have revisions, they have menu items they have authors, they have status they have comments, they have workflow they have creation dates, change dates so they've got a lot of aspects about them now if I don't want any of that kind of stuff a little custom entity is perfect right but what if I want some of those things now what do I do well I could create a custom content type and then I'm going to get all of them and I'm going to have to hide the ones I don't want or maybe I need an entity but I need to pick back pick back up some of these things that I lost and so now we're kind of coming into this really crazy world where now we're saying oh my god everything can be like a node really scary so there's a title field now what the title field actually grew out of was the fact that the entity translation model needed a way to translate the title, the title is not a field the title of a node is still a property of the node and we needed to translate it and the entity translation model module translates fields so this field makes the title into a field and actually what it does is it creates a field and kind of swaps it in but anyway it makes it possible to create translations for the title field properties so this is line is getting really blurry so this is something to turn fields into properties I don't know why but you could renderable elements so if you're looking at the display field screen you know you can move all your fields around but the properties aren't there so this is saying okay maybe you want to be able to have that same level of control for the properties as well as the fields so this adds that dynamic properties so this one is really crazy this came out of the commerce module there may not be a lot of use cases outside of commerce but the idea is you might have things that are so dynamic and so complex that you really don't want to create fields for all these things it would just be overwhelming and so what it is is a method of creating things that are like fields but not really fields the properties for like one of the examples is a camera and you've got all the possible things that a camera might have in a commerce situation I don't think we're done yet maybe we want comments we've got a couple of modules that are exploring the idea of putting comments on other kinds of entities so there's a reply module and a comment field module and these are both looking at the idea of making it possible to add comments to other kinds of entities we want menus and paths you know that was a nice thing about nodes was you can have menus and paths and maybe we want some of those kinds of things on our entities so we've got a couple things here we've got a menu link field and an entity path field going down the road of trying to figure out how to add those things to any kind of entity we talked about the fact that access control is nice we like to have access control and it would be kind of nice to have a more generic access control that is like for any kind of entity instead of a very specific node access control system these are I believe really really rough early experimental kinds of things I don't think either of these is a polished thing but they're interesting exploring the idea of access control for entities what about status field you know it's kind of nice to have that status field there are times when you might want to use that so here's a couple of projects to add a status field to files and to terms and there's more stuff there's the entity view modes to say you know I might want to have other kinds of view modes on my entities not just nodes and I might want to have flags on other things it turns out you can't put flags on all kinds of entities but now they're now you can so the funny thing about this is I feel like we've come full cycle and we did everything as a node back when everything was a node and we thought everything should be a node and now everything's not a node everything's an entity but everything is an entity that's like a node so it's a really topsy-turvy world it's a pretty crazy world we got here I just want to have a couple of provisions again I've flashed through a whole bunch of modules here the fact that I named them does not mean they are production ready or even recommended they are just interesting and you got to do your own due diligence on them I'm sure you couldn't keep up with all the names but there's a PDF there's a link to the PDF on the session page and I actually will publish it after here I didn't want it to get clobbered before the session but I'll publish it after this session and in that PDF I made every place that you see the name of a module should be a clickable link to the project page to help you find them so questions ok my question is can we wake up now is the journey over can you wake up now but actually I'm really confused by a lot of this there are so many options my question is how do we come up with best how do we learn about best practices best practice how do we learn about best practices I don't know if we know what the best practices are yet that's part of this topsy to every world if you are not a developer and you're just going with mostly using modules that exist and you can do what you need to do using standard tools like content types I would probably do that if you're a developer and you want to dive into some of these kinds of things I'm not sure yet what the best practices are going to I think we're working that out right now if you built applications in the past which of the relationship flavors you've mentioned would you recommend for a traditional primary key, foreign key relationship if you build relationships in the past database 101 primary key, foreign key you know these references then there's the reference on steroids as relationship none of the reference modules are actually creating primary key, foreign key things it's just the number the ID it's just storing the ID of the thing that it's related to I'm not sure I understand sorry could you speak a little more about what bundles are yes I did kind of gloss over bundles so with nodes we have content types familiar that we've got page and we've got story, basically they're just variations of a node we had to find a kind of a generic word for what that was going to be we can't use the word content type in Drupal 7 where it's any kind of entity because that doesn't make any sense we had to kind of back up to a word that didn't have any meaning of its own and we actually tried all kinds of things and we finally ended up with bundles as in bundle of fields you know a thing that is a collection of stuff that belongs together it's not necessarily the best word but that's what we ended up with a couple years ago I built a project with something called cck3 if anyone in here has heard of that we were worried what was going to happen with that with Drupal 7 and the fields module came in I'm assuming that this fieldable fields or field collection is where is the replacement for that? the idea is that cck3 the multi group thing would migrate to the field collection module somebody needs to actually write the migration code which I know needs to be done what would your advice be if you're creating a module that defines maybe three types of data should it be a single entity with three bundles or three entities? say that again sorry so if you're defining a module that defines say three types of data would you go with three entities or one entity with three bundles? I don't know if I can give a generic the question was if you have an entity with three types of data would it be three entities or an entity with three bundles well a bundle is a separate entity I mean no one entity has more than one bundle any particular identity entity has a single bundle yeah I'm not sure are there pros and cons? you're talking about any types right? again I don't know if there's a generic answer for that to me the big question is do you want entity or do you want content type and I think the way that you make that call is do you want all the stuff that goes with nodes and if you do then you want content types or if you really just want a really slim mean and clean thing that doesn't have all the nodes stuff on it then you want an entity thank you migration from reference to entity reference is there any discussions for that? it needs to happen I don't think it will be hard it should be a pretty easy transition somebody just needs to write the code so the new address field is that a fieldable field? oh the address field I actually had that in my slide originally and then I took out I had to another 30 or 40 modules and I realized I wasn't going to have time to cover them also I pulled those out and address field was one of them it's not a collection of fields it's not the field collection module it's just a module that defines its own set of fields it's a field that has fields attached to it as a fieldable field no it's not a fieldable field it's not an entity it is just a complex field that has multiple columns in it okay I think I blew your minds that's it