Ben Ward

Pondering URLs

.

I’m working on adding a wiki system to my personal site for non-chronological content. I hinted at doing this a while ago in Practical Publishing. It’s taken until now to actually get it together.

I’ve ended up going with MediaWiki since it’s what I know, shares the same PHP language as my blog (running on Wordpress) and does everything I want. I also feel pretty good working with the core code to improve it (expect a fork or patch project on my github page soon).

Anyway, there’s an interesting thing about its advice with regard to URLs, which boils down to strongly discouraging having wiki pages served from the root of a domain, and instead having it one level deep (e.g. /wiki/ on [Wikipedia](http://wikipedia.org)).

I think this is wrong in the context of personal publishing

‘wiki’ says nothing about the content. Whilst /blog/ relates to the kind of content provided, ‘wiki’ is a fact about my publishing platform. Certainly on a personal site, where the collaborative aspect of wiki culture won’t be available to a visitor, it’s a misleading fragment. So, ben-ward.co.uk/wiki/about is out.

Now, the reason to try and heed the MediaWiki advice is quite simple; the top level of my site is already shared between different systems. Wordpress powers my blog, Mint runs my stats and there are some directories of static content too. To run wiki URLs at the top level of my site I either have to run thorough exclusion rules to make sure my static content and expected top level items aren’t overridden, or do the opposite and create a whitelisted structure of wiki pages. Either way, whenever I add content to the wiki or the static structure, I have to edit the apache config and restart. It’s not ideal.

As such, it’s worth considering a URL structure that does keep the wiki separated from other systems. But what? Everything I think of comes over as redundant:

Really, what I’m publishing is my website. Unless I’m missing something really obvious, melding it together into the top level seems to be the only option that makes sense.

You can file issues or provide corrections: View Source on Github. Contributor credits.