From: Joey Hess Date: Tue, 30 Aug 2011 15:38:30 +0000 (-0400) Subject: Merge branch 'master' of ssh://git.ikiwiki.info X-Git-Tag: 3.20110905~20 X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/commitdiff_plain/2c2c537dd521bbc659f0499af72ca70078d97d50?hp=4af7b2c14d548beaf09f100e7fc6efc39e9c73a2 Merge branch 'master' of ssh://git.ikiwiki.info --- diff --git a/doc/bugs/conditional_preprocess_during_scan.mdwn b/doc/bugs/conditional_preprocess_during_scan.mdwn index 896998bf8..baa430e19 100644 --- a/doc/bugs/conditional_preprocess_during_scan.mdwn +++ b/doc/bugs/conditional_preprocess_during_scan.mdwn @@ -8,3 +8,12 @@ I've written a simple [[patch]] to fix the issue, currently hosted on the scanif branch of my repository. The patch also passes the preview option back to the Ikiwiki::preprocess call, making sure that whatever is being reprocessed is done so in the same conditions as the original call. + +> One problem with this is that it has the same dependency-ordering problems +> as inline-based or pagespec-based trails with my [[plugins/contrib/trail]] +> plugin: `if` takes a pagespec, but pagespecs aren't guaranteed to match +> correctly until everything has been scanned (for instance, `link()` might +> give the wrong results because a page that added or deleted a link hasn't +> been scanned yet). If you have a clever idea for how to fix this, I'd love +> to hear it - being able to specify a [[plugins/contrib/trail]] in terms +> of a sorted pagespec would be useful. --[[smcv]] diff --git a/doc/forum/Define_custom_commands.mdwn b/doc/forum/Define_custom_commands.mdwn new file mode 100644 index 000000000..c8ac00eed --- /dev/null +++ b/doc/forum/Define_custom_commands.mdwn @@ -0,0 +1 @@ +Is it possible to define custom "commands" in ikiwiki? For example if I write &%test&% in the source of a wiki-page in markdown, the word "test" should be displayed red, bold and italic. diff --git a/doc/forum/Setting_template_variable_from_config_file__63__.mdwn b/doc/forum/Setting_template_variable_from_config_file__63__.mdwn new file mode 100644 index 000000000..ac7631e60 --- /dev/null +++ b/doc/forum/Setting_template_variable_from_config_file__63__.mdwn @@ -0,0 +1 @@ +Is ist possible to set a template variable from the config file? diff --git a/doc/forum/Setting_template_variable_from_config_file__63__/comment_1_bb4b5a7a49f33d660b5116fc0ce3c92d._comment b/doc/forum/Setting_template_variable_from_config_file__63__/comment_1_bb4b5a7a49f33d660b5116fc0ce3c92d._comment new file mode 100644 index 000000000..6dddb1f21 --- /dev/null +++ b/doc/forum/Setting_template_variable_from_config_file__63__/comment_1_bb4b5a7a49f33d660b5116fc0ce3c92d._comment @@ -0,0 +1,8 @@ +[[!comment format=mdwn + username="http://kerravonsen.dreamwidth.org/" + ip="202.173.183.92" + subject="comment 1" + date="2011-08-29T23:07:21Z" + content=""" +With the [[plugins/contrib/field]] plugin one can; set the `field_allow_config` config value to 1, and the config variables are accessible with a \"CONFIG-\" prefix. That is, if you set a value \"foo\" in the config file, then you would access it in in the template as ``. +"""]] diff --git a/doc/plugins/contrib/field.mdwn b/doc/plugins/contrib/field.mdwn index dce2d891c..e57f91362 100644 --- a/doc/plugins/contrib/field.mdwn +++ b/doc/plugins/contrib/field.mdwn @@ -54,7 +54,7 @@ The following options can be set in the ikiwiki setup file. field_allow_config => 1, Allow the $config hash to be queried like any other field; the -keys of the config hash are the field names. +keys of the config hash are the field names, with a prefix of "CONFIG-". **field_register** diff --git a/doc/todo/allow_site-wide_meta_definitions.mdwn b/doc/todo/allow_site-wide_meta_definitions.mdwn index 82670250e..a308e0d8c 100644 --- a/doc/todo/allow_site-wide_meta_definitions.mdwn +++ b/doc/todo/allow_site-wide_meta_definitions.mdwn @@ -60,75 +60,7 @@ definitions essentially. >>> I'm not necessarily saying that's a good idea. Indeed, my memory >>> concerns below invalidate this idea pretty well. --[[Joey]] - diff --git a/IkiWiki/Plugin/meta.pm b/IkiWiki/Plugin/meta.pm - index 6fe9cda..2f8c098 100644 - --- a/IkiWiki/Plugin/meta.pm - +++ b/IkiWiki/Plugin/meta.pm - @@ -13,6 +13,8 @@ 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) - + if $config{"meta_defaults"}; - } - - sub getsetup () { - @@ -305,6 +307,15 @@ sub match { - } - } - - +sub scan() { - + my %params = @_; - + my $page = $params{page}; - + foreach my $default (@{$config{"meta_defaults"}}) { - + preprocess(%$default, page => $page, - + destpage => $page, preview => 0); - + } - +} - + - package IkiWiki::PageSpec; - - sub match_title ($$;@) { - diff --git a/IkiWiki/Setup.pm b/IkiWiki/Setup.pm - index 8a25ecc..e4d50c9 100644 - --- a/IkiWiki/Setup.pm - +++ b/IkiWiki/Setup.pm - @@ -51,7 +51,13 @@ sub merge ($) { - $config{$c}=$setup{$c}; - } - else { - - $config{$c}=[map { IkiWiki::possibly_foolish_untaint($_) } @{$setup{$c}}] - + $config{$c}=[map { - + if(ref $_ eq 'HASH') { - + $_ - + } else { - + IkiWiki::possibly_foolish_untaint($_) - + } - + } @{$setup{$c}}]; - } - } - elsif (ref $setup{$c} eq 'HASH') { - diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn - index 000f461..8d34ee4 100644 - --- a/doc/ikiwiki/directive/meta.mdwn - +++ b/doc/ikiwiki/directive/meta.mdwn - @@ -12,6 +12,16 @@ 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. The key used is `meta_defaults` and the value is a list - +of hashes, one per meta directive. e.g.: - + - + meta_defaults = [ - + { copyright => "Copyright 2007 by Joey Hess" }, - + { license => "GPL v2+" }, - + { link => "somepage", rel => "site entrypoint", }, - + ], - + - Supported fields: - - * title + -- [[Jon]] @@ -159,51 +91,7 @@ definitions essentially. >> >> Is this merge-worthy? - 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]] @@ -244,3 +132,21 @@ definitions essentially. >>> metadata of the given type is present. --[[Joey]] >>>> >>>> that should be easy enough to do. I will work on a patch. -- [[Jon]] +>>>>> Hi — I've written a new patch which I hope addresses the concerns raised +>>>>> with the previous ones. The new approach is to hard-code in `scan()` +>>>>> which of the meta types are supported in the setup file. If one is +>>>>> defined, then `scan()` calls `preprocess()`, as [[smcv]] suggested, +>>>>> rather than stuffing redundant data into ikiwiki's data structures. +>>>>> +>>>>> Two types supported in the setup file have optional arguments: `author` +>>>>> and `title`. These are supported by having special-cased setup keys +>>>>> `meta_author_sortas` and `meta_title_sortas`. Future expansion of the +>>>>> number of supported types, or addition of arguments to existing ones, +>>>>> can similarly be special-cased. +>>>>> +>>>>> The setup data structure is no longer complicated with an +>>>>> array-of-hashes, which means this is suitable for exposing via websetup. +>>>>> `getsetup()` has been adjusted accordingly. +>>>>> +>>>>> The patch can be found at the git branch described above. +>>>>> — [[Jon]] diff --git a/doc/todo/pagespec_aliases.mdwn b/doc/todo/pagespec_aliases.mdwn index 43714dc50..afb655bc2 100644 --- a/doc/todo/pagespec_aliases.mdwn +++ b/doc/todo/pagespec_aliases.mdwn @@ -1,3 +1,4 @@ +[[!template id=gitbranch branch=jon/pagespec_alias author="[[Jon]]"]] [[!tag patch wishlist]]I quite often find myself repeating a boiler-plate [[ikiwiki/pagespec]] chunk, e.g. @@ -10,64 +11,7 @@ pagespec "alias", and instead write I wrote the following plugin to achieve this: - commit f3a9dd113338fe5d2b717de1dc69679ff74e2f8d - Author: Jon Dowland - Date: Tue May 3 17:40:16 2011 +0100 - - new plugin: alias.pm - pagespec aliases - - diff --git a/IkiWiki/Plugin/alias.pm b/IkiWiki/Plugin/alias.pm - new file mode 100644 - index 0000000..b8d4574 - --- /dev/null - +++ b/IkiWiki/Plugin/alias.pm - @@ -0,0 +1,47 @@ - +package IkiWiki::Plugin::alias; - + - +use warnings; - +use strict; - +use IkiWiki '3.00'; - + - +sub import { - + hook(type => "getsetup", id=> "alias", call => \&getsetup); - + hook(type => "checkconfig", id=> "alias", call => \&checkconfig); - +} - + - +sub getsetup () { - + return - + plugin => { - + description => "allows the definition of pagespec aliases", - + safe => 1, - + rebuild => 1, - + section => "misc", - + }, - + pagespec_aliases => { - + type => "string", - + example => {"image" => "*jpg or *jpeg or *png or *gif or *ico" }, - + description => "a set of mappings from alias name to pagespec", - + safe => 1, - + rebuild => 0, - + }, - +} - + - +sub checkconfig () { - + no strict 'refs'; - + no warnings 'redefine'; - + - + if ($config{pagespec_aliases}) { - + foreach my $key (keys %{$config{pagespec_aliases}}) { - + my $value = ${$config{pagespec_aliases}}{$key}; - + # XXX: validate key? - + my $subname = "IkiWiki::PageSpec::match_$key"; - + *{ $subname } = sub { - + my $path = shift; - + return IkiWiki::pagespec_match($path, $value); - + } - + } - + } - +} - + - +1; + I need to reflect on this a bit more before I send a pull request. In particular I imagine the strict/warnings stuff will make you puke. Also, I'm @@ -76,9 +20,8 @@ an existing wishlist item. > I think it would make sense to have "pagespec" in the name somehow. -> > Good idea, how about `pagespecalias`? — [[Jon]] +>> Good idea, how about `pagespecalias`? — [[Jon]] -> > No, the strict/warnings does not make me puke. Have you read my perl > code? :-P > @@ -136,6 +79,19 @@ however, to add ' or internal()' to `boring`, for some reason. >> Useful indeed! --[[Joey]] + +>>> I've tweaked my patch in light of your above feedback: The plugin has been +>>> renamed, and I now validate keys. I've also added documentation and tests +>>> to the branch. I haven't read rubykat's code properly yet, and don't have +>>> access at the time of writing (I'm on a beach in Greece ☺), but I expect it +>>> would be possible to extend what I've got here to support defining the +>>> aliases in a PageSpec, once the dependency stuff has been reasoned out +>>> properly. +>>> +>>> I'd like to solve the issue of this not being web-configurable by +>>> implementing support for more nested datatypes in [[plugins/websetup]]. — +>>> [[Jon]] + --------------------------- Based on the above, I have written an experimental plugin called "subset". @@ -184,3 +140,17 @@ Unfortunately I haven't figured out how to do the dependencies - I'd really appr >>> As for the name "subset"... well, it's even less like an alias now, and "alias" is already a reserved name. What other names would you suggest? >>>--[[KathrynAndersen]] + +>>>> Regarding my comments: I wasn't clear what you are/were intending to +>>>> achieve with your modifications. I've aimed for a self-contained plugin +>>>> which could be merged with ikiwiki proper. I think I initially took your +>>>> developments as being an evolution of that with the same goal, which is +>>>> why I commented on the (change of) name. However, I guess your work is +>>>> more of a fork than a continuation, in which case you can call it +>>>> whatever you like ☺ I like some of the enhancements you've made, but +>>>> having the aliases/subsets/"things" work in any pagespec (inside map, or +>>>> inline) is a deal-breaker for me. — [[Jon]] + +>>>>> I'm a bit confused by your statement "having the aliases/subsets/"things" work in any pagespec (inside map, or inline) is a deal-breaker for me". +>>>>> Do you mean that you want them to work in any pagespec, or that you *don't* want them to work in any pagespec? -- [[KathrynAndersen]] + diff --git a/doc/todo/support_dicts_in_setup.mdwn b/doc/todo/support_dicts_in_setup.mdwn new file mode 100644 index 000000000..c89158e21 --- /dev/null +++ b/doc/todo/support_dicts_in_setup.mdwn @@ -0,0 +1,19 @@ +It would be nice for some plugins to use hashes as setup data structures +(which ones? pagespec aliases for one. Any others?), but these cannot +currently be adequately described in `getsetup()`, nor represented in +`websetup()`. It would be nice to extend ikiwiki to support this. + +I've had an initial go at how to represent this in a nice way within a HTML +page. An initial mock up is available at +. The +approach taken is to use a javascript hash/dictionary as the canonical copy of +the data; to express that in the form elements, and to capture all relevant +events to update the main data structure (and the HTML representations +thereof). + +I imagine packing the js structure into a form element which is posted, and +ignoring the other form element data. + +This would mean mandating javascript support for editing such hashes. + +— [[Jon]]