Drupal

Drupal Installation

Drupal was chosen as the WolfTech CMS of choice because of how well it works and installs in the EOS Environment. A Drupal installation guide for EOS servers can be found here.

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.

Exhibit

Could be very nice for alumni information, grad applicants, etc...

Drush

command line shell for Drupal --- may be a way to manage updates, patching, turning on/off modules across multiple sites.

[10:32] <djgreen> excellent... I was able to use drush on CHRONOS to run a drupal 5.6 cron...
[10:33] <djgreen> complains alot, but appears to work.
[10:46] <djgreen> did not handle the module updates correctly though.
[10:47] <djgreen> seems to have updated the db, but not the files, which makes sense, but now drupal thinks its using the newst version.

Poormanscron

A module which runs the Drupal cron operations without needing the cron application. For every page view, this module checks to see if the last cron run was more than 1 hour ago (this period is configurable). If so, the cron hooks are executed, and Drupal is happy. These cron hooks fire after all HTML is returned to the browser, so the user who kicks off the cron jobs should not notice any delay. http://drupal.org/project/poormanscron

Service Links

The service links module enables admins to add links to a number of social bookmarking sites, blog search sites etc. Includes sites are del.icio.us, Digg, Reddit, ma.gnolia.com, Newsvine, Furl, Google, Yahoo, Technorati and IceRocket. http://drupal.org/node/40790

XML Sitemap

XML Sitemap automatically creates a site map that conforms to the sitemaps.org specification. This helps search engines (esp Google) keep their search results up to date. http://drupal.org/project/xmlsitemap

Windows Live Writer BlogAPI

http://www.tributemedia.com/drupal_community/modules/windows_live_writer_module_windows_live_writer_blogapi

DHTML Menu

This module will alter the way your menu based navigational blocks are treated so that they are loaded fully ahead of time and then jQuery open and closed when the user clicks on parent menu items. This not only saves a lot of time in page loads but looks more visually appealing. http://drupal.org/project/dhtml_menu

Admin Menu: The module renders all administrative menu items below 'administer' in a clean, attractive and purely CSS-based menu at the top of your website. It contains not only regular menu items - local tasks are also included, giving you extremely fast access to any administrative resource and function your Drupal installation provides. http://drupal.org/project/admin_menu

External Links

External Links is a small module used to differentiate between internal and external links. Using jQuery, it will find all external links on a page and add a small icon indicating it will take you offsite. You may optionally make all external links open in a new window. http://drupal.org/project/extlink

Modified Modules

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

color.module

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
• http://www.freedm.ncsu.edu
• http://www.atec.ncsu.edu
• http://www.spec.ncsu.edu

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

Rollout

MyECE

• Internal network of sites to address multiple audiences within the ECE Community
• Content provided by and maintained by those who service these communities.
• Easy interfaces.
• Entirely web-based.
• Extensible – the type of content you be able to provide will expand over time.
• Will publically launch alongside the new ECE website.

Initial Sites

• General Administration
  • Content Admins: Britt, Beatty, Santoro, T. Johnson
• Sponsored Research
  • Content Admins: Kirk, Albright
• Graduate
  • Content Admins: Lunardi, Hardin, M. Johnson
• Undergraduate*
  • Content Admins: Townsend, Sharpe

Sites down the road…

• Alumni
• Corporate Relations
• Information Technology

Barrier 1: Authentication / Logins

• All NCSUers will use WRAP logins. Non-NCSUers are still on the to-do list.
• You won’t have to remember ANOTHER username and password.
• After authentication, you’ll auto-login to the intranet.

Stage 1

• Pages
  • Regular HTML pages
• Books
  • Pages w/ a hierarchy and auto index
  • Policies, procedures, guides, manuals, job duties, etc.
• Links

We’ll be able to secure these so only you (internal groups) can see some of them. Job Duties for example.

Barrier 2: File Management

• File uploads are quite working.
• Need to make them more reliable / easier to use.

Stage 2 (couple weeks from now)

• Categories
  • Used to display/search types of content
    • Announcements for example

• File Uploads
• Dates / Event Calendars
• News / Announcements
• Frequently Asked Questions

Barrier 3: Account Provisioning

• Need to be able to auto create and maintain:
  • ECE Staff
  • ECE Faculty
  • ECE IT
  • ECE Graduate Student
  • ECE Undergraduate Student
  • …

Stage 3: User interactions/contributions

Now we have the option to start encouraging interactions with our communities…

• Comments
• Forums
• Ask a question…
• Expanding who can contribute content…
• Workflows can now be investigated (forms, etc)

Barrier 4: Groups

• Grouping of accounts into “private” areas.
  • Private forums?
  • Private files?
  • Private homepage?
  • Private events/calendars?
• Potential usages:
  • Committees
  • Advisory Board?
  • Grants/Accounts?

Barrier 5: External Data

• Need to look at methods to import external NCSU data sources:
  • Facilities
  • Finance
  • Contracts and Grants
  • Alumni Records
  • CAMS
  • …

Barrier 6: Time and Experience

• Need time to research and learn new technology.
• Need time to experiment.
• Need time to develop and create.

• NEW FEATURES will be added to the Intranet sites as we are able to implement them.

• These sites will be developing, updating, and expanding for a long time…