April 2007 Archives

I've been going through the list of tables on my Drupal site in prep to convert an existing single-site to a multi-site with a shared database. However, I haven't found any reference that illuminates the general purpose of the tables. I've tried to put together at least a preliminary list here. I share it in hopes that someone else might find it useful, but it is not normative or complete.

access

User. This is the table used by the "Access Rules" section for banning usernames, IPs, etc.

accesslog

Statistics. This stores the accesslog if Drupal is collecting statistics.

aggregator_category

Aggregator. Store the categories feeds may belong to.

aggregator_category_feed

Aggregator. Links feeds to categories.

aggregator_category_item

Aggregator. Links feed items to categories.

aggregator_feed

Aggregator. Store the feeds that the Aggregator module pulls from.

aggregator_item

Aggregator. Store the items that the Aggregator module has pulled for the various configured feeds.

authmap

User. This stores a map to the authentication module used to authentication each user in the database.

blocks

Block. This stores information about blocks provided by every module installed, including custom blocks.

blocks_role

Block. Stores the roles permitted to view blocks in the system.

boxes

Block. Administrator created blocks.

cache

System. The general cache of data, used by many modules.

cache_filter

System. I have no idea what this table is used for.

cache_menu

System. I have no idea what this table is used for.

cache_page

System. I have no idea what this table is used for.

cache_views

Views. Used to cache information related to views.

client

Drupal. Used to record Drupal client sites. I believe this is the list of sites that others have logged in from if you use the Drupal module.

client_system

Drupal. I'm not exactly certain what this table is for.

comments

Comment. Stores all comments made on your Drupal site.

contact

Contact. Stores the emails sent via a contact form.

files

Upload. Stores information about files uploaded via the file upload module (and used by some other modules too).

file_revisions

Upload. Associated file revisions with node revisions allowing different node revisions to have different versions of a file associated with them.

filters

Filter. Stores information about the body content filters used in your install.

filter_formats

Filter. Associates filter formats and settings with a body content filter.

flood

Watchdog. Used to detect floods from requests coming from a set.

forum

Forum. Used to link forum posts with the forum topic.

history

Node. Used to track which nodes are read/unread.

locales_meta

Locale. Something to do with language translation.

locales_source

Locale. Something to do with language translation.

locales_target

Locale. Something to do with language translation.

menu

Menu. Storage of menu module customizations.

node

Node. The main table for storing general node information, including the title, node number, dates, workflow state, but it does not store most of the actual content.

node_access

Node. Storage of per-node access permissions.

node_comment_statistics

Comment. Notes certain statistics related to the number of comments and how recently comments have been made on a node.

node_counter

Statistics. Records the view count for each node.

node_revisions

Node. Stores information about node revisions, including the main content of the node.

node_type

Node. Stores information about the custom node types.

permission

User. Stores the permissions that have been assigned to each role.

poll

Poll. Extra information associated with poll nodes.

poll_choices

Poll. Associates the available choices with a poll node.

poll_votes

Poll. Votes by visitors on a poll node.

profile_fields

Profile. Definitions of available profile fields.

profile_values

Profile. Profile field values associated with a particular user.

role

User. Assigns role IDs and names to all the roles in the system.

search_dataset

Search. Something to do with search.

search_index

Search. The search index.

search_total

Search. The number of times a given word appears on the site.

sequences

System. The current counter for each of the sequence IDs.

sessions

User. User session tracking data stored in the database.

system

System. Information about installed modules.

term_access

Taxonomy Access Control. Access control per category.

term_access_defaults

Taxonomy Access Control. Access control per vocabulary.

term_data

Taxonomy. Definition of taxonomy terms.

term_hierarchy

Taxonomy. List of parent terms for each taxonomy term.

term_node

Taxonomy. Table linking taxonomy terms to nodes.

term_relation

Taxonomy. Relationships between taxonomy terms.

term_synonym

Taxonomy. Alternative names for a taxonomy term.

tinymce_role

TinyMCE WYSIWYG Editor. Roles assigned to use TinyMCE profiles.

tinymce_settings

TinyMCE WYSIWYG Editor. Definition of TinyMCE profiles.

url_alias

Path. Path aliases recorded to nodes.

users

User. User records.

users_roles

User. Link table between users and roles.

variable

System. Administrative settings and other site-wide variables.

view_argument

Views. Definition of arguments to a view.

view_exposed_filter

Views. Definition of exposed filters in a view.

view_filter

Views. Definition of filters in a view.

view_sort

Views. Definition of sorting in a view.

view_tablefield

Views. Something to do with the views plugin.

view_view

Views. Basic information about a view.

vocabulary

Taxonomy. Definition of taxonomy vocabularies.

vocabulary_node_types

Taxonomy. Associates vocabularies with node types.

watchdog

Watchdog. Records watchdog log entries.

Drupal
is by far my favorite CMS, despite the PHP (or poohp as I tend to pronounce it). One of the places Drupal is strong is organization, as long as you want to organize everything in a web. It does provide hierarchies and has breadcrumbs, but these are where Drupal begins to show weakness. In this articles, I'm going to explore how Drupal organizes itself and how you can take advantage of that organization out of the box, or with some module help, or by custom hacking. It's a summary of the research I've been doing on the topic.

Organization

Organization of content in Drupal, as shipped, primarily operates in these ways:

• Follow that term. You click on a post in a list and see a list of categories (formally "terms" in Drupalese) associated with the post. You click on one of those and you can see all the other posts on the site that are like that one.
• Order from the menu. You can assign a page to one or more menus, which are just hierarchical lists of links. If a menu item on the screen matches what you're looking for, clicking on it will take you to the node, term page, a list, or whatever the link points to.
• By the book. Pages can be arranged in ordered hierarchies, like books. If you look at a page in one of these organizations, you can click on the sub-pages or go to the previous page or the next page or up to the next level from any page here.
• Follow that forum. Forums are really glorified category terms.

That's it. Those are all the organization options you have built-in.

Caveat Emptor

However, there are some inherent gotchas that newbies aren't always aware of. The first is that the breadcrumb is pretty weak in Drupal without some help. This usually reveals itself in a scenario like this (this is approximately how I ran into it). A newby downloads and installs Drupal, logs in as administrator, and goes to create his first vocabulary (a custom system of categories). He creates a hierarchy and adds a bunch of terms. He finishes and adds a test node that has one of the category terms set that has two or three parents. Let's say, "Food > Fruit > Citrus > Orange". However, rather than seeing a breadcrumb on the node view that reads "Home > Food > Fruit > Citrus > Orange", he just sees "Home". If he's like me, he's confused but just assumes he did something wrong. He tries clicking on the "Orange" term to see the breadcrumb there. The breadcrumb turns out to be exactly as expected, "Home > Food > Fruit > Citrus". That means if someone gets that term and clicks on the test node, the breadcrumb that should, intuitively, expand one level deeper completely evaporates.

The problem is that this is a misunderstanding of the purpose of the taxonomy system. The taxonomy system does not provide any structure for the nodes. It provides some structure for itself, but the nodes themselves still belong at the top. It's a completely flat structure. Structure is provided to nodes in Drupal core in one of two ways: the Book module and the Menu module. Which way is appropriate for your site will depend on your needs. Also, neither of these may be satisfactory, but we'll get to that in a bit.

Book Solution

The first mechanism provided by Drupal is the book module. This module allows any node to have a parent. To use the book module, you must first enable the module, configure the permissions, and then create a Book page. The first Book page will be at the "Top Level" meaning it starts a new "book". You can then create additional nodes that are in the tree. The top must always be a Book page node type, but the rest can be any node type you like, but you have to go through the extra step of configuring the node via the Outline tab after your create it. Update April 21 @ 7:28pm: I just realized this is an error. I forgot about the Outline tab. You can make any page the root of a book via the Outline tab. (Book pages automatically have the "Parent" option configured on their create form.)

If you look a the breadcrumbs of Book pages, they operate exactly as expected. Each breadcrumb is created by traversing the list of parents until it gets to the top level and then adds "Home" in front of everything. The book module can also provide a hierarchical list of pages that looks like a typical Drupal menu as well via the Book block that comes with the Book module.

This is, by far, the most common sense method for hierarchically organizing your site's content. However, if you need special content other than the book pages you have an extra step to make it work. If you need to organize non-node content (special forms or something) the Book module may not be any help at all. Also, a single node can't belong to multiple books. A node may only have 0 or 1 parents in a simple hierarchy.

Menu Solution

An even more flexible solution is through the Menu module. The Menu module allows you to create Menus, which are hierarchical lists of links (it allows you to manipulate the built-in menu items as well, but that's another topic). These links may be to nodes, terms, or anything else on the local site that has a URL. They may also be absolute links to get to locations on other web sites. Each menu item has exactly one parent, but since you're only creating links, you could have a single node or other item linked in as many different menus as you need.

Furthermore, creating a hierarchical menu also tweaks the breadcrumb. If you have a node that would otherwise appear at the top level (i.e., it doesn't belong to a book), the first menu it is listed in will be used to create a breadcrumb for that node. Therefore, if you had a taxonomy structure with a matching menu, you could fix the problem of having your node appear without a breadcrumb.

Unfortunately, this too comes at a certain cost. You must maintain the menu structure manually. You have to add each node as it goes. If you have a taxonomy structure to mimic, you have to do double duty on your data entry and then make sure your menus point to each new node you create.

Setting up the menu while creating a node is pretty easy for an administrator. Anyone with permission to administer the menus can setup the menu for a new node via the "Menu settings" box on the create page. However, if you want authors to be able to do this without being able to tweak the entire menu structure, you're out of luck. You either grant someone the right to manipulate everything or nothing, which isn't acceptable in many situations with more than a few authors.

You can address this issue by looking into the Menu Subtree Permissions
module. This allows you to grant edit access on parts of menus to certain roles.

Add-ons

There are many, many add-on solutions for handling this. I'm going to give my favorite choices and then list the others I've found. This is not a complete list, but it does highlight the modules I've examined a bit in my search for a solution.

Taxonomy Menu

A solution that uses the combined power of taxonomy and menu is available in the Taxonomy Menu
module. This module creates a menu item for each taxonomy term in the system. This automatically gives you both downward navigation through menu items and upward navigation through breadcrumbs. This isn't quite as good as the navigation provided by the book module, but with intelligent use of the sticky flag or manual items, you can come relatively close.

Add on Custom Breadcrumb

Another way of handling the breadcrumb is via the Custom Breadcrumb
module. This module allows you to associate a breadcrumb with a node based upon it's node type. For example, if you have event nodes that always needed to appear in "Home > News > Calendar > Events," then you can use the Custom Breadcrumb module to do this. If you need a more variable structure than this, then Custom Breadcrumb still doesn't do it.

Others

Here are some other add-on modules that you may wish to consider:

• Taxonomy Bradcrumb
  . This module provides half the abilities of the Taxonomy Menu in tweaking the breadcrumb. It does not, however, provide any way to navigate down to the items in the tree, just the parents on the way back up.
• Category
  . For the daring, there's also the Category
  module which provides a complete replacement system for the core Taxonomy module, Book module, and provides a special menu module for creating menu items automatically on the creation of nodes. However, this is a big module with lots of options and I've back off from using it because it's almost too powerful to figure out how to use it most effectively. I've had some trouble getting it to work really well.
• Pathauto
  . This module doesn't actually help you organize your site, but it can makes your URLs match your breadcrumb organization structure. I highly recommend this module to make your URLs pretty. However, be aware that the URL aliases can quickly clutter the URL Alias page if you have a lot of pages.

• Theme Hacks

  If you do a search on the Drupal site for "breadcrumb" you will come across several hacks to the theme. All of which are customizations that make use of drupal_set_breadcrumb()
. You pass that function an array of links and it will give that array of links to the page template. This is the ultimate solution if no other will work for you.

  However, again, this still only gives you the upward navigation. It doesn't provide any kind of downward navigational structure.

  Conclusion

  Drupal does provide ways for organizing your content, but some of the out-of-the-box methods may not be ideally suited for your situation. Drupal comes out of the box with excellent support for web-like and river-of-news style organization. Hierarchies are quite possible and can be managed, but the structures provided for such assume a relatively light amount of hierarchical information. However, by using a few modules and the taxonomy structure, you can create very flexible and functional hierarchies to suit any site structure.

I was scrolling through my morning feeds and came across this gem on Slashdot, "Should Schools Block Sites Like Wikipedia?
" The story goes on to describe someone's question regarding the fact that the local school board decided to block access to Wikipedia "because students may be exposed to misinformation". This simply describes an opportunity lost and a new form of book banning.

I grew up learning about how books like the Wizard of Oz were banned from schools because some people didn't like the fact that it had a witch. Other books were banned because they praised opposing political ideals. Now, apparently, it's vogue to ban something because it might not be accurate. However, this is still just as bad an idea as all the original book bans.

Where do you stop? The New York Times has in the past few years had at least one reporter fired because he fabricated information published in the Times. Should we block the New York Times because it might expose students to misinformation? Should we also block cable television because certain news anchors published stories in that medium without verifying the facts? Should we start blocking the text books because they sometimes contain errors or misrepresent facts?

Should we stop allowing teachers in the class room because sometimes teachers share incorrect informatino? I once had a teacher tell me that NASA was experimenting with mounting monkeys heads on robots and that the monkeys were controlling the robots successfully, but only for a few hours until the head died. Should we throw all the teachers out because there are some that are crackpots?

No! Of course not. This is an opportunity to explain that all sources are suspect until they are corroborated. If you read something in Wikipedia, you take a note to check any fact you can't verify from your own experience. You then verify that fact in the quoted source (for articles that properly quote sources), you can check your local library and do a database search, check another encyclopedia, look in a journal or magazine, find related books, etc. I find that Wikipedia is a great place to get started, but I certainly don't think of it as authoritative.

On the other hand, you should always do the same thing, insofar as you are able, for any source of information. If a source of information makes a claim, you should check it's sources and possibly verify the claim in other places. It's easy to make an unverified claim. It's hard to make a claim that is cited and backed up with facts and also backed up by other unrelated sources.

The lesson is that some sources are more trustworthy than others, but none are beyond suspicion. The lesson should be that you should always check your sources and verify that what you're reading is factual and reliable. Banning a source only means that you take this object lesson away and you raise students that are actually less able to think for themselves and more ignorant. Great, that's just what we need. Good job Anonymous School Board.

Cheers.