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.
Blocks
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?
Comments
Not what but why?
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
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
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 :-)
Gerd
Only core?
This question is mainly about core -- right? Or should I think in wider circles?
core
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…
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
objectsenti…thingies you mention – contact forms and aggregator items – don't really make sense to me.What other candidates could be found?
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
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
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
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
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?
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
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
Except...
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 :)
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
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
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
So fabsor has joined me with http://drupal.org/project/bean and sun and I are talking about how not to duplicate efforts.
Neil Hastings
http://twitter.com/indytechcook
I'm afraid the fieldable
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.
http://drupal.org/sandbox/pp/1198648
tricky
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
What does it mean make contact forms fieldable?
Only orderable form elements (see my module)
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)
pp
storage and/or rendering in email
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
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?
Content
There are three basic types of thingie:
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
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 :)
http://arborwebdevelopment.com