Implementation Documentation

What?

This module was built to provide an internal documentation component for Drupal sites. It provides a CRUD interface that can be used by administrative/technical users for documenting why they are implementing Drupal in the manner they are.

The module provides:

• A simple text box for each content type, module, taxonomy vocabulary, menu, theme, block, and user role that allows administrative users to create documentation
• Automated generation of information on content type usage, database structure, etc.
• A means of viewing this documentation and information in a report format will one day be able to be exported

Why?

As Drupal takes a framework approach to content management, it provides a number of ways to implement its features. This can lead to arguments over how to go about implementing specific functionality. For instance, as I lay out my site, should I code everything into templates, use Display Suite, or use Panels? If I want to create a network of affiliated content, should I use core multisite, Domain Access, or Organic Groups? After much research, decisions are made, and the site is implemented. Without documentation, the rationale behind these decisions can easily be lost over time, and future developers may end up scratching their heads, wondering why a specific module or content type exists on the site. Perhaps the original developer wanted to test out Openlayers vs. Google Maps, installed both modules, and forgot to remove the one not used. In any case, this module hopes to prevent that confusion.

While many elements within core Drupal provide "Description" boxes that can aid with this need, these are often used primarily for providing non-technical "hints" on how to use the site's Drupal implementation, not for why the site was implemented like it was in the first place. In addition, some site elements (user roles, modules) don't even provide even these description fields.

Who?

This module is being developed for a large organization with a Drupal implementation that was operating with over 100 modules, 20 content types, 50 menus, 15 user roles, and a plethora of other complexities. While the module has not even been tested yet, the process of developing it has helped the organization to begin to do an audit of their Drupal implementation. The hope is that this module will help to complete that audit, and will help other organizations like ours in the future.