Skip to content Skip to navigation

Criteria for Adding New Modules to Stanford Sites

As a centrally-supported service, Stanford Sites is designed to have a robust yet limited set of modules available to site owners. This ensures the service can be tested and upgraded as needed. Though Stanford Sites does not accommodate the direct installation of modules by site owners, we welcome suggestions for module additions or changes; our goal is to ensure the service grows and adapts to the needs of our campus community.

When requests for new modules come in, either internal or external, we use the following criteria to evaluate those requests:

  • Actively maintained
  • Provides functionality that is not available otherwise
  • Widely useful
  • Does not conflict with other modules in the stack
  • Number of installs
  • Standing of lead maintainer in the Drupal world (core maintainer? etc.)
  • No major unresolved, or "won't fix" issues in the issue queue
  • Appropriately documented (so we can point to it in our user guide and training)
  • Size and complexity of module

We use these guidelines as a matrix rather than a checklist; if a module has a low install base but is relatively simple and provides critical functionality (e.g., backup_migrate_files), it may get added, but if a module duplicates existing functionality, conflicts with other modules, yet is written by a rockstar Drupal developer (e.g., Panels), it may not get added.

Questions and comments are welcome, and if you have a module to recommend for our consideration, please submit a HelpSU request.