X-Git-Url: https://sipb.mit.edu/gitweb.cgi/ikiwiki.git/blobdiff_plain/ab1b2add9817c0c9b48b2bfb62a228188997a2b9..1b46f52043aa6eff37da3677d7bdf11944b733ab:/doc/todo/plugin.mdwn diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn index 4d034a814..c2322f788 100644 --- a/doc/todo/plugin.mdwn +++ b/doc/todo/plugin.mdwn @@ -1,27 +1,43 @@ 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 + * 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]] -* [[sigs]] ? - -* 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.) - - Or using an iframe - to inline the cgi, although firefox seems to render that nastily with - nested scroll bars. :-( -> Or just link to the equivalent in the version control system, if available; -> gitweb's shortlog or summary view would work nicely as a -> RecentChanges. --[[JoshTriplett]] ->>Why not fork the process? We wouldn't have to wait around for a response since we would assume the recent changes page was being generated correctly. - * It would be nice to be able to have a button to show "Differences" (or "Show Diff") when editing a page. Is that an option that can be enabled? Using a plugin? @@ -60,4 +76,15 @@ Suggestions of ideas for plugins: * 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. - > 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]] \ No newline at end of file + > 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]] + +* 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]] + +* 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 +[[plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__]] +-- [[DavidBremner]] + +* Would it make sense to have a hook to set the page name? This would solve a problem I see with +[[source_code_highlighting|plugins/contrib/sourcehighlight]] +-- [[DavidBremner]]