Early Drupal strategies

I am leading an internal team to move the public-facing web site of our PS-12 independent school to Drupal. In this post, I share accomplishments and decisions made so far in an attempt to spread any knowledge that is useful to other institutions and gain your feedback. I consider myself an intermediate Drupal user, so some of the following may seem trivial to advanced users, whereas beginners may find it helpful as they get started. A test site is available for you to view. I have included module and content type lists at the end if you would like to jump directly to them. Many thanks in advance for any advice or feedback you may provide!

Page and News content types

We recently made the decision to give news more prominent billing than we do in our current site. We realized that news is more important than calendar information, for instance. At the same time, we will still require the ability to post descriptive content about school programs that doesn’t change all too often. First-time visitors to our school will still require this, and they are a very important audience. How could we provide for both within Drupal’s structure?

We want to have as many school departments and divisions manage their own site content. Therefore, adding pages to the Book hierarchy or adding News items to one or more sections needs to be as easy as possible. In Drupal 6, Book nodes can be of any content type. This will serve us later, though for the time being I am only adding Page nodes to Books. I did modify the Page content type to allow comments and add fields for multimedia content. I configured Book to automatically create menu items, as we don’t want to trouble our site editors around campus with navigating Drupal’s menu administration pages, which will get quite long in a large site.

landing page

I have included News content by embedding a manual PHP-driven database query in each top-level landing page. Users will click on a primary nav link and find a page with the category outline in the left-hand menu and the news for that section in the body of the page. News can be posted to multiple site sections (taxonomy terms), whereas Pages can only be posted to one place in the book hierarchy. Our web site editor was very pleased to see how easily we could move pages around the hierarchy, even from one book to another.

Will we want to post a single page to multiple books? I am not sure that this is desirable, since users may benefit from a predictable hierarchy (where is that page? what section am I in?). However, we may also find a way to configure this in Drupal, or we could write a script to pull content from the desired node when in a specific page. The ability to insert any node into a book is going to be a great boon if we need to create a custom content type with code to pull content from other nodes.

Book Access has been troublesome so far. I at first assumed that we would want to grant editing privileges at the book level, to those people who need to able to edit that book. However, not only has book access not worked as advertised, but I have also come to the realization that more open access may in fact better serve our purposes. We know and trust our web site editors, and time is precious. Why shouldn’t all users blessed as editors of our books be able to edit any of them? Some institutions have even wikified their entire site. We can mitigate (unlikely) problems by turning on revisions and setting actions to notify the web site editor when changes are made to the books. Presto.

Classroom and team pages

Organic Groups seems the obvious choice for classroom and team pages. Small communities build up around classrooms and teams at our school. Parents want to know news and upcoming dates, teachers and coaches want to contribute content, there are scores and reports to publish, and we want to expose most of this to the public for people to see our school in action.

Organic groups allows us to mark some content as public and some as private, maintain descriptive and news items, invite others into the group, and allow users to maintain short lists of their favorite groups in the site. I will want to further investigate how to set multiple moderators for a single group, suppress other groups from the audience list, and make subscription management easier.

Organic groups could also permit other affinity groups to spring up within the school around issues, initiatives, or interests. Again, it helps enormously that community features are core to the Drupal ecosystem. These features are well developed, well-documented, and widely used, making it easier for us to make our next web site more capable of community strengthening functions.


On our current site, the home page feature image is randomly selected from a set of photos. Each photo has as caption. I am experimenting with enhancing this feature by: 1) using a Flash-based slideshow to cycle through images on the home page; 2) linking each image to related pages within the site, so that it also serves as a navigational element. The test site currently uses MonoSlideshow, but Slideshow Pro also has a standalone version that pulls image information from a XML file and a Drupal module. I would like to take this one step further by writing an extension to automatically updated the XML file based on the contents of a particular image gallery.

Outside of the home page, I am using the Image module, including galleries. I have not yet seen the need to go to ImageCache and appreciate the simplicity of automatic creation of gallery pages. If Image Gallery Access works as advertised, then I will be able to distinguish albums to which ordinary, authenticated users can post from those that are reserved for web site editors. FUpload appears to provide batch uploading that should work nicely for site editors, parents, and students (should I worry about Flash version compatibility?). Missing at the moment is the ability for an authenticated user to create a new image gallery, which would be great if someone is posting sports photos and wants to create a new sub-gallery for each game. If we decide to limit the number of photos posted on this server, then prolific photographers may be better off using Flickr, anyhow.

Embedded Media Field appears to work great, except that I can’t figure out a way to wrap body text around the embedded item. This may be fine for relatively unprivileged, authenticated users but probably not sufficient for web site editors.

I have recently switched from TinyMCE to FCKEditor and am loving it so far. Everything seems to present and work better with FCKEditor, especially embedded images. Do you know of a way to limit file browsing capability to user directories for some roles? I wouldn’t want any user to have access to the primary embedded image store for the site. I would also like buttons and filters to elegantly embed files, uploaded media, and third-party media all within the WYSIWYG interface. I wonder how difficult it would be to write those extensions and make them available to some roles and not others.


Drupal, as community software, offers the exciting opportunity to invite many different constituencies in our community within the site and provide features such as comments, blogs, directories of people, and photo upload privileges specifically to them. I have created the following roles so far:

anonymous user
authenticated user
applicant for admission
faculty/staff member
job applicant
web site editor

User Profiles

I haven’t begun to explore this yet. In some cases, the user profile is a critical function. For example, we want alumni to edit their information through the site: contact details, schools attended, place of employment, interest in the career network, etc. Faculty members will have short biographical passages to help describe themselves. This means that some roles will use different profile fields from others — I need to learn how to make that happen, and whether to use nodes for user profiles in these cases. On a related note, real names will need to be visible throughout the site — I have used Authorship for this before and will need to evaluate it and investigate alternatives once more. Authorship does not have a Drupal 6 version at this time.


Opening commenting is a really exciting opportunity. We currently do not have this feature in our current site, yet we know that our users have a lot to say, and we want to draw them more tightly into the school community. At the same time, independent schools try to maintain a decent level of control over publicly-available content. Drupal’s commenting system seems perfect for this — allow all authenticated users to see and post comments, allow all web site editors to administer comments, and do not use a moderation queue at all. Done.

One downside I can see at this time is that a blog author may in the future want the ability to moderate their own comments. I’m not sure whether this would require a lot of hoop-jumping-through in Drupal, as compared to a blogging platform such as WordPress.


I have done a little investigation here, not very much. I have set up Calendar and CCK Date. I am finding setting up calendar Views to be bit involved. We will make extensive use of list views of calendar items by taxonomy terms in blocks throughout the site.

The custom content type for Athletics events looks great — opponent (node reference), bus departure and return times, result, score, notes will serve their function well. One glaring omission for Drupal 6 is Time. The last I read, developers are testing a Drupal 6 version. We will need this CCK field in order to have additional times for the day of the event (such as bus departure and return times).

We have yet to decide whether Drupal’s calendar could meet all of our internal, public calendaring and resource reservation needs, or whether we should install a proper calendar server.

Migrating Custom Functionality

We have built over the years a lot of custom PHP and Perl scripts that we plan to migrate into Drupal over time. Many of these will wait until year two or three of the project. They function fine now, and we have to first roll out the core functionality of the site.

Applicants for admission can complete an inquiry form, sign up to visit the campus, and download admission forms online. All of these functions pull data from our Blackbaud database in order to function. We could migrate these (rather large) scripts into Drupal, gaining additional benefits: applicants for admission would become authenticated users and be able to read and post comments, gaining greater visibility into the site.

Our current volunteer signup and management system keeps track of multiple events, caps signups for specific time slots in order to automatically distribute volunteers to where they are needed, and produces summary lists for volunteer coordinators. If Signup can do all this, then we will move this feature to Drupal in a flash.

Job applicants can, using another site, view and apply for jobs at the school. This seems like a prime candidate to move to Drupal, which has better designed file submission features than our current system. It will be key to leverage Drupal to provide good workflow management functions for the human resources office — the ability to flag applicants for certain categories, add notes to applicant files, invite supervisors to review applicants online, and send mass emails to those declined for the position.

Social network sites

Connecting with constituents through social network sites is a hot issue right now for independent schools.We want to meet our constituents where they are, in addition to drawing them into our site. At the same time, we want to leverage existing content and processes as much as possible while making this happen. I am happy to find out about Ping.fm, which should allow us to automatically generate Twitter, Facebook, and other status updates from specific News items that we post to our site. With no additional effort, we will broadcast our news items to our users’ communities and cultivate follower lists around the web.

Content types

Here is a list of content types in our test site so far.

Athletic event
Blog entry
Calendar event
Classroom (node for organic groups)
News item
Page (modified to serve as the main content type for descriptive pages)
Team (node for organic groups)


(so far)



  1. Bob Irving says:

    Wow, Richard. This is truly ambitious! Do you have a timeline for implementation? How long do you think it will take?

    Are you still going to use Moodle, and how? Are you using LDAP integration?

    Thanks for posting this.

  2. Richard says:

    Launch date is this August. I think we have sufficient time. For one, development houses would typically build such a site in about a month. We have six months of part-time work. Second, we have made quick progress with the test site, suggesting that we will be able to fine-tune features to our satisfaction if we keep up this pace. Finally, the beauty of an open-source project is that it never has to be "done." We will develop an annual set of development goals and timeframe, so that we gradually add features and refine the site over time.


  3. Bob Irving says:

    Thanks for the answer.

    How about Moodle integration?

  4. Richard says:

    Sorry. Yes, both Drupal and Moodle are bound to Active Directory using LDAP. We will continue to offer Moodle for teachers who want more interactive course web site features than what our Drupal web site will offer.


  5. Bob Irving says:

    I’d love to hear more about how this works, both technically and educationally. Perhaps I’ll email you privately if that would be cluttering up this blog post.

  6. Richard says:

    Please do email — what are your specific questions?

  7. Richard says:

    It’s richard at kassblog.com