X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/a968efd3d6cc8aa810d42880e167106a83172bfd..a28f028ed48d2f4d37a5ba7a2b53c33a3f604e09:/doc/patchqueue/index.html_allowed.mdwn diff --git a/doc/patchqueue/index.html_allowed.mdwn b/doc/patchqueue/index.html_allowed.mdwn index 7a544fca1..2431b802a 100644 --- a/doc/patchqueue/index.html_allowed.mdwn +++ b/doc/patchqueue/index.html_allowed.mdwn @@ -274,6 +274,30 @@ I'll attach an updated and slightly modified version below. >> Can someone elaborate on this? What's broken about it? Will pages >> foo/index/index.html include foo/index in their parentlinks? --Ethan + >>> Presently the patch does not move `foo/index.type` as `foo/index/index.html`, but renders + >>> it as `foo/index.html`, not because I particularly want that (except for the top-level one, of + >>> course), but because it could be done :). This, however, conflicts with a `foo.mdwn` + >>> rendered as `foo/index.html`. The easiest and cleanest way to fix this, is to simply + >>> not handle `index` in such a special manner -- except for the top-level one. --[[tuomov]] + + >>>> Oh, I see, this patch doesn't address wanting to use foo/index.mdwn as + >>>> an input page. Hmm. --Ethan + + >>>>> No, it doesn't. I originally also was after that, but after discussing the + >>>>> complexities of supporting that with Joey, came up with this simpler scheme + >>>>> without many of those issues. It is the output that I primarily care about, anyway, + >>>>> and I do, in fact, find the present input file organisation quite nice. The output + >>>>> locations just aren't very good for conversion of an existing site to ikiwiki, and do + >>>>> make for rather ugly URLs with the .html extensions. (I do often type some URLs + >>>>> out of memory, when they're gone from the browser's completion history, and the + >>>>> .html makes that more laboursome.) + + >>>>>> I support your decision, but now this wiki page serves two different patches :). + >>>>>> Can we split them somehow? + >>>>>> What are the complexities involved? + >>>>>> I think I overcomplicated it a little with my patch, and Per Bothner's gets + >>>>>> much closer to the heart of it. --Ethan + * This does make the resulting wikis much less browsable directly on the filesystem, since `dir` to `dir/index.html` conversion is only handled by web servers and so you end up browsing to a directory index all the time. @@ -290,6 +314,12 @@ I'll attach an updated and slightly modified version below. >> index.html yet another option. I'm not _that_ fond of optioons >> however. --[[Joey]] + >>> It is worth noting, that with this patch, you _can_ render the local + >>> copy in the present manner, while rendering the Web copy under + >>> directories. So no extra options are really needed for local browsing, + >>> unless you also want to serve the same copy over the Web, which I + >>> doubt. --[[tuomov]] + * Some of the generated links are missing the trailing / , which is innefficient since it leads to a http redirect when clicking on that link. Seems to be limited to ".." links, and possibly only to @@ -377,6 +407,19 @@ Index: linkmap.pm } +> This is probably supposed to be `$mapitems{$item}=urlto($item, $params{destpage});`, +> which does indeed remove one more `htmlpage` call from the plugins. I can't actually +> try it: "failed writing to dst/ts.png.ikiwiki-new: Inappropriate ioctl for device". + +>> Crazy perl bug that ioctl thing. Worked around now in svn. --[[Joey]] + +> After this probable fix, in fact, all uses of htmlpage in the plugins are used to +> construct an absolute address: the absolute url in most cases, so an `absurl` +> call could be added to be used instead of htmlpage, and something else in the +> aggregate plugin (above), that I also think isn't what's wanted: +> aren't `foo.html` pages also "rendered", so that they get moved as `foo/index.html`? +> --[[tuomov]] + * `inline.pm` uses htmlpage and `abs2rel` to generate a link, and probably needs to be changed to either use `urlto` or to call `beautify_url` like htmllink does. This might work: