doc/plugins/write/discussion.mdwn

   1 Maybe this is obvious, but the config variable lives in the IkiWiki module, and one probably
   2 wants to call defaultconfig for most applications.
   3 <pre>
   4 %IkiWiki::config=IkiWiki::defaultconfig();
   5 IkiWiki::Setup::load($config_file);
   6 print  join(",",keys %IkiWiki::config);
   7 </pre>
   8
   9 [[DavidBremner]]
  10
  11 I'm a little concerned about one aspect of the `%wikistate` variable that was just introduced.
  12 I think global state for each plugin is a fine idea, but I worry about making it persist across
  13 rebuilds.  (And by rebuild, I assume we're talking about the `--rebuild` option.)
  14
  15 My reasoning is that a 'rebuild' should be similar to checking out a new copy of the wiki
  16 and building.  Another way of saying this is that all permanent state should be in the RCS.
  17 It is great that there is temporary state stored in other places - I think of it as indexing
  18 and caching.  I'm worried that with the persistence, plugin writers will start putting data
  19 there that isn't backed by the RCS and that will break IkiWiki's great abilities as a
  20 distributed wiki.
  21
  22 [[Will]]
  23
  24 > Well, if you look at state that already persists across rebuilds, we have
  25 > pagectime, which can be extracted from RCS only very slowly in many
  26 > cases. There's also the separate state stored by the aggregate plugin,
  27 > which is indeed independant of the RCS, and can in some cases not be
  28 > replecated by rebuilding a different checkout (if the data is gone from
  29 > the feeds). Then there's the session cookie database, and the user
  30 > database, which started out with a lot of local state, has been
  31 > whittled down by removing admin prefs and subscriptions, but still has
  32 > important state including password hashes.
  33 >
  34 > So while I take your point about the potential for abuse,
  35 > there's certianly legitimate reasons to need to store data across
  36 > rebuilds. And plugins have always been able to drop their own files in
  37 > wikistatedir as aggregate does and have it persist, so the abuse
  38 > potential has always been there, the barrier has been lowered only
  39 > slightly.
  40 >
  41 > OTOH, if something can be added to the documentation that encourages
  42 > good behavior, that'd be a good thing ... --[[Joey]]
  43
  44 ---
  45
  46 Since there's no mailing list, I'll post my request for help here :-)
  47
  48 I would like to use ikiwiki to build a static site which needs some transformations to be made on binary assets. A simple example is to translate a .odp presentation to .pdf using (e.g.) unoconv. If I add a new .odp attachment, or push one into the repo, I want the corresponding .pdf to appear in the generated site. What's the right place to hook in to do this?
  49
  50 I've made an experimental prototype which hooks into needsbuild, builds the pages then and there, and at the same time removes them from the list of pages to be built.
  51
  52 ~~~
  53 sub needsbuild {
  54     my $files=shift;
  55     my $nfiles=[];
  56     foreach my $f (@$files) {
  57         if ($f =~ /\.odp$/) {
  58             my $g = $f;
  59             $g =~ s/\.odp$/\.pdf/;
  60             debug("building $f to $g");
  61             will_render($f, $g);
  62             if (system("unoconv","-f","pdf","-o",IkiWiki::dirname("$config{destdir}/$g"),srcfile($f)) != 0) {
  63                 error("unoconv: failed to translate $f to $g");
  64             }
  65         }
  66         else {
  67             push @$nfiles, $f;
  68         }
  69     };
  70     return $nfiles;
  71 }
  72 ~~~
  73
  74 It appears to work, but is this the right way to do it, bearing in mind ikiwiki's dependency tracking and the like? And is the usage of will_render() correct?
  75
  76 [[BrianCandler]]
  77
  78 ---
  79
  80 I would find this page clearer split up into sub-pages. Does anyone agree/disagree? -- [[users/Jon]]