Last updated February 1, 2014. Created on June 4, 2008.
Edited by igorski, Verscienta, Marty2081, fgm. Log in to edit this page.

Choosing between glossary-type modules

There are several glossary-type modules available, all of which are designed for slightly different needs. This page is here to help you choose which module you should probably be using, or if you should really write your own.

Feature Glossary G2 Glossify Lexicon
Drupal 7.x -dev -dev -beta Yes
Drupal 6.x Yes Yes -beta Yes
Drupal 5.x Yes Yes* No
Drupal 4.7.x -dev Yes No
Drupal 4.6.x -dev No No
Documentation Handbook
external to DO
AJAX No Entry selector No
Architecture term-based node-based term&node-based term-based
Services provided
Multiple glossaries on one site Yes No Yes
RSS feeds on entries Yes, Drupal core No Yes, Drupal core
RSS feeds on additional vocabularies No Yes, Drupal core No
Classify entries using taxonomy No Yes, Drupal core No
Commenting on entries No Yes, Drupal core No
Private editorial information No Yes No
Feature blocks Search glossary
Random / Term of the Day
word of the day
Random term block
XML-RPC services provided No alphabar
word of the day
Security Drupal core Drupal core
XML-RPC access control
XML-RPC throttling
Drupal core
Alphabar maintenance automatic manual automatic
Content filtering automatic dfn elements automatic
Memory needs/number of entries proportional constant proportional
Speed on small glossaries faster slower faster
Speed on large glossaries slower with size remains constant slower with size
Themeability search form
node overview
Drupal core node themeing
Independent themeing for all 5 feature blocks
Independent themeing for all parts of a term definition
overridable tpl files for all output
Translation template supplied Yes No No

* G2's support for 5.x is intended as a bridge from 4.7 to 6.x.

Obviously, in all cases, a "No" actually means: "roll your own", as in all Open Source software.

Rationale for G2 specificities

G2 is not intended as a direct replacement for the glossary module already available with Drupal for quite some time now.

A more detailed comparison for choosing a glossary-type module can be found at audean.

  • Optimization for large glossaries: this is the need expressed by OSInet, which funded development, to support its 5000+ term glossary of computing, for which glossary.module, even when coupled with flexinode to bind blob content to terms, is not really efficient enough.
  • Single glossary: multiple glossaries were not necessary to the initial sponsor
  • Explicit linking to terms with dfn elements:
    • limits system workload
    • allows invisible marking of entries made of other entries. Think: XML-RPC, points to XML and to RPC with glossary.module and various wiki filters, but can point to "XML-RPC" with G2. Wrapping XML-RPC in quotes is necessary to allow linking to this entry in glossary, but the quotes remain visible, degrading the UI.
    • allows redactor-level choice of:
      • whether to link to an entry: Glossary typically links if the term matches, which is not always meaningful ("and" can be present in a glossary and you don't want "and" to be linked from in all nodes on the site).
      • where to link to an entry: glossary allows only a predefined set of positions (first, last or all matches).
  • nodes vs terms: this is the most salient difference.
    • Using custom node types in G2 allows large definitions, with the complete Drupal feature set for nodes.
    • Using terms (glossary.module) allows definitions to be bound to custom nodes instead of being nodes on their own.
  • Alphabar maintenance: large glossaries will, most of the time, use all available initials, so the processing cost of maintaining it is not justifiable.

Glossary Design

  • Customizable
    • Administrator options.
      • Glossary display.
      • Alphabet / Alphabar.
      • Input Formats.
        • Indicator style.
        • Link type.
        • Choice of HTML elements.
        • Term matching flexibility.
    • Liberal CSS usage.
    • Multiple glossaries.
    • Add-on modules.
  • Taxonomy options.
    • Related terms link to each other.
    • Synonyms will filter the same.
  • Drupal filter. Cacheable.
  • Translation template provided.

The Glossary module has largely been designed by its users. Many, if not most, of its features have been added and refined by the input of the community. It is actively maintained and there have been performance efforts to make sure it runs as fast as possible. Considerable work has been done to make sure that i18n (internationalization) can be effectively used with Glossary.

Glossary uses Taxonomy to define its terms. While most sites have a smaller glossary than the one G2 was designed for, there are also sites with larger glossaries. The ability to handle multiple vocabularies as glossaries gives Glossary additional flexibility.

The Glossary module acts as a Drupal filter, locating terms within administrator-selectable content and adding additional HTML to them to show or (optionally) link the term's definition to the end-user as they view the content. The terms may be marked with a superscript or icon that links to the term or the term may be converted to an "acronym," "abbr," "cite," or "dfn" element with browser help tips. If the Hovertips and Clicktips module is installed, it may be used to provide hovertips. There are also three mechanisms for marking a section of the content to not be filtered. Matching of terms may be selected as whole words or substrings, and may be either case-sensitive or not.

Since Glossary filters content, the first time a piece of content is shown, there will be a small delay while the filtering is done. The filtered content is then cached, so the next time, the filtering is unnecessary and the delay does not occur.

When a user clicks on a linked term, they will go to the entire glossary or the individual term, depending on which option the administrator chose. When displaying the entire glossary, there is an alphabar on top, which fills in automatically. The administrator may define his/her own alphabet for those who use some language other than English. The terms are then organized by the first letter of the term's name. Each section may be separated by a CSS-themable separator. At the bottom of the display, if the user has the appropriate permissions, are shortcut links to the vocabulary and module settings pages.

Within the glossary display, each term may be followed by a link that will initiate a search for the term, if the search module is enabled. For those who have the proper permission, there will also be a link to edit the term itself.

The type of glossary indicator that is used is specified for each input format, so, for example, "Filtered HTML" may use a superscript type of indicator, while "Full HTML" may use a hovertip. Additionally, each input format also selects which vocabularies are to be used. So one may, again for example, specify that "Filtered HTML" filter for Bible verses, while "Full HTML" filters for technical terms.

Since Glossary is taxonomy-based, that opens the range of taxonomy-based modules to work together. For example, Taxonomy Image may be used to show images for the terms and Taxonomy Delegate may be used to delegate vocabulary maintenance to sub-administrators or editors.


The Lexicon module started out as a fork of the Glossary module for Drupal 6.x improving the output to be XHTML strict compliant for use in a project for the Dutch government. Soon after the release of Drupal 7.0 a 7.x version of the module was released and has been improved since then.


Looking for support? Visit the forums, or join #drupal-support in IRC.