Drupal 6 from Drupal 5 – 130 multisite installation and 'A Drupal Open House'

This is a sketch of our upgrade plans at the University of Prince Edward Island for the week of the 8th of December. It includes an invitation on the 10th of December to the Drupal community (here in Charlottetown PEI, Canada and abroad) to come in and see what we're about.

History

Over the past 18 months the university has been switching the majority of its outward facing web presence to Drupal. We've gone through a large number of iterations, of plans, of perspectives and have slowly honed our way to a point where we have some sense of what we want to do, of what works in our environments and how to scale drupal out across our university campus. We have created a number of modules, put aside our entire first set of code and plans and have moved to what we see as a nice way forward.

But what to do with all the legacy code and modules? We currently have 130 multi-site installations, have great hopes of getting under 60 at some point, but as our initial plan was a mind-bogglingly huge 300 installations, we're pretty happy to be where we are. As many of the local sites were built ad hoc from the beginning and have yet to be fully upgraded, we still have single installations running a particular module or other, or hanging on to a particularly outdated philosophy. In the same period of time, modules have faded from prominence (Tinymce has not, some say, been upgraded for 17 months) and we've discovered any number of other ways to do stuff

We have also started to integrate our UIS (student information system+) into our website. We are now able to import courses (via XML) directly from the database and are working towards the integration of other content in order to move to a single source iconic model of information management. We are only really at the beginning of this but with the excellent help of our computer services group, we should get there by the end of next year. This does, of course, mean that we will be dealing with outdated content on many sites that will need to be updated. And, as we've decided to do our newest developments in drupal 6 the invitable conclusion that we have come to is that an upgrade to drupal 6 will address the largest number of our legacy issues with the 'least' effort.

Solution

Our solution then, is to rush our upgrade to drupal 6 and clean everything on the way over. This allows us to rid ourselves of legacy code and modules, forces a unification of our existing module and theme code in assessing it for upgrade, and allows us to apply our newer philosophies to all the sites as they come over.

We've set week of the 8th of December as our target date for this upgrade and hope, given a little luck, to be able to complete the upgrade by the end of that week. We're plugging away on the code right now and have managed to port most of our stuff to 6 and hope to be able to release that code early in the new year. None of it is particularly mindbreaking but rather a little snippet here or there, a simple module or two to help us deal with the fact that we have 3 people handling 130 installations and 300-400 content creators for an institution that is actively marketing itself and has things changing and improving all the time.

The Code

We have a number of customizations that we've put together over the last year to give us some efficiencies as well as added security. It probably needs to be added that each of installations starts from a standard 'template' version of drupal created by a bash script. The following is a 'most of it' list....

MODULES

'scrape' – This is our word for our use of httrack to make static copies of drupal which represent the majority of our websites. It is being built into a module for drupal 6 (from the bash script hack we had in drupal 5) that allows for a html mirroring of the site on the same server or another server to increase performance, reduce the appearance of errors and improve security. The module is role sensitive and can be employed in a fairly granular way. In our instance, the drupal installation is behind the university firewall and the html version is open to the world. For those sites that require more interactivity, we simply proxy the site through the firewall in apache on the html computer.

'campus management'
- creates roles called "content manager" and "super admin" if they do not exist.
- Creates "Other Content" Menu and block not visible to anonymous users, allows us to add links which users can switch to where they want
- Creates "Main Navigation" to replace default navigation
- Sets default navigation to administration navigation
- adds blocks to the content top section for across campus notifications
- adds block to the top of the left side bar for content manager messaging.

'faqs'
- makes a content type for frequenty Asked questions.
- simple title and body type
- creates a page view for FAQs available by RSS

'communications'
creates a content type called "campus connector" which is a notice type which sets up a global and local RSS feed.
allows the integration of other communication content types for the future.

'campus emergency module' – This module allows us to enable a jquery screen that overlays each of our website pages on a reload (for viewers internally, or to the world... there is a toggle switch) that forces the user to take a 10 second look at the emergency message. The user can refresh or change pages to rid themselves of the overlay, but it will reappear in 15 minutes should the emergency still be ongoing. After the 10 second warning, a 'close' button appears that allows for the easy dispersal of the overlay. The module is using xml to send the message and we have attached it to our campus information monitors so that an authorized 'emergency manager' can, with one click of the button, send a message to all the websites and the monitors with one click.

'Campus communications module' – This is the workhorse of the operation... it provide a standard menu across all sites, an information block for content managers that can be used from a central multisite installation to send information to site creators, and a variety of standardized functionality like role sensitive content lists that make the creation/editing of content a little easier.

THEMES

Banners – We've done two customizations to banners. The one, allows for banners to appear based on pathauto (mimicking a module that didn't quite do what we wanted) and another, still in development that will allow us to create location sensitive banners on the fly from content available on local sites.

Sub-Themes We have created Newsflash subthemes. A red "Market" theme and a green "Faculty" theme.

CUSTOMS

'sub-sites' – We are attemption to eliminate many of our multisite installations by finding a location within our existing university structure to create a subsite. These are actually quite simple. We use a content type/role/pathauto/viewsblock menu combination to create a subsite that maps up against our local banners to give some sense of a local feel but remaining part of a larger organization. With the management module providing a role sensitive content list and the view autogenerating a menu from node titles it allows the content creator a customized feel.

Upgrade Plan

This should give you some sense of what we are up against for our upgrade on the 8th of December. We are setting aside a week of time where our local content creators will not be able to access the content of their websites while we do the upgrade. The world will still be able to access the static content from upei.ca and we will probably focus on getting our 'main' page up relatively early so that we can start to use that for keeping people up to date with what's going on.

PRE-PREPARATION
For the last couple of weeks we've been taking a look at different modules that we're using and evaluating whether we need them or not, we are also trying a few upgrades out to see how they are working. We have, for instance, (tentatively) decided to move to FCKeditor from tinymce due to the greater activity around that module. We are also hoping to trim our list of used modules down considerably as the constant upgrades across 130 installations is very nerve racking and time consuming. We have also almost completed upgrading all of our custom code to drupal 6 (while looking towards generalizing it for releasing the code early in the new year) and will certainly have to have this finished and tested before go time at 9am Atlantic time on December 8th.

DAY 1
The morning of day one will be entirely put over to scripting out our upgrade path, organizing the different websites into an upgrade order and ensuring that all the different websites are accounted for and that a given person is responsible for taking care of that website. The afternoon of DAY 1 will be take an example of each 'type' of website, follow the upgrade plan and check to see if it works... check all the logs and pages to ensure that the upgrade went according to plan.

DAY 2
We will start to ramp up to speed and get the final plan from the day earlier moving in a positive direction. We'll focus on some of the more active sites in order to ensure things like 'views' and 'panels' will get completed by the end of the week.

DAY 3 OPEN DRUPAL DAY
We have reserved a space on campus with plenty of computers for our 'open drupal day'. We'll be doing our upgrades out in the open and accepting all interested drupalers (online or f2f) and give them a tour of our facilities and give them a sense of what we've been doing here for the last 18 months. People will be encouraged to leave suggestion or even join in if they are willing :) (maybe)

DAY 4
This will hopefully be a very smooth (yeah right) day of processing the more static sites and their transition to drupal 6.

DAY 5
If all goes well, this will be a day of turning on websites and patiently waiting for fires to erupt so that we can put them out.