I used to write on Wikipedia, years ago when it was a wild frontier, we had barely 30 thousand articles, and not even my geek friends had heard of it from a source other than my blathering on about it.

It was quick and simple, deserving the origin of its name [1]. And it was quick not just to edit the content of pages, but their place in hierarchies and their order within lists. A whole section of the site that wasn't to our liking could be rejigged in a handful of browser tabs. Pages didn't belong to anyone, but the edit history and the attached talk pages gave you a clue of who was involved, and once you'd made edits to a page you could spot it in the Recent Changes list or your personal watchlist of bookmarks.

Now over to Drupal handbooks, where I find the process slow and laborious and confusing. I ask myself (and you!) — why?

We have Recent Changes of a sort: the tracker; we even have a tracker just for documentation changes, but I forget it exists because it's tucked down at the bottom of the site blocks. We have page revisions and diffs of pages, just like Wikipedia.

The differences I can see are:

1. HTML is slower. I know purists dislike wiki markup, but it's undeniably quicker to type ''italic'' and [[clean URLs]] than to muck around with opening and closing tags and finding the right URL. Granted, there is no one standard (though I would say that used at UseMod comes close) and Wikipedia has now bloated it so much with complex syntax to create all manner of things. But the handful of basic wiki syntax elements are good.

2. Structure is divorced from content. It's very handy the way Book module builds menus and trees for you. But it makes moving a page to another part of a book feel like a big destructive (and irreversible?) act. Furthermore, only a small number of admins can change the order of child pages, something which frequently makes all the difference between a clear read and a mess. On wiki, structure ''is'' content (italics, remember?): you want to make a list of child pages? You write a bullet list of page names. You want to move a page to a different part of the hierarchy? You just find what links to it and edit. Granted, this can often lead to an almighty tangled mess; not for nothing it is the full term a 'wiki-wiki-web' — not a tree.

3. Every article has an associated talk page. One day you find a section has all been changed and you're confused as to why? Find the answer in the talk page. You're pondering a big reorganization yourself, and you want to make sure other writers who are interested in this page get wind of it and have a chance to discuss it? The talk page. It's a bit more anarchic to what we're used to on drupal.org, but it keeps the discussion and the document side by side. I'm only an occasional participant in the documentation team, I'm not on the mailing list[2] and so I often find ''everything'' has been turned upside down and I can't fathom why, and I can't tell if it's work in progress that I should help with or just an almighty mess. Talk pages aren't perfect, and it's hard to follow discussions spread across many places, or even to know if you might be missing something. But there is an immediacy about the 'talk' tab at the top of a page.

4. Lastly, on Wikipedia it felt like there was a collective ownership of pages and sections. On drupal.org, I feel I'm treading on toes if I make too many changes. I don't know why that is; maybe we don't have the critical mass of documentation editors to turn into a community.

In conclusion: I don't have answers. I know that editing and more to the point, organizing our documentation is a big job, and I think the tools are not quite up to the job. As a first step, we should make book hierarchy editable by the documentation team. After that, start upon the inevitable debate about wiki syntax, and think about ways to better tie isues to the documentation pages they are about.

Footnotes:

[1] 'wiki' meaning 'quick' in Hawaiian, coined by Ward Cunningham for the original wiki.
[2] I hate mailing lists. Don't get me started on them. The 1980s called: they want their communication technology back is all I'm going to say.

I've been putting off setting up multisite on my localhost for ages, mostly because in the past I've found getting Apache virtual hosts to work can be a bit tricky: not impossible, but the sort of thing where I could easily lose an hour on a minor thing I've forgotten to do. And after all, with a shiny new iMac and a hard drive whose proportions I can't even remember, why not just 'drush dl' all over again?

But I'm actually working on a multisite project at the moment, and suddenly getting this to work becomes more interesting than having another SVN copy of my code kicking around.

Given multisite can respond to subfolders, I was wondering if this could work when Drupal itself is in a subfolder, like this:

Turns out it can. Suppose you want a new subsite called 'drupal-subsite'. Here's what to do in your webroot:

Your lolcathost(*) sees just another subfolder that's a site; the symbolic link sends you to the existing Drupal folder; and finally, the multisite system sees that you're browsing 'localhost/drupal-subsite' and selects the localhost.drupal-subsite folder as the one holding your site.

You can also have your subsite explicitly sit below the main site like this:

In which case your sites folder is localhost.drupal-multisite.drupal-subsite and the symlink should be inside the multisite folder:

So when I next get a moment I'll consolidate the various test sites I have, and when I have more than one patch on the go that I want to keep segregated, I can just add a multisite, get a fresh CVS copy of the code, and get going.

I've added details to the documentation too.

(*) yes, I keep typing it like that.