ikiwiki/ todo/ done

recently fixed TODO items

rss title description

There could be a better way of setting the title and description of the rss feeds. Perhaps through the meta plugin, or extra options to the inline plugin.

At the moment The description is the same for all feeds from a single wiki it seems, and the title is forced to be one word, though I don't think it needs to be.

A few pointers and I might be able to implement this myself. -- JamesWestby

I don't see any problem with the title, it's the same as the title of the wiki page that the rss feed comes from, which can be set using the meta plugin. There are no restrictions to one word or anything like that. Just made ikiwiki emit the following in a test feed:

billy bob's news

Now, the description field currently defaults to the wiki name, and that could indeed stand to be made configurable. Since the current (svn) version of ikiwiki supports long, word-wrapped blocks of text as parameters to PreProcessorDirectives, seems to me the best way would be to simple modify inline.pm to make the descripion configurable by such parameter, with a fallback to the wiki name. You'll need to modify rsspage.tmpl to use whatever new template variable you define, that should be all.

--Joey

Apologies for the title thing. I tried it yesterday, and it onlt used the first word. I must have done something wrong. I'll have a look at implementing the description. Thanks. -- JamesWestby

My patch can be found at http://jameswestby.net/scratch/blog-desc.diff -- JamesWestby

Thanks, done --Joey

Posted Sun Aug 30 21:49:15 2009
fileupload

(I've written a proposal for this feature --Ben).

Support for uploading files is useful for many circumstances:

ikiwiki should have an easy to use interface for this, but the real meat of the work is in securing it. Several classes of controls seem appropriate:

It seems that for max flexability, rules should be configurable by the admin to combine these limits in different ways. If we again extend the pagespec for this, as was done for conditional text based on ikiwiki features, the rules might look something like this:

( maxsize(30kb) and type(webimage) ) or
( user(joey) and maxsize(1mb) and (type(webimage) or *.mp3) ) or
( user(joey) and maxsize(200mb) and (*.mov or *.avi) and videos/*)

With a small extension, this could even be used to limit the max sizes of normal wiki pages, which could be useful if someone was abusing an open wiki as a wikifs. Maybe.

( type(page) and maxsize(32k) )

And if that's done, it can also be used to lock users from editing a pages or the whole wiki:

!(( user(spammer) and * ) or
 ( user(42.12.*) and * ) or
 ( user(http://evilopenidserver/*) and * ) or
 ( user(annoying) and index) or
 ( immutable_page ))

That would obsolete the current simple admin prefs for banned users and locked pages. Suddenly all the access controls live in one place. Wonderbar!

(Note that pagespec_match will now return an object that stringifies to a message indicating why the pagespec matched, or failed to match, so if a pagespec lock like the above prevents an edit or upload from happening, ikiwiki could display a reasonable message to the user, indicating what they've done wrong.)

Posted Sun Aug 30 21:49:15 2009 Tags: done
git-rev-list requires relative path (fixes git ctime)
Index: IkiWiki/Rcs/git.pm
===================================================================
--- IkiWiki/Rcs/git.pm  (revision 4532)
+++ IkiWiki/Rcs/git.pm  (working copy)
@@ -275,6 +275,9 @@

    my $file = shift || q{--};

+   # Remove srcdir prefix to appease git-rev-list
+   $file =~ s/^$config{srcdir}\/?//;
+
    # Ignore error since a non-existing file might be given.
    my ($sha1) = run_or_non('git-rev-list', '--max-count=1', 'HEAD', $file);
    if ($sha1) {

I actually see a bug in this patch. :-) If srcdir = "foo" and the wiki contains a "foo/bar" and a "bar", this will make it, in the non-ctime case, get the sha1 of the wrong file, "bar", when "foo/bar" is asked for.

Better to strip the path out in getctime, I guess.

--Joey

Posted Sun Aug 30 21:49:15 2009 Tags: done
Add showdown GUI input/edit

Add an option to use the Showdown GUI for editing or adding content. It is BSD-licensed javascript that shows the rendered Markdown (or HTML) while editing.

A demo is at http://www.attacklab.net/showdown-gui.html

(I read about this on the markdown mailing list.)

Wikiwyg also can provide a nice GUI for editing, although it would need to be expanded to support markdown. The benefit compared to showdown is that it provides a GUI for editing with widets for italics, etc, compared to showdown which still leaves input in markdown and seems more geared to a fast preview of the html. --Joey

Since we have semi-working wikiwgy and it's better, I'm considering this todo item as done or rather, will-not-be-done..

Given the unfortunate state of affairs for the wikiwyg project, could it be worthwhile to consider this option again? It seems to have a companion product (wmd) with formatting widgets and a live preview pane, that is promised to be MIT licensed as of the next release.... --Chapman Flack

Posted Sun Aug 30 21:49:15 2009
pageindexes

Might be nice to support automatically generating an index based on headers in a page, for long pages. This could be done as a sanitize hook that parsed the html, with a preprocessordirective that controlled it.

done

Posted Sun Aug 30 21:49:15 2009
calendar -- archive browsing via a calendar frontend

I am serving notice that I am starting work on a calendar plugin inspired by Blosxom's calendar plugin. The current plan is to create a plugin that looks through all the source files matching a certain pagespec, and optionally spit out a month view for the specified month (default to current), or spit out a year view for a given year (defaulting to the current year), of a list of year with posts in them. The output would be a table, with the same CSS directives that the Blosxom plugin used to use (so that I can just reuse my css file). The links would be created to a $config{archivedir}/$year or $config{archivedir}/$year-$month file, which can just have

 [[inline pages="blog/* and !*/Discussion and creation_year($year) and creation_month($month)" rss="no" atom="no" show="0"]]

or some thing to generate a archive of postings.

Roland Mas suggested a separate cron job to generate these archive indices automatically, but that is another thread.

ManojSrivastava

This plugin is inspired by the calendar plugin for Blosxom, but derivesno code from it. This plugin is essentially a fancy front end to archives of previous pages, usually used for blogs. It can produce a calendar for a given month, or a list of months for a given year. To invoke the calendar, just use the preprocessor directive:

 [[calendar ]]

or

  [[calendar type="month" pages="blog/* and !*/Discussion"]]

or

   [[calendar type="year"  year="2005" pages="blog/* and !*/Discussion"]]

The year and month entities in the out put have links to archive index pages, which are supposed to exist already. The idea is to create an archives hierarchy, rooted in the subdirectory specified in the site-wide customization variable, archivebase. archivebase defaults to "archives". Links are created to pages "$archivebase/$year" and "$archivebase/$year/$month". The idea is to create annual and monthly indices, for example, by using something like this sample from my archives/2006/01.mdwn

      [[meta title="Archives for 2006/01"]]
      [[inline rootpage="blog" atom="no" rss="no" show="0" pages="blog/* and !*/Discussion and creation_year(2006) and creation_month(01)" ]]

I'll send in the patch via email.

ManojSrivastava


Since this is a little bit er, stalled, I'll post here the stuff Manoj mailed me, and my response to it. --Joey

I'm sending in an updated package, and have removed the older version you had here.--ManojSrivastava


've been looking over the calendar plugin. Some items:

I am scared of the html scrubber, and have never turned it on, and did not look too deeply into what would be scrubbed out --ManojSrivastava

Unless you're using javascript, a few annoyances link , or inline css, it's unlikly to object to any html you might write. The list of allowed tags and attributes is easy to find near the top of the plugin.

In case the option that gets the ctime of the pages from the SCM itself, %IkiWiki::pagectime is not populated that early, is it? So I waited until the last possible moment to look at the time information.

Actually, since my big rewrite of the rendering path a few months ago, ikiwiki scans and populates almost all page information before starting to render any page. This includes %pagectime, and even %links. So you shouldn't need to worry about running it late.

I use it on the sidebar; and the blog pages are almost always rebuilt, which is where the calendar is looked at most often. Oh, and I also cheat, I have ikiwiki --setup foo as a @daily cronjob, so my wiki is always built daily from scratch.

I think it should be mentioned, yes.

I need to look into this.

OK, this is simple enough to implement. I'll do that (well, perhaps not before Xmas, I have a family dinner to cook) and send in another patch.


And that's all I've heard so far. Hoping I didn't miss another patch?

--Joey

No, you did not. But I am back to hacking on this, and I think I have discovered a major problem with my approach. One of the problems with the current plugin is that the goal of a calendar is to create a calendar, either a month >or year based on, that provides links to blogs for all the days in (for the month calendar), and all the months (in a year calendar) in which there have been blog postings. For the monthly calendar, it needs to know the previous >and next months where there is a posting, and for the year calendar, it needs to know which of the previous (next) years had entries.

Now, this means that it needs to know about at all pages that meet the pagespec, and stash that information, before it begins generating the calandar in question, in order to calculate how to create the symlinks. And, of >course, all pages that have calendars on them might need to change anytime a page that meets the pagespec is added; and again at midnight, when the current day changes.

I think I have solved the ""Need to look at all pages that match the spec"" issue; but the nightly rebuild to handle the current day changing still remain. I use cron. It is now, however, richly documented :)

--ManojSrivastava

Finally reviewed and applied this. done! --Joey

Posted Sun Aug 30 21:49:15 2009 Tags:
quieten-bzr

The bzr plug echoes "added: somefile.mdwn" when it adds somefile.mdwn to the repository. As a result, the redirect performed after a new article is created fails because the bzr output comes before the HTTP headers.

The fix is simply to call bzr with the --quiet switch. Something like this applied to bzr.pm works for me:

46c46
<   my @cmdline = ("bzr", $config{srcdir}, "update");
---
>   my @cmdline = ("bzr", "update", "--quiet", $config{srcdir});
74c74
<   my @cmdline = ("bzr", "commit", "-m", $message, "--author", $user,
---
>   my @cmdline = ("bzr", "commit", "--quiet", "-m", $message, "--author", $user, 
86c86
<   my @cmdline = ("bzr", "add", "$config{srcdir}/$file");
---
>   my @cmdline = ("bzr", "add", "--quiet", "$config{srcdir}/$file");
94a95,97
>   eval q{use CGI 'escapeHTML'};
>   error($@) if $@;
> 

done, although I left off the escapeHTML thing which seems to be in your patch by accident.

(Please use diff -u BTW..) --Joey

Posted Sun Aug 30 21:49:15 2009 Tags:
Wrapper config with multiline regexp

Turning the wikilink regexp into an extended regexp on the svn trunk seems to have broken the setuid wrapper on my system, because of two reasons: First, the wrapper generator should turn each newline in $configstring into \n in the C code rather than \ followed by a newline in the C code. Second, the untainting of $configstring should allow newlines.

Both of these problems were already dealt with in commit r3714, on June 3rd. Confused why you're posting patches for them now. done --Joey

Modified: wiki-meta/perl/IkiWiki.pm
==============================================================================
--- wiki-meta/perl/IkiWiki.pm (original)
+++ wiki-meta/perl/IkiWiki.pm Mon Jun 11 10:52:07 2007
@@ -205,7 +205,7 @@

 sub possibly_foolish_untaint ($) { #{{{
  my $tainted=shift;
- my ($untainted)=$tainted=~/(.*)/;
+ my ($untainted)=$tainted=~/(.*)/s;
  return $untainted;
 } #}}}


Modified: wiki-meta/perl/IkiWiki/Wrapper.pm
==============================================================================
--- wiki-meta/perl/IkiWiki/Wrapper.pm (original)
+++ wiki-meta/perl/IkiWiki/Wrapper.pm Mon Jun 11 10:52:07 2007
@@ -62,7 +62,7 @@
  }
  $configstring=~s/\\/\\\\/g;
  $configstring=~s/"/\\"/g;
- $configstring=~s/\n/\\\n/g;
+ $configstring=~s/\n/\\n/g;

  #translators: The first parameter is a filename, and the second is
  #translators: a (probably not translated) error message.
Posted Sun Aug 30 21:49:15 2009
skip option for inline plugin

How about a skip option for inline? This would allow things like the following:

[[inline pages="news/*" show="5"]]
[[inline pages="news/*" skip="5" show="5" archive="yes"]]

I just wrote a patch. --Ethan

done --Joey

Posted Sun Aug 30 21:49:15 2009
shortcut link text

shortcut creates link shortcut PreprocessorDirectives, which substitute their argument into the specified shortcut URL to generate the link target, and use the argument as the link text. For example, given the example shortcuts, [[wikipedia ikiwiki]] generates a link to http://en.wikipedia.org/wiki/ikiwiki, with the link text "ikiwiki". This works well in many cases; however, for things like the debbug example, it simply uses the number as the link text, which does not always provide enough context to understand the link at first glance. For example, [[debbug 397501]] generates a link to http://bugs.debian.org/397501, with just "397501" as the link text. While template provides a general solution for arbitrary cases, it would help to have a simple option via the shortcut plugin to set the link text, with a %s substitution. Thus, something like [[shortcut name=debbug url="http://bugs.debian.org/%s" desc="bug #%s"]] might suffice on a Debian-specific wiki to indicate a bug number, while a more general wiki might use something like [[shortcut name=debbug url="http://bugs.debian.org/%s" desc="Debian bug #%s"]].

done --Joey

Posted Sun Aug 30 21:49:15 2009