Stanford Law School Homepage Screenshot

The SLS web team, working with Webdrips, migrated a database-driven proprietary content management system to Drupal. This provided a significantly improved content management experience while preserving the look and feel of the site.

Why Drupal was chosen: 

Stanford Law School (SLS) wanted to migrate law.stanford.edu from a custom, unsupported, outdated, unwieldy, proprietary legacy CMS to an open-source, scalable, extendable, robust CMS that would meet SLS web needs now and in the future.

The Drupal CMS was selected for the following reasons:

  • Drupal is a scalable and extendable CMS with wide variety of modules that enable a developer to build a system that can meet current site requirements and easily add new functionality in the future.
  • Advanced system of Roles and Permissions makes Drupal a perfect platform to securely distribute content management to departments, students, and other stakeholders.
  • Drupal has great community support and has become the de facto standard at Stanford.
Describe the project (goals, requirements and outcome): 

Goals

The primary goal of this project was to migrate law.stanford.edu from a legacy CMS to Drupal. Migration was comprised of two parts:

  • Conversion of a set of complex layouts and proprietary PHP code into a Drupal-based site that uses modules (mostly contributed and custom where needed) and a custom theme.
  • Migration of approximately 10,000 pages stored in the database, and around 5000 HTML or text-based pages.

The look of the site was to be preserved, so no graphical design changes were made. The secondary goal was to make improvements where possible. The timeline for the project, given the limited resources, was 12 to 18 months. Also, with more than 300,000 page views and 80,000 unique visitors per month, we wanted to be sure the performance wasn't diminished.

Requirements

The primary requirements of the site were as follows:

  • Five information portals (see the first screenshot, below): provide a Mega Menu with links for the portal audience (e.g. alumni), and news, events, publications, and user groups related to the portal.
  • Areas of Interest sections that display all information related to a particular area of law.
  • Person and department directory: a filterable, sorted list of all people and departments associated with SLS.
  • Events section: a searchable, filterable list of events and mini calendar filterable by event type, audience, etc.
  • News Center (see the second screenshot, below): a hub for displaying latest tweets, news, press releases, and publications. The page is also a launching point to all of the school's tweeters and bloggers.
  • Publications Section: searchable, complete bibliography of all publications by SLS faculty and staff.
  • Organizational pages for research centers, programs, student organizations and departments.
  • Library section (see the final screenshot, below): a collection of pages, news, events, and other information related to the Robert Crown Law Library.
  • Static pages for general information about the school, admissions, and other topics, with several levels of child pages.
  • Complex breadcrumbs: the breadcrumb navigation is used on pages within the site buried several levels deep, and the algorithm for how they're generated became so complex, it wound up requiring more than 100 lines of code.
  • Events submission and approval workflow (configured by SLS web team).
  • Additional specialized pages for case studies, fellowship information, etc.

Primary Content (Page) Types

  • Areas of Interest: SLS showcases six areas of interest. Each area of interest includes a primary description, links to more detailed description by subject within an image carousel, an automated menu with links to related listing pages for faculty, news, departments, publications, events, and other related information. The primary challenge for this page type was in building the automated menu such that the links to related listing pages were only displayed if the listing page had at least one valid item. For example, we only wanted to show the "News" link if at least one news page had been associated to that area of interest with the proper tag.
  • Child page: several content types, including areas of interest, needed to have the idea of a page hierarchy. Child pages of any depth needed the option of inheriting a parent's page title, banner, and left/right sidebar content. This feature was provided so content managers could edit information in one place. Child pages also needed to be optionally inserted into an automated context navigation menu. The primary challenge with child pages was providing the optional inheritance of one or more parent assets.
  • Courses: include basic information such as title and description, tagging, related person who taught the course, and the departments the course was related to. Course content is imported from a university-wide Stanford site using an XML feed (developed by Stanford ITS).
  • Events: the most complex page type featured common fields such as title, description, from/to dates, location, related department, and several fields to help the facilities department decide on the best location. Events also included a workflow described in the Modules/Themes section below.
  • Landing page: a page type used as a root page for each of 18 sections on the site (eg. School, Courses, Giving to SLS, etc.). These pages include title, banner, right/left sidebar content, related person quote, and the ability to insert automated content using a view. Providing content managers the capability to insert a view was somewhat challenging in that we needed to generate a list of views, their associated displays, and any optional arguments. This involved writing some custom code because no existing Drupal module provided this capability.
  • News, publications, and press releases: media page types included basic information such as title, author, date, source, article link, related faculty, and related organization.
  • Organizations: this page type allowed for creation of office, department, program, and clinic pages. Organizations included location/contact information, left/right sidebar content, relationships to other organizations, and other information. Organizations presented two primary challenges: 1) if the content manager chose a particular taxonomy term, the layout needed to be altered to accommodate an image carousel (which was accomplished with the Panels module (see below); 2) If the organization had the proper flag set and at least one news, publication, or press release page related to the organization existed, SLS wanted to display the news/press release/publication in place of the organization's description as the landing page for the organization. In Drupal terms, this implies displaying either the node or a view when the path of the node was accessed.
  • Person: a page type for adding faculty, staff, and other people to SLS. Person included name, contact information, photo, CV (résumé) file, biography, awards/honors, education, areas of expertise, and website links and, most complex part, one or multiple roles at SLS.

Outcome

The project is a major upgrade over the previous CMS for both content creators and administrators. This site now provides a path to the future that will scale with SLS needs.

One of the biggest challenges was working with the team from several groups, including the Office of Communications, Office of IT, and the testing team. Drupal came to the rescue once again with the Open Atrium project-in-a-box website. If you've never played with Open Atrium before, consider giving it a try. In about four hours, we had a basic project collaboration tool in place. It provides bug tracking by project, a notebook for documentation, a calendar for project events, and a wonderful dashboard to bring it all together.

Organizations involved: 
Modules/Themes/Distributions
Why these modules/theme/distribution were chosen: 

The primary modules deserving special mention include the following:

Views UI, Views API

While no site is complete without Views, we were able to put together some interesting scenarios, including the following:

  • Automated menu where each menu item is a view, and we used the Views API to determine if a set of view displays had results. Each view display with at least one result resulted in a menu item being generated for the related display.
  • "Query altering" to get the correct argument set in the view. Sometimes there's no way around using node titles as a Views argument, but titles can contain just about any text, including punctuation that breaks Views arguments (because it's automatically removed by Pathauto and not desirable in the path in any case). With a little Views query altering magic (hook_views_query_alter()), it's relatively simple to load the correct node title and use it as an argument.
  • Custom theme output using over 80 Views template files. The way Views breaks down its theming typically makes overriding output relatively simple and straightforward.

Note: We believe development could have been sped up somewhat if we had put together a Views row plugin. Also, when this project gets migrated to Drupal 7, we believe we could make significant use of entity theming to reduce the overall theming needed.

CCK, CCK API

CCK is another must-have module without a doubt, but we really found some "hidden" API gems that saved a ton of time. For example the $field_[your_field/group_name]_rendered object contains the complete markup for the related field or group. This allows for printing the rendered output for the field or group only under certain conditions.

Also the CCK theme override functions, such as theme_content_view_multiple_field() were life savers, since they allowed us to display CCK fields exactly as the school desired.

Node Hierarchy

Aside from Views and CCK, this module was probably the third most useful. It allows for any page type to have child pages; provides some handy menus, Views, and Pathauto integration; and includes an API robust enough to create more complex relationships and even set hierarchy during migration using the Migrate module. The school was able to use these features to create some complex sections with multiple levels of hierarchy.

Migrate/Migrate Extras

These modules (plus some dependent modules) were required to migrate the content from the legacy MySQL database to the Drupal MySQL database. Of all the modules used, these modules were by far the most extensible by being built from the ground up using object oriented programming (OOP). This extensibility made what would have been an absolute nightmare into a reasonably straightforward coding task.

Now throw in Drush integration, the ability to update existing content, and the ability to simply roll back and re-import content, and you have a wonderful user experience on top of a very powerful import tool. If you have a complex migration that can't be handled with the Feeds module, look no further.

Other Modules

  • Devel: with thousands of lines of PHP added during development, this module was a godsend for navigating through complex objects and aiding in debugging.
  • Workflow/Rules: the school had a requirement that faculty and students be able to create events. Student events needed to be approved by Student Affairs, and all in-house events needed approval from Facilities. The Workflow and Rules module were used to set up all the required event flows, send emails, and keep all the event stakeholders happy.
  • Panels: while Zen provided a nice one, two, or three column layout, and Views theming allowed for others, there were a few places where layout variations required the use of Panels to keep content/layout manageable. Panels also allowed us to use a taxonomy tag to determine page layout, which turned out to be a very nice addition for their content managers.

Zen Theme

We built a sub-theme based on the Zen theme because, at the time, it had the best accessibility rating, and it comes with a plethora of incredibly well-documented theme override functions that came in very handy during development. For example, we made use of the zen_body_attributes() function to automatically set the page background color based on page type and other conditions.

Special Thanks

Webdrips would like to thank each and every person and organization involved in crafting the modules listed above, with a special huge thanks to Mike Ryan for all his help with the Migrate module. Without the Migrate module, I simply don't know how we would have completed the legacy CMS to Drupal database migration.

Team members: 
Stanford Law School Alumni Portal
Stanford Law School News Center
Stanford Law School Robert Crown Library

Comments

drupalgarl’s picture

Hello,
Your documentation and site give me inspirations. What I wanna know is you are using Drupal 6 or Drupal 7?

drupal garl

webdrips’s picture

Hi @drupalgarl, the site was built on Drupal 6 because Drupal 7 was not quite ready when we started working on the site. We have since built sites on Drupal 7 and think entities are better for a more modular/reusable approach to design.

Need Drupal module or theme design? Please visit Webdrips to learn how we can help.

zgos’s picture

is it ready for drupal 7 now, do you have plan to upgrade to 7?

WebNock’s picture

Hi,

Nice work ther
I suggest you to use http://drupal.org/project/invisimail/ to block spambots from accessing the emails listed in the http://www.yoursite.edu/directory/ view.

- Team WebNock

saitanay’s picture

The Navigation in the black box is too difficult to use.

Say I want to click on "The school"->"History", the hovered link changes to "The Program"->"Degrees and Joint Degrees",.

Same with "The Programs"->"Programs & Centers" under. Trying to open it causes the hover link to be changed to "The Experience"->"Student Life", before you can actually click.

Yet another use of over-enthusiastic use of Javascript gone wrong,. The primary purpose of the site navigation does not seem to be served.

drummondf’s picture

I second this - it is very disappointing that sliding beyond one or two pixels over the word would disrupt this... Why not instead simply move the "menus" apart further? There is plenty of empty space for the shift

This is why there are designers and there are developers and they are both equally important - there should always be a checks and balances system in place to ensure these sort of truly glaring mistakes don't occur

This is a nice site and very well built, but when a website is boasted on the front page of drupal.org I hold it to a very high standard - this is after all the world's greatest CMS and you are representing it to potential users and proud developers across the globe! :)

I Offer Drupal Web Design and Development

saitanay’s picture

Besides just having the "Stanford" tag,. there is nothing great about this site to be showcased as FEATURED on drupal.org,.

webdrips’s picture

I find it highly offensive that you'd single out some javascript on a migration project that has absolutely nothing to do with Drupal or the Case Study, then say it doesn't deserve to be a featured case study just because this higher education site doesn't have all the bells and whistles you deem necessary.

If you don't have something constructive to say, why say anything at all? By the way, you are more than welcome to post your own case study and request it be considered as a featured one.

Please keep in the spirit of Drupal and not attack other people's work.

Need Drupal module or theme design? Please visit Webdrips to learn how we can help.

irinaz’s picture

Hi,
Comment about navigation menu is very valid - with this implementation main site navigation has limited usability. This error was introduced during migration. We have fixed the problem now, and users can easily access all items in the black navigation menu.

Irina Zaks,
Stanford Law School

saitanay’s picture

dileep.kumar’s picture

Hi,
It looks good. As per my review of the site I have found the following small issues.
1. Trailing slashes of all the urls eg: http://www.law.stanford.edu/directory/. I think it can be solved by global redirect module.
2. HTML validation error exist please check http://validator.w3.org/check?uri=http%3A%2F%2Fwww.law.stanford.edu%2Fdi...

Thanks

Dileep

shamio’s picture

In the directory page you entered, both links with and without slashes work fine. but for making both styles the same, they can use global redirect module which checks the current URL for a trailing slash, removes it if present.

Doubt is the father of invention.... موبایل گوشی

Balu Ertl’s picture

The hyperlink below the first screenshot, after the title 'Why Drupal was chosen', doesn't seems to work properly for me, redirects to 404.
In my opinion I would kindly suggest to add the http:// prefix before www in the href parameter of this item:

<a href="www.law.stanford.edu" title="Stanford Law School" rel="nofollow">Stanford Law School</a>
webdrips’s picture

Thanks!

Need Drupal module or theme design? Please visit Webdrips to learn how we can help.

mods’s picture