]> sipb.mit.edu Git - ikiwiki.git/blobdiff - doc/bugs/po:__apache_config_serves_index_directory_for_index.mdwn
Merge remote-tracking branch 'remotes/smcv/ready/careful-eval'
[ikiwiki.git] / doc / bugs / po:__apache_config_serves_index_directory_for_index.mdwn
index e8969abd72f5a897398830a0eaf7d277808ac162..fd7cd518c8a0ac16cc6346e45d568759c77d1ee7 100644 (file)
@@ -11,3 +11,75 @@ the "index" directory exists, and so apache happily displays that
 directory, rather than the site's index page!
 
 --[[Joey]]
+
+> 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](http://httpd.apache.org/docs/2.2/mod/mod_negotiation.html#multiviews)
+> says, `index.*` are considered as possible matches only if the
+> `index/` directory *does not exist*. Neither type maps nor
+> `mod_mime` config parameters seem to allow overriding this behavior.
+> Worse even, I guess any page called `index` would have the same
+> issues, not only the wiki homepage.
+
+> I can think of two workarounds, both kinda stink:
+>
+> 1. Have the homepage's `targetpage` be something else than
+>    `index.html`.
+> 2. Have the directory for the homepage's sub-pages and attachments
+>    be something else than `index`.
+>
+> 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`
+>> * `DirectoryIndex index.var`
+>> * make `index.var` a typemap (text file) pointing to `index.en.html`,
+>>   `index.fr.html`, etc.
+>>
+>> 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.en`
+>> and `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 `.pl` as "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.pl` does 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 `po` module;
+>>>> 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 `po` module 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]]