I’m currently running Drupal 4.6.6, Drupal 4.7 RC3 and CivicSpace 0.8.3 . I preferred to have one set of source files, but I wanted each site (Apache vhost) to have its own root folder.

So, with some symlink magic, here’s what I do. Each version of Drupal has its own directory under my servers web root. I have the following directories and symlinks:

• drupal-4.6.6
• drupal-4.7.0-rc3
• civicspace-0.8.3

• drupal-4.6 -> drupal-4.6.6
• drupal-4.7 -> drupal-4.7.0-rc3
• civicspace -> civicspace-0.8.3

Each vhost has its own DocumentRoot with the following symlinks, substituting drupal-4.6 or civicspace for drupal-4.7 as appropriate:

• cron.php -> ../drupal-4.7/cron.php
• database -> ../drupal-4.7/database
• includes -> ../drupal-4.7/includes
• index.php -> ../drupal-4.7/index.php
• misc -> ../drupal-4.7/misc
• modules -> ../drupal-4.7/modules
• scripts -> ../drupal-4.7/scripts
• sites -> ../drupal-4.7/sites
• themes -> ../drupal-4.7/themes
• update.php -> ../drupal-4.7/update.php
• xmlrpc.php -> ../drupal-4.7/xmlrpc.php

Each vhost gets its own files/ directory, robots.txt, .htaccess and favicon.ico files.

Now, when the next version (e.g. 4.7.1) is released I can unpack the files, copy the sites folder from the previous version, and then update the version symlink (drupal-4.7 -> drupal-4.7.1) and run the update.php script.

If I want to change a particular site from Drupal 4.6 or CivicSpace 0.8.3 to Drupal 4.7 I update the symlinks in the DocumentRoot to point to the 4.7 series, copy the appropriate site config file over and run the update.php script.

This is working well so far, but in my recent “Memory Hogging” blog I mention that having too many modules installed (even if not activated) make the admin/modules screen take up tons of RAM. My sites have different modules needs, so I think I’m going to give each vhost its own modules directory and then symlink the modules under that. This way I’ll have only one module version per drupal version in my filesystem and be able to remove modules I know don’t need from individual sites.

Although a relative newbie, I have some observations on CivicSpace 0.8.3 as compared to a base Drupal install:

• The “plain text” input filter allows unfiltered html!
• The bug list isn’t closely monitored. I submitted the unfiltered html issue to CivicSpace as a bug, and 4 1/2 days later it is still unassigned and has no replies.

• The zadministration panel has a cute front page but mucks up the administration navigation menu in a way that’s confusing to me, different from Drupal (and therefore Drupal documentation and discussion) and when you turn off the zadministration module your administer settings are scattered amongst the top level of your navigation menu; in other words you don’t go back to Drupal normal admin when disabling zadministration. EDIT Dec 20, 2006: I just noticed how to avoid this problem when disabling zadministration: Before disabling the zadmin module, from the zadmin panel, click “Activate/Deactivate this page” and then push the “Deactivate” button. Then the admin menus return to their Drupal state and you can safely disable the zadmin module.
• CivicSpace seems to be a memory hog compared to Drupal. CivicSpace recommends setting php.ini to use 24M of memory, but on my 256M virtual server I keep running out of VM pages when I do that. I’ve tried different settings and had problems at 8M and 12M; I’m at 16M now but I haven’t had a problem with a Drupal site at 8M with the same modules enabled yet. I think the enabled statistics module may be to blame, but I’m not sure yet. (I have CivicCRM turned off. I could also probably tune apache and MySql to not use as much RAM, but I haven’t tried that yet.)
• After upgrading CivicSpace to Drupal 4.7 rc3 with a mix of Drupal 4.7 and cvs modules, the “my profile” page has some odd characters on it.

These past two or three weeks I’ve been working hard on figuring out CivicSpace / Drupal. I’m ditching CivicSpace 0.8.3–based on Drupal 4.6–and going with Drupal 4.7 rc3.

Drupal 4.7 is very new. In fact it hasn’t been officially released yet. But there are enough changes I think it’s important to go ahead and switch now while my websites are young and shy on content. The big feature for me is the free tagging additions to taxonomy. I don’t fully understand these yet but have some ideas on how I want to use them. As I understand it, the backported free tagging / folksonomy patches for 4.6 are sufficiently different from 4.7 as to cause upgraded headaches.

At first CivicSpace sounded like an easy-to-install Drupal distribution that included a robust default configuration with popular modules. I had used Drupal 4.6, but hadn’t quite figured it out, and CivicSpace seemed slicker. Perhaps it helped; I don’t know. But I’ve already outgrown the need for the preselected modules. As far as the easy install, it was easy, but I didn’t have a problem installing Drupal in the first place. As I learned to use CivicSpace I decided I didn’t like their “zadministration” modified administration menu, didn’t use the features (CivicCRM) that set CivicSpace apart from Drupal plus modules and started to suspect that CivicSpace is enough different from Drupal that “upgrading” to Drupal could be a problem, especially with established content.

So, on the the upgrade. I installed the drupal 4.7 files in a new directory, copied my files/ directory and configuration directory over and checked the .htaccess and robots.txt files. I downloaded and installed the modules that were enabled in CivicSpace but not included with Drupal. Some modules have a 4.7 version, some I had to get the cvs build. Actually I left out the zadministration panel module because I couldn’t find it on Drupal’s site, and I hate it, anyway.

EDIT Dec 20, 2006: I just noticed how to avoid the administration menu problem when disabling zadministration: Before disabling the zadmin module, from the zadmin panel, click “Activate/Deactivate this page” and then push the “Deactivate” button. Then the admin menus return to their Drupal state and you can safely disable the zadmin module. (/EDIT)

Drupal 4.6/CivicSpace don’t have a “site maintenance” mode; I wanted to prevent possible changes to the database during the upgrade. I found suggestions on using conditional apache redirects, but it occurred to me I could just remove authenticated users’ permission to access content. To make a friendly message, I created a new block for the top of the left column explaining the site was briefly down for maintenance. After enabling that and disabling “access content” under the node section of the access control page everybody except user #1 gets “Access Denied”, the login box and my site mx message block. I patted myself on the back for being so clever and knowing how to do this.

I backed up the databse. The files hadn’t changed since the daily backup, and I didn’t intend to delete or overwrite anything, so I didn’t do any specific file backup. I logged in as user #1 as per the upgrade instructions. I disabled the zadministration module because I wasn’t going to use it in 4.7. I used the unix “mv” command to move the existing install to an old/ directory and move the new directory in its place. Already logged in as user #1, I browsed to /update.php . Drupal 4.7 is pretty slick in that it has upgrade hooks for its modules, meaning you don’t need to update modules individually. This screen handles upgrading the datbase for the system and all hooked modules.

That was easy, and then the site worked fine. I poked around a bit and then reenabled user access to content and disabled the site mx message block. There were a couple of oddities at first, but they cleared and were apparently caching issues. Only two issues remained: the admin menu was messed up due to disabling zadministration; the primary links were missing (I don’t use secondary).

EDIT Dec 20, 2006: The zadministration menu issues in the previous and following paragraphs are avoidable by “deactivating” zadmin before disabling the module. See my earlier edit above for details. I haven’t upgraded a deactivated zadmin site yet, so I’m not sure yet if the Primary Links problem will still happen.(/EDIT)

These issues are actually the same. Drupal 4.7’s main menu is called “Primary Links” and is propogated to the Primary Links area on the theme as well. But due to the zadministration influence your “upgraded” menu doesn’t fit the scheme. I had done a Drupal 4.6->4.7 upgrade before the CivicSpace upgrade, so I knew what the menu should look like. Rather than rebuild it by hand I used mysqldump and mysql to dump the menu table from the “good” site’s menu and import it into my upgraded CS site, overwriting the existing structure. (Lots of backups and careful typing here, of course.) It worked great! I then had to delete an item I had added to the other site’s menu and manually add links to my aggregator sources. Interestingly it automatically deleted the invalid aggregator source links that were imported from the other board. After this my navigation menu, administration menu and Primary Links along the top of the page were working spiffy and the menu adapted to new modules I enabled. UPDATE: Drupal 4.7 doesn’t add menu items under aggregator/sources anymore; that’s probably part of why I had to manually re-add the menu items after doing my menu trick. Come to think of it, I think I’ll take the aggregator/sources subitems back off again as I have too many feeds to make sense of; I’ll set up the categories instead.

The only two remaining glitches I know of are that the profile page is slightly garbled and the “1,2,3 next page” links are squished together for some reason. The squished links are on my 4.6->4.7 upgrade site, too, so I don’t know if that’s an rc3 issue yet or an upgrade artifact. UPDATED: The “squished links” were apparently also a caching issue (cached CSS file?). It looks fine now for both the 4.6->4.7 site and the CivicSpace->Drupal 4.7 site, and I haven’t changed anything.