What else should be entities in Drupal 8?

Gábor Hojtsy's picture

Drupal 7 got "CCK" integrated with key concepts like entities and fields. Entities encapsulate the description of a content item while fields are the individual editable pieces of entities which have their widgets, validators, storage and rendering well defined. That entities were introduced for nodes, taxonomy and users, it became possible to attach fields to these, and unify their configuration, storage and rendering. This coupled with translatable fields and the contributed Entity translation and Title modules enabled these objects to be translated the same way, reusing concepts, workflows and implementation.

As part of the multilingual initiative, we are trying to (a) unify and (b) broaden support for translatable objects. Fieldable entities are the ideal backend in terms of translatability, especially when all their translatable values actually use fields. Therefore part of the Drupal 8 goals for multilingual support is to get the Title module or similar functionality to core (issue at http://drupal.org/node/1188394) as well the field translation UI based on / from Entity translation (issue at http://drupal.org/node/1188388).

That all helps with existing entities. However, we encounter structured objects that for one reason or another don't use entities. Think blocks, menu items, contact forms, views, and so on. While fields and entities are great for translatability, the custom implementation of non-entities is the other end. We discussed in a previous post that structuring non-entity objects with fields or field like metainformation, widgets, permissions and rendering with associations to the original objects is needed for clean multilingual implementations. However, there are probably more objects that would make sense to convert to entities, which in itself will not only make them more powerful, customizable and standard to work with, it will also help tremendously with translatability.


There are so many efforts to make entities out of blocks, it is hard to count them even :) Dave Reid has a project at http://drupal.org/project/block, fabsor has a sandbox at http://drupal.org/sandbox/fabsor/1158058, there is yet another project at http://drupal.org/project/bean and another at http://drupal.org/project/block_api. The core issue is at http://drupal.org/node/430886

Menus and menu links

Again, Dave Reid has multiple issues about this, the current one is at http://drupal.org/node/916388

What else?

Would the above two make sense to make entities? What other Drupal objects would be good entities? Fieldable contact forms anyone? Aggregator sources that you can assign an optional image to? Also, let's not confine ourselves to a wishlist. Who is going to help get these done?


Not what but why?

ronald_istos's picture

Don't want to sound pedantic (though I guess its inevitable!) but not quite sure the question is set right - its not so much what should be an entity but why should something be an entity (or some would say why would something not be an entity).

Let me see if I can outline a simple framework to guide choice that hopefully others will find useful.

The way I see it Entities can be a way to store data in the database and attach fields to it (thus expanding) on the main entity data. The fact that it all happens via a (semi)-consistent interface means we can manipulate that data at a higher level of abstraction (entity level) rather than the specific use/application level (node, tax term, user, block).

By the way, this data should be amenable to be represented in the database as essentially one row per data item (not everything fits this model but a lot of things do).

Ok - so with this in mind we may decide that given that we have an abstract method for getting things in and out of the database we want to standardize on it for consistency's sake. A great thing to have in a framework! The question then needs to be why are we not using entities for something.

If we are not standardising (and we need to explain why not - e.g. too many things don't fit the Entities approach) - then we should be asking why would we want to use the Entity way here. What benefits will there be in handling things in an abstract manner (at the entity level) and expanding via fields.

Having said this - looking at some of the examples above:

Blocks sounds like a great candidate in either case. I can see why we would need bundles, etc.

Menus? Sounds like a candidate for standardisation sake - need to study other aspects of it.

etc... :-)

Abstraction seems to be the key

AndrzejG's picture

Abstraction is crucial to increase flexibility of the system because it enables to go (or process) apart of the concrete and details, reducing complexity at the same time. Variety of concrete processes or "things" can appear to be only the various manifestations or "specimen" of the abstract "thing".

From this point of view introducing Entities has been a reasonable step to improve flexibility of Drupal system.

However, to benefit most of the abstraction requires to keep number of "high order" abstractions optimal - not too much, not too less. But always it is necessary to choose abstractions as independent ontologically each from other as possible. For example "user" is of very different ontological nature than "taxonomy term", and both are very different than "a node" or "a context".

So, if attempting to add some "things" to the set of Entities, the following seem to me to worth considering:
- presentation - it could be the Theme or the Block or more general "the Display";
- the content that is different from node etc. - I see the File; maybe there are more such "things";
- the path or (better?) URL or more generally - the address;
- the "collection"; problem is of the algebraic structure, as we have for example a Book as ordered group, and Organic Group as unordered collection;

Probably the list above to be considered should be further extended.

There is also some limitation of the technical nature - so called "identifier problem". It is not the place to describe it, so let me only remark that it is often included in the questions like "what identifies particular taxonomy term (or user or context etc) - the ID, the page with the description of this term or the name of the term itself?".

Sorry for such long rant, but I think that philosophy of the Entities should be elaborated first, WITHOUT limiting discussion by going too quickly to the technological problems (database manipulation).

Also sorry for posting to the group without invitation.

Panels content

GerdC's picture

Out of my head:
Inside a panel I can add new content (that is not a node that is already existing).
I have the impression that this new content inside panels is not an entity since I found no way to add fields to this content.
(I know this is panels, not core, but hey, you asked :-)


Only core?

Itangalo's picture

This question is mainly about core -- right? Or should I think in wider circles?


Gábor Hojtsy's picture

Well, my question was for core because contrib developers could migrate their data structures either way on their own schedule. Core can only do this every 3 years or so :) (ref: http://buytaert.net/how-i-think-about-drupal-release-date-planning). I fully encourage people to make things fieldable entities whenever it makes sense in their contrib modules though.

Not much more…

Itangalo's picture

I went through the list of core modules, trying to find more things that could be entities.

Files, users, nodes, comments and taxonomy terms are already entities.

As you already have pointed out, blocks and menus are good candidates.

The other two objects enti… thingies you mention – contact forms and aggregator items – don't really make sense to me.

  • Aggregator items are collected from somewhere else and only (as I see it) borrowed to your site – modifying these items with new field and content seems strange
  • Contact forms don't make sense on the basis of entities being something you create multitudes of, not getting "one single per site" or "one per user". If you want multitudes of contact forms, you basically got Webform (or perhaps modified node forms).

What other candidates could be found?

  • Help pages could probably be entities. But before doing anything like that we'd have to have a good idea about how to manage help in Drual 8 (which is a kind of active discussion in the docs team).
  • Maybe shortcuts could be entities.
  • Maybe color schemes for the Color module could be entities – but then you would start storing configuration in entities and heyrocker would go completely nuts.
  • Maybe log entries could be entities – but that would make them too heavy for their purpose.
  • If this was April 1st I would suggest modules as entities.

Those were my thoughts! Drupal 8 for the win.
//Johan Falk
Learn Drupal with Nodeone! Drupal 7 introduction | The Views module | Learn Page manager! | Drupal configuration learning curve | Learn Drupal coding | Rules for Drupal 6 | Theming Drupal 6 | 49 Drupal 6 modules you should know

While aggregator items don't

catch's picture

While aggregator items don't necessarily make sense as entities, aggregator feeds might (i.e. each Drupal planet feed could be an entity). Then you could use taxonomy terms instead of aggregator categories for example. There was a D7 issue to make aggregator feeds into nodes - http://drupal.org/node/293318

The global contact form can have different categories can't it? And description text? That doesn't seem too bad to me.

The per-user contact form, agreed that's not a proper candidate.

Shortcuts are currently menu items iirc, so making menu items into entities would cover some or most of that. Short cut sets is a bit of a different thing though.

Log items nooooo.

aggregator sources

Gábor Hojtsy's picture

Yes, I've said aggregator sources as well (vs. aggregator items). I think this would make sense. Will tag up the issue.

Before April the 1st

AndrzejG's picture

I'm not sure if the PROPER answer could be find until April the 1st :-). Simply because there is no clear criterion of the value or purpose of the Entity. Some participants here stressed data (or database) handling, some focused on data structure, I proposed flexibility. What do You think - what is the Entity for? Or simply "Why Entity?". I think it should be a kind of brainstorm on such questions.

Maybe good way is to ask: what developers need? what site admins need? what endusers need? What kind of next big thing?

Or simply - what is the exact purpose of actual Entity module?

I found somewhere the sentence that "everything can be the Entity". It follows from such standpoint that Entity is 100% redundant concept, 100% useless as long as we have no criterion.

Drupal is great, and full of inconsistencies at the same time. Overlapping functionalities, weaknesses of integration etc. No doubt that the abstraction of Entity should facilitate imposing more order into its anatomy and physiology.

profile module

catch's picture

Whether profiles become an entity, or whether user fields are used is up for discussion, but profile module is literally swept under the carpet in D7 so let's not let it drop off the todo list for another release.

they already are?

Gábor Hojtsy's picture

My understanding is that new D7 sites (and responsible migrations) will migrate to user fields, except they don't have some of the features of profiles, which can be augmented with contrib solutions right now. Since we swept profile under the carpet anyway, and it is deprecated in Drupal 7, I think we are safe just removing it in Drupal 8 even if there is no core solution for all of its stuff. If we could release Drupal 7 without an upgrade path for that (skipping our "your data is safe" mantra this time), then there should not be anybody hurt if we remove it in Drupal 8.

We tried that in Drupal 7 but

catch's picture

We tried that in Drupal 7 but it didn't get past Dries and webchick you're welcome to try.

Except... there is also the

catch's picture


there is also the issue that adding a lot of fields to the user object bloats it quite a bit, so there is some value to having a separate profile entity that holds all the large data - but there are trade-offs in both directions. profile2 module would not exist in contrib if this was a done deal though.

well, they did it anyway :)

Gábor Hojtsy's picture

Well, by hiding the module on new installs, they effectively made it unusable for unsuspecting people :) I think this will prove that people did not miss it.

Well the idea was that people

catch's picture

Well the idea was that people use http://drupal.org/project/profile2

At one point people were seriously discussing rolling back fieldable users instead.

For bigger profiles having

fago's picture

For bigger profiles having everything baked into the user account object really doesn't fly. Also, lots of sites want do distinguish between user account settings and user profiles, so having the data stored in a separate entity makes much sense then.

Block Entities

indytechcook's picture

So fabsor has joined me with http://drupal.org/project/bean and sun and I are talking about how not to duplicate efforts.

I'm afraid the fieldable

pp's picture

I'm afraid the fieldable contact forms is the webform modul. :)
I made a mini modul, just for fun (practice to my workshop), the contact entity. You can order the contact forms elements whit it.



Gábor Hojtsy's picture

Yeah, fieldable contact forms is like webform. It could still send email with an action :) I'd not say we should have webform in core (there are lot more to webform than just those fields), but I'd be happier with an extensible contact module compared to what we have there, do you agree?

What does it mean make

pp's picture

What does it mean make contact forms fieldable?

  1. Only orderable form elements (see my module)

  2. You can add fields to contact forms -> the fields modul makes table to each fields in the database, but you don't save any data, because you only send email. (if you would like to save data you use webform or implement webform functionality in the core -> webform in core :))

What will happen with the new fields?
a) add mail body and render with drupal_render and drupal_html_to_text.
b) add tokens, and replace the tokens in the body? (webform in core)


storage and/or rendering in email

Gábor Hojtsy's picture

I think either storing them AND sending emails would be good or just sending them in emails. I think email sending would be a feature either way, so we'd need "display settings" for the fields on how they are rendered in email (eg. whether the label will be printed).

fieldable = FALSE

andypost's picture

Having the same api for core objects is a good plan to unify CRUD and display. But don't forget that some entities are not fieldable so having hook_entity_info_alter() could lead to additional overhead on entire system. So I'm not sure about profit on this "unifying" ... maybe we need to introduce analog of hook_form_FORMID_alter() for entities?


Crell's picture

There are three basic types of thingie:

  • Content
  • Configuration
  • Logic

Entities should be used to represent Content... NOT configuration, NOT logic. The CMI initiative is working on the Configuration front, and looks like it will be able to produce a common standard for Configuration objects. The WSCCI initiative is working on logic objects (Plugins).

These are three separate things, and we should not conflate them.

That of course begs the content vs. configuration question, which in some cases is easy (server configuration is not content by any means, while a blog post absolutely is) and other cases not so much (nodequeues are the common example here, although currently leaning to configuration). Part of the solution is to realize that configuration can reference content without being content.

I should probably stop here and just blog this... :-)

Node links

sk33lz's picture

Great question. I believe node links would fit into the content thingies group. I am not sure if these can be entities, but I find that node links are one of the more non-configurable pieces of content in Drupal out of the box. In most cases a custom module, custom theming, or some sort of contrib module is required to modify anything.

Modifying, moving around, and adding custom elements to the node links such as Read more, Comments links, and other node links provided by modules should be easy to do I think without needing to know PHP. One may just want to put a custom link in the node links area that isn't being provided by any module, or having to write a custom module. I just built a site in D7 for a client and the node links were no easier to work with than in D6 in my book. Perhaps making them entities in D8 would solve this problem and make them much more configurable without having to build a custom module or anything like that.

I will think some more and post anything else I can think of :)