ikiwiki/ todo/ done

recently fixed TODO items

pluggablerenderers

Should be able to plug in support for rst or other markup formats.

done

(posted Mon Jul 3 22:32:34 2006)

utf8

ikiwiki should support utf-8 pages, both input and output. To test, here's a utf-8 smiley:

Currently ikiwiki is belived to be utf-8 clean itself; it tells perl to use binmode when reading possibly binary files (such as images) and it uses utf-8 compatable regexps etc.

There may be the odd corner where utf-8 still doesn't work; these are being fixed as they're found.

Notes:

done

(posted Sun Jul 2 19:52:31 2006)

search

done

(posted Sun Jul 2 01:43:23 2006)

underlay

Rather than copy the basewiki around everywhere, it should be configured to underlay the main srcdir, and pages be rendered from there if not in the srcdir. This would allow upgrades to add/edit pages in the basewiki.

Implementaion will be slightly tricky since currently ikiwiki is hardcoded in many places to look in srcdir for pages. Also, there are possible security attacks in the vein of providing a file ikiwiki would normally skip in the srcdir, and tricking it to processing this file instead of the one from the underlaydir. -- Fixed by scanning srcdir first, then underlaydir, and refusing to add any files from underlaydir if they also exist in the srcdir. However, see security for caveats.

done

(posted Sun Jul 2 01:43:23 2006)

htmlvalidation

This page is now valid. Test: validate this page

done

(posted Sun Jul 2 01:43:23 2006)

wikilinkfeatures

done

(posted Sun Jul 2 01:43:23 2006)

mailnotification

Should support mail notification of new and changed pages.

Hmm, should be easy to implement this.. it runs as a svn post-coommit hook already, so just look at the userdb, svnlook at what's changed, and send mails to people who have subscribed.

A few details: 1. Joey mentioned that being able to subscribe to globs as well as explicitly named pages would be desirable. 2. I think that since we're using Perl on the backend, being able to let users craft their own arbitrary regexes would be good.

 Joey points out that this is actually a security hole, because Perl
 regexes let you embed (arbitrary?) Perl expressions inside them.  Yuck!

(This is not actually true unless you "use re 'eval';", without which (?{ code }) is disabled for expressions which interpolate variables. See perldoc re, second paragraph of DESCRIPTION. It's a little iffy to allow arbitrary regexen, since it's fairly easy to craft a regular expression that takes unbounded time to run, but this can be avoided with the use of alarm to add a time limit. Something like

eval { # catches invalid regexen
  no re 'eval'; # to be sure
  local $SIG{ALRM} = sub { die };
  alarm(1);
  ... stuff involving m/$some_random_variable/ ...
  alarm(0);
};
if ($@) { ... handle the error ... }

should be safe. --?WillThompson)

 It would also be good to be able to subscribe to all pages except discussion pages or the SandBox: `* !*/discussion !sandobx`, maybe --<a href="../joey.html">Joey</a>
  1. Of course if you do that, you want to have form processing on the user page that lets them tune it, and probably choose literal or glob by default.

    I think that the new globlist() function should do everything you need. Adding a field to the prefs page will be trivial --Joey

    The first cut, I suppose, could use one sendmail process to batch-mail all subscribers for a given page. However, in the long run, I can see users demanding a bit of feature creep:

  2. Each user should be able to tune whether they see the actual diff parts or not.

  3. Each user should be able to set a maximum desired email size.
  4. We might want to support a user-specified shibboleth string that will be included in the email they receive so they can easily procmail the messages into a folder.

    --?BrandenRobinson

    I'm deferring these nicities until there's some demonstrated demand --Joey.

done

(posted Sun Jul 2 01:43:23 2006)

strftime

There should be a --strftime switch that controls how all the dates are formatted.

done

(posted Sun Jul 2 01:43:23 2006)

logo

ikiwiki needs a logo. I'm thinking something simple like the word "ikiwiki" with the first "k" backwards; drawn to show that it's "wiki" reflected.

done

(posted Sun Jul 2 01:43:23 2006)

upgradehooks

It's annoying to have to manually run --setup, especially for multiple blogs, on upgrade. Is the deb is used, there could be a postinst hook to do this.

Let there be an /etc/ikiwiki/wikis, which just lists setup files and the user who owns them. postinst loops through, su's, and runs --setup. Voila!

done

(posted Sun Jul 2 01:43:23 2006)