diff --git a/IkiWiki/Plugin/search.pm b/IkiWiki/Plugin/search.pm index c0e8703d8..a1e7026ca 100644 --- a/IkiWiki/Plugin/search.pm +++ b/IkiWiki/Plugin/search.pm @@ -70,7 +70,7 @@ sub index (@) { # A unique pageterm is used to identify the document for a page. my $pageterm=pageterm($params{page}); - return $params{content} unless defined $pageterm; + return unless defined $pageterm; my $db=xapiandb(); my $doc=Search::Xapian::Document->new(); diff --git a/IkiWiki/Render.pm b/IkiWiki/Render.pm index a6b0f0617..bbf8f915e 100644 --- a/IkiWiki/Render.pm +++ b/IkiWiki/Render.pm @@ -366,13 +366,13 @@ sub find_new_files ($) { push @internal_new, $file; } elsif ($config{rcs}) { - if (! $times_noted) { - debug(sprintf(gettext("querying %s for file creation and modification times.."), $config{rcs})); - $times_noted=1; - } - push @new, $file; if ($config{gettime} && -e "$config{srcdir}/$file") { + if (! $times_noted) { + debug(sprintf(gettext("querying %s for file creation and modification times.."), $config{rcs})); + $times_noted=1; + } + eval { my $ctime=rcs_getctime("$config{srcdir}/$file"); if ($ctime > 0) { @@ -431,7 +431,7 @@ sub remove_del (@) { foreach my $file (@_) { my $page=pagename($file); if (! isinternal($page)) { - debug(sprintf(gettext("removing old page %s"), $page)); + debug(sprintf(gettext("removing obsolete %s"), $page)); } foreach my $old (@{$oldrenderedfiles{$page}}) { @@ -634,34 +634,35 @@ sub render_dependent ($$$$$$$) { if ($type == $IkiWiki::DEPEND_LINKS) { next unless $linkchangers->{lc($page)}; } - return $page; + $reason=$page; + return 1; } } return undef; }; if ($depends{$p}{$dep} & $IkiWiki::DEPEND_CONTENT) { - last if $reason = - $in->(\@changed, $IkiWiki::DEPEND_CONTENT); - last if $internal_dep && ($reason = + last if $in->(\@changed, $IkiWiki::DEPEND_CONTENT); + last if $internal_dep && ( $in->($internal_new, $IkiWiki::DEPEND_CONTENT) || $in->($internal_del, $IkiWiki::DEPEND_CONTENT) || - $in->($internal_changed, $IkiWiki::DEPEND_CONTENT)); + $in->($internal_changed, $IkiWiki::DEPEND_CONTENT) + ); } if ($depends{$p}{$dep} & $IkiWiki::DEPEND_PRESENCE) { - last if $reason = - $in->(\@exists_changed, $IkiWiki::DEPEND_PRESENCE); - last if $internal_dep && ($reason = + last if $in->(\@exists_changed, $IkiWiki::DEPEND_PRESENCE); + last if $internal_dep && ( $in->($internal_new, $IkiWiki::DEPEND_PRESENCE) || - $in->($internal_del, $IkiWiki::DEPEND_PRESENCE)); + $in->($internal_del, $IkiWiki::DEPEND_PRESENCE) + ); } if ($depends{$p}{$dep} & $IkiWiki::DEPEND_LINKS) { - last if $reason = - $in->(\@changed, $IkiWiki::DEPEND_LINKS); - last if $internal_dep && ($reason = + last if $in->(\@changed, $IkiWiki::DEPEND_LINKS); + last if $internal_dep && ( $in->($internal_new, $IkiWiki::DEPEND_LINKS) || $in->($internal_del, $IkiWiki::DEPEND_LINKS) || - $in->($internal_changed, $IkiWiki::DEPEND_LINKS)); + $in->($internal_changed, $IkiWiki::DEPEND_LINKS) + ); } } } diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn index 4a3e41e83..cb4213405 100644 --- a/doc/ikiwikiusers.mdwn +++ b/doc/ikiwikiusers.mdwn @@ -120,7 +120,7 @@ Personal sites and blogs * [[Adam_Trickett|ajt]]'s home intranet/sanbox system ([Internet site & blog](http://www.iredale.net/) -- not ikiwiki yet) * [[Simon_McVittie|smcv]]'s [website](http://www.pseudorandom.co.uk/) and [blog](http://smcv.pseudorandom.co.uk/) -* Svend's [website](http://www.ciffer.net/~svend/) and [blog](http://www.ciffer.net/~svend/blog/) +* Svend's [website](http://ciffer.net/~svend/) and [blog](http://ciffer.net/~svend/blog/) * [muammar's site](http://muammar.me) * [Per Bothner's blog](http://per.bothner.com/blog/) * [Bernd Zeimetz (bzed)](http://bzed.de/) diff --git a/doc/peteg.mdwn b/doc/peteg.mdwn new file mode 100644 index 000000000..4e2face0e --- /dev/null +++ b/doc/peteg.mdwn @@ -0,0 +1,7 @@ +I'm adding some plugins to Ikiwiki to support a bioacoustic wiki. See here: + + + +Personal home page: + + diff --git a/doc/todo/Multiple_categorization_namespaces.mdwn b/doc/todo/Multiple_categorization_namespaces.mdwn index ee3bbd88d..74e5bc812 100644 --- a/doc/todo/Multiple_categorization_namespaces.mdwn +++ b/doc/todo/Multiple_categorization_namespaces.mdwn @@ -56,17 +56,33 @@ and the tags would appear at the bottom of the post, the Rubrica next to the tit Aside from the name of the plugin (and thus of the main directive), which could be `tag`, `meta`, `field` or whatever (maybe extending `meta` would be the most sensible choice), the features we want are - 1. allow multiple values per type/attribute/field/whatever (fields currently only allows one) - 2. allow both hidden and visible references (à la tag vs taglink) - 3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too) - 4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones) +1. allow multiple values per type/attribute/field/whatever (fields currently only allows one) + * Agreed about multiple values; I've been considering whether I should add that to `field`. -- K.A. +2. allow both hidden and visible references (a la tag vs taglink) + * Hidden and visible references; that's fair enough too. My approach with `ymlfront` and `getfield` is that the YAML code is hidden, and the display is done with `getfield`, but there's no reason not to use additional approaches. -- K.A. +3. allow each type/attribute/field to be exposed under multiple queries (e.g. tags and categories; this is mostly important for backwards compatibility, not sure if it might have other uses too) + * I'm not sure what you mean here. -- K.A. + * Typical example is tags: they are accessible both as `tags` and as `categories`, although the way they are presented changes a little -- G.B. +4. allow arbitrary types/attributes/fields/whatever (even 'undefined' ones) + * Are you saying that these must be typed, or are you saying that they can be user-defined? -- K.A. + * I am saying that the user should be able to define (e.g. in the config) some set of types/fields/attributes/whatever, following the specification illustrated below, but also be able to use something like `\[[!meta somefield="somevalue"]]` where `somefield` was never defined before. In this case `somefield` will have some default values for the properties described in the spec below. -- G.B. Each type/attribute/field/whatever (predefined, user-defined, arbitrary) would thus have the following parameters: - * `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined. - * `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default - * `linktype` : link type for (hidden and visible) references - * `linkbase` : akin to the tagbase parameter - * `queries` : list of template queries this type/attribute/field/whatever is exposed to +* `directive` : the name of the directive that can be used to set the value as a hidden reference; we can discuss whether, for pre- or user-defined types, it being undef means no directive or a default directive matching the attribute name would be defined. + * I still want there to be able to be enough flexibility in the concept to enable plugins such as `yamlfront`, which sets the data using YAML format, rather than using directives. -- K.A. + * The possibility to use a directive does not preclude other ways of defining the field values. IOW, even if the directive `somefield` is defined, the user would still be able to use the syntax `\[[!meta somefield="somevalue"]]`, or any other syntax (such as YAML). -- G.B. +* `linkdirective` : the name of the directive that can be used for a visible reference; no such directive would be defined by default +* `linktype` : link type for (hidden and visible) references + * Is this the equivalent to "field name"? -- K.A. + * This would be such by default, but it could be set to something different. [[Typed links|matching_different_kinds_of_links]] is a very recent ikiwiki feature. -- G.B. +* `linkbase` : akin to the tagbase parameter + * Is this a field-name -> directory mapping? -- K.A. + * yes, with each directory having one page per value. It might not make sense for all fields, of course -- G.B. + * (nods) I've been working on something similar with my unreleased `tagger` module. In that, by default, the field-name maps to the closest wiki-page of the same name. Thus, if one had the field "genre=poetry" on the page fiction/stories/mary/lamb, then that would map to fiction/genre/poetry if fiction/genre existed. --K.A. +* `queries` : list of template queries this type/attribute/field/whatever is exposed to + * I'm not sure what you mean here. -- K.A. + * as mentioned before, some fields may be made accessible through different template queries, in different form. This is the case already for tags, that also come up in the `categories` query (used by Atom and RSS feeds). -- G.B. + * Ah, do you mean that the input value is the same, but the output format is different? Like the difference between TMPL_VAR NAME="FOO" and TMPL_VAR NAME="raw_FOO"; one is htmlized, and the other is not. -- K.A. -Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. +Where this approach is limiting is on the kind of data that is passed to (template) queries. The value of the metadata fields might need some massaging (e.g. compare how tags are passed to tags queries vs cateogires queries, or also see what is done with the fields in the current `meta` plugin). I have problems on picturing an easy way to make this possible user-side (i.e. via templates and not in Perl modules). Suggestions welcome. diff --git a/doc/todo/auto_rebuild_on_template_change.mdwn b/doc/todo/auto_rebuild_on_template_change.mdwn new file mode 100644 index 000000000..2e4ba8e9a --- /dev/null +++ b/doc/todo/auto_rebuild_on_template_change.mdwn @@ -0,0 +1,48 @@ +If `page.tmpl` is changed, it would be nice if ikiwiki automatically +noticed, and rebuilt all pages. If `inlinepage.tmpl` is changed, a rebuild +of all pages using it in an inline would be stellar. + +This would allow setting: + + templatedir => "$srcdir/templates", + +.. and then the [[wikitemplates]] are managed like other wiki files; and +like other wiki files, a change to them automatically updates dependent +pages. + +Originally, it made good sense not to have the templatedir inside the wiki. +Those templates can be used to bypass the htmlscrubber, and you don't want +just anyone to edit them. But the same can be said of `style.css` and +`ikiwiki.js`, which *are* in the wiki. We rely on `allowed_attachments` +being set to secure those to prevent users uploading replacements. And we +assume that users who can directly (non-anon) commit *can* edit them, and +that's ok. + +So, perhaps the easiest way to solve this [[wishlist]] would be to +make templatedir *default* to "$srcdir/templates/, and make ikiwiki +register dependencies on `page.tmpl`, `inlinepage.tmpl`, etc, as they're +used. Although, having every page declare an explicit dep on `page.tmpl` +is perhaps a bit much; might be better to implement a special case for that +one. Also, having the templates be copied to `destdir` is not desirable. +In a sense, these template would be like internal pages, except not wiki +pages, but raw files. + +The risk is that a site might have `allowed_attachments` set to +`templates/*` or `*.tmpl` something like that. I think such a configuration +is the *only* risk, and it's unlikely enough that a NEWS warning should +suffice. + +(This would also help to clear up the tricky disctinction between +wikitemplates and in-wiki templates.) + +> But would this require that templates be parseable as wiki pages? Because that would be a nuisance. --[[KathrynAndersen]] + +>> It would be better for them not to be rendered separately at all. +>> --[[Joey]] + +>>> I don't follow you. --[[KathrynAndersen]] + +>>>> If they don't render to output files, they clearly don't +>>>> need to be treated as wiki pages. (They need to be treated +>>>> as raw files anyway, because you don't want random users editing them +>>>> in the online editor.) --[[Joey]] diff --git a/doc/users/svend.mdwn b/doc/users/svend.mdwn index 69d83584f..712a0d3e7 100644 --- a/doc/users/svend.mdwn +++ b/doc/users/svend.mdwn @@ -1,4 +1,4 @@ [[!meta title="Svend Sorensen"]] -* [website](http://www.ciffer.net/~svend/) -* [blog](http://www.ciffer.net/~svend/blog/) +* [website](http://ciffer.net/~svend/) +* [blog](http://ciffer.net/~svend/blog/)