-A plugin system should ideally support things like:
-
-* [[todo/lists]] of pages, of mising pages / broken links (done), orphaned
- pages (done), of registered users, etc
-* a [[todo/link_map]]
-* [[todo/sigs]] ?
-* [[pageindexes]]
-* Wiki stats, such as the total number of pages (done), total number of links, most linked to pages, etc, etc.
-* wiki info page, giving the ikiwiki version etc
-* would it be useful to reimplement the hyperestradier search integration as a plugin?
-* Support [[RecentChanges]] as a regular page containing a plugin that updates each time there is a change, and statically builds the recent changes list. (Would this be too expensive/inflexible? There might be other ways to do it as a plugin, like making all links to RecentChanges link to the cgi and have the cgi render it on demand.)
-* Support for smileys or other symbols. I appreciate the support for check
- marks, etc in other wikis.
+Suggestions of ideas for plugins:
+
+* enable editable, non-htmlized files
+
+ Some months ago, before upgrading my wiki, I used svn to check in an XML file
+ and a companion XSL file for client-side styling. That was cool, ikiwiki
+ copied them over unchanged and the file could be linked to as `\[[foo|foo.xml]]`.
+
+ I even had the XSL produce an `Edit` link at the top, because I wanted a simple
+ way for a web user to edit the XML. But I had to hack stuff to make the edit CGI
+ not say `foo.xml is not an editable page`.
+
+ I did that in a kind of slash-and-burn way, and apparently that's the one change
+ that was uncommitted when I upgraded ikiwiki, so now it's in the same place
+ as the wikiwyg project. On the bright side, that's a chance to think about how to
+ do it better.
+
+ Any suggestions for appropriate uses of existing plugins, or the plugin API,
+ to selectively add to the set of files in the working copy that the edit CGI
+ will consider editable? --ChapmanFlack 17July2008
+
+ > It looks like 80% of the job would be accomplished by hooking `htmlize` for
+ > the `.xml` extension. That would satisfy the `pagetype` test that causes
+ > the edit CGI to say `not an editable page`. (That happens too early for a
+ > `canedit` hook.) The `htmlize` hook could just
+ > copy in to out unchanged (this is an internal wiki, I'm not thinking hard
+ > about evil XML content right now). For extra credit, an `editcontent` hook
+ > could validate the XML. (Can an `editcontent` hook signal a content error?)
+
+ > The tricky bit seems to be to register the fact that the target file should
+ > have extension `.xml` and not `.html`. Maybe what's needed is a generalized
+ > notion of an `htmlize` hook, one that specifies its output extension as well
+ > as its input, and isn't assumed to produce html? --ChapmanFlack 17July2008
+
+ > Belay that, there's nothing good about trying to use `htmlize` for this; too
+ > many html-specific assumptions follow. For now I'm back to an embarrassing quick
+ > hack that allows editing my xml file. But here's the larger generalization I
+ > think this is driving at:
+
+ > IkiWiki is currently a tool that can compile a wiki by doing two things:
+ > 1. Process files of various input types _foo_ into a single output type, html, by
+ > finding suitable _foo_->html plugins, applying various useful transformations
+ > along the way.
+ > 1. Process files of other input types by copying them with no useful transformations at all.
+
+ > What it could be: a tool that compiles a wiki by doing this:
+ > 1. Process files of various input types _foo_ into various output types _bar_, by
+ > finding suitable _foo_->_bar_ plugins, applying various useful transformations along
+ > the way, but only those that apply to the _foo_->_bar_ conversion.
+ > 1. The second case above is now just a special case of 1 where _foo_->_foo_ for any
+ > unknown _foo_ is just a copy, and no other transformations apply.
+
+ > In some ways this seems like an easy and natural generalization. `%renderedfiles`
+ > is already mostly there, keeping the actual names of rendered files without assuming
+ > an html extension. There isn't a mechanism yet to say which transformations for
+ > linkification, preprocessing, etc., apply to which in/out types, but it could be
+ > easily added without a flag day. Right now, they _all_ apply to any input type for
+ > which an `htmlize` hook exists, and _none_ otherwise. That rule could be retained
+ > with an optional hook parameter available to override it.
+
+ > The hard part is just that right now the assumption of html as the one destination
+ > type is in the code a lot. --ChapmanFlack
+
+ >> Readers who bought this also liked: [[format_escape]], [[multiple_output_formats]]
+ >> --[[JeremieKoenig]]
+
+* 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?
+> At best, this could only show the users who have logged in, not all
+> permitted by the current auth plugin(s). HTTP auth would need
+> web-server-specific code to list all users, and openid can't feasibly do so
+> at all. --[[JoshTriplett]]
+