1 [[!tag plugins/meta patch]]
2 [[!template id=gitbranch branch=jon/defaultmeta author="[[Jon]]"]]
4 I'd like to define [[plugins/meta]] values to apply across all pages
5 site-wide unless the pages define their own: default values for meta
6 definitions essentially.
8 <snip old patch, see below for latest>
12 > This doesn't support multiple-argument meta directives like
13 > `link=x rel=y`, or meta directives with special side-effects like
16 > The first could be solved (if you care) by a syntax like this:
19 > { copyright => "© me" },
20 > { link => "about:blank", rel => "silly", },
23 > The second could perhaps be solved by invoking `meta::preprocess` from within
24 > `scan` (which might be a simplification anyway), although this is complicated
25 > by the fact that some (but not all!) meta headers are idempotent.
29 >> Thanks for your comment. I've revised the patch to use the config syntax
30 >> you suggest. I need to perform some more testing to make sure I've
31 >> addressed the issues you highlight.
33 >> I had to patch part of IkiWiki core, the merge routine in Setup, because
34 >> the use of `possibly_foolish_untaint` was causing the hashrefs at the deep
35 >> end of the data structure to be converted into strings. The specific change
36 >> I've made may not be acceptable, though -- I'd appreciate someone providing
37 >> some feedback on that hunk!
39 >>> Well, re that hunk, taint checking is currently disabled, but
40 >>> if the perl bug that disallows it is fixed and it is turned back on,
41 >>> the hash values will remain tainted, which will probably lead to
44 >>> I'm also leery of using such a complex data structure in config.
45 >>> The websetup plugin would be hard pressed to provide a UI for such a
46 >>> data structure. (It lacks even UI for a single hash ref yet, let alone
49 >>> Also, it seems sorta wrong to have two so very different syntaxes to
50 >>> represent the same meta data. A user without a lot of experience will
51 >>> be hard pressed to map from a directive to this in the setup file.
53 >>> All of which leads me to think the setup file could just contain
54 >>> a text that could hold meta directives. Which generalizes really to
55 >>> a text that contains any directives, and is, perhaps appended to the
56 >>> top of every page. Which nearly generalizes to the sidebar plugin,
57 >>> or perhaps something more general than that...
59 >>> However, excessive generalization is the root of all evil, so
60 >>> I'm not necessarily saying that's a good idea. Indeed, my memory
61 >>> concerns below invalidate this idea pretty well. --[[Joey]]
67 >> Ok, I've had a bit of a think about this. There are currently 15 supported
68 >> meta fields. Of these: title, licence, copyright, author, authorurl,
69 >> and robots might make sense to define globally and override on a per-page
72 >> Less so, description (due to its impact on map); openid (why would
73 >> someone want more than one URI to act as an openid endpoint to the same
74 >> place?); updated. I can almost see why someone might want to set a global
75 >> updated value. Almost.
77 >> Not useful are permalink, date, stylesheet (you already have a global
78 >> stylesheet), link, redir, and guid.
80 >> In other words, the limitations of my first patch that [[smcv]] outlined
81 >> are only relevant to defined fields that you wouldn't want to specify a
82 >> global default for anyway.
84 >>> I generally agree with this. It is *possible* that meta would have a new
85 >>> field added, that takes parameters and make sense to use globally.
86 >>> (Indeed, this later happened to some extent with the sortas parameters
87 >>> being added to some metas.)
90 >> Due to this, and the added complexity of the second patch (having to adjust
91 >> `IkiWiki/Setup.pm`), I think the first patch makes more sense. I've thus
92 >> reverted to it here.
94 >> Is this merge-worthy?
100 >>> Merry Christmas/festive season/happy new year folks. I've been away from
101 >>> ikiwiki for the break, and now I've returned to watching recentchanges.
102 >>> Hopefully I'll be back in the mix soon, too. In the meantime, Joey, have
103 >>> you had a chance to look at this yet? -- [[Jon]]
105 >>>> Ping :) Hi. [[Joey]], would you consider this patch for the next
106 >>>> ikiwiki release? -- [[Jon]]
108 >>> For this to work with websetup and --dumpsetup, it needs to define the
109 >>> `meta_*` settings in the getsetup function.
111 >>>> I think this will be problematic with the current implementation of this
112 >>>> patch. The datatype here is an array of hash references, with each hash
113 >>>> having a variable (and arbitrary) number of key/value pairs. I can't
114 >>>> think of an intuitive way of implementing a way of editing such a
115 >>>> datatype in the web interface, let alone registering the option in
118 >>>> Perhaps a limited set of defined meta values could be exposed via
119 >>>> websetup (the obvious ones: author, copyright, license, etc.) -- [[Jon]]
121 >>> I also have some concerns about both these patches, since both throw
122 >>> a lot of redundant data at meta, which then stores it in a very redundant
123 >>> way. Specifically, meta populates a per-page `%metaheaders` hash
124 >>> as well as storing per-page metadata in `%pagestate`. So, if you have
125 >>> a wiki with 10 thousand pages, and you add a 1k site-wide license text,
126 >>> that will bloat the memory usage of ikiwiki by in excess of 2
127 >>> megabytes. It will also cause ikiwiki to write a similar amount more data
128 >>> to its state file which has to be loaded back in each
131 >>> Seems that this could be managed much more efficiently by having
132 >>> meta special-case the site-wide settings, not store them in these
133 >>> per-page data structures, and just make them be used if no per-page
134 >>> metadata of the given type is present. --[[Joey]]
136 >>>> that should be easy enough to do. I will work on a patch. -- [[Jon]]
137 >>>>> Hi — I've written a new patch which I hope addresses the concerns raised
138 >>>>> with the previous ones. The new approach is to hard-code in `scan()`
139 >>>>> which of the meta types are supported in the setup file. If one is
140 >>>>> defined, then `scan()` calls `preprocess()`, as [[smcv]] suggested,
141 >>>>> rather than stuffing redundant data into ikiwiki's data structures.
143 >>>>> Two types supported in the setup file have optional arguments: `author`
144 >>>>> and `title`. These are supported by having special-cased setup keys
145 >>>>> `meta_author_sortas` and `meta_title_sortas`. Future expansion of the
146 >>>>> number of supported types, or addition of arguments to existing ones,
147 >>>>> can similarly be special-cased.
149 >>>>> The setup data structure is no longer complicated with an
150 >>>>> array-of-hashes, which means this is suitable for exposing via websetup.
151 >>>>> `getsetup()` has been adjusted accordingly.
153 >>>>> The patch can be found at the git branch described above.
156 >>>>>> I wish I could take pity on you and just merge this, but
157 >>>>>> AFAICS it still suffers from the memory bloat described above.
158 >>>>>> Specifically, when `scan` calls `preprocess`, it
159 >>>>>> stores the metadata in `%pagestate` etc. --[[Joey]]
161 >>>>>>> No pity required — but whoops, yes, that was a bit of a mistake
162 >>>>>>> ☺ I guess I'll have to split the current `preprocess` in half.
165 >>>>>>>> I've been taking another look at this today, as I'm very keen to
166 >>>>>>>> close various open loops of mine in IkiWiki to move on and do some
167 >>>>>>>> other stuff. However, I'm not actually *using* this at the moment,
168 >>>>>>>> so whilst I think it's a good idea, I can't really motivate myself
169 >>>>>>>> to fix it anymore. I guess for now, this should just rot. — [[Jon]]
projects / ikiwiki / blob