1 Similarly to [[po:_apache_config_serves_index.rss_for_index]],
2 the [[plugins/po]] apache config has another bug.
4 The use of "DirectoryIndex index", when combined with multiviews, is intended
5 to serve up a localized version of the index.??.html file.
7 But, if the site's toplevel index page has a discussion page, that
8 is "/index/discussion/index.html". Or, if the img plugin is used to scale
9 an image on the index page, that will be "/index/foo.jpg". In either case,
10 the "index" directory exists, and so apache happily displays that
11 directory, rather than the site's index page!
15 > Ack, we do have a problem. Seems like ikiwiki's use of `index/` as
16 > the directory for homepage's sub-pages and attachments makes it
17 > conflict deeply with Apache's `MultiViews`: as the [MultiViews
18 > documentation](http://httpd.apache.org/docs/2.2/mod/mod_negotiation.html#multiviews)
19 > says, `index.*` are considered as possible matches only if the
20 > `index/` directory *does not exist*. Neither type maps nor
21 > `mod_mime` config parameters seem to allow overriding this behavior.
22 > Worse even, I guess any page called `index` would have the same
23 > issues, not only the wiki homepage.
25 > I can think of two workarounds, both kinda stink:
27 > 1. Have the homepage's `targetpage` be something else than
29 > 2. Have the directory for the homepage's sub-pages and attachments
30 > be something else than `index`.
32 > I doubt either of those can be implemented without ugly special
33 > casing. Any other idea? --[[intrigeri]]
35 >> As I understand it, this is how you'd do it with type maps:
37 >> * turn off MultiViews
38 >> * `AddHandler type-map .var`
39 >> * `DirectoryIndex index.var`
40 >> * make `index.var` a typemap (text file) pointing to `index.en.html`,
41 >> `index.fr.html`, etc.
43 >> I'm not sure how well that fits into IkiWiki's structure, though;
44 >> perhaps the master language could be responsible for generating the
45 >> type-map on behalf of all slave languages, or something?
47 >> Another possibility would be to use filenames like `index.html.en`
48 >> and `index.html.fr`, and set `DirectoryIndex index.html`? This could
49 >> get problematic for languages whose ISO codes conventionally mean
50 >> something else as extensions (Polish, `.pl`, is the usual example,
51 >> since many sites interpret `.pl` as "this is a (Perl) CGI").
54 >>> There is something to be said about "index/foo" being really ugly
55 >>> and perhaps it would be nice to use something else. There does not
56 >>> appear to even be one function that could be changed; "$page/foo" is
57 >>> hardwired into ikiwiki in many places as a place to dump subsidiary
58 >>> content -- and it's not even consistent, since there is also eg,
59 >>> "$page.rss". I agree, approaching it from this direction would be a
60 >>> mess or a lot of work.
62 >>> Type maps seem like a valid option, but also a lot of clutter.
64 >>> `index.html.pl` does seem to be asking for trouble, even if apache
65 >>> can be configured to DTRT. It would make serving actual up perl scripts
66 >>> hard, at least. But that is some good out of the box thinking..
67 >>> perhaps "index.foo.pl.html"?
69 >>> However, that would mean that
70 >>> web servers need to be configured differently to serve translated
71 >>> and non-translated sites. The current apache configuration for po
72 >>> can be used with non-po sites and they still work. --[[Joey]]
74 >>>> I am vulnerable to the same problem because I use MultiViews, though I don't use the `po` module;
75 >>>> I have to serve both Australian English and American English for my company's website
76 >>>> (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).
77 >>>> I'm just fortunate that nobody has thought to add attachments to the front page yet.
78 >>>> I raise this to point out that this is going to be a recurring problem that won't necessarily be fixed by changing the `po` module in isolation.
80 >>>> One could argue that "index" is already a special case, since it is the top page of the site.
81 >>>> Things like parentlinks already use a special case for the top page (checking the variable HAS_PARENTLINKS).
82 >>>> Likewise, when --usedirs is true, index is treated as a special case, since it generates "index.html" and not "index/index.html".
84 >>>> Unfortunately, I'm not sure what the best approach to solving this would be.
85 >>>> --[[KathrynAndersen]]