How to Make Entities and Influence Drupal - Emerging Patterns from Drupal Contrib


Published on

Drupal 7 introduced Entities as the main unit of data alongside an API to manipulate entities. This is changing the way we can develop Drupal-based applications. The aim of this presentation is to identify emerging patterns of usage to inform further refinement and development and support the spread of best practices for development.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

How to Make Entities and Influence Drupal - Emerging Patterns from Drupal Contrib

  1. 1. Making Entities and Influencing Drupal emerging patterns from contribTuesday, February 8, 2011
  2. 2. Ronald Ashri @ronald_istos, February 8, 2011
  3. 3. itinerary • from nodes to entities • brief explanation of what entities are • Patterns of usage • Drupal Commerce • Organic Groups • Media • Cool stuff to watch out for • Discussion / Questions • Beer!Tuesday, February 8, 2011
  4. 4. nodes are great love drupal = love nodesTuesday, February 8, 2011
  5. 5. we love nodes because everything drupal does it does it around nodes - so you get lots of stuff for free oh, and node is a cool sounding geeky word that can mean anything you want it toTuesday, February 8, 2011
  6. 6. secretly we all dream(ed) of turning everything into nodes ...and almost did...Tuesday, February 8, 2011
  7. 7. user profiles =, February 8, 2011
  8. 8. taxonomy =, February 8, 2011
  9. 9. comments =, February 8, 2011
  10. 10. Entities in Drupal 7 are the nodes we really wanted but didn’t know it yetTuesday, February 8, 2011
  11. 11. Entities is the stuff that makes up our site nodes, users, taxonomy terms, commentsTuesday, February 8, 2011
  12. 12. Entities were born out of the need to streamline operation for: “loadable thingies, that can be optionally fieldable” (, February 8, 2011
  13. 13. The relationships between Entities - the ways entities can interact with each other - define our Drupal application nodes can have comments users create nodes taxonomy terms are attached to nodes these relationships are implicit - perhaps they could be made explicit?Tuesday, February 8, 2011
  14. 14. ok - so core does nodes, users, taxonomy and comments (still some way to go to a perfectly consistent implementation)Tuesday, February 8, 2011
  15. 15. Drupal 7 allows you to create your own entities your own loadable thingies with optional fields!Tuesday, February 8, 2011
  16. 16. But how to use these loadable thingies?Tuesday, February 8, 2011
  17. 17. Emerging Patterns of Usage The are many possible ways to employ entities to solve various problems - this is a first step at trying to identify some specific patterns that we can reuse across application domains We identify emerging patterns by looking at how entities are currently used in Drupal ContribTuesday, February 8, 2011
  18. 18. Drupal Commerce Extending Drupal by adding domain specific conceptsTuesday, February 8, 2011
  19. 19. in order to add commerce capabilities we need to introduce a whole set of concepts (and their supporting data types) in D6 this was done almost entirely “outside” of Drupal except Product which were nodes (which was a good fit but not ideal)Tuesday, February 8, 2011
  20. 20. Drupal Commerce defines Customer Profiles Lines Items Orders Payment Transactions Products as entitiesTuesday, February 8, 2011
  21. 21. Drupal Commerce defines as much as it needs in terms of fields attached to these entities - allows the user add extra fields where it makes senseTuesday, February 8, 2011
  22. 22. use entities to introduce new data types that can be user-extensible provide minimum conf required ps: you really, really, really need a good reason not to use entities when introducing new data (and data tables) to DrupalTuesday, February 8, 2011
  23. 23. Organic Groups - Keep Basic Info and (possibly) use Entities as a configuration controllerTuesday, February 8, 2011
  24. 24. Organic Groups uses Entities because via the Entity API ( it gets CRUD, caching, etc for free Less to worry about! But also...Tuesday, February 8, 2011
  25. 25. Disconnect between the D6 way (node was a group) to: Group Entity holds reference to actual Node that represents the group separation of concerns opens up interesting possibilities and enables things that were not possible before like better internationalization supportTuesday, February 8, 2011
  26. 26. An organic group entity is fieldable so you could have...Tuesday, February 8, 2011
  27. 27. an organic group entity that controls another entity’s behavior as an organic group (munch on that for a bit)Tuesday, February 8, 2011
  28. 28. By adding fields to the Group entity that expose configuration options you allow the end user (site admin) to fine tune the behavior of specific group instancesTuesday, February 8, 2011
  29. 29. use Entities to separate concerns - using the Field API as a way to flexibly add access to configuration options Site builder can decide how much config to make available to Site AdminsTuesday, February 8, 2011
  30. 30. Media Module - Entifying existing dataTuesday, February 8, 2011
  31. 31. base table of the media module is file_managed file_managed is a “core” table entity key = fid file_managed modified in media.installTuesday, February 8, 2011
  32. 32. /** * DISCLAIMER: * Yes I am altering a core table. * No I am not on crack. * Basically, the problem were facing is the media "type" which is not the * mime type, but is probably computed from it. * * The file table has no type field. As a result, we would have to either: * * 1). Create a media_files table to join them. This is nice and clean, * however it requires keeping the tables in sync, and it also means we have * to write our own SQL instead of using BaseEntityController, and thats * kinda scary. * * 2). Make the media type a "computed" field. Wherein, everytime we loaded * a piece of media, we would need to compute its type from the mime-type. * This is unacceptable from a performance standpoint and also requires us * override the Controller in ways we probably dont want to. * * I know its a sin, but I think it is also excusable because: * * 1). This is hoping to be a core addition, so think of it as a core patch * that will eventually go in. * * 2). It is adding a new field, so it shouldnt cause any conflicts. If it * does that INSERT / SELECT code is badly written and should use complete * INSERTS or column names. */Tuesday, February 8, 2011
  33. 33. What is going on is data is brought into the Entity way of doing things. Something that could apply just as well to external data imported into your Drupal DBTuesday, February 8, 2011
  34. 34. Entify external data - fold it into Drupal and now you can add extra info via fieldsTuesday, February 8, 2011
  35. 35. Patterns 1. When you need to introduce new data types create entities that are configured as much as you require and can be extended by users 2. Use entities to separate concerns - enable expansion later on 3. When you need to provide multiple configuration options that can optionally be switched on and off use entities to allow the site builder to choose what configuration options are made available by adding or removing fields to a Controller entity 4. When you import external data and need to fold it into Drupal entify the data table and make it available to Field API and Entity functionalityTuesday, February 8, 2011
  36. 36. Cool Stuff to Look Out For: Entity API: This module extends the entity API of Drupal core in order to provide a unified way to deal with entities and their properties. Additionally, it provides an entity CRUD controller, which helps simplifying the creation of new entity types Relation: A relation denotes and describes the connection between two entities. A relation is fieldable Micro: Micro is a small, lightweight, fieldable entity that attaches to other entities.Tuesday, February 8, 2011
  37. 37. Thanks! t: @ronald_istos entitiesTuesday, February 8, 2011