When deciding to create the IT Know-It-All site I reviewed my options. My goal was to write about my IT experiences—discovered solutions, lab tests, and reports on my research—to share them and to create a navigable knowledgebase for myself. I had originally envisioned a site with a knowledgebase engine, but later realized  blog with search and tags would work just fine for my purposes and be easier to update and maintain. Wordpress does this “out of the box” with no additional modules, is quite popular and well-maintained, so I chose Wordpress for the new site.

I found no reliably simple way to import two Drupal sites’ articles into Wordpress. I didn’t have that many articles, and none with photos or other media, so I viewed them with Firefox with “no style” chosen and simply copied each article to the clipboard and then pasted it into a new Wordpress post on the new site, then adjusted the publish date. That worked surprisingly well. (I then set up redirects, but that is out-of-scope for this post.)

So far I really like using Wordpress. Drupal can do more and is more flexible, but without thinking about it I had reduced my Drupal sites to a level of simplicity that Wordpress does better. I have two more simple Drupal blog sites, and I think I will convert them to Wordpress, too. My Drupal sites are at least one major version behind because upgrading would cause module issues, so I might as well update (for my purposes) to Wordpress.

I haven’t yet converted my real web server from Apache/mod_fcgid to Apache/mod_fastgi with an externally spawned FastCGI process. It is doable and works fine, but it is a pain to configure it how I want it to work.

I’m not sure I can blame Apache or FastCGI. It actually makes sense how they are doing it. However, I tend to install PHP software packages like Drupal, Simple Machines Forum, Mambo/Joomla, Gallery2, WordPress and so forth. Generally these applications are built with Apache/mod_php in mind and take some tweaking to make work on other setups. But I don’t want to tweak, especially if I have to do it periodically when upgrading.

I switched from lighttpd/ModFastCGI to Apache/mod_php/Squid because I was tired of fiddling with lighttpd rewrites to make pretty urls for Drupal and SMF which include ready-made Apache pretty rewrite rules.

Apache/mod_fcgid has worked pretty well so far, and with the AddHandler directive it behaves like mod_php: Any .php files under the document root will be parsed by the PHP interpreter. The downside is that any caching–like APC–is not share across the PHP processes.

So I wanted to spawn my own PHP FastCGI process with several child processes sharing a cache like I did with lighttpd and then have Apache use it. That works, but the mod_fastcgi FastCgiExternalServer directive behaves much like a ScriptAlias directive: if you specify a folder, anything under that folder will be processed by the FastCGI server, so you can’t easily mix static files with PHP script files. I tried hacking my way around this with various combinations of symlinks, aliases, handlers and rewrites, and I even got a couple of the combinations to work, but I would have to make changes to each Apache virtual host (or enforce a strict naming scheme for my vhosts), and if I missed something it would be too easy to accidentally serve up the source of a .php file.

Now if I were making an application from scratch it would be fine to put the PHP files in a script folder and the static files elsewhere, and I could alter premade software like that with rather simple aliases, but I would have to do it for every installed instance and then re-tweak every time I updated the software. No thanks.

I was able to spawn a separate PHP FastCGI server with children and have Apache connect to it. It was trickier than I thought. The big benefit is that one shared APC cache can serve all the PHP child processes and being able to use a multithreaded Apache without worrying about whether my PHP dependencies are thread safe.

The trick isn’t getting it working, but getting it working the way I wanted. I want “.php” files to be processed by the FastCGI server and have the other files sent by Apache. Without some tricky configuration, Apache’s mod_fastcgi can only send specified file requests or specified directories–plus all their contents–to the external FastCGI server.

But I am getting ahead of myself. Let me back up to my old lighttpd setup: I had lighttpd installed, and a script that launced several php-cgi processes and listened on a network socket. Lighttpd would connect to the php-cgi processes and let them handle PHP processing. Apache can do this, too, but it was hard for me to easily find out how online.

As it turns out, the spawn-fcgi program from lighttpd that I used to start the FastCGI server is now a project on its own. Supposedly the mod_fastcgi developers have a launcher program, too, but I couldn’t easily find it, and I was already familiar with spawn-fcgi and was happy to see it’s being maintained. I downloaded the source package from the site, extracted it and then did the usual “./compile”, “make” and “sudo make install”. So now I have /usr/local/bin/spawn-fcgi installed.

There is some good info on lighttpd’s ModFastCGI documentation site on launching a PHP server with spawn-fcgi and various helper scripts. I modified one slightly to make it use a unix socket instead of a network tcp socket:

#!/bin/bash

## ABSOLUTE path to the spawn-fcgi binary
SPAWNFCGI="/usr/local/bin/spawn-fcgi"

## ABSOLUTE path to the PHP binary
FCGIPROGRAM="/usr/bin/php-cgi"

## TCP port to which to bind on localhost
FCGIPORT="1026"

## bind to unix domain socket
FCGISOCKET="/tmp/php.sock"

## number of PHP children to spawn
PHP_FCGI_CHILDREN=4

## maximum number of requests a single PHP process can serve before it is restarted
PHP_FCGI_MAX_REQUESTS=1000

## IP addresses from which PHP should access server connections
FCGI_WEB_SERVER_ADDRS="127.0.0.1"

# allowed environment variables, separated by spaces
ALLOWED_ENV="ORACLE_HOME PATH USER"

## if this script is run as root, switch to the following user
USERID=www-data
GROUPID=www-data

################## no config below this line

if test x$PHP_FCGI_CHILDREN = x; then
  PHP_FCGI_CHILDREN=5
fi

export PHP_FCGI_MAX_REQUESTS
export FCGI_WEB_SERVER_ADDRS

ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS FCGI_WEB_SERVER_ADDRS"

### This if-then-else is for opening a network TCP port
#if test x$UID = x0; then
#  EX="$SPAWNFCGI -n -p $FCGIPORT -f $FCGIPROGRAM -u $USERID -g $GROUPID -C $PHP_FCGI_CHILDREN"
#else
#  EX="$SPAWNFCGI -n -p $FCGIPORT -f $FCGIPROGRAM -C $PHP_FCGI_CHILDREN"
#fi

### This if-then-else is for opening a unix socket
if test x$UID = x0; then
  EX="$SPAWNFCGI -n -s $FCGISOCKET -f $FCGIPROGRAM -u $USERID -g $GROUPID -C $PHP_FCGI_CHILDREN"
else
  EX="$SPAWNFCGI -n -s $FCGISOCKET -f $FCGIPROGRAM -C $PHP_FCGI_CHILDREN"
fi

# copy the allowed environment variables
E=

for i in $ALLOWED_ENV; do
  E="$E $i=${!i}"
done

# clean the environment and set up a new one
exec env - $E $EX

In the above script I had to use /bin/bash instead of Ubuntu’s default /bin/sh as it uses some of bash’s features. Also note that with spawn-fcgi you can have a network tcp socket or a unix socket, but not both. On my test server I just simply ran the above script as root; it won’t restart itself if the VPS is restarted or if the script crashes. I have daemontools on my real server, and I’ll use that to start and monitor the launcher script. The link to lighttpd’s site has other startup scripts worht looking at.

You can’t use mod_fcgid to connect to the externally spawned FastCGI process. It can only launch and manage the processes itself. So I loaded mod_fastcgi and used the FastCgiExternalServer directive:

<IfModule mod_fastcgi.c>
  FastCgiExternalServer /srv/www/site/fcgi -socket /tmp/php.sock
</IfModule>

That tells Apache that any request under the /srv/www/site/fcgi directory gets passed to the FastCGI process with a unix socket at /tmp/php.sock. Unfortunately there is not an simple configuration to have it just run php files, and the FastCGI server may not know what to do with static files like pictures or .css files.

There is a good article explaining the FastCgiExternalServer directive. Its solution to having just the .php files be handled by the external server involve adding a handler, assigning an action to the handler pointing to a nonexistent script and then aliasing the nonexistent script back to a folder symlinked to the original directory. The only way I could find to simplify that was to use a ReWriteRule. In either case we need to unfortunately modify the configuration for each vhost to make it work.

I have several vhosts under /srv/www/. Following the articles example I created a symlink /srv/fcgi pointing to /srv/www . Then I modified my mod_fastcgi configuration as such:

<IfModule mod_fastcgi.c>
  FastCgiExternalServer /srv/fcgi -socket /tmp/php.sock
  ReWriteEngine On
  ReWriteCond %{DOCUMENT_ROOT} ^/srv/www/(.*)
  ReWriteRule ^/(.*\.php(3|4)?(\?.*)?)$ /srv/fcgi/%1/$1
</IfModule>

Now the external FastCGI server is invoked whenever a file under /srv/fcgi is accessed, but /srv/fcgi is just a symlink to /srv/www. Instead of the above article’s gyrations I figured out the above rewrite rules that will rewrite any request for a .php file to /srv/fcgi/(rest-of-document-root)/(request_URL) . So in effect the rewrite points back to the original file, but through a symlink that makes Apache use the FastCGI server to process it. The ReWriteCond shown doesn’t actually make a decision; it is giving me a reference to use when constructing my rewritten path name.

Now I have to modify my vhosts. Rewrite rules don’t carry over to vhosts by default. For each VirtualHost section I have to add the following which allows the server rewrite rules inherit to the vhost:

ReWriteEngine On
ReWriteOptions Inherit

Alternately I could just put the rewrite rules in each VirtualHost section. In fact I may need to if I have other rewrite rules for pretty URLs.

With FastCGI–whether externally spawned or managed by mod_fcgid or mod_fastcgi–you also need ExecCGI enabled in the Options directive.

I used Apache benchmark and verified that all the child proceses are being used concurrently. And now the APC cache is shared among all the child processes.

My best-performing small VPS setup was with lighttpd and FastCGI PHP, but I got tired of trying to make rewrites work in lighttpd and switched to a two-process prefork Apache with mod_php and Squid as a web accelerator. That worked pretty well, but not as fast as lighttpd and FastCGI. What I really want is a multithreaded Apache and a FastCGI PHP that will fit in my small, cheap VPS.

I had tried Apache’s worker MPM and FastCGI before, but at the time both Apache and the PHP FastCGI process bloated and took up all my RAM despite my settings. Recently I decided to try again and was able to find out how to make it work.

Under Linux, by default each thread is assigned 8MB of stack memory, so an Apache process with 25 threads would try to take up 25*8=200MB of RAM!!! Plus the size of the Apache parent process, plus anything else that runs on my VPS. Not going to work in my small VPS. However, each thread doesn’t really need that much RAM. In fact, 128k is working fine for me so far. Apache 2.2 has a new directive ThreadStackSize for the worker MPM, and I set mine to “ThreadStackSize 131072″, and now I can have two Apache processes with 25 threads each taking up about 25MB worth of privvmpages. Another way to accomplish this is add “ulimit -s 128″ to the Apache startup scripts. For Apache 2.0 you have to do it this way. Since I am using Apache 2.2 I didn’t have to use ulimit, but when I was testing the effects of changing the stack size I used this script which worked as a temporary measure:

#!/bin/sh

ulimit -s 128
/usr/sbin/invoke-rc.d apache2 restart

My 25 MB RAM usage above is without mod_php, though. Google searches lead to conflicting information about whether PHP is thread safe, so I want to use FastCGI. My problem with Apache FastCGI before was that it spawned several times as many PHP processes as I thought I had told it to. I was using mod_fcgid and pointing it to the same FastCGI PHP wrapper script that I had used for lighttpd. But that script set PHP to launch child processes, and I have since learned that mod_fcgid does not multiplex and therefore will not use the child processes. Instead it launches as many processes as it sees fit, and my configuration had each of those launching 4 children. No wonder my RAM got chewed up so quickly. So now I am letting mod_fcgid call /usr/bin/php-cgi directly:

<IfModule mod_fcgid.c>
        AddHandler fcgid-script .fcgi .php
        # Where to look for the php.ini file?
        DefaultInitEnv PHPRC        "/etc/php5/cgi"
        # Maximum requests a process should handle before it is terminated
        MaxRequestsPerProcess       1000
        # Maximum number of PHP processes
        MaxProcessCount             4
        # Number of seconds of idle time before a php-cgi process is terminated
        IPCCommTimeout              120
        IdleTimeout                 120
        #Or use this if you use the file above
        FCGIWrapper /usr/bin/php-cgi .php
</IfModule>

Unfortunately, since each PHP processes is launched separately, any caching such as eAccelerator or APC will not be shared across each process. And each process uses up another X MB of RAM for the cache. So if I’m using APC with the default 30 MB cache and have 4 FastCGI PHP processes going, my APC caches are taking up 120 MB all by themselves! At the moment this is exactly what I’m doing, because I’ve moved up from a 256 MB VPS to a 390 MB VPS, and my total memory usage seems to be hovering near 256 MB when all processes are running. However, when PHP processes aren’t needed, mod_fcgid will kill them off to save memory, so most of the time I’m using much less RAM. I will see if I can set up the FastCGI processes like I did with lighttpd and then connect to it from Apache. I think it’s doable, but I haven’t tried yet.

I like using the worker MPM and FastCGI better than using the prefork MPM, mod_php and Squid. First of all the log files are a lot easier to parse. Apache (as I have it configured) can handle 50 concurrent static requests including 4 concurrent PHP requests, and I was able to enable KeepAlives again so my sites feel more responsive. With prefork Apache and Squid I could see a row of GIF smileys load up left-to-right when posting a reply in one of my forums. Now it happens so fast I can’t see it anymore. If I can get the PHP cache–previously eAccelerator, but I just switched to APC–to share itself across all my PHP processes then the overal RAM usage will be much lower, and I’ll be able to have more PHP processes.

And I like the new setup better than lighttpd because I can use the Apache rewrite rules provided by software programs like Drupal and SMF rather than try to translate them into lighttpd rewrites.

I never did upgrade my VPS RAM. Part of it is laziness, but part of it is that I keep thinking my web server doesn’t do enough and isn’t busy enough for 256mb to not be enough.

I’m using mod_php for drupal and CivicSpace on several sites. I’m running Apache 2 with the prefork MLM. The problem with this setup and limited resources is that the running Apache processes bloat to handle the biggest PHP script they’ve run. To counter that I reduced the number of Apache processes. Per earlier blogs, I also deleted unused drupal modules and all my sites work fine under a PHP memory limit of 12mb. Between those two things I’ve kept my memory issues at bay.

However, running only 4 Apache proceses is causing problems, too. If a PHP script is slow to complete due to business or MySQL slowness, then that thread can’t handle any more requests.

Using the Apache worker MLM would relieve both the sustained memory bloat issues (memory can be released upon completing the PHP script) and the concurrent connection issues (no problem to make a new thread to handle a new request), but then you have all that PHP & thread stuff to worry about.

I started looking into another solution that I’m going to try: FastCGI. With FastCGI you take mod_php out of the web server and run a persistent PHP (or other language) interpreter. The web server passes requests to the persistent interpreter. In PHP’s case, the php-cgi program will spawn multiple child processes to handle requests. I got this working on my home server and it works fine. Now the web server (I also switched to lighttp, but Apache can do FastCGI, too) can handle tons of requests with little resource usage and pass off the PHP scripts to the persistent php-cgi group. Sure, I can still overload my php-cgi group, but at least I can keep servicing small requests while PHP is jammed up. And I’m not servicing small requests with fat processes. But the biggie is now I can seperately manage my web server resources and my PHP resources for better fine tuning.

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.

BBCode: (Input format / filter.) I love this module. Most of my intended audience is familiar with BBSes that use BBCode. With auto-url recognition and line breaks this is almost perfect for my needs. Perfect would include formatting buttons. Note that it also allows image links. (Images are so complicated in Drupal, but that’s another topic…)

BBCode_wysiwyg: (Formatting buttons.) Sounded like a great addition to the BBCode module, but it’s just 4 pushbuttons that don’t work as the buttons on the forums. I quickly turned it off. phpBB is GPL; I wonder how hard it would be to use their formatting toolbuttons for Drupal? UPDATE: I looked at phpBB’s form, and it’s also just html pushbuttons. I had remembered it being fancier.

Textile: (Input format / filter, included with CivicSpace.) Cute idea. *This text bolded* _this text underlined_ ; simple markup to produce valid xhtml. I especially like the links: “link text”:http://URL . Two problems: 1: it’s different than what my audience is used to. 2: you have to use white space to separate the markup from other text, so a sentence ending in bold, for example, would have a space before the period. Or comma, etc. That bugs me. I converted all content to BBCode and disabled Textile.

Short note on altering input formats: While playing with input formats I wound up with existing content using several different types of input formats. I wanted to simplify choices for users to BBCode or Plain Text (yeah, it’s a tad redundant), but in doing so it turns out the users can’t edit content created in that input format! A node administrator has to edit each bit of content and change the input format (and formatting, if necessary) to allow the users to edit their content again. (This is only if the users can’t currently use the input format the content was originally created in.) Moral of the story: Decide early in your site history what input options you want to use. Alternately offer tons of input types, but my users aren’t generally tech savvy and confuse with too many choices.

tagadelic: Very nifty. It lists your categories sorted as you want, but categories with more nodes in them have a bigger font indicating more content. I’ve only peeked at this module a little bit. At first it seemed like it shows all terms for all vocabularies, but then I noticed it created a nested menu item with links for each vocabulary. I wasn’t ready for that to be there but couldn’t disable the stupid thing! I got clever and moved it to my Secondary Links menu (Drupal 4.7) which I don’t display on my site.

votingapi: I just got this. It doesn’t do anything on its own, but it is the power behind simple voting and latest and greatest. After upgrading to Drupal 4.7 I played with free tagging taxonomies and was disappointed to learn you can’t have users (or guests) apply tags to existing content (a la rating/moderating/evaluating). I think I can work up something with votingapi to do this, though.

TinyMCE: (Formatting toolbar.) This thing and I got off to a bad start and just didn’t hit it off. I turned it off pretty quickly and haven’t tried it since. It reformatted my text box and removed all line/paragraph breaks in the box and in the output. I tried this as one of the first things I did with CivicSpace, and now that I know more about input formatting I may have to give this a try again as I’d really like some basic formatting buttons for my posters. UPDATE: I’m highly suspicious of an HTML editor, though…hackers could bypass the editor in a hand-crafted POST request. I’m much more comfortable using BBCode and escaping all HTML. Besides, I don’t really care for WYSIWYG; I just want an easy-to-use toolbar.

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.