The use of "DirectoryIndex index", when combined with multiviews, is intended to serve up a localized version of the index.??.html file.
But, if the site's toplevel index page has a discussion page, that is "/index/discussion/index.html". Or, if the img plugin is used to scale an image on the index page, that will be "/index/foo.jpg". In either case, the "index" directory exists, and so apache happily displays that directory, rather than the site's index page!
Ack, we do have a problem. Seems like ikiwiki's use of
index/as the directory for homepage's sub-pages and attachments makes it conflict deeply with Apache's
MultiViews: as the MultiViews documentation says,
index.*are considered as possible matches only if the
index/directory does not exist. Neither type maps nor
mod_mimeconfig parameters seem to allow overriding this behavior. Worse even, I guess any page called
indexwould have the same issues, not only the wiki homepage.
I can think of two workarounds, both kinda stink:
- Have the homepage's
targetpagebe something else than
- Have the directory for the homepage's sub-pages and attachments be something else than
I doubt either of those can be implemented without ugly special casing. Any other idea? --intrigeri
As I understand it, this is how you'd do it with type maps:
- turn off MultiViews
AddHandler type-map .var
index.vara typemap (text file) pointing to
I'm not sure how well that fits into IkiWiki's structure, though; perhaps the master language could be responsible for generating the type-map on behalf of all slave languages, or something?
Another possibility would be to use filenames like
index.html.fr, and set
DirectoryIndex index.html? This could get problematic for languages whose ISO codes conventionally mean something else as extensions (Polish,
.pl, is the usual example, since many sites interpret
.plas "this is a (Perl) CGI"). --smcv
There is something to be said about "index/foo" being really ugly and perhaps it would be nice to use something else. There does not appear to even be one function that could be changed; "$page/foo" is hardwired into ikiwiki in many places as a place to dump subsidiary content -- and it's not even consistent, since there is also eg, "$page.rss". I agree, approaching it from this direction would be a mess or a lot of work.
Type maps seem like a valid option, but also a lot of clutter.
index.html.pldoes seem to be asking for trouble, even if apache can be configured to DTRT. It would make serving actual up perl scripts hard, at least. But that is some good out of the box thinking.. perhaps "index.foo.pl.html"?
However, that would mean that web servers need to be configured differently to serve translated and non-translated sites. The current apache configuration for po can be used with non-po sites and they still work. --Joey
I am vulnerable to the same problem because I use MultiViews, though I don't use the
pomodule; I have to serve both Australian English and American English for my company's website (for SEO purposes; certain words that relate to our products are spelt differently in US and Australian English, and we need to be able to be googled with both spellings). I'm just fortunate that nobody has thought to add attachments to the front page yet. I raise this to point out that this is going to be a recurring problem that won't necessarily be fixed by changing the
pomodule in isolation.
One could argue that "index" is already a special case, since it is the top page of the site. Things like parentlinks already use a special case for the top page (checking the variable HAS_PARENTLINKS). Likewise, when --usedirs is true, index is treated as a special case, since it generates "index.html" and not "index/index.html".
Unfortunately, I'm not sure what the best approach to solving this would be. --KathrynAndersen