Well, it's been over a month since we deployed our new Drupal-backed site, so I decided to share it and general experiences & problems we've had with a migration to Drupal for a higher education website. We deployed two separate websites; first, the BYU Computer Science Alumni Association website, which we deployed several months ago as a 'test' website, and then the main BYU Computer Science Department website. The department website had previously been running an old conglomeration of scripts that had been accumulating from the various webmasters over the years (some stuff was created back in the days of PHP 3!) There was no concept of CMS whatsoever, but there were a TON of legacy custom utilities (mostly private for faculty and staff) that needed to also survive the migration.
We chose drupal after evaluating various alternatives (including Joomla). The main influences on our decision were A) The module and theme system appeared to be the easiest to customize to our needs. B) The sheer amount of documentation. Drupal is definitely one of the best documented open-source projects we've seen.
It took us about 6 months from the time we started development to deployment (including learning time of being new to drupal). We actually had the majority of the work done within 4 months, but various committees dragged their heals on approval. :)
The department website now runs Drupal 4.7, with a ton of custom modules for integration into legacy code (as well as a bunch of completely rewritten stuff). Some of the modules we currently run are: actions, advanced_menu, atom, autotimezone, calendar, cck, email, event, fieldgroup, fileshare, image, image_attach, image_exact, image_gallery, imagefield, imce, jscalendar, link, node_privacy_byrole, nodeimageblock, nodequeue, path_redirect, pathauto, sched_act, securepages, tinymce, views, and workflow. Some of these have some custom patches (some of which have been submitted to the modules). We wrote a custom authentication module to tie accounts into our local LDAP and the university-wide LDAP servers. We make a lot of use of the Views and CCK modules, although we also have created a number of node types manually. Our front page is powered by no less than 3 views and 6 blocks.
The theme we use is the university-designed theme that our old site also used. It was quite easy to update it to the various drupal-isms. We found the theme system extremely flexible to our needs, even we were doing things that drupal did not expect us to be doing (such as the fact that our front page is not controlled by the normal Front Page publish option, but by a range of published dates from the event module).
Our biggest challenge was our custom authentication. The majority of it we were able to accomplish using a patch that is now in 5.0 and an authentication module. We did have to put in an additional snippet into the drupal session management in order to use our cross-site session management that we use within the department. Otherwise, the authentication module was fairly easy to create.
Our other big challenge, and one that we still haven't solved, is the menu. Our department wishes to have multiple menu links in various submenus to the same page...And drupal gets very confused with this. We are currently trying to work out a solution for this.
We do have some complaints about some of the administration UI, but 5.0 seems like it fixes at least some of that. (Of course, it's going to take us quite a while of testing 5.0 with all our custom modules and such before we deploy a 5.0 version.)
We've been very happy so far with our new Drupal-based website, and so has our faculty and staff, who are now learning that being able to edit website content themselves, rather than coming to the webmasters for every little change, is very convenient and easy. We do wish that something could be done about the sheer amount of stuff on the node add/edit forms, as it can be somewhat overwhelming to less technical users such as our secretaries (and, believe it or not, some CS faculty even get confused). Some of this problem is module bloat, and the collapsible fieldsets do help a lot, which is why we really don't have any idea of what to do about it. It's just our observation.
As webmasters, some of our favorite features include: the error log (invaluable), the awesomeness that is the Views module, and the great customization of the access control/roles. Future development will continue with internal modules for various department tasks, some possible patches to add some features we'd like to the Views module, fixing our menu, and hopefully moving our course listing system into drupal nodes (currently a legacy system).
Hopefully, this post will provide someone considering a drupal migration with some valuable insight. Thanks Drupal, for a great platform for website development.
Comments
Nice job and welcome to
Nice job and welcome to Drupal. You may want to check your css for the events module when viewing events by lists, it breaks in firefox. Here's a link - http://cs.byu.edu/event/2007/01/20/list/all/all.
-----------------------------------------------------------------
Petafoo - We Love Animals
I'm the other web programmer
I'm the other web programmer here; thanks for the tip. It's been fixed.
Heats down!
Nice work ... heats down!
A humble advise: if you don't like tons of spam then use the contact-form for webmaster's email.
Florian
PuzzleIT | EU Copyright Office | SoftChannels | STReight
Florian
I'm not sure how much it
I'm not sure how much it matters, since the webmaster account, which it was linked to, is often a default place to send spam too, but since it can't hurt either, I've also put that in place. Thanks for the tip.
Nice Work. I work for the
Nice Work.
I work for the Computer Services at the College of Engineering, Michigan State University. We started using drupal last year and have done quite a few sites on it now. Some of our recent projects:
Future Engineers
Mechanical Engineering
Office for Inclusion and Intercultural Initiatives
And we've more coming our in the next couple of months, including our own departments site (finally!). It seems that with each site we develop our drupal knowledge builds and they become more complex adding the 'cool' features.
One thing I would like to do this semester is create a custom login module. I haven't been too concerned yet, since we have a limited number of people adding/editing content. The majority of the college won't need access until we work on the main college site, which we'll start to tackle in a couple of months. I can only image how long that's going to take... Any more insight you can provide into the auth module you developed? We have a single-sign-on login on other apps that I'd like to get this working with.
We went through the same choices when choosing a cms and evaluated joomla/mambo and other paid solutions. The amount of drupal modules, document and large community are really what drove the choice.
:bd3
auth module
For the auth module, we had to use a patch for 4.7 in order to get the external auth working like we needed (I think 5.0 has the patch though).
Our auth module does a couple of things:
First, it authenticates against the university LDAP. There are some interesting issues with that, since the php ldap functions like to throw errors on password failures. Wouldn't have been a problem except that the @ php expression does NOT work when there are custom error handlers...Thus filling our logs with numerous ldap errors. We had to temporarily reset the drupal error handler while we worked with ldap, and then set it back. Really hackish. If you're not using ldap, you shouldn't have this problem :)
The auth module also converts LDAP groups (faculty, staff, undergrad, grad, admin, etc.) into drupal roles. We accomplished this by loading all the groups at login, checking if they were in the appropriate roles that were setup for those purposes, and then manually inserting role membership entries into the roles table when needed. It's a little bit of a pain, since you have to setup group-to-role associations somehow (we simply used some drupal variables that could be modified in the settings for the module). All other ldap information we need we pull in and store on the user object as normal drupal user data.
Our auth module was further complicated by the fact that we needed to support sessions from other department controlled sites that were not under drupal...Without that, the auth module is surprisingly simple. The documentation provided on this site basically covers most of what is necessary. Our module is also further complicated by having two separate LDAP sources to authenticate with (university and department)...Luckily, drupal already provides for having multiple authentication sources by using @server in the login. Our faculty (which use the separate ldap) simply have to login with the username@cs. Faculty, however, are notoriously lazy and forgetful, so we used the form_alter hook to add a drop-down menu that adds the @cs to faculty logins via javascript. :)
Error suppresion
Off-topic, but I believe Drupal 5 fixes the problem of @ not suppressing errors.
--
If you have a problem, please search before posting a question.
Looks like a solid
Looks like a solid implementation. A very good example of what drupal can do.
Best regards,
Lennart
Best regards,
Lennart
Wiki w/ list of other academic uses of drupal
Nice job! I've started a wiki on EDUCAUSE CONNECT with a list of other universities using Drupal.
You can find it here:
http://connect.educause.edu/term_view/drupal
It is a truly great example
It is a truly great example of the posibilites and aplication of drupal sites. Nice job
Drupal is great for Universities, but not just for brochure-ware
I was bitten by the Drupal bug “way” back in the days of 4.6 while working at the Bradley University’s Slane College of Communications and Fine Arts. We had tried everything there… exporting HTML from Microsoft Word, teaching Dreamweaver, then Contribute, writing our own homebrew CMSes. When we started the transition to Drupal, we “front-ended” the homebrew sites with hard coded PHP that pulled specific node IDs. It wasn’t until I read the passionate discussions that went into the decision to move the body text from the node table to the revisions table in 4.7 that I decided that the Drupal core team really knew what they were doing. With 4.7 I stopped front ending sites and started theme’ing full blown Drupal sites.
http://music.bradley.edu/ is an example of a well done “front-ended” site
http://slane.bradley.edu is now a full blown Drupal site
The biggest challenge with all these sites has been training. The interface improvements to Drupal 5 make this much easier. Having a great WYSIWYG browser based editor like TinyMCE or FCKEditor and utilizing client side tools like Ecto (http://ecto.kung-foo.tv/) and Photon (http://decaffeinated.org/archives/2004/08/24/photon) help too.
Several of the Slane College’s sites are stuck in limbo because the faculty can’t agree to move forward with a design or content hierarchy, but give students a Drupal site and they produce impressive sites very quickly. This is a project (b)log for a 400-level multimedia class… http://addingmachine.bradley.edu/. These project (b)logs in some ways replace traditional elearning software like Blackboard or WebCT. They are great for senior level work where the students and faculty are confident enough to work in the open, but I discouraged a 100 level writing class from blogging with Drupal on a public site. With Google and Archive.org, anything you post can quickly become part of your permanent record.
I now work for the Reynolds School of Journalism at the University of Nevada Reno and have been spreading the Drupal love here as well. The graduate school site was ported to Drupal 4.7 last semester http://journalism.unr.edu/grad. We were in the middle of porting the main RSJ site to Drupal 5 when we suffered an unexpected loss. The Dean of the school was killed in a car accident. Having the based Drupal 5 install up and running did allow us to quickly transform the RSJ’s homepage into a living document with a form that allowed people to add their memories of him http://journalism.unr.edu. Those posts are inserted as comments and reviewed by an editor before they appear on the site.
The RSJ’s commitment to Drupal continues despite this loss, but with a different top priority for the time being. In March the graduate program in interactive environmental journalism will launch a Drupal 5 driven site exploring ways journalists can connect with their audience using Web2.0 technologies. This will be something of a hybrid site. http://www.ourtahoe.org will be fall somewhere between an unfocussed, general purpose online community and a traditional top-down news site. Drupal has most of the tools we need to do that and the ones it doesn’t, we are creating ourselves. The first module the RSJ is developing from scratch is RSJ Promise http://drupal.org/project/promise.
For schools, Drupal is a great solution to transition your brochure-ware site into a community that connects your current students and alumni. It can be used to extend (or even replace) traditional closed elearning systems or give your students a publishing platform of their own. My last piece of advice for people in academic environments just getting started with Drupal, don’t try to do everything with a single Drupal site. Break the sites up by departments, program, students area, etc. Start small and build. Find a piece of a site… an image gallery, a calendar, even the homepage to sneak Drupal in and start showing people how it works. Once they are comfortable posting one type of content, add another, and another until they are asking you…
“Wouldn’t this be easier if we did it in Drupal?”
___
Kevin Reynen
Integrated Media Coordinator
Reynolds School of Journalism and
Advanced Media Research
University of Nevada, Reno
menu suggestion
For complex menu systems (in an intranet environment where you can reduce cross-browser JS quirks), I'd consider a static site-wide solution in an external .js file.
-- Naturally the external js file can complement any of the Drupal menu systems, but with the possibility for the js menu object to overlay the Drupal menu -- in a layer that pastes itself over a menu block.
-- Navigational structure typically does not change significantly over time, so dynamic structure updates (drupal menus) become less important than absolute control on what gets put in the menu. While I applaud the Drupal menus for their graceful decay, sometimes there's a need for Javascript pzazz too!
-- An external javascript menu object also opens up the possibility to plug a common js menu(s) object into numerous sites (Drupal, Joomla, plain HTML, Cold Fusion, Blackboard etc.).
PopMenus offer high flexibility, stability, ample menus-per-page and customisation (I managed 12 menus once without severe performance problems). They are also pretty easy to get to know (documentation). Another good aspect of popmenus is that they are a good means of introducing other custome js scripts into single js embed on the page.
-- http://www.burmees.nl/menu/menus.htm
I also detailed our
I also detailed our experiences with drupal at a university here - http://drupal.org/node/85409
Overall we've been happy and the flexibility is great. CCK and views give you the ability to rapidly depoy new CRUD type applications quickly and it's been a great help. The only real downside we've found is that there are often significant changes between major releases, and since we run a number of custom modules, it makes upgrading to new versions a real pain.
Hierarchical sites with devolved responsibility
I agree that menus are not one of drupal's strongest points. For me the major weakness is that anyone with the administer menus permission can mess up menus in any part of the site.
I've a couple of projects that require sites to be divided into sections with editorial responsibilty for each subsection delegated to particular users. Ideally the menu structure would be created automatically, a la the book module. Users would not be presented the menu options for each node, and would certainly not be able to change menu items outwith their section.
In fact, I think that the category module (http://drupal.org/project/category) along with cac_lite should pretty much does what I want. I have used category on one site (http://www.venue40.org.uk), but not cac_lite.
My main reservation about the category module is that it is really a replacement for the taxonomy module (though there is a compatability layer). It would be nice if at least some of the category functionality could be incorporated into taxonomy (and made to play nicely with views and cck). I think the key thing is the taxonomy-term-as-node concept, where a node is associated with taxonomy term, really in place of the taxonomy term's "description". A bit like the old taxonomy_assoc module, but more integrated with drupal core. There would still be the issue of creating menus, though perhaps taxonomy_menu would rise to the challenge. And perhaps there would be a way of linking views to each term/node, so that one could have a set of URLs like this:
http://www.example.com/fooland/barshire/bazton - a term/node for the bazton branch of example.com
http://www.example.com/fooland/barshire/bazton/events - a view of events attached to the term/node for the bazton branch of example.com
http://www.example.com/fooland/events - a view of all events happening fooland, with each event having a link to its precise location (e.g. bazton)
Probably I'm missing something in these ever more fanciful ramblings, and this is all doable right now without (too many) hacks, but if not, I think it would be interesting to think how drupal could better support this type of structure. A distribution anyone?
Thanks
Thanks for your support for getting (part of) the category module into core. Unfortunately, Dries is adamantly against the term-as-node-vocab-as-node concept, which is the core concept behind the category module, so it seems very unlikely that this will happen in the foreseeable future.
However, recent discussions about creating a new 'base entity' or 'underlying container object' for Drupal (from which all other entities - e.g. nodes, users, terms, comments - would inherit functionality) are very promising, and may ultimately allow us to make currently-node-only features get shared not just by nodes and terms/vocabs, but also by anything else in Drupal. This could potentially make the core taxonomy module 'automatically' as powerful as the category module, which would be very cool. See my post in this discussion: http://lists.drupal.org/archives/development/2007-01/msg00437.html
Jeremy Epstein - GreenAsh
Jeremy Epstein - GreenAsh
Could you provide a little more detail...
...about how you created the dynamic tabs in the bottom portion of the homepage? I assume you're using panels to create the layout, but how do you enable the dynamic content swapping?
Erik Britt-Webb
drupal@britt-webb.net (subscriptions)
erik@britt-webb.net (personal)
The tabs are actually part
The tabs are actually part of the university-supplied template. As you mentioned, we use panels (as described here http://drupal.org/node/29140) to define the content areas and had the special front-page template load the university-supplied JS file (we just included the script tag directly in the template's source), which handles the mechanics of the switching. Unfortunately, the content of these tabs are merely hidden and shown on the page; the full HTML for everything is sent to the browser on page-load. It might be nice to make it more dynamic and ajaxy in the future, but we haven't gotten a need to yet.
Now that I think about that, you'd need to find a way to make Drupal cough up the HTML for an individual block region using AJAX, something that I don't know how to do. It would be interesting to see someone make a module that does that, however (if there isn't already one). The rest of it would be pretty easy, since you'd just have the block regions defined as needed and have the JS load with the template. I'd suggest trying the forums if that's something you need.
So if development took that long for a couple departments...
How long would it take to develop on drupal for 7+ departments? Where does Drupal make sense for universities that don't follow the drupal idioms? Cause to me it seems only do I not get to build anything yet, I have to first make it Drupal safe, then maybe I can think about actually building something usable. I've never done so much hacking in all my years in web development. CSS has nothing on Drupal when it comes to hacking things to get real results.
Drupal makes me bananas!!
I'm not quite sure what
I'm not quite sure what you're getting at, though I agree, there are things about Drupal that make me want to tear out my hair. Though a lot of those are fixed in Drupal 5. On the other hand, there's a lot of power that you can leverage with concepts such as modules, views, CCK, etc.
As far as development time goes, keep in mind that these two sites were our first serious experience developing a drupal site. There was a lot of learning and missteps involved in getting us to where we were. Now that we've gone through that pain, I'm thinking it wouldn't take as long to add additional sites. Most of our development time was spent figuring out the authentication/user system, a place where documentation is sadly very lacking. Were it not for that, we could probably have cut about 2-3 weeks out of our development cycle. One other thing to note is that we are part-time employees with the two of us working about 20 hours per week, and split among a number of different projects, making it very difficult to put an actual man-hour number on our drupal development time. It /does/ require commitment, but again, I think the benefits of the framework outweigh the problems.