Merge branch 'master' of ssh://git.ikiwiki.info/srv/git/ikiwiki.info
commit
b10c6dd631
|
@ -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. :-)
|
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]]
|
[[bugs/done]]
|
||||||
|
|
|
@ -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!
|
|
@ -37,8 +37,12 @@ I have written additional plugins which integrate with the [[plugins/contrib/fie
|
||||||
> with different syntaxes while keeping `field` for the
|
> with different syntaxes while keeping `field` for the
|
||||||
> behind-the-scenes bits.
|
> 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
|
> 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.
|
> probably... I'll try to work on that at some point.
|
||||||
>
|
>
|
||||||
> [[plugins/contrib/report]] may be doing too much, though:
|
> [[plugins/contrib/report]] may be doing too much, though:
|
||||||
|
|
|
@ -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;
|
|
@ -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]]
|
|
@ -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]]
|
Loading…
Reference in New Issue