Voting starts in March for the Drupal Association Board election.
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.
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.
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.
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.
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.