diff options
Diffstat (limited to 'doc/todo')
29 files changed, 346 insertions, 24 deletions
diff --git a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn index 8ecdf36d0..e5ac391c3 100644 --- a/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn +++ b/doc/todo/Add_DATE_parameter_for_use_in_templates.mdwn @@ -83,4 +83,4 @@ regenerate this one against that). -- 1.5.2.2 -[[!tag patch]] +[[!tag patch patch/core plugins/inline]] diff --git a/doc/todo/Add_space_before_slash_in_parent_links.mdwn b/doc/todo/Add_space_before_slash_in_parent_links.mdwn index 40a334032..9eb8e5364 100644 --- a/doc/todo/Add_space_before_slash_in_parent_links.mdwn +++ b/doc/todo/Add_space_before_slash_in_parent_links.mdwn @@ -8,6 +8,11 @@ This [[patch]] adds a space before the forward-slash in the the parent links. Th >>> Yes, please. This seems to be something a lot of people want to customize. (I certainly do -- a forward slash only looks natural to Unix users) --[[sabr]] +>> Joey, would I be right to summarize your position on this as "people who +>> want to change the text of the templates should maintain their own version +>> of the `.tmpl` files"? It's not clear to me how this todo item could be +>> closed in a way acceptable to you, except perhaps as WONTFIX. --[[smcv]] + Before: ikiwiki/ todo/ Add space before slash in parent links diff --git a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn index 5b9cc8742..17f45dda6 100644 --- a/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn +++ b/doc/todo/Allow_disabling_edit_and_preferences_links.mdwn @@ -67,3 +67,15 @@ Patch: >>> Adding a new `canlogin` hook looks like overkill to me. [[Joey]], how >>> about making registration of the `auth` hook mandatory for all plugins >>> making sense of the "Preferences" link? --[[Lunar]] + +>>>> Hmm, using the `auth` hook existance does seem like a nice solution. +>>>> While splitting the preferences code out into its own plugin is +>>>> easily enough done, it has the minor problem of being yet another +>>>> file nearly all ikiwikis will have to load, and also, prefs would +>>>> have to be disabled manually. So I like that using the hook would +>>>> cause it to auto-disable if nothing uses it. It's a bit ugly that +>>>> passwordauth doesn't need an auth hook (it could be reorged to +>>>> use it instead of formbuilder, maybe) and would probably just have an +>>>> empty one. Thanks for the idea. --[[Joey]] [[done]] + +>>>>> Thanks for implementing it! --[[Lunar]] diff --git a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn index 95c38f794..bf8de16cd 100644 --- a/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn +++ b/doc/todo/Bestdir_along_with_bestlink_in_IkiWiki.pm.mdwn @@ -1,5 +1,8 @@ This patch adds function bestdir() which returns best directory from the directory structure. This is in addition to the bestlink() function which is there in IkiWiki.pm +> Um, what is this for? :-) It would probably be a lot easier to review if it +> had documentation, and/or a plugin that used it. --[[smcv]] + ------- Index: IkiWiki.pm @@ -45,4 +48,4 @@ This patch adds function bestdir() which returns best directory from the directo ---- -[[users/arpitjain]] -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn index 89167c084..4bc828e6e 100644 --- a/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn +++ b/doc/todo/Set_arbitrary_date_to_be_used_by_calendar_plugin.mdwn @@ -1,4 +1,4 @@ -[[!tag patch]] +[[!tag patch plugins/calendar]] Here's my next version of the patch - still a work in progress. diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn new file mode 100644 index 000000000..492a8d747 --- /dev/null +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -0,0 +1,73 @@ +[[!tag plugins/meta patch]] + +I'd like to define [[plugins/meta]] values to apply across all pages +site-wide unless the pages define their own: default values for meta +definitions essentially. + +Here's a patch to achieve this (also in the "defaultmeta" branch of +my github ikiwiki fork): + + diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm + index b229592..3132257 100644 + --- a/IkiWiki/Plugin/meta.pm + +++ b/IkiWiki/Plugin/meta.pm + @@ -13,6 +13,7 @@ sub import { + hook(type => "needsbuild", id => "meta", call => \&needsbuild); + hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1); + hook(type => "pagetemplate", id => "meta", call => \&pagetemplate); + + hook(type => "scan", id => "meta", call => \&scan); + } + + sub getsetup () { + @@ -302,6 +303,15 @@ sub match { + } + } + + +sub scan() { + + my %params = @_; + + my $page = $params{page}; + + foreach my $type (map { s/^meta_//; $_ } grep /^meta_/, keys %config) { + + $pagestate{$page}{meta}{$type} = $config{"meta_$type"} + + unless defined $pagestate{$page}{meta}{$type}; + + } + +} + + + package IkiWiki::PageSpec; + + sub match_title ($$;@) { + diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn + index 000f461..200c4b2 100644 + --- a/doc/ikiwiki/directive/meta.mdwn + +++ b/doc/ikiwiki/directive/meta.mdwn + @@ -12,6 +12,12 @@ also specifies some additional sub-parameters. + The field values are treated as HTML entity-escaped text, so you can include + a quote in the text by writing `"` and so on. + + +You can also define site-wide defaults for meta values by including them + +in your setup file, e.g. + + + + meta_copyright => "Copyright 2007 by Joey Hess", + + meta_license => "GPL v2+", + + + Supported fields: + + * title + +-- [[Jon]] + +> This doesn't support multiple-argument meta directives like +> `link=x rel=y`, or meta directives with special side-effects like +> `updated`. +> +> The first could be solved (if you care) by a syntax like this: +> +> meta_defaults => [ +> { copyright => "© me" }, +> { link => "about:blank", rel => "silly", }, +> ] +> +> The second could perhaps be solved by invoking `meta::preprocess` from within +> `scan` (which might be a simplification anyway), although this is complicated +> by the fact that some (but not all!) meta headers are idempotent. +> +> --[[smcv]] diff --git a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn index f60fc3d6e..f1d33114f 100644 --- a/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn +++ b/doc/todo/auto-create_tag_pages_according_to_a_template.mdwn @@ -4,7 +4,7 @@ Tags are mainly specific to the object to which they’re stuck. However, I ofte Also see: <http://madduck.net/blog/2008.01.06:new-blog/> and <http://users.itk.ppke.hu/~cstamas/code/ikiwiki/autocreatetagpage/> -[[!tag wishlist]] +[[!tag wishlist plugins/tag patch]] I would love to see this as well. -- dato diff --git a/doc/todo/backlinks_result_is_lossy.mdwn b/doc/todo/backlinks_result_is_lossy.mdwn new file mode 100644 index 000000000..7b64a4f2c --- /dev/null +++ b/doc/todo/backlinks_result_is_lossy.mdwn @@ -0,0 +1,10 @@ +[[!tag patch patch/core]] + +IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a +lossy transformation (to get it in the form that page templates want), making +it more difficult to use in other contexts (like pagestats). + +A commit on my `among` branch splits it into IkiWiki::backlink_pages +(which returns the keys of $backlinks{$page}, and might be suitable for +exporting) and IkiWiki::backlinks (which calls backlink_pages, then performs +the same lossy transformation as before on the result). diff --git a/doc/todo/blogpost_plugin.mdwn b/doc/todo/blogpost_plugin.mdwn index bb91ffd02..69df27271 100644 --- a/doc/todo/blogpost_plugin.mdwn +++ b/doc/todo/blogpost_plugin.mdwn @@ -153,4 +153,4 @@ Index: IkiWiki.pm our $version='unknown'; # VERSION_AUTOREPLACE done by Makefile, DNE </pre> -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/enable-htaccess-files.mdwn b/doc/todo/enable-htaccess-files.mdwn index e3b295123..e302a49ed 100644 --- a/doc/todo/enable-htaccess-files.mdwn +++ b/doc/todo/enable-htaccess-files.mdwn @@ -12,7 +12,7 @@ qr/(^|\/).svn\//, qr/.arch-ids\//, qr/{arch}\//], wiki_link_regexp => qr/\[\[(?:([^\]\|]+)\|)?([^\s\]#]+)(?:#([^\s\]]+))?\]\]/, -[[!tag patch]] +[[!tag patch patch/core]] This lets the site administrator have a `.htaccess` file in their underlay directory, say, then get it copied over when the wiki is built. Without @@ -39,6 +39,13 @@ access and such .htaccess files should not be accessible through wiki cgi. Of co > See [[!debbug 447267]] for a patch for this. +>> It looks to me as though this functionality won't be included in ikiwiki +>> unless someone who wants it takes responsibility for updating the patch +>> from that Debian bug to be applicable to current versions, so that there's a +>> setup file parameter for extra filenames to allow, defaulting to none +>> (i.e. a less simplistic patch than the one at the top of this page). +>> Joey, is this an accurate summary? --[[smcv]] + --- bump! I would like to see some form of this functionality included in ikiwiki. I use a patched version, but @@ -47,4 +54,8 @@ but I use ikiwiki with a very small group of people collaborating so svn/web acc and htaccess is for limiting access to some areas of wiki. It should be off by default of course. --Max -[[!tag patch]] +--- ++1 I want `.htaccess` so I can rewrite some old Wordpress URLs to make feeds work again. --[[hendry]] + +--- ++1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]] diff --git a/doc/todo/format_escape.mdwn b/doc/todo/format_escape.mdwn index 574883d1b..762f16646 100644 --- a/doc/todo/format_escape.mdwn +++ b/doc/todo/format_escape.mdwn @@ -97,7 +97,7 @@ I've created an updated [patch](http://www.idletheme.org/code/patches/ikiwiki-fo --Ryan Koppenhaver ## Original patch -[[!tag patch]] +[[!tag patch patch/core plugins/rst]] <pre> Index: debian/changelog diff --git a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn index a6a6ec1e1..7cf37fbb9 100644 --- a/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn +++ b/doc/todo/hard-coded_location_for_man_pages_and_w3m_cgi_wrapper.mdwn @@ -12,7 +12,7 @@ while the default stays as it is now. > INSTALLMAN1DIR (though MakeMaker lacks one for man8). I'd prefer not > adding new variables where MakeMaker already has them. --[[Joey]] -[[!tag patch]] +[[!tag patch patch/core]] <pre> diff --git a/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn new file mode 100644 index 000000000..336ae38d6 --- /dev/null +++ b/doc/todo/inline_plugin:_specifying_ordered_page_names.mdwn @@ -0,0 +1,14 @@ +A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds +the following parameter to the [[ikiwiki/directive/inline]] directive: + +> * `pagenames` - If given instead of `pages`, this is interpreted as a +> space-separated list of links to pages (with the same +> [[ikiwiki/SubPage/LinkingRules]] as in a [[ikiwiki/WikiLink]]), and they are inlined +> in exactly the order given: the `sort` and `pages` parameters cannot be used +> in conjunction with this one. + +This is on my [[wishlist]] for my [[plugins/contrib/album]] plugin, which currently +uses it internally (as it has already collected the pages in order). It could also +be useful for other things, like [[todo/wikitrails]]. --[[smcv]] + +[[!tag plugins/inline]] diff --git a/doc/todo/inline_postform_autotitles.mdwn b/doc/todo/inline_postform_autotitles.mdwn index 5005208be..b3366f60e 100644 --- a/doc/todo/inline_postform_autotitles.mdwn +++ b/doc/todo/inline_postform_autotitles.mdwn @@ -1,5 +1,4 @@ -[[!tag wishlist]] -[[!tag patch]] +[[!tag wishlist patch plugins/inline]] for postforms in inlines of pages which follow a certain scheme, it might not be required to set the title for each individual post, but to automatically set diff --git a/doc/todo/language_definition_for_the_meta_plugin.mdwn b/doc/todo/language_definition_for_the_meta_plugin.mdwn index 4ac4e2e25..8c4b45141 100644 --- a/doc/todo/language_definition_for_the_meta_plugin.mdwn +++ b/doc/todo/language_definition_for_the_meta_plugin.mdwn @@ -81,4 +81,16 @@ This may be useful for sites with a few pages in different languages, but no ful > Please resolve lang somewhere reusable rather than within meta plugin: It is certainly usable outside > the scope of the meta plugin as well. --[[JonasSmedegaard]] +>> I don't see any problem with having this in meta? meta is on by default, and +>> other plugins are free to use it or even depend on it (e.g. inline does). +>> +>> My only comments on this patch beyond what Joey said are that the page +>> language could usefully go into `$pagestate{$page}{meta}{lang}` for other +>> plugins to be able to see it (is that what you meant?), and that +>> restricting to 2 characters is too restrictive (HTML 4.01 mentions +>> `en`, `en-US` and `i-navajo` as possible language codes). +>> This slightly complicates parsing the locale to get the default language: +>> it'll need `tr/_/-/` after the optional `.encoding` is removed. +>> --[[smcv]] + [[!tag wishlist patch plugins/meta translation]] diff --git a/doc/todo/meta_rcsid.mdwn b/doc/todo/meta_rcsid.mdwn index 158edea6e..9e112317f 100644 --- a/doc/todo/meta_rcsid.mdwn +++ b/doc/todo/meta_rcsid.mdwn @@ -1,4 +1,4 @@ -The following patch adds an 'rcsid' parameter to the Meta plugin, to allow inclusion +The following patch adds an 'rcsid' parameter to the [[!taglink plugins/Meta]] plugin, to allow inclusion of CVS/SVN-style keywords (like '$Id$', etc.) from the source file in the page template. > So the idea is you'd write something like: diff --git a/doc/todo/missingparents.pm.mdwn b/doc/todo/missingparents.pm.mdwn index c5f2ab535..cecac7a94 100644 --- a/doc/todo/missingparents.pm.mdwn +++ b/doc/todo/missingparents.pm.mdwn @@ -258,4 +258,4 @@ Index: IkiWiki.pm my $page=shift; </pre> -[[!tag patch]] +[[!tag patch patch/core]] diff --git a/doc/todo/more_class__61____34____34___for_css.mdwn b/doc/todo/more_class__61____34____34___for_css.mdwn index 4712c12b3..cace27d63 100644 --- a/doc/todo/more_class__61____34____34___for_css.mdwn +++ b/doc/todo/more_class__61____34____34___for_css.mdwn @@ -15,6 +15,8 @@ Here's the one-liner: > applied --[[Joey]] +---- + The following adds a div element with class="trailer" around the meta-information added after an inlined page (namely: the post date, the tags, and the actions): @@ -42,7 +44,7 @@ added after an inlined page (namely: the post date, the tags, and the actions): > gets confused by these nested div's and puts p's around one of them, generating > broken html. If you can come up with a way to put in the div that passes > the test suite, or a fix to markdown, I will accept it, but the above patch -> fails the test suite. --[[Joey]] +> fails the test suite. --[[Joey]] >> Just a note... This discrepancy doesn't exist in [pandoc](http://code.google.com/p/pandoc/) as >> demonstrated in the relevant [page](http://code.google.com/p/pandoc/wiki/PandocVsMarkdownPl). @@ -64,6 +66,16 @@ added after an inlined page (namely: the post date, the tags, and the actions): >>>> to at least get into debian testing before I make ikiwiki depend on it >>>> though. --[[Joey]] +>> This Markdown issue seems to have been worked around by the optimization +>> in which \[[!inline]] is replaced with a placeholder, and the +>> placeholder is later replaced by the HTML. Meanwhile, this patch +>> has been obsoleted by applying a similar one (wrapping things in a div +>> with class inlinefooter). That was the last remaining unapplied patch +>> on this page, so I think this whole page can be considered [[done]]. +>> --[[smcv]] + +---- + I'd like a class attribute on the `<span>` tag surrounding wikilinks that refer to non-existent pages, in Ikiwiki.pm:htmllink, so that such broken links can be styled more dramatically with CSS. --Jamey diff --git a/doc/todo/pagestats_among_a_subset_of_pages.mdwn b/doc/todo/pagestats_among_a_subset_of_pages.mdwn new file mode 100644 index 000000000..1c1656b4e --- /dev/null +++ b/doc/todo/pagestats_among_a_subset_of_pages.mdwn @@ -0,0 +1,26 @@ +[[!tag patch plugins/pagestats]] + +My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that +to provide pagestats for links from a subset of pages. From the docs included +in the patch: + +> The optional `among` parameter limits counting to pages that match a +> [[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog +> entries, you could use: +> +> \[[!pagestats pages="tags/*" among="blog/posts/*"]] +> +> or to display a cloud of tags related to Linux, you could use: +> +> \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]] + +I use this on my tag pages on one site, with the following template: + + \[[!pagestats pages="tags/* and !tags/<TMPL_VAR raw_tag> + and !tags/photogallery" + among="tagged(<TMPL_VAR raw_tag>)"]] + + \[[!inline pages="tagged(<TMPL_VAR raw_tag>)" + archive="yes" quick="yes" reverse="yes" timeformat="%x"]] + +--[[smcv]] diff --git a/doc/todo/passwordauth:_sendmail_interface.mdwn b/doc/todo/passwordauth:_sendmail_interface.mdwn index 9598af234..29f28ca32 100644 --- a/doc/todo/passwordauth:_sendmail_interface.mdwn +++ b/doc/todo/passwordauth:_sendmail_interface.mdwn @@ -1,4 +1,4 @@ -[[!tag wishlist]] +[[!tag wishlist plugins/passwordauth]] For sending out password reminder emails, the [[plugins/passwordauth]] plugin currently uses the *[Mail::Sendmail](http://search.cpan.org/perldoc?Mail::Sendmail)* module. @@ -52,3 +52,10 @@ Remaining TODOs: > lost it. --[[Joey]] Resent. --[[tschwinge]] + +> Debian now has Mail::Sender, Mail::SendEasy, and Email::Sender +> (which, according to its dpkg description, "replaces the old and sometimes +> problematic Email::Send library, which did a decent job at handling very +> simple email sending tasks, but was not suitable for serious use, for a +> variety of reasons"). Are any of those any better? It's unfortunate that +> there doesn't seem to be a clear "best practice"... --[[smcv]] diff --git a/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn new file mode 100644 index 000000000..3d4338a78 --- /dev/null +++ b/doc/todo/pretty-print_OpenIDs_even_if_not_enabled.mdwn @@ -0,0 +1,29 @@ +A feature I originally requested on +[[a_related_bug|bugs/openid_no_longer_pretty-prints_OpenIDs]]: + + Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser + + On various sites I have two IkiWiki instances running from the same + repository: one accessible via http and only accepting openid logins, + and one accessible via authenticated https and only accepting httpauth. + Ideally, the https version should still pretty-print OpenIDs seen in + git history. + +--[[smcv]] + +> I wonder if an option is the best approach. Maybe it would be better to +> simply move `openiduser` into `userlink`, and thus always support openid +> usernames whether the plugin is enabled or not. --[[Joey]] + +>> OK, implemented that as 'smcv/always-openid'; if you don't think that's +>> bloating the IkiWiki core too much, please consider merging. The poll on +>> [[news/openid]] indicates fairly strong support for *only* accepting OpenID +>> logins, so I think recognising OpenIDs can reasonably be considered core +>> functionality! --[[smcv]] + +>>> That seemed easier than expected, [[done]]. +>>> (I do wonder if the call to openiduser still needs to be evaled -- +>>> it was probably only evaled before in case it was not available, but +>>> I have not carefully checked it to make sure it doesn't ever die. --[[Joey]] + +[[!tag patch]] diff --git a/doc/todo/should_optimise_pagespecs.mdwn b/doc/todo/should_optimise_pagespecs.mdwn index 0ef8a7847..61458d972 100644 --- a/doc/todo/should_optimise_pagespecs.mdwn +++ b/doc/todo/should_optimise_pagespecs.mdwn @@ -79,4 +79,21 @@ I can think about reducung the size of my wiki source and making it available on > > --[[Joey]] -[[!tag wishlist]] +>> I've been looking at optimizing ikiwiki for a site using +>> [[plugins/contrib/album]] (which produces a lot of pages) and it seems +>> that checking which pages depend on which pages does take a significant +>> amount of time. The optimize-depends branch in my git repository +>> avoids using `pagespec_merge()` for this (indeed it's no longer used +>> at all), and instead represents dependencies as a list of pagespecs +>> rather than a single pagespec. This does turn out to be faster, although +>> not as much as I'd like. --[[smcv]] + +>>> I just wanted to note that there is a whole long discussion of dependencies and pagespecs on the [[todo/tracking_bugs_with_dependencies]] page. -- [[Will]] + +>>>> Yeah, I had a look at that (as the only other mention of `pagespec_merge`). +>>>> I think I might have solved some of the problems mentioned there, +>>>> actually - `pagespec_merge` no longer needs to exist in my branch (although +>>>> I haven't actually deleted it), because the "or" operation is now done in +>>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]] + +[[!tag wishlist patch patch/core]] diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn index b051361a8..9d9ec9697 100644 --- a/doc/todo/source_link.mdwn +++ b/doc/todo/source_link.mdwn @@ -4,6 +4,11 @@ How about a direct link from the page header to the source of the latest version I just implemented this. There is one [[patch]] to the default page template, and a new plugin. -- [[Will]] +> The use of sessioncgi here seems undesirable: on wikis where anonymity is +> not allowed, you'll be asked to log in. Couldn't you achieve the same thing +> by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does? +> --[[smcv]] + ---- diff --git a/templates/page.tmpl b/templates/page.tmpl diff --git a/doc/todo/support_for_plugins_written_in_other_languages.mdwn b/doc/todo/support_for_plugins_written_in_other_languages.mdwn index 8476d1b44..006b6fd5e 100644 --- a/doc/todo/support_for_plugins_written_in_other_languages.mdwn +++ b/doc/todo/support_for_plugins_written_in_other_languages.mdwn @@ -1,4 +1,4 @@ -ikiwiki should support writing plugins in other languages +ikiwiki should support [[writing plugins in other languages|plugins/write/external]] > [[done]] !! diff --git a/doc/todo/tmplvars_plugin.mdwn b/doc/todo/tmplvars_plugin.mdwn index 644cf23aa..2fe819682 100644 --- a/doc/todo/tmplvars_plugin.mdwn +++ b/doc/todo/tmplvars_plugin.mdwn @@ -2,6 +2,29 @@ A simple plugin to allow per-page customization of a template by passing paramat [[!tag patch]] +> The implementation looks fine to me (assuming it works with current ikiwiki), +> apart from the "XXX" already noted in the patch. The design could reasonably +> be considered premature generalization, though - how often do you actually +> need to define new tmplvars? +> +> As for the page/destpage/preview thing, it would be good if the preprocess +> hook could distinguish between software-supplied and user-supplied +> parameters (the [[plugins/tag]] plugin could benefit from this too). Perhaps +> the IkiWiki core could be modified so that +> `hook(type => "preprocess", splitparams => 1, ...)` would invoke preprocess +> with { page => "foo", destpage => "bar", ... } as a special first argument, +> and the user-supplied parameters as subsequent arguments? Then plugins like +> tag could use: +> +> my $ikiparams = shift; +> my %params = @_; +> +> add_tags($ikiparams->{page}, keys %params); +> +> --[[smcv]] + +---- + #!/usr/bin/perl package IkiWiki::Plugin::tmplvars; diff --git a/doc/todo/tracking_bugs_with_dependencies.mdwn b/doc/todo/tracking_bugs_with_dependencies.mdwn index 3a761731b..80aaf3c39 100644 --- a/doc/todo/tracking_bugs_with_dependencies.mdwn +++ b/doc/todo/tracking_bugs_with_dependencies.mdwn @@ -1,3 +1,5 @@ +[[!tag patch patch/core]] + I like the idea of [[tips/integrated_issue_tracking_with_ikiwiki]], and I do so on several wikis. However, as far as I can tell, ikiwiki has no functionality which can represent dependencies between bugs and allow pagespecs to select based on dependencies. For instance, I can't write a pagespec which selects all bugs with no dependencies on bugs not marked as done. --[[JoshTriplett]] > I started having a think about this. I'm going to start with the idea that expanding diff --git a/doc/todo/unaccent_url_instead_of_encoding.mdwn b/doc/todo/unaccent_url_instead_of_encoding.mdwn index 1be150a82..d74b632bd 100644 --- a/doc/todo/unaccent_url_instead_of_encoding.mdwn +++ b/doc/todo/unaccent_url_instead_of_encoding.mdwn @@ -6,4 +6,4 @@ This is a one liner change, but requires a bit of reordering in the code. [[cstamas]] -[[!tag wishlist patch]] +[[!tag wishlist patch patch/core]] diff --git a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn index b28469993..d292a1184 100644 --- a/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn +++ b/doc/todo/varioki_--_add_template_variables___40__with_closures_for_values__41___in_ikiwiki.setup.mdwn @@ -33,6 +33,12 @@ ManojSrivastava > > directory, which is not very easy for a plain ol' user. Not everyone is the > > sysadmin of their own machines with access to system dirs. --ManojSrivastava +>>> It seems worth mentioning here that the `libdir` configuration parameter +>>> lets you install additional plugins in a user-controlled directory +>>> (*libdir*`/IkiWiki/Plugin`), avoiding needing root; indeed, a full local +>>> ikiwiki installation without any involvement from the sysadmin is +>>> [[possible|tips/DreamHost]]. --[[smcv]] + <pre> varioki => {'motto' => '"Manoj\'s musings"', 'arrayvar' => '[0, 1, 2, 3]', diff --git a/doc/todo/wikitrails/discussion.mdwn b/doc/todo/wikitrails/discussion.mdwn index 327e61491..9dbbb6bc8 100644 --- a/doc/todo/wikitrails/discussion.mdwn +++ b/doc/todo/wikitrails/discussion.mdwn @@ -1,9 +1,3 @@ -This sounds like a more general version of what I want for -one-photo-per-page galleries, where each page has previous|up|next links -(like this plugin) and the index page has a list or grid of thumbnails -(\[[!inline]] with a specially modified template perhaps). I'll watch this -with interest! --[[smcv]] - This is a nice idea, I do have my gripes about the imeplementation. Assuming that the index's list is in mdwn format is not ideal. I guess the @@ -22,3 +16,65 @@ breadcrums to be automatically inserted at the top of every page on the trail. (You'd have to use a directive to define the index for that to work.) --[[Joey]] + +---- + +Revisiting this, after effectively reimplementing a small version of it +in [[plugins/contrib/album]]: it occurs to me that might be a more +"ikiwiki-like" way we could get this functionality. + +In the index page, you either want an [[ikiwiki/directive/inline]], or +a list of links. In the former case, maybe we could extend inline like +this: + + \[[!inline ... blah blah ... trail=yes]] + +to make it remember the pages it inlined, in order, in the pagestate; +in the latter case, we could replace the wikilinks with a directive, +an operation something like this in diff notation: + + - \[[one]] - the unit + - \[[two]] - the base of binary + - \[[three|3]] - is a crowd + + \[[!trailitem one]] - the unit + + \[[!trailitem two]] - the base of binary + + \[[!trailitem three|3]] - is a crowd + +and have that directive remember the pages in order. + +In both cases, a scan() hook could clear the list before starting to +scan, then the inline or trailitem preprocessor directive could run in +the scan stage as well as the render stage (in the case of inline, +there'd be a very early return if trail=yes was not given, and +an early return after collecting and sorting the pages if not +actually rendering). + +This would mean that the contents of the trail, and a list of +trails in which each page can be found, would already be in +the pagestate by the time any page was rendered, so we'd be able +to use them for output, either in a pagetemplate() hook or +a \[[!trail]] preprocessor directive. + +This way, my album plugin could be turned inside out: instead +of precomputing the pages to be inlined, then using +[[pagenames|todo/inline plugin: specifying ordered page names]] +to get them into the inline, it could just do the inline, then +incorporate the output of \[[!trail]] into the template rendered +for \[[!albumimage]] on each viewer page. (Also, the viewers +wouldn't necessarily need to reference the album, only the other +way round.) + +Using a pagetemplate() hook to stuff the next/previous links +into page.tmpl would actually be a bit unfortunate for \[[!album]], +because that plugin definitely wants to style the next/previous +links as a thumbnail, which means there'd have to be a way to +affect the style - perhaps by arranging for album's pagetemplate +hook to run *after* trail's, or perhaps by having trail's +pagetemplate hook disable itself for pages that contain +a \[[!trail]] directive. + +I have now implemented this at [[plugins/contrib/trail]]. +What do you think? I'm still not sure how it would relate +to [[plugins/contrib/album]], but if trail is reviewed +and approved in principle, I'll try to adapt album as +outlined above. --[[smcv]] |