doc/todo/allow_site-wide_meta_definitions.mdwn

   1 [[!tag plugins/meta patch]]
   2 [[!template id=gitbranch branch=jon/defaultmeta author="[[Jon]]"]]
   3
   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.
   7
   8     <snip old patch, see below for latest>
   9
  10 -- [[Jon]]
  11
  12 > This doesn't support multiple-argument meta directives like
  13 > `link=x rel=y`, or meta directives with special side-effects like
  14 > `updated`.
  15 >
  16 > The first could be solved (if you care) by a syntax like this:
  17 >
  18 >     meta_defaults => [
  19 >         { copyright => "© me" },
  20 >         { link => "about:blank", rel => "silly", },
  21 >     ]
  22 >
  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.
  26 >
  27 > --[[smcv]]
  28
  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.
  32 >>
  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!
  38
  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
  42 >>> problems.
  43 >>>
  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
  47 >>> a list.)
  48 >>>
  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.
  52 >>>
  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...
  58 >>>
  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]]
  62
  63     <snip old patch>
  64
  65 -- [[Jon]]
  66
  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
  70 >> basis.
  71 >>
  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.
  76 >>
  77 >> Not useful are permalink, date, stylesheet (you already have a global
  78 >> stylesheet), link, redir, and guid.
  79 >>
  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.
  83 >>
  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.)
  88 >>> --[[Joey]]
  89 >>
  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.
  93 >>
  94 >> Is this merge-worthy?
  95
  96     <snip old patch>
  97
  98 -- [[Jon]]
  99
 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]]
 104
 105 >>>> Ping :) Hi.  [[Joey]], would you consider this patch for the next
 106 >>>> ikiwiki release? -- [[Jon]]
 107
 108 >>> For this to work with websetup and --dumpsetup, it needs to define the
 109 >>> `meta_*` settings in the getsetup function.
 110 >>>>
 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
 116 >>>> getsetup.
 117 >>>>
 118 >>>> Perhaps a limited set of defined meta values could be exposed via
 119 >>>> websetup (the obvious ones: author, copyright, license, etc.) -- [[Jon]]
 120 >>>
 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
 129 >>> run.
 130 >>>
 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]]
 135 >>>>
 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.
 142 >>>>>
 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.
 148 >>>>>
 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.
 152 >>>>>
 153 >>>>> The patch can be found at the git branch described above.
 154 >>>>>  — [[Jon]]
 155
 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]]
 160
 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.
 163 >>>>>>> — [[Jon]]