[coming- this is a repeat of what is in the chapter to start out]

Drupal Entities: Common Structure Behind Site Components

Drupal 7 introduced the concept of entities to standardize its treatment of essential data objects. Users, nodes, comments, taxonomy vocabularies, taxonomy terms, and files – these are all entities in Drupal 7 core. Contributed modules can register additional entity types by implementing hook_entity_info(); this will be covered in Chapter 20.
Nodes, the main content object on Drupal sites, are the prototypical entity; the creation of the entities concept in Drupal 7 had a lot to do with making the other core objects act more like nodes. In particular, the introduction of Fields in Drupal core made it seem necessary to give non-node objects something analogous to content types (also called node types). In Drupal 6, the Content Construction Kit project (drupal.org/project/cck) and related modules made it possible to add fields (text fields, number fields, e-mail address fields, file fields, image fields, etc.) to content types. Every content type represented a set of fields. In Drupal 7, any entity can have fields (if its entity type definition declares it a "fieldable entity") but it was still desired for one entity type to be able to have different sets of fields. The word bundle was forcibly conscripted into service in Drupal to describe this generic sense of "thing with fields," the analog of content type for non-node entities.
Note Entities introduce the concept of bundle and content types are examples of bundles. That is to say, a content type is a bundle, the most common bundle we are likely to deal with in Drupal 7.
We can get information about every bundle on a Drupal site with a function named field_info_bundles(). While figuring out what to display and how to display it on the Structures administration page, we can print the output of this and other functions or variables with the debug() function. (We can also, of course, use a debugger; see chapter 11.)
n Tip Drupal 7 introduces a debug() function, which is a great convenience when developing (or, naturally, debugging). To use it we can put any variable or output-generating function as the first parameter, optionally followed by a label to help us keep straight multiple uses of debug(). For instance, debug($user, 'User object'); prints the contents of the $user variable, which in most places in Drupal is an object representing the currently logged-in user.
Back in the section on switch statements we gave our module a set of help calls for each of the major administration sections— but we had these calls go to empty functions. Let's put something in _xray_help_admin_structure(). Sticking a function that provides output, like field_info_bundles(), in a debug will print that output.
Listing 16.56. Debug printing of entity information from a stub function in X-ray module.

The output is a wealth of information about the entities. It would take 11 pages if placed in this book, so please look at your own output (or refer to dgd7.org/151) for the full result. This is an excessively large array, but expect to get used to huge nested arrays when developing with Drupal.
From this entity and bundle information, output by the function field_info_bundles(), we learn there are six types of entities on our site already in a typical install. These entities are comment, node, file, taxonomy_term, taxonomy_vocabulary, and user. Each entity type is further divided into at least one bundle. The file entity type, for instance, defines only the file bundle, while the comment entity type has bundles for every content type comments attach to.
Gotcha The node type is not stored in the comment table, it's only available in the comment entity— and so through a function such as field_info_bundles(). Do not expect all bundle information to be easily found in the database!
We can use field_info_bundles() to to provide a listing of all entities and bundles with X-ray.