When my wife ran for State Representative, I set up a domain, smartcampaigns.com where I could easily host many CivicSpace sites. Over time, it has gone from a handful of sites, mostly in Drupal 4.4 running on a couple different Windows 2000 servers with IIS in peoples houses to over three dozen sites running a collection of versions of CivicSpace on a resellers account at a reliable hosting service.

Part of my approach has been to use a shared directory for the files and a shared database. The shared database is accomplished using the db_prefix variable for CivicSpace. As a general rule, I set up one database for each shared directory. For example, I had one database for version for CivicSpace 0.8.0.1, another for CivicSpace 0.8.0.3, a third for CivicSpace 0.8.1 and then a few special databases. Each site was then set up with its own section for its files, including files for theme_editor. As a general rule, each site uses the box_grey theme, customized through theme_editor.

With this many sites, I need to find a clean quick way of updating sites from one version to the next. I’ve started updating some of my sites to CivicSpace 0.8.1 and have run into various interesting issues which I will outline here.

First, I dumped out my ‘0.8.0.1’ database using mysqldump from a command line. I strongly recommend anyone that is doing serious CivicSpace work to get the MySQL client so you can run commands from your command line. With seventeen sites in this one database, some of them very active sites, the dump worked out to be about 350 Meg.

To move a site from my ‘0.8.0.1’ database to a new install on 0.8.1, I selected out all the records for a specific db_prefix. Since the file is 350 megs, using a standard text editor was too cumbersome, so I used a combination of the head and tail unix commands to get the sections of the dump that I wanted.

I then loaded the section of the dump for the specific site into my new database and could start the upgrade.

Since I am using a single directory for many sites, I don’t make a test site, muck around for a while, and then make a production site. Instead, I just link the production 0.8.1 directory in with a new name, work with the new name and when it is ready, just drop the link to the patched 0.8.0.1 directory and link the site name to the new directory.

The first site I upgraded went without a hitch. It was a simple straight forward update. The second site ran into a problem. For some reason the update script got confused about what the next sequence number for the flexinode types are and the script failed. I suspect there is some problem with flexinodes in at least one of the versions of CivicSpace that caused it to not work properly with db_prefix. This is a problem that needs more investigation.

The third site I tried to upgrade had another interesting problem. The theme editor theme engine in 0.8.0.1 was in the themes/engines directory. That worked in 0.8.0.1, but in 0.8.1 the theme editor theme engine needed to be in the themes/engines/theme_editor directory. Since the file was in a different location, the following error occurred:

warning: init_theme(themes/engines/theme_editor_engine.engine): failed to open stream: No such file or directory in civicspace-0.8.1/includes/theme.inc on line 88.

This probably would have been okay. However, the process then attempted to write an error message in the watchdog table. With 0.8.1, the watchdog table has a new column, severity. Attempting to add a record to the watchdog table without the severity column added resulted in a fatal error that caused the whole process to terminate. I manually added the severity column and I then successfully reran the process.

I now have five of my CivicSpace 0.8.0.1 sites successfully moved to 0.8.1. I’ve also run into a few other random issues. The problem with the theme_engine, listed above, resulted in the theme information not successfully being copied to the new site. It was a minor annoyance but could easily be reset.

I’ve also used the slurpee theme a little bit for a specific client, but I was disappointed to find that the theme editor doesn’t pick up the slurpee them as one that can be edited.

As a final comment, by having all the sites in the same database, it makes it possible to create special scripts to check all the sites at the same time. As an example, using SHOW TABLES I can display a list of all the sites within a database, and by doing some other queries, I can see how many hits I’m getting for all of my sites within a specific time frame.