7 Steps to Building A Drupal Site Within a University Environment

Tracy Smith & Rob Knight from Quiddities, Inc. presented on their experience with doing their first ever Drupal site within the Berkeley campus. They developed the College of Letters & Science website at: http://ls.berkeley.edu They presented an overview of their lessons learned

Background Context

• Quiddities, Inc. is located in Santa Cruz & started with Joomla!, but have since made the change the Drupal and haven't looked back since.
• Worked on the http://ls.berkeley.edu site from March to May 2007 developed it in Drupal 5
• Used 18 Modules
• Developed 550 Content Items

• Had Content from 1890 to 2007 -- some of it probably not needed.

• What did they learn?

1. Know Your Stakeholders

• Make sure they know each other because sometimes they don't.

• They use BaseCamp and get everyone on together with the same Project management software as soon as possible.
  Get them talking to each other.

• There are many roles and departments -- Create a variety of different Drupal user roles and start testing those as early as possible.

• Roles & Workflow -- Know who the users are to find out what their needs are, pull it all together, and then present it back with the specs of what they want. In the end, you have to please the user and give them a happy experience

2. Know Your Environment

• Current Website Platform -- do analytics on it right away to be able to compare the way it is now and the way it is after. Need a baseline for comparing the Google Analytics to later, which provides a lot of really rich data for optimizing the site from a themer's perspective

• Create a development strategy -- have a dev sandbox, QA server, and a live production server -- test it on the test server (the one that you can break) before it goes live. They started with six people working on the site at the same time, and when they got the White Screen of Death you can disturb whomever else is supposed to be using the site for their work. So be sure to break things on the dev sandbox and QA server first.

• Internal Server Hosting Constraints with a lot of other sub-domains & redirects. They're on a Berkeley server with a lot of various different sites. They recommend being able to put Drupal onto its own server if possible because dealing with a convoluted .htaccess file with a lot of other server configuration conflicts can be a bit of a nightmare. If doing it again, they'd put the http://ls.berkeley.edu site on its own server as quickly as possible and migrate it over slowly.

3. Be prepared to Sell Drupal -- (Hint: Just saying "It's free software" doesn't work)

• Be sure to go through the various advantages and disadvantages -- and emphasize how the extensibility and flexibility are such a huge benefit that makes it worthwhile even with its limitations.

• The Cost of IIS and .NET are actually priced competitively with the cost of maintaining a LAMP stack on campus

• Drupal sells itself, but it'll need your help

• Drupal use on the Berkeley campus is growing -- as evidenced by how many people are showing up to the Drupal user group meetings

• Programming in Joomla! can be quite tricky -- there is a Drupal learning curve, but once he picked up some key concepts, then it gets a lot easier. Be sure to learn FORM API, and learn how the Drupal hooks work. And they're still learning as well. They were wireframing the site last night and ran into four things that they've run into the past, and was able to tell them about it very quickly. But each of those four things can be an hour's worth of research and homework in order to find the best solution.

4. Watch Your Scope

• Requirements can very easily explode

• Drupal is flexible -- which can be both good and bad

• You don't necessarily need to do a 30-page scope page -- you certainly can -- but you need to be clear about what you'll have at the end of the day. Drupal wireframing is great for doing a quick site to quickly show the customer what they can expect.

• There are many different possibilities that come from one request. Sometimes say that Drupal can probably do something before really researching how long it will take to actually integrate it. Sometimes you can also hammer something out very quickly. But ultimately you need to step back to think about the user first and what they need.

• Important to think about the future

5. Be Prepared for Delays

• Be aware of how scheduling conflicts can create delays

• Custom development -- need to be able to spec out exactly what's needed -- especially if people will be gone at the end of quarters and summer breaks, etc

• Summer break is pretty silent

• Got server access? -- Do this BEFORE any breaks -- otherwise you'll be waiting for a few weeks. But once you have server access with the Drupal CMS, you can start on the theming aspects even before you have any content.

6. Content Preparation

• Information Architecture is key -- while browsing a site, it's easy to say "Where am I?" -- easy to get lost on existing sites -- so designing the IA is key

• Determine necessary content types -- What are your content definitions that you use? They uses the content types of Page, News items, and a FAQ topics and FAQ Q&A

• Outdated content must go -- The more that you prune and streamline upfront, the more you save yourself in time later

• Be sure to look for content at all levels

• Regarding Data Migration: It was easier for them to brute force copy and paste into NOTEPAD because it was tricky to strip the HTML out of the content automatically. It was easier for them to have eyes on and decide where its suppose to go and what other content pieces need to be linked to it. That's one area that could use some UI improvements -- the node-to-node linking mechanism for the end user -- in order to help them view their site and be able to see how their pages are related with each other.
  Someone suggested using URL aliases, and then use the L() command is another way to do this.

• Also, someone else suggested that the end user needs to be able to link to another page -- especially in WYSIWYG UI -- but what they've found to be the best is to implement a wiki input filter -- something link [TITLE LINK_Name] -- works really well for lowing the barrier for link creation for folks not familiar with HTML.

7. Bring It Home

• Test the user roles & access levels -- It is pretty common to have 10-12 different admin levels that have different rules -- and so they needed to test the access levels.

• You also need to train the admin users, and plan on a variety of skill sets and a diversity of HTML-knowlededge

• IMPORTANT -- Implement and monitor a backup scheme. Important for any site. But it's especially important when you're on a shared server situation. Their site is living in the webroot with the cgi-bin -- so the .htaccess can be a nightmare -- can't run clean URLS on a shared server environment at the moment -- but they're working on a solution that should go live in a couple of weeks.

What Were the Drupal Pitfalls to Look Out for?

• Mod_rewrite couldn't be turned on -- within the next two weeks it should be working -- but clean URLs & Pathauto had difficulties to generate aliases. When you're seven levels deep, you get really huge URLS. They strive for a cleaner URL structure. They'll have a better solution for that within a couple of weeks.
  Knowing your URL schema upfront makes your life a lot easier as well.

• Took and altered Nice_Menus.module, which creates nice drop-down menus. An official Drupal 5.x release for this module hasn't been made yet.

• Where do themes go again? -- They made a beginner error or putting them in the core theme folder instead of the sites/all/themes directory

• Be sure to put any PHP theming logic in the template.php and not the *.tpl template files. The *.tpl template files are just that -- templates for how the HTML code is generated. Variables are put in there, and the PHP logic needs to be broken off into the template.php file in your sites/all/themes/theme_name directory

• Caching? Not yet, but will be looking into the Virtual Hosting environment and other solutions soon.

Why Quiddities Loves Using Drupal for Berkeley Sites

• Security -- have had other CMSs hacked, and haven't had any problems with Drupal security thus far.

• Flexibility -- having content separated from presentation -- having template files to change things as he needs.

• Powerful Extensibility -- Had a launch that didn't include an archived news section, and an after an afternoon of CCK and Views, they were done

• Multisite -- will have in multisites in production soon, and there are some big benefits to be able to run multiple sites off of the same Drupal installation.

• Thank you

QUESTIONS

• How do you identify the editorial process? And how do you get buy into an open access content system versus a closed system?
  Upfront ask the users what the roles are, and work on getting buy in w/ Drupal. Make it work for the user -- optimizing the workflow is important. Should it get approved before it's published? etc. Get the IA ironed out with the user and get defined roles.

• They also usually try to talk in Drupal terms. For example, Drupal is more rich than Joomla! when it comes to Access controls & user role management. It's not always as granular as they like it, but it's the best out there. And Drupal is also flexible enough that you can get it as closed down so that only one person has access for publishing.

• Do you use Taxonomy Access? Sometimes the user doesn't have the correct permission -- sometimes give them all permissions to see if they can do it, and then slowly take them away with a process of elimination of which access the user really needs.

• That's the thing about Drupal -- There are usually 10 different ways to do any one thing -- it's great that there are all of these options. But the horrible thing is that there are 10 different ways, and you have to do your own homework to figure out which one is the best for you.

Calnet.module Authentication Module Could Use Some Help and Attention

At the beginning of the meeting, Tao Starbow wanted to stir up some more momentum behind the Calnet.module authentication module.

Update: It looks like the drupal cas.module (http://drupal.org/project/cas) is the better way to go.

It's used for http://bigideas.berkeley.edu

There is a project that has been created, but only the issue queue is active at this point at http://drupal.org/project/calnet

The CVS Code is here: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/calnet/

What needs to be done?
The infrastructure is there, and people are open to participate.
Security audits before release -- needs more testing
Need more people to look at it, and poke at it before an official release
CivicActions has security specialists that people can look over if they want to subcontract this out to them.
There are some Big Ideas specific code that needs cleaning up
Upgrade it to Drupal 5.x
Needs more error handling around aws.php
Need to change the copyright notices

LDAP & aws
Don't allow direct access to LDAP on campus

Campus is moving to Centralized Authentication Service [CAS] authentication -- AWS will be obsolete by 2009.

CAS got beat by OpenID, and the next version will be integrating OpenID into it.
http://wiki.case.edu/Central_Authentication_Service

Vahid adds that all Calnet related info can be found here: https://calnet.berkeley.edu/developers/
There are also links to CAS and AWS on the left-hand menu -- plus some code samples for different languages.

Bay Area Drupal Camp

There will be a Bay Area Drupal Camp on November 2nd and 3rd. You can find out more information at the website here:

http://badcamp07.org

Everyone is encouraged to get involved and participate by proposing your own session or a round table discussion.