I would recommend
RewriteRule ^([A-Z].*)$ /wikka.php?wakka=$1
to prevent rewriting-loops

The above comment was by me. I just found out, that on some pages even with mod_rewrite activated in the wikka config some URIs still have GET-parameters, for example /WantedPages?linking_to=... therefor the correct rewrite rule should be:
RewriteRule ^([A-Z].*)$ /wikka.php?wakka=$1 [QSA]

TimoK, thank you for the info.

My understanding of modrewrite is admittedly a bit lacking. If it wouldn't take too much of your time, would you mind providing a brief breakdown of the syntax you have recommended?

Sure. It's actually quite easy. ^ means we start at the beginning of the 'path', right after the first slash in the URI. First char has to be an uppercase letter between A and Z (the square brackets mark a class in regular expressions), followed by 0 to unlimited more chars of any kind, until the end of the URI, for which the $ stands, so we should end up with the full path (which is actually the item to be displayed) saved in $1.
Since for apache the URI ends when a query string starts we would lose any GET-parameters, as they are not part of $1 when rewriting. The argument [QSA] stands for 'query string append' and makes mod_rewrite append any GET-Parameters at the end of the target URI. apache/mod_rewrite automatically will add an ampersand if needed.
I hope this helps. If not: the apache doc is written by a native english speaker ;)

Nicely explained. Thank you.

I just checked the .htaccess file that we are actually using and noticed that the info on this page was out of date. I've updated this page with the current usage.

Looking at the sytax on the page above, do you still think we might have a problem with re-writing loops?

Regarding your recommendation: the first character is required to be a uppercase character, however, in Wikka, people can force links and create pages with lowercase characters. Your recommendation would probably have to be modified as follows, right?
RewriteRule ^([A-Za-z].*)$ /wikka.php?wakka=$1

Can't page names also include digits?!

Sure, but that's covered by the dot. The items within the brackets are specifying just the first character. Then after the first character we can have characters of any kind.

Aren't regular expressions fun? :)

Is something wrong with
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L] ?
Isn' t the role of ,L to prevent rewriting-loops ?

"Is something wrong with
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L] ?"
It doesn't look for something that starts with a *letter* - that's what the [A-Za-z] in JsnX's rule is for (though it allows only ASCII-7 letters, and not all that the Wikka engine allows in a page name... - the expression really should be the *same* as what Wikka applies internally).

"Isn' t the role of ,L to prevent rewriting-loops ?"
L means "Last" - if the expression matches, no other rewrite rule will be applied after this.

Ok, sorry for the long delay...
I read up about mod_rewrite a bit more. I am not sure anymore what caused the trouble for me, but actually it wasn't a real rewrite loop since that could only happen in combination with a forced redirect [R] (or with a 'forced loop' using [N]).
Anyhow, the QSA was missing, so at least something was correct.
RewriteRule ^([A-Za-z].*)$ /wikka.php?wakka=$1 [QSA,L]
is still the most simple (while beeing failsafe) rule I can think of now and it is quite close to what is allowed in Wikka.
"the expression really should be the *same* as what Wikka applies internally)"
I am not sure this is a good idea. Of course I am new to Wikka, but I am not new to web development and personally I try to avoid using anything but ASCII-7 (and numbers) in URIs. I will read up a bit more on this topic and if I find a failsafe RewriteRule which is more accurate I will post it here.

What I am doing at the moment is using some RewriteConditions:
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^([a-zA-Z].*)$ wikka.php?wakka=$1 [QSA,L]
This way I can still access regular files and directories in and below the wikka-directory. The downside is that I can not use some words as pagenames.

I've been struggling myself with the question whether (or how) non-ASCII-7 pagenames can be allowed. I have come to the following reasoning now:
- without rewriting, a pagename is just a query string - and anything goes for a query string, so "extended characters" can be allowed there
- with rewriting though, they would appear as part of the URL where such characters are not (yet) allowed
- but encoding _is_ allowed so as long as the extended charatcers are URI-encoded the (not-rewritten) URL would be valid.

That would mean we could change the rewrite rule to this to cover non-ASCII-7 pagenames:
^([A-Za-z%].*)$ wikka.php?wakka=$1 [QSA,L]

Since internationalization is a big issue already, allowing national-language pagenames this way would be a definite plus.

Any holes in my reasoning?

(Of course the formatter should make sure any page links are also URI-encoded)

I have just tested this and it does not work, the URL gets decoded before it is passed to mod_rewrite and this can not be turned off (you can only turn off URI escaping of output).
So if we want to allow non-ASCII-7 characters at first position, we will have to go with .* (and thus allowing everything) or enter all allowed characters by hand.

Timo, thanks for that disappointing test. ;)
Elsewhere I had worked out the character ranges for "letters and numbers" encoding them as (ranges of) hex characters rather than spelling out everything, but I'm never sure to what extent Apache supports the Perl syntax for defining character ranges.
I'm not really in favor of allowing *anything* as a first character (so would not be happy with .*), and still think rewriting and internal Wikka behavior for allowing page names should match so as not to confuse (end)users.

For the (hex encoded) characters ranges for "letters and numbers" see my remark regarding 'RE building blocks' on ValidPageNames. (Had a heck of a time finding that back. :()

I just tried your patterns from ValidPageNames, they do not work (Internal Server Error).
But I did some research and testing and came to
RewriteRule ^([A-Za-zÀ-ÿ].*)$ wikka.php?wakka=$1 [QSA,L]
which covers Latin-1 Supplement (see http://www.unicode.org/charts/ for details) and works well for me. Maybe this is a good compromise?

Hmmm - so apparently hex-encoded ranges don't work for Apache REs. Pity :(
But - to still include only "letters and numbers" you'd then have to translated each of the separate ranges in my patterns into their corresponding characters: À-ÿ contains quote a few characters that are *not* letters (or numbers - hence my collection of (sub)ranges: they are formulated to exclude those characters.

That said, I now realize I haven't checked what exacly other charsets of the Latin family have in those 'non-letter' positions - that wil need a bit more research; and they might also be needed for Unicode (UTF-8 encoded) page names. Merely Latin-1 would not be sufficient, certainly (though it would at least be a step in the direction of i18n).

Ok, I didn't see × (00D7) and ÷ (00F7). [A-Za-zÀ-ÖØ-öø-ÿ] should do it (it is the translation of your patterns over at ValidPageNames, just a different order/grouping: À is \xc0, Ö is \xd6, Ø is \xd8, ö is \xf6, ø is \xf8 and ÿ i \xff).

Hi, I discovered that the default .htaccess included did not work for my setup up. I needed to include RewriteBase /directory/ as well since Wikka is installed in a subdirectory. I hope this helps anyone having trouble getting Wikka to work.

Hi everyone, I'm having a little problem with getting the rewrite to work and I hope somebody can help me please. The URL's work okay but I get broken paths beneath the wikka directory (for images and such). I am using the httpd.conf instead of .htaccess and have the following rule

<Directory /pathto/mysite/html/treo600faq >
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</Directory>

How do I prevent this rule from applying to sub-directories within the wikka directory, such as /treo600faq/images? Thank you for your help.

MyTreo,
With the .htaccess method we have separate .htaccess files in the css and images directories that turn off rewriting. I would guess the httpd.conf equavalent of that would be to create corresponding Directory sections, something like this:
<Directory /pathto/mysite/html/treo600faq/images>
RewriteEngine off
</Directory>

Please report back whether that works (I can't test it right now), so we can create a "Workaround" page for that situation! Thanks,

Thanks JavaWoman, in fact I already had the correct settings but the image I was using for testing had an incorrect path, silly me! The httpd.conf settings that work correctly for me are as follows:

<Directory /pathto/mysite/html/wiki >
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^(.*/[^\./]*[^/])$ $1/
RewriteRule ^(.*)$ wikka.php?wakka=$1 [QSA,L]
</Directory>

<Directory /pathto/mysite/html/wiki/* >
RewriteEngine Off
</Directory>

Hope this helps somebody else. Thanks again for your help.
Chris

Just a headsup for anyone getting "403" when turning on mod_rewrite for Wikka:
Find the "Options" entry in your httpd.conf - I set it to "all" and presto, rewrite works.
NB! You might consider looking at the http://httpd.apache.org/docs-2.0/mod/core.html#options before using that setting. I have no idea if it is a security risk, and I don't care for now since I am working offline.

This page is a hybrid, it currently belongs to CategoryDocumentation and CategoryDevelopment. Nils, maybe some cleaning-up is needed. Documentation pages should not contain development discussions nor code suggestions.

Now better?

I added some content about requirements etc. - the page without the discussion sort of suggested it is always possible and easy, which is not the case.

An interesting PHP class to emulate URL rewriting on servers without a ModRewrite module: http://www.phpclasses.org/browse/package/1844.html

Hi, although more or less not having had any clue as to programming so far , maybe you have a hint for me ? Having installed the wiki at my homepage, having tried out the suggestions on this page and finding it not working so far, I contacted my provider. He suggested the following solution:

Options -MultiViews
RewriteEngine on
#RewriteBase /wiki/one
#RewriteCond %{REQUEST_URI} wikka.php(.*)$
RewriteCond %{REQUEST_URI} !wikka\.php(.*)$
RewriteRule (.*)$ /wiki/one/wikka.php?wakka=$1
# RewriteCond %{REQUEST_URI} wikka/(.*)\.html$
# RewriteRule wikka/(.*)\.html$ /wikka.php?id=$1

This works with most pages, but the TextSearch has stopped working, comments are not possible and although PageIndex works, display of the contents of single letters does not. - Does anyone have any hints ?

Thank you. LichtHeil.

FYI, I recently got Wikka up and running with URL rewriting under lighttpd. Since I wasn't able to find much documentation on this, I created a page describing my configuration. It's linked from my user page, and I'd welcome any feedback on it.

Thanks,

Hi BulletCard and thanks for your contribution! I've cross-linked your page with the Wikka Docs and with other installation-related topics.

Could someone point me a newb in the right direction? I want to make it so uploaded files are only accessible by registered (selected) Wikka users on my Wikka site. Could someone help me out?

Hi, Newb2Wiki, and welcome! I'd start here:

http://wikkawiki.org/FilesAction?show_comments=1#comments

Typically, files are stored in directories corresponding to the page the action is associated with. So as long as you have appropriate dir perms set, others should not be able to access the files directly (via URL). You can use ACLs to set the permissions on the page to only allow read/write access to registered users.