doc/todo/plugin.mdwn

   1 Suggestions of ideas for plugins:
   2
   3 * enable editable, non-htmlized files
   4
   5     Some months ago, before upgrading my wiki, I used svn to check in an XML file
   6     and a companion XSL file for client-side styling. That was cool, ikiwiki
   7     copied them over unchanged and the file could be linked to as `\[[foo|foo.xml]]`.
   8
   9     I even had the XSL produce an `Edit` link at the top, because I wanted a simple
  10     way for a web user to edit the XML. But I had to hack stuff to make the edit CGI
  11     not say `foo.xml is not an editable page`.
  12
  13     I did that in a kind of slash-and-burn way, and apparently that's the one change
  14     that was uncommitted when I upgraded ikiwiki, so now it's in the same place
  15     as the wikiwyg project. On the bright side, that's a chance to think about how to
  16     do it better.
  17
  18     Any suggestions for appropriate uses of existing plugins, or the plugin API,
  19     to selectively add to the set of files in the working copy that the edit CGI
  20     will consider editable? --ChapmanFlack 17July2008
  21
  22     > It looks like 80% of the job would be accomplished by hooking `htmlize` for
  23     > the `.xml` extension. That would satisfy the `pagetype` test that causes
  24     > the edit CGI to say `not an editable page`. (That happens too early for a
  25     > `canedit` hook.) The `htmlize` hook could just
  26     > copy in to out unchanged (this is an internal wiki, I'm not thinking hard
  27     > about evil XML content right now). For extra credit, an `editcontent` hook
  28     > could validate the XML. (Can an `editcontent` hook signal a content error?)
  29
  30     > The tricky bit seems to be to register the fact that the target file should
  31     > have extension `.xml` and not `.html`.  Maybe what's needed is a generalized
  32     > notion of an `htmlize` hook, one that specifies its output extension as well
  33     > as its input, and isn't assumed to produce html? --ChapmanFlack 17July2008
  34
  35     > Belay that, there's nothing good about trying to use `htmlize` for this; too
  36     > many html-specific assumptions follow. For now I'm back to an embarrassing quick
  37     > hack that allows editing my xml file.  But here's the larger generalization I
  38     > think this is driving at:
  39
  40     > IkiWiki is currently a tool that can compile a wiki by doing two things:
  41     > 1. Process files of various input types _foo_ into a single output type, html, by
  42     >    finding suitable _foo_->html plugins, applying various useful transformations
  43     >    along the way.
  44     > 1. Process files of other input types by copying them with no useful transformations at all.
  45
  46     > What it could be: a tool that compiles a wiki by doing this:
  47     > 1. Process files of various input types _foo_ into various output types _bar_, by
  48     >    finding suitable _foo_->_bar_ plugins, applying various useful transformations along
  49     >    the way, but only those that apply to the _foo_->_bar_ conversion.
  50     > 1. The second case above is now just a special case of 1 where _foo_->_foo_ for any
  51     >    unknown _foo_ is just a copy, and no other transformations apply.
  52
  53     > In some ways this seems like an easy and natural generalization. `%renderedfiles`
  54     > is already mostly there, keeping the actual names of rendered files without assuming
  55     > an html extension. There isn't a mechanism yet to say which transformations for
  56     > linkification, preprocessing, etc., apply to which in/out types, but it could be
  57     > easily added without a flag day. Right now, they _all_ apply to any input type for
  58     > which an `htmlize` hook exists, and _none_ otherwise. That rule could be retained
  59     > with an optional hook parameter available to override it.
  60
  61     > The hard part is just that right now the assumption of html as the one destination
  62     > type is in the code a lot. --ChapmanFlack
  63
  64     >> Readers who bought this also liked: [[format_escape]], [[multiple_output_formats]]
  65     >> --[[JeremieKoenig]]
  66
  67 * list of registered users - tricky because it sorta calls for a way to rebuild the page when a new user is registered. Might be better as a cgi?
  68 > At best, this could only show the users who have logged in, not all
  69 > permitted by the current auth plugin(s).  HTTP auth would need
  70 > web-server-specific code to list all users, and openid can't feasibly do so
  71 > at all. --[[JoshTriplett]]
  72
  73 * For PlaceWiki I want to be able to do some custom plugins, including one
  74   that links together subpages about the same place created by different
  75   users. This seems to call for a plugin that applies to every page w/o any
  76   specific marker being used, and pre-or-post-processes the full page
  77   content. It also needs to update pages when related pages are added,
  78   so it needs to register dependencies pre-emptively between pages,
  79   or something. It's possible that this is a special case of backlinks and
  80   is best implemented by making backlinks a plugin somehow. --[[Joey]]
  81
  82 * random page (cgi plugin; how to link to it easily?)
  83
  84 * How about an event calendar. Events could be sub-pages with an embedded
  85   code to detail recurrance and/or event date/time
  86
  87 * rcs plugin ([[JeremyReed]] has one he has been using for over a month with over 850 web commits with 13 users with over ten commits each.)
  88
  89 * asciidoc or txt2tags format plugins
  90
  91   Should be quite easy to write, the otl plugin is a good example of a
  92   similar formatter.
  93
  94 >>Isn't there a conflict between ikiwiki using \[\[  \]\] and asciidoc using the same?
  95 >>There is a start of an asciidoc plugin at <http://www.mail-archive.com/asciidoc-discuss@metaperl.com/msg00120.html>
  96 >>-- KarlMW
  97
  98 * manpage plugin: convert **"ls(1)"** style content into Markdown like **\[ls(1)\]\(http://example.org/man.cgi?name=ls&sect=1\)** or into HTML directly.
  99
 100 > With a full installation of groff available, man offers HTML output.  Might
 101 > take some fiddling to make it fit into the ikiwiki templates, and you might
 102 > or might not want to convert pages in the SEE ALSO as
 103 > well. --[[JoshTriplett]]
 104
 105 * As I couldn't find another place to ask, I'll try here. I would like to install some contributed plugins, but can not find anywhere to downlod them.
 106
 107   > Not sure what you mean, the [[plugins/contrib]] page lists contributed plugins, and each of their pages tells where to download the plugin from.. --[[Joey]]
 108
 109 * I wrote a very crude wrapper around tex4ht to render TeX files.  I hesitate to give it a contrib/plugins page in its current state, but if someone wants to play, [here](http://www.cs.unb.ca/~bremner/wiki/software/ikiwiki/tex4ht.pm) it is.--[[DavidBremner]]
 110
 111 * Setting default values for the meta plugin in the setup file, particularly author, license, and copyright, would be useful
 112 There is work in progress at
 113 [[plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__]]
 114 -- [[DavidBremner]]
 115
 116 * Would it make sense to have a hook to set the page name?  This would solve a problem I see with
 117 [[source_code_highlighting|plugins/contrib/sourcehighlight]]
 118 -- [[DavidBremner]]