Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info

master
Joey Hess 2010-03-26 12:59:57 -04:00
commit b10c6dd631
6 changed files with 120 additions and 1 deletions

View File

@ -41,4 +41,6 @@ Whilst trying to edit http://hugh.vm.bytemark.co.uk/ikiwiki.cgi via OpenID. Any
Thanks for you excellent analysis. The bug was due to old pre-3.0 **templates** laying about. After deleting them, ikiwiki defaults to its own templates. Clever. :-)
Great, this saved me big time! It is a google 1st hit. I had the same with accidentally using old templates. Thanks! --[[cstamas]]
[[bugs/done]]

View File

@ -0,0 +1,15 @@
When installing ikiwiki the perl module path is setup correctly
use lib '/usr/local/ikiwiki-3.20100312/share/perl/5.10.0';
This is not true for ikiwiki-transition:
$ PATH=/usr/local/ikiwiki-3.20100312/bin ikiwiki-transition prefix_directives ikiwiki.setup
Can't locate IkiWiki.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.10.0
/usr/local/share/perl/5.10.0 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.10 /usr/share/perl/5.10 /usr/local/lib/site_perl .)
at /usr/local/ikiwiki-3.20100312/bin/ikiwiki-transition line 4.
BEGIN failed--compilation aborted at /usr/local/ikiwiki-3.20100312/bin/ikiwiki-transition line 4.
The missing line should be added.
Thanks!

View File

@ -37,8 +37,12 @@ I have written additional plugins which integrate with the [[plugins/contrib/fie
> with different syntaxes while keeping `field` for the
> behind-the-scenes bits.
>
>> I've started using `field` on a private site and it's working
>> well for me; I'll try to do some code review on its
>> [[plugins/contrib/field/discussion]] page. --s
>
> My [[plugins/contrib/album]] plugin could benefit from
> integration with [[field]] for photos' captions and so on,
> integration with `field` for photos' captions and so on,
> probably... I'll try to work on that at some point.
>
> [[plugins/contrib/report]] may be doing too much, though:

View File

@ -0,0 +1,62 @@
Having tried out `field`, some comments (from [[smcv]]):
The general concept looks great.
The `pagetemplate` hook seems quite namespace-polluting: on a site containing
a list of books, I'd like to have an `author` field, but that would collide
with IkiWiki's use of `<TMPL_VAR AUTHOR>` for the author of the *page*
(i.e. me). Perhaps it'd be better if the pagetemplate hook was only active for
`<TMPL_VAR FIELD_AUTHOR>` or something? (For those who want the current
behaviour, an auxiliary plugin would be easy.)
From a coding style point of view, the `$CamelCase` variable names aren't
IkiWiki style, and the `match_foo` functions look as though they could benefit
from being thin wrappers around a common `&IkiWiki::Plugin::field::match`
function (see `meta` for a similar approach).
I think the documentation would probably be clearer in a less manpage-like
and more ikiwiki-like style?
If one of my branches from [[todo/allow_plugins_to_add_sorting_methods]] is
accepted, a `field()` cmp type would mean that [[plugins/contrib/report]] can
stop reimplementing sorting. Here's the implementation I'm using, with
your "sortspec" concept (a sort-hook would be very similar): if merged,
I think it should just be part of `field` rather than a separate plugin.
# Copyright © 2010 Simon McVittie, released under GNU LGPL >= 2.1
package IkiWiki::Plugin::fieldsort;
use warnings;
use strict;
use IkiWiki 3.00;
use IkiWiki::Plugin::field;
sub import {
hook(type => "getsetup", id => "fieldsort", call => \&getsetup);
}
sub getsetup () {
return
plugin => {
safe => 1,
rebuild => undef,
},
}
package IkiWiki::PageSpec;
sub check_cmp_field {
if (!length $_[0]) {
error("sort=field requires a parameter");
}
}
sub cmp_field {
my $left = IkiWiki::Plugin::field::field_get_value($_[2], $_[0]);
my $right = IkiWiki::Plugin::field::field_get_value($_[2], $_[1]);
$left = "" unless defined $left;
$right = "" unless defined $right;
return $left cmp $right;
}
1;

View File

@ -0,0 +1,13 @@
I initially thought this wasn't actually necessary - the combination
of [[plugins/template]] with [[plugins/contrib/field]]'s `pagetemplate`
hook ought to provide the same functionality. However, `template`
doesn't run `pagetemplate` hooks; a more general version of this
plugin would be to have a variant of `template` that runs `pagetemplate`
hooks (probably easiest to just patch `template` to implement a
second directive, or have a special parameter `run_hooks="yes"`,
or something).
Another missing thing is that `ftemplate` looks in
the "system" templates directories, not just in the wiki, but that
seems orthogonal (and might be a good enhancement to `template` anyway).
--[[smcv]]

View File

@ -0,0 +1,23 @@
Wow, this plugin does a lot... it seems to be `inline` (but without the feeds
or the ability to not have `archive="yes"`), plus part of
[[plugins/contrib/trail]], plus some sorting, plus an ingenious workaround
for template evaluation being relatively stateless.
A large part of this plugin would just fall off if one of the versions of
"[[todo/allow_plugins_to_add_sorting_methods]]" was merged, which was a
large part of the idea of that feature request :-) To make use of that
you'd have to use `pagespec_match_list` in the trail case too, but that's
easy enough - just add `list => [@the_trail_pages]` to the arguments.
Another large part would fall off if this plugin required, and internally
invoked, `inline` (like my `comments` plugin does) - `inline` runs
`pagetemplate` hooks, and in particular, it'll run the `field` hook.
Alternatively, this plugin could invoke `pagetemplate` hooks itself,
removing the special case for `field`.
Perhaps the `headers` thing could migrate into inline somehow? That might
lead to making inline too big, though.
Is the intention that the `trail` part is a performance hack, or a way
to select pages? How does it relate to [[todo/wikitrails]] or
[[plugins/contrib/trail]]? --[[smcv]]