Merge branch 'master' of ssh://git.ikiwiki.info
Joey Hess
commit
2c2c537dd5
|
|
@ -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]]
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1 @@
|
|||
Is ist possible to set a template variable from the config file?
|
||||
|
|
@ -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 `<TMPL_VAR CONFIG-FOO>`.
|
||||
"""]]
|
||||
|
|
@ -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**
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<snip old patch>
|
||||
|
||||
-- [[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
|
||||
<snip old patch>
|
||||
|
||||
-- [[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]]
|
||||
|
|
|
|||
|
|
@ -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 <jmtd@debian.org>
|
||||
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;
|
||||
<snip old patch; see git branch outlined above>
|
||||
|
||||
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]]
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
<https://github.com/jmtd/ikiwiki/blob/websetup_hashes/hash.html>. 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]]
|
||||
Loading…
Reference in New Issue