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
I even had the XSL produce an
Editlink 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
.xmlextension. That would satisfy the
pagetypetest that causes the edit CGI to say
not an editable page. (That happens too early for a
htmlizehook 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
editcontenthook could validate the XML. (Can an
editcontenthook signal a content error?)
The tricky bit seems to be to register the fact that the target file should have extension
.html. Maybe what's needed is a generalized notion of an
htmlizehook, 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
htmlizefor 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:
- 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.
- 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:
- 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.
- 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.
%renderedfilesis 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
htmlizehook 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
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
For PlaceWiki I want to be able to do some custom plugins, including one that links together subpages about the same place created by different users. This seems to call for a plugin that applies to every page w/o any specific marker being used, and pre-or-post-processes the full page content. It also needs to update pages when related pages are added, so it needs to register dependencies pre-emptively between pages, or something. It's possible that this is a special case of backlinks and is best implemented by making backlinks a plugin somehow. --Joey
random page (cgi plugin; how to link to it easily?)
How about an event calendar. Events could be sub-pages with an embedded code to detail recurrance and/or event date/time
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.)
asciidoc or txt2tags format plugins
Should be quite easy to write, the otl plugin is a good example of a similar formatter.
Isn't there a conflict between ikiwiki using [[ ]] and asciidoc using the same? There is a start of an asciidoc plugin at http://firstname.lastname@example.org/msg00120.html -- KarlMW
- manpage plugin: convert "ls(1)" style content into Markdown like [ls(1)](http://example.org/man.cgi?name=ls§=1) or into HTML directly.
With a full installation of groff available, man offers HTML output. Might take some fiddling to make it fit into the ikiwiki templates, and you might or might not want to convert pages in the SEE ALSO as well. --JoshTriplett
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.
Setting default values for the meta plugin in the setup file, particularly author, license, and copyright, would be useful There is work in progress at default content for *copyright* and *license* -- DavidBremner