Thiết kế Drupal site: Stanford Law School

Hàm kiểm tra nguyên tố nhận vào một số nguyên n và trả lại kết quả là true

Tính và in ra trung bình cộng của các số âm, số dương trong array Pascal

Posted by: Khanh Hoang
Fri, 20/07/2012, 10:07 (GMT+7)
0 Bình luận

Thiết kế Drupal site: Stanford Law School

Why Drupal was chosen:

Stanford Law School (SLS) wanted to migrate their unwieldy proprietary legacy CMS called Pentagram to Drupal. The primary reasons for the migration include:

Drupal has become the de facto standard at Stanford, with hundreds of Stanford sites now built on Drupal and more added daily.
The desire to move away from an unsupported legacy CMS that was bulky to update (think CakePHP) to an open-source, scalable, robust CMS that meets their needs now and in the future.
The need for content managers spanning several departments and students to easily add, edit, and manage content and event workflows.

Completed Drupal site or project URL:

http://www.law.stanford.edu

Webdrips migrated a database-driven proprietary content management system to Drupal 6. This provided a significantly improved content editor experience, allowing for content to be reused and automated in ways not feasible using the legacy CMS. Event workflows were also a major area of improvement, eliminating some of the clumsy UI issues faced by event content editors.

Describe the project (goals, requirements and outcome):

Goals

The primary goal of this project was to migrate from a legacy CMS to Drupal, including 10,000 pages (mostly) stored in the database, the complex theme, and proprietary code. The secondary goal was to make improvements where possible, especially to the way in which complex page hierarchies were handled. The timeline for the project given the limited resources was 12 to 18 months. Also, with over 300,000 page views and 80,000 unique visitors per month, we wanted to be sure the performance wasn't noticeably diminished.

Requirements

The primary requirements of the site were as follows:

A homepage (see screenshot above) that provided a central hub for the school's latest social activity, such as real-time tweet updates and a carousel view displaying the latest news, events, blogs, and articles.
Five information portals (see screenshot below): provided a mega menu with links related to the portal (e.g. alumni), news, events, publications, blogs, and other information related to the portal.
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 broken down by event type, audience, etc.
News Center (see screenshot below): a hub for displaying latest tweets, news, press releases, and publications. The page was also a launching point to all of the school's tweeters and bloggers.
Library section (see screenshot below): a collection of pages, news, events, and other information related to the Robert Crown Law Library.
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 over 100 lines of code.

Primary Content (Page) Types

Areas of Interest: SLS has six primary areas of study, so these pages provided 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, etc. 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 so that content managers needed only 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: included 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 separate Stanford site using an XML feed.
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 targeting students that explain the school, program, and experience. These pages included 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, etc. 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 included their name, contact information, photo, CV (résumé) file, biography, awards/honors, education, areas of expertise, and website links.

Outcome

With over 17,000 lines of custom CSS, PHP, and JavaScript code, the project was delivered in the desired time frame, and 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 their needs.

One of the biggest challenges was the lack of a true project manager, so 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 complete 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.

Modules/Themes/Distributions

Key modules/theme/distribution used:

Content Construction Kit (CCK)

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]_renderedobject 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 SLS 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. SLS 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: SLS 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 SLS 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:

webdrips

Stanford Law School Alumni portal