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.
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.
Media
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.
Roles
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
administrator
alumnus/a
applicant for admission
faculty/staff member
job applicant
parent
student
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.
Commenting
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.
Calendaring
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.
Here is a list of content types in our test site so far.
Athletic event
Blog entry
Calendar event
Classroom (node for organic groups)
Image
News item
Opponent
Page (modified to serve as the main content type for descriptive pages)
Team (node for organic groups)
Modules
(so far)
autosave
book_access
calendar
cck
date
devel
emfield
fckeditor
filefield
image
image_fupload
jquery_media
ldap_integration
lightbox2
messaging
notifications
og
print
scheduler
simplemenu
slideshow
token
views
Comments
Teachers
I notice in your roles you don't have a teacher role. Is this because you are calling them faculty/staff?
I'm currently setting up a drupal 6 site for a k-12 district and we're allowing every teacher in the school to have a webpage. (They get links to them using a views block). Anyway, I was wondering if you are doing this, and I'm interested in how you accomplished this?
Thanks,
Cameron
A little different
Yes, we group our employees under the title "faculty and staff." Each teacher, staff member, and student automatically gets a blog by assigning these roles blog posting permission. We also provide class web pages, built around three content types (resources, events, and news) and joined through a unique taxonomy term for each class id. For the moment, I am creating class ids manually but plan to sync them up with our central school database via cron.
Impressive
I like the idea of using the blog for the teachers to user as their page. What are some examples on how you are using taxonomy?
Also I was trying to take a look at your test site, but either the site is down or the link is broken.
Views
Views gives you a lot more flexibility than the core blog module -- FWIW, we haven't used the blog module in a couple years, as it comes with urls/breadcrumbs that get annoying.
FunnyMonkey
Click. Connect. Learn.
Using Drupal in Education
FunnyMonkey
Agreed
I'm using auto url-aliasing and views to control the overall flow of our site. I didn't want the blog feel.
Not an either-or
I don't understand why blog and views are being framed as mutually exclusive choices. We use blog to make it easy for teachers and students to maintain a blog. We use views to display the blog posts in an easily-consumable manner. With blog, we automatically get a link to each user's blog in their profile (but you probably don't use Profile either). As far as I can tell, blog is acting just like a regular custom content type for us but saving some of the setup work.
I actually found that OG
I actually found that OG works well for organizing classes -- you get the same sort of functionality to connect content that you're doing with taxonomy, but then you get a variety of other functions, too -- it makes calendars very flexible and useful, for example -- a user's view of a calendar can show both the public events and any private events associated with groups (classes, activities, etc) that the user is subscribed to.
OG would work fine. I
OG would work fine. I installed OG and used it for a while and then removed it. It had far more functions and overhead than I needed. For example, I don't need to maintain "membership" in a class when we have another system for that, and the Subscriptions module takes care of any email notification people would want.
I am using taxonomy to hold the class name, so that posts of the classroom news, classroom events, and classroom resources content types are aggregated by class. I then use a specially formatted link and hook_form_alter to provide an "add new" link under each one.
I retired that old test site. We are now developing on http://new.catlin.edu, though the classroom pages are protected.
Richard
OG without OG Access Control
Using OG without OG Access Control allows you to group posts together, get an RSS feed for your groups, set up a group blog, and control who posts into the group. This also frees you up to use other means of access control (if needed) on posts associated with a group.
This strategy provides more flexibility than you get with taxonomy, without the need for membership in a group (except, of course, for authors posting into a group). Also, given that OG integrates with Views, you have a fairly broad amount of control over presentation of content.
FunnyMonkey
Click. Connect. Learn.
Using Drupal in Education
FunnyMonkey
I assume that each school
I assume that each school finds the web site strategy that meets their needs. For many, it may be OG. For us, it is not.
A classroom page is not a "group" on our site. We already have Moodle for that purpose, a tool that meets our internal classroom needs without requiring much setup or maintenance.
On our site, classroom pages mainly exist to present classroom news, resources, and events (including volunteer opportunities) to broader audiences, mainly parents. In nearly all cases, the teachers are doing all of the posting.
How do you manage user accounts? Moodle integration possible?
Hi Richard,
I've been looking over your discussion of drupal use in an educational institution - very informative. We've been investigating a similar transition over here at our school. I was wondering about how you manage your user accounts and different databases and if you differentiate in your methods for your various roles.
For example we have been successfully running Moodle here for about a year. For the faculty/staff accounts I am able to link them to our LDAP server to provide a single sign-on type functionality. But the students here don't have their own individual domain accounts so we were faced with the choice of either allowing them to all sign up individually based on their student email accounts (which they DO have), or pre-populate the moodle database with the names of the students and determine a way to distribute the passwords. We ended up deciding to allow the students to create their own accounts based on their email address which has been mostly successful.
But now faced with the prospect of having a constituent database comprised of even more role types in drupal, many of which would NOT be in our LDAP database (parents, alumni, prospective families, etc) I am a bit at a loss as to how best to get new accounts created.
For existing families I suppose we could pre-populate the database and assign the roles and distribute the account information but then it seems we would have to do that twice for Drupal and Moodle (if we wanted any kind of integration) and is that the most efficient method? And that still leaves the question of what to do with initial anonymous users who want to join the community as either an applicant or a supporter or any number of other roles. I see you allow people to create their own account on Catlin Gabels website and assign themselves into a role. Do you verify those requests and does that method work well for you? And advice you could give would be appreciated.
-Arian
Managing user accounts
I have been dealing with similar issues here. Different groups different authentication etc...
Personally this entire project is a plan that needs giant white boards.
Something I learned from Sun's Drupal usage for intranet projects. Do not do the one site to rule them all thing.
Personally I would start with a current external ldap system. The school has staff and student logins. Moodle should be setup to work with those accounts on that system.
Then you start building sites based on usage
A site that serves just staff
A site that serves staff and students ( your classroom and organic groups )
A site that serves the public that can staff can authenticate to to do updates, and the general public (alumni) can create accounts.
Finally if the LDAP authentication thing is causing you to much grief this is one thing I would not hesitate in hiring an external LDAP expert to setup. Once its setup you can use that as a template for other sites. We have done that for a couple servers over the years and it was well worth it.
This starts simplifying things. I would beg you to at least move your staff intranet off of you drupal install, that one move solved so many permissions issues it wasn't funny.
Mike Hathaway
mike@mikehathaway.com
http://www.mikehathaway.com
Self-registration
Arian,
Faculty, staff, and students log in with LDAP accounts.
Parents and alumni self-register with email verification against our school information system.
Everyone else self-registers without verification against an external database.
All non-LDAP users start the process in the same manner, by requesting a new account in the standard Drupal way. They choose their own username, and Drupal sends them the email verification link. If the user passes the standard email verification, then I query two external databases by their email address. I hook into Drupal using hook_user and $op=="insert." If my custom module finds the user in the parent database, then I add the parent role and populate additional profile fields with their real name and external ID. If the module finds the user in the alumni database, then I add the alumni role and populate additional profile fields. The constituency field you noticed is just a user profile field that helps us identify people who think they are registering a parent or alumni account, but we don't already have their email address. Otherwise, we couldn't tell them apart from people who register for other purposes. We receive email notifications for these and then verify them using a human process.
I considered prepopulating Drupal with parent and alumni accounts but decided that parents would better remember their logins if they created their own accounts.
We actually don't have roles for admission applicants, summer program registrants, and other such users of the website. Any registered user can use these site tools. In other words, I only create roles based on distinct uses of the site and security needs.
When we get to the point that applicants become families, we will first promote those individuals in our school information system, and then we will add the parent role in the Drupal website. The external ID in the school information system will serve as the key for this process.
With regard to Moodle-Drupal integration, we really aren't doing any. Mostly, this is because Moodle has evolved into a tool for small groups (classes, clubs, committees, working groups) to use for internal purposes, and our Drupal site has appropriated all of the community publishing functions. Teachers and students live on both sites, but they log in easily based on LDAP. Parents mostly don't go to the Moodle site anymore. Those that do go through user registration a second time. This summer, I plan to create a sync module that will keep Moodle parent accounts up-to-date based on Drupal account status. Thank goodness they both use the same password encryption scheme!
Mike, I see your point, and I agree that one site cannot serve all needs. However, I find that functions overlap considerably, so the more sites you create, the more often that functions will overlap multiple sites. Users can also get confused as to what site they should use for different purposes.
Best,
Richard
http://kassblog.com