I'm working on implementing clean URLs for my wiki, not just enabling them from a technical POV by eliminating the
doku.php?id= and using the slash rather than colon for namespaces, but also by creating and enforcing consistent page/namespace conventions.
One issue is that I don't like the semantics of a "start" or "home" or "index" page within a namespace, and want to enforce the following rules using a mod_rewrite rule:
Given a topic document in a namespace referenced by url
ns1/topic[/m] and then deciding to expand on that topic by creating a namespace referenced by url [m]ns1/topic/, leave the
topic.txt in place in the
ns1 folder as the "about the topic" document, using the same pagename as the namespace below. This would most likely be an introduction/overview and/or a ToC to the docs in that namespace.
DokuWiki's usual setup means the result of clicking on the namespace URL itself, ending with a trailing colon
ns1/topic:[/m] (or with useslash, a trailing slash [m]ns1/topic/) would be to automatically open (or create) a "start.txt" document in that namespace.
I want to disable this behavior (in effect disabling the normal
mod_dir behavior at the same time), and enforce the use of
ns1/topic.txt as the "about" document for the
ns1/topic/ namespace. I'm open to any other suggestions on how to do this, or why doing so may be a bad idea etc., but I'm currently thinking of using mod_rewrite to automatically strip the trailing slash from any inbound URLs, using the same
.htaccess file used to implement regular "clean URLs" as documented here
http://www.dokuwiki.org/rewrite.
I'm not a regex guru at all, but after some googling and testing it seems this works:
RewriteRule ^(.*)/$ $1 [R=301,L]
RewriteRule ^(.*):$ $1 [R=301,L]
Note these rules should come after
RewriteBase /dokuwiki
but before the other DW-specified ones. Also, I'm sure they could be combined into one, but once I've successfully gotten rid of the colon syntax everywhere (see
http://forum.dokuwiki.org/post/28210) I may want to be able to make use of that separately as an "admin shortcut" to the auto-generated ToC/index page for that namespace - from the users' POV, I really only want them to deal with slashes.
Any feedback on this would be welcome, especially if someone more knowledgable than I knows why doing this is not a good idea - not just technically but from an information architecture POV as well. . .