diff options
Diffstat (limited to 'doc/todo')
3 files changed, 88 insertions, 1 deletions
diff --git a/doc/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn b/doc/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn new file mode 100644 index 000000000..cdabdb774 --- /dev/null +++ b/doc/todo/Allow_TITLE_to_include_part_of_the_path_in_addition_to_the_basename.mdwn @@ -0,0 +1,64 @@ +I need to display part of my pages' path in the `<title>` meta HTML +header instead of their basename ; e.g. for /abs/path/to/basename, I'd +like to set it to path/to/basename. + +Of course, one might consider it's my own problem, as I could +workaround this in my templates, and replace, in the `<title>` meta +HTML header, `<TMPL_VAR TITLE>` with a `TMPL_LOOP` on `PARENTLINKS`, +but... + +- it's ugly (call it a semantic hijacking if you want) ; a side-effect + of this ugliness is : +- it defeats any further plugin's (e.g. [[plugins/meta]]) + attempt to override the default title with a nicer one ; +- all parents appear : there is no way to specify how deep to go up in + the parents tree. + +So I really want to avoid this ugly workaround. + +Looking at `Render.pm`, the second solution I thought of was : + +- add a `parents_in_page_title` configuration option (default=0, i.e. + the current behaviour) ; +- modify `Render.pm` to insert as much parents as possible (up to + `N=parents_in_page_title`), separated by '/', in the `title` + template parameter, before the actual page basename ; I personally + would use N=2. + +The only problems I can see with this approach are : + +- it requires modification of the core, which may not be desirable +- the resulting title would be unconditionally overridden by the meta + plugin, and I can think of no clean solution to make this + configurable without hacking [[plugins/meta]], which I'd rather not + to ; I don't care, but once you add a ad-hoc feature to the core, + you can be sure someone will want a more generic version in less than + three months ;) + +I'm not too convinced writing a plugin for such a small feature isn't +overdoing it, so I'm tempted to implement this solution in the +simplest way : the generated title would be the default and could be +overridden later by plugins. + +Joey, what do you think ? + +(Before starting to write any single line of code, I need to know how +much you are on the "if you can do it as a plugin, don't ever modify +the core" side... :) + +In case you're on the hardcore side, I would probably write +a dedicated plugin, called `genealogictitle` or whatever, and : + +- use the pagetemplate hook to modify the `title` template parameter, + and maybe set `title_overridden`, as does the meta plugin +- add a `genealogictitle_depth` configuration option to tell how many + parents to display +- maybe add a `genealogictitle_overrides_meta` or whatever to decide + whether a title overridden by [[plugins/meta]] should be overridden + by genealogictitle ; but anyway, I've not found, in the plugins + documentation, any hint about the order in which the plugins are + called for a given hook, so the "choose the strongest between meta + and genealogictitle" thing might just be more complicated... (no, + I did not Read The Nice Source, yet). + +-- intrigeri diff --git a/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn b/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn index 4bc3ffc8e..0f8f9bb73 100644 --- a/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn +++ b/doc/todo/ability_to_force_particular_UUIDs_on_blog_posts.mdwn @@ -1,7 +1,15 @@ When converting an existing blog to ikiwiki it would be useful to be able to preserve any existing UUIDs on posts, in order to [avoid flooding aggregators](/tips/howto_avoid_flooding_aggregators/). -Also, it should be possible to change the canonical URL of a post, i.e. the atom `<link>` (e.g. leaving a redirector behind) while keeping the same UUID (so that aggregators don't get confused). +Also, it should be possible to change the permalink (the Atom `<link>`) of a post (e.g. moving the content and leaving a redirector behind), while keeping the same Atom `<id>` (so that aggregators don't get confused). Ideally UUIDs for [blog posts](/ikiwiki/blog/) should be chosen when the post is created, and frozen permanently by checking them in along with the content. Perhaps ikiwiki's blogging functionality could be hooked up to the [meta plugin](/meta/plugin/), with a new meta keyword (uuid? feed-uuid? atom-uuid?) to achieve this. + +> I've now knocked together a [[patch]], which is in the "force-uuids" branch of git://git.debian.org/git/users/smcv/ikiwiki.git (see also [gitweb](http://git.debian.org/?p=users/smcv/ikiwiki.git;a=shortlog;h=refs/heads/force-uuids)). +> +> I'm not convinced that "uuid" is the best name for this functionality - the `<id>` in an Atom feed can be any URI, and one of the use-cases I have for this functionality in my own blog needs to have its `<id>` set to a URI that is not, in fact, its own address (it was a typo). "id" is a bit arrogant (forcing Atom terminology into a flat namespace!), "atom-id" is slightly misleading because it's also used for RSS... any ideas? +> +> While I was there, I noticed that the quality of the generated Atom/RSS feeds could be improved by making more use of the meta plugin if it's also enabled - would anyone object to me hacking on this some more? +> +> -[smcv](http://smcv.pseudorandom.co.uk/) diff --git a/doc/todo/multiple_repository_support.mdwn b/doc/todo/multiple_repository_support.mdwn new file mode 100644 index 000000000..33d794790 --- /dev/null +++ b/doc/todo/multiple_repository_support.mdwn @@ -0,0 +1,15 @@ +I'd like to be able to use one git repository for my basic website, and +another one for the big files (pictures, videos), and another one for temp +files. This way I'd not bloat the basic repo, and I could toss temp files +up, and throw the temp repo away periodically. + +For this to work really well, ikiwiki would need multiple repository +support. Possibly it could be tied into 'mr'? + +Another thought is that it would be good if ikiwiki could determine the +type of repo a subdirectory is in by itself, eliminating the need to +manually configure it in the setup file. + +--[[Joey]] + +[[tag wishlist]] |