How Drupal 7 Fields are changing the way you write modules

Printer-friendly versionPrinter-friendly version

(notes on a session at DrupalCon 2010)

  • from columns to fields
    • in D6, adding data to a node (with a module) required adding a table and implementing hook_nodeapi() to fetch and store data
    • in D7, just add a field and let Drupal handle all the I/O.
    • fields are reusable, can be added to any entity, shared between entities.
    • a field has a schema (how to store, hook_field_schema), a widget (how to edit, hook_widget_info), a formatter (how to display, hook_field_formatter), and settings (global or per instance, hook_field_info)
  • from nodes, users, comments, & taxonomy terms to entities
    • entities are the new nodes: high-level objects that can receive fields, revisions, bundles (sub-types), a URI, and various build modes.
    • entity API: hook_entity_info, hook_entity_load/insert/update, entity_load -- saving and deleting are still entity-specific
    • Entity module provides missing save & delete functions and may become indispensible.
  • hands-on: a case tracker in 100 lines
    • don't need comment_upload anymore, because files can be attached to comments
    • assign the same field to both node type and its comments
    • write a few hooks to assign the parent node's field value to the comments by default, and to change the node's value to match the comment's when it's submitted.
  • rethinking modules in D7
    • why? D7 is a new milestone
    • after a straight port, we will need to rethink the modules to take advantage of new concepts
    • extend existing entities with fields before creating new entities
    • don't use nodes for anything that isn't content - that's when to create your own entities
    • always use Views for displaying entities - don't create your own query & display platform