Drupal

Default Modules

These modules are those modules which we activate on all of our sites across the board.

WRAP Authentication (custom)

Custom module created by WolfTech to allow the drupal system to recognize when and to auto login when someone has used WRAP authentication.

Masquarade

allows the site admins to troubleshoot permissions issues by "logging in as" another user.

Optional Modules

The following are optional modules which have been tested by us and are supported for use within our drupal sites.

Future Modules

These modules are ones that we're investigating and may support once we've had time to play with them.

User Badges

We could possibly use these to distinguish people on the sites when posting. Especially when we get into forums, commenting, etc. Think of "ECE Faculty", "ECE Staff", "ECE IT", "ECE Grad Student", "ECE Ugrad Student", etc.

Modified Modules

These modules require modification to run correctly on the engineering servers.

color.module

This module allows for the altering of the color theme of the site. The module was altered as follows:

STEP 1 - Replace (line 296-300):

  // Look for @import commands and insert the referenced stylesheets.
  $cwd = getcwd();
  chdir(drupal_get_path('theme', $theme));
  $style = preg_replace_callback('/@import\s*["\']([^"\']+)["\'];/', '_color_import_stylesheet', $style);
  chdir($cwd);

With:

  // Look for @import commands and insert the referenced stylesheets.
  $cwd = getcwd();
  //chdir(drupal_get_path('theme', $theme)); //WOLFTECH CHANGES MADE
  $style = preg_replace_callback('/@import\s*["\']([^"\']+)["\'];/', '_color_import_stylesheet', $style);
  //chdir($cwd); //WOLFTECH CHANGES MADE

STEP 2 - Replace (line 361-363):

function _color_import_stylesheet($matches) {
  return preg_replace('/url\(([\'"]?)(?![a-z]+:)/i', 'url(\1'. dirname($matches[1]) .'/', file_get_contents($matches[1]));
}

With:

function _color_import_stylesheet($matches) {
  return preg_replace('/url\(([\'"]?)(?![a-z]+:)/i', 'url(\1'. drupal_get_path('theme', $theme) . dirname($matches[1]) .'/', drupal_get_path('theme', $theme) . file_get_contents($matches[1])); //WOLFTECH CHANGES MADE
}

STEP 3 - Comment out all lines in the .htaccess file located in the [drupal_install_root]/files/ directory

Rejected Modules

Just for us to keep note/logs, here are those modules which we've looked at, but rejected. If we're smart, we've noted why the module was rejected.

Current Drupal Sites

• ECE Intranet -- General Administration
• ECE Intranet -- Sponsored Research
• ECE Intranet -- Graduate
• ECE Intranet -- Undergraduate
• WolfTech -- Drupal Development

Initial/Common Site Setups

Need to start listing this out, creating a recipe for our sites... here's a few in no particular order

• Turn on the Full HTML Input format as default. Will stop people from having problems with images and tables in their pages/articles.
• Configure your default content types to not promote to the frontpage -- though this probably isn't an issue if we're changing the frontpage. Need to check on that. Administer>>Content management>>Content types
• Administer>>Content management>>Comments>>Settings and set the comments to be entered on a "separate page" and make sure that "Preview comment" is set to "Required."
• Change the frontpage from "node" to a page of your choice -- or enable the "front_page" module to force the issue.
• Create initial roles -- site admin, faculty, staff, grad student, ugrad student, and the particular content admins for that site: "Grad Office", "Main Office", "Grants Manager", etc.
• Create an error page. Read http://drupal.org/node/120646

Development Plans

1. GuardDog Module -- in order to provision all of our accounts, we'll need to create a GuardDog module that (and we can look at the ldap groups module for ideas I believe) will allow us to detect and select GD groups, associate them with roles, and maintain user accounts... creation is one thing, but when we start looking at keeping content over time, or specifically in the case of students become alumni, we'll need to think about how we disable/delete accounts.
2. Drupal Mass Manager -- due to the fact that we'll be installing Drupals everywhere, and upon many different vhosts, we need ways to maintain the sites.
   1. If possible, we should look at ways of creating a single theme and module repository that all of the sites can either see, or that we somehow automatically maintain... not sure about this.
   2. Due to the fact that the one central location we have for everything (that we can always access) is our database server, we need to look at creating an application that allows us to automate/update/view site settings across the board...
      1. example usage -- http://drupal.org/node/134535