Glossary: Auto-flag Terms in Content

Last updated on
3 May 2017

Drupal 7 will no longer be supported after January 5, 2025. Learn more and find resources for Drupal 7 sites

The Glossary module helps newbies understand the jargon which always crops up when specialists talk about a topic. Doctors discuss CBC and EKG and CCs. Web developers keep talking about CSS, P2P, XSLT, etc. This can all be intimidating for newbies.

The glossary module scans content for glossary terms (including synonyms). The glossary indicator is inserted after every found term, or the term itself is turned into an indicator, depending on the site settings. By hovering over the indicator, users will see the definition of that term displayed as a "tool tip." Clicking the indicator leads the user to that term presented within the whole glossary or directly to the detailed description of the term, if available.

The glossary uses Drupal's built in taxonomy feature, so you organize your terms in a Drupal vocabulary. This allows you to create hierarchical structures, synonyms, and relations. Glossary terms are represented with the taxonomy terms in the glossary vocabulary. Descriptions are used to provide a short explanation of the terms. You can attach nodes to the terms to provide detailed explanation on the keywords.

Some background

The working part of the Glossary module is an implementation of Drupal's filter mechanism. As such it is not the fastest feature on your site. To help speed it up, there is a separate cache ("cache_filter") to hold content that has already been processed so it need not be done each time that content is displayed.

The module will do its substitution on any node type that uses filters (which is most of them).

The Glossary module will invalidate the filter cache any time a taxonomy term is added to, deleted from, or changed in an associated vocabulary or a setting is changed that would affect the display. You may manually empty the cache_filter table any time you like. Just be aware that there will be a temporary performance impact until the cache is rebuilt. This will, obviously, be more noticeable on a slower server.

Where to Put Terms

The words that are to be flagged by the Glossary module are defined as terms within the "Glossary" vocabulary. You'll find this under "Administer » Content » Categories" (in Drupal 6, "Administer » Content » Taxonomy"). There you will see "Glossary" in the list of vocabularies. Next to it you will see a link to edit it.

You do not need to set up the vocabulary for any content types unless you want to use the "detailed description" (or "full node") method below. You do indicate if the vocabulary is hierarchical (usually not), has related terms, etc. [I recommend that "multi-select," "free-tagging," and "required" be left unselected.]

Usage note: If you choose a hierarchical vocabulary, be aware that the supplied CSS file only supports a depth of three (3) in the display. If your hierarchy is deeper, you should add additional formatting to deal with it.

Next you add terms to the vocabulary. You don't have to get them all at once; you can come back any time and add more.

There is no point in adding a term without a description - that's the whole point of the Glossary module.

Full Node or "Detailed" Descriptions

Glossary runs on a taxonomy vocabulary and its terms. That means that there is a "Glossary" vocabulary to be used on the node types for which you have it set. Hopefully one of those types is either "page" or "story."

This may be a little confusing at first: You should not assign these terms to the nodes that will have the glossary flagged. Those who have done so have noticed that clicking on the indicator takes them to a "taxonomy/term" page for that term - listing all such tagged content.

The only content that should be tagged with the actual glossary terms are the "full node" ("detailed") descriptions. That way clicking on the link takes you to that full-node description. I would assume that the vast majority of the time there will be only one node assigned with those terms.

Issues

As with all contributed modules, when considering submitting an issue:

  1. Read the documentation (two or three times is better).
  2. Review the existing issues list. (Don't forget to select "<all>" for the "Status" field.)
  3. Gather all the appropriate information. This may include (but is not limited to):
  • Drupal version.
  • Browser type and version.
  • Database type and version.
  • Error messages, if any.
  • Module settings.
  • Submit the issue. If other modules are involved, you may need to submit the issue to those modules as well.
Authors

Originally written by Moshe Weitzman. Much help from killes.

Modified extensively by Al Maw.

Many improvements by Gábor Hojtsy

More improvements by Frodo Looijaard

More improvements by Moshe Weitzman again. And so it goes around ...

Additional fixes and improvements by Nancy Wichmann

Help improve this page

Page status: No known problems

You can: