git.oblomov.eu Git - ikiwiki/blob - doc/todo/Render_multiple_destinations_from_one_source.mdwn

   1 I've set up a couple of sites where the users use ikiwiki in fairly standard mode as a CMS and I then set up another ikiwiki setup file that's got the edit options turned off, but is pointing at the same git repository in the background.  I then make the post-update hook for each be <tt>post-update-hook.ikiwiki</tt> and <tt>post-update-hook.ikiwiki-public</tt> and have the <tt>post-update</tt> hook itself be a script like:
   2
   3     #!/bin/sh
   4
   5     $0.ikiwiki "$@"
   6     $0.ikiwiki-public "$@"
   7
   8 obviously this results in duplication of most of the <tt>ikiwiki.setup</tt>, a spare working directory that (perhaps) isn't needed, and an extra post-update hook plus wrapper script that is really needless extra complication.
   9
  10 If instead there was a way of specifying additional destdir's, or perhaps more generally a way of specifying that there should be multiple passes through the build process using alternative values for some of the variables, then one could have both the private wiki view, and the public static view generated with minimal additional configuration.
  11
  12 One idea that occurs to me is an <tt>additional_configs</tt> list where one would specify files containing just the settings you want to override compared with the main setup file.
  13
  14 Alternatively, one might invent a new way of specifying alternative settings.  i.e.:
  15
  16      additionalsites:
  17        - public
  18
  19      destdir: /home/wiki/wiki-view
  20      destdir[public]: /home/wiki/public_html
  21
  22      disable_plugins: []
  23      disable_plugins[public]:
  24        - recentchanges
  25        - editpage
  26
  27      url: https://example.com/editors/
  28      url[public]: http://www.example.com/
  29
  30      ...
  31
  32 where the existance of the <tt>additionalsites</tt> list provokes additional runs through using the settings with matching extra bits to be used to override the defaults found in the rest of the file.
  33
  34 Just brainstorming a bit after [[liw]]'s comment about this being useful on IRC, and thought I'd write the idea up while I was thinking about it. -[[fil]]
  35
  36 > I don't think you can avoid ikiwiki needing to store a different
  37 > `.ikiwiki` directory with state for each site. Differences in
  38 > configuration can affect the state it stores in arbitrary ways,
  39 > ranging from which pages are even built to what plugins are enabled and
  40 > store state. This also means that it doesn't make sense to try and
  41 > share state amoung rebuilds of the same site.
  42 >
  43 > There is a hidden, and undocumented configuration setting `wikistatedir`
  44 > that can actually be pointed at a different directory than `.ikiwiki`.
  45 > Then you can rebuild multiple configurations from one working directory.
  46 >
  47 > Another handy trick is to use the old perl-format (not yaml) setup file,
  48 > and parameterize it using `$ENV{FOO}`, then you can build two different
  49 > setups from the same setup file.
  50 > --[[Joey]]
  51
  52 > > My post-update script has grown a bit, as I'm using ikiwiki-hosting now, so want to let the users update stuff themselves:
  53 > >
  54 > >     #!/bin/sh
  55 > >
  56 > >     PUB_URL=http://truestedt.hands.com
  57 > >     PUB_TMPL=$HOME/source-public/templates-public
  58 > >
  59 > >     # make the public config, in case of updates via ikiwiki-hosting
  60 > >     sed -e 's/^\(srcdir\|destdir\|git_wrapper\): .*/&-public/;s#^\(url:\).*#\1 '$PUB_URL'#;s/^\(cgi_wrapper:\).*/\1 '"''"'/;s#^\(templatedir:\).*#\1 '$PUB_TMPL'#;s/^\(cgiurl\|historyurl\):/#&/;/disable_plugins:/a \
  61 > >     - recentchanges\
  62 > >     - editpage' ~/ikiwiki.setup > ~/ikiwiki.setup-public
  63 > >     #echo 'wikistatedir: source/.ikiwiki-public' >> ~/ikiwiki.setup-public
  64 > >     [ -d ~/source-public ] || cp -a ~/source ~/source-public
  65 > >     [ -d ~/public_html-public ] || mkdir ~/public_html-public
  66 > >
  67 > >     # run normal post-update hook
  68 > >     ./hooks/post-update-ikiwiki "$@"
  69 > >
  70 > >     # run post-update hook for the public version of the site
  71 > >     ./hooks/post-update-ikiwiki-public "$@"
  72 > >
  73 > >     exec git update-server-info
  74 > >
  75 > > I tried using wikistatedir, as you suggested, but then wiki edits are not reflected on the second site (AFAICT), so reverted to having a full checkout of the source.
  76 > > I'm guessing that that's because the second run through with the post-update hook sees no changes that it needs to worry about in the source directory, but it's just
  77 > > possible that I got confused while testing, as the sed is pretty fragile, so some of the time it was failing because of sed syntax errors.
  78 > >
  79 > > It strikes me that one ought to be able to have a plugin that takes the current config, applies a few minor tweaks to it (perhaps by loading an extra config file) and
  80 > > then does some or all of the tasks normally run by main() again, targeting a new directory -- that way there would be no need for the two post-updates, and whatever
  81 > > provoked a rebuild would always do both, whether on the command line or via CGI.
  82 > > I just don't know quite where the right place to plumb such a plugin in would be -- also, it would be good to separate out the bits of main() that we'd be calling
  83 > > so that both the plugin and main calls them in the same way, to ease future maintenance
  84 > >
  85 > > Any hints on where to start with such a plugin, gratefully received :-)  -[[fil]]