We had the advantage of having built and lived with the previous content management system, so we all had a pretty good handle on what the new CMS would need to do. Most of it is pretty predictable stuff. We have news items, we have calendars of events, we have sporting events with scores, we have profiles of people, etc.
The academic departments and administrative offices all have some degree of autonomy, and so we treat them like clients. They can choose to have their sites managed through this CMS or not, and we need to be able to accommodate that. The two biggest clients are ourselves (for the home pages and other centralized content), the athletics department. Other important clients are undergraduate admissions, graduate admissions, and the music department.
One of the things that is just a little bit off the beaten path is our desire to be able to publish one piece of content in many places. In Quahog we implemented this with topics – a news item or whatever can be associated with one or more topics. A few other things we knew we would need were:
- LDAP authentication against our Novell eDirectory,
- some way to manage relatively static content on relatively free-form pages,
- a menu module to manage the links within an academic department or other client,
- a module for managing and displaying photos
- modules for relatively simple but specialized content
- the admissions office has write-ups of each major
- they also have a large number of scholarships with eligibility requirements, amounts, deadlines, etc.
All in all, I am expecting about 30 to 50 people to have their hands in maintaining the content for about half of our ~15,000 page site.
Just as important as the things we knew we needed were the things we knew we really didn't need. At a few key places, we had built into Quahog some sophisticated complexifications that ended not being worth the trouble they were to build. News items, calendar items, scores and press releases were all subsumed in Quahog under the umbrella of a "story." It was all very impressive, but for the handful of times that it was genuinely useful to keep all of the manifestations of some real-world event grouped together in a story, there was a LOT of overhead, both in terms of an overly complex and fragile application and in terms of a usability/training nightmare.
We had also built Quahog's photo gallery module with essentially its own independent topic system, and in hindsight it was clear that that was a mistake we didn't want to repeat.
And in general, we took a more sober look at anything that added complexity. We tried to make Sputnik as simple as possible, but no simpler. That commitment really served us well once we started seeing how much we could get from Django "for free" as long as we were willing to live within occasional constraints. The cost of building a custom admin interface when we really needed something more complex is an issue we'll return to in later blog posts.
July 9th, 2006 at 10:48 am
Note that the new authentication backends functionality will let you do the LDAP integration easily.
July 10th, 2006 at 10:43 am
Adrian, when we were first getting started about a month ago, we decided to try our hand at building our own LDAP authentication code, partly to see how easy it would be to make changes at that sort of level. It worked out really well, which was very encouraging for us at that stage of our learning curve.
Now that the new authentication stuff is ready for prime time, and as we\'re getting close to going live with the first chunk of our Django-powered site, we\'re going to go back and use the built-in suport for LDAP authentication. We\'ll write up our experiences with that here.
July 10th, 2006 at 9:11 pm
Sounds great! I'm curious to see what parts of the new, "official" authentication framework you like and don't like. You have a distinct perspective as somebody who's built that sort of thing already. Looking forward to your writeup…
August 13th, 2006 at 5:42 pm
I'm also the webmaster at a small college and am currently evaluating django as a possible solution for the next iteration of our site. In some ways it (django and its admin app) seems ideal (rapid development for a small, overworked team with code that it easy to maintain and extend). On the other hand, I have several reservations about how well it might fit the way a typical college site is managed and run. For example, as you mention there is a large quantity of relatively static content on every college site and the admin framework (w/ flatpages app) seems woefully inadequate to handling a large number of pages and more importantly permissions (ie admissions people login and edit/see only admissions pages, athletics people login and see only athletics pages, etc.).
All that to ask, how will/are you handling permissions for the different sections of your site? See http://www2.jeffcroft.com/2006/jul/20/top-ten-things-suck-about-django/ problem#2 for a better explaination of what I'm getting at.
Thanks for blogging about this topic!
August 13th, 2006 at 11:51 pm
Art, hopefully I can field this question in a general sense.
As far as the inadequacy of flatpages goes – we've implemented what I think is a fairly good solution for it. Essentially, it's like flatpages on steroids – and creatable through the admin interface. A user can create and edit 'Pages' via the admin module – and each page is associated with a template that is already created. Every block on a chosen template is editable via an editor in the admin, and users can create and edit static content for their pages quite easily.
In terms of permissions, we've implemented a special many-to-many relationship on our users called Topics. Every user has a list of Topics assigned to them that restricts what they see when they enter the admin. For example, the sports director would be associated with the Athletics topic, and anything that is a child of the Athletics topic (Men's Basketball, etc). When the sports director logs in, the admin interface is automatically filtered based on what his Topics are. The way we've achieved this is pretty hackish, and involves some pretty complex logic that overrides get_query_set in the manager of the Topic class to filter by permission behind-the-scenes – so that any admin interface automatically gets a restricted set of records to return.
Either way, I think Dave or I should write a blog about both of these issues. Thanks for the input! Any further questions are graciously accepted.
-Chris Dary