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 Feb 10 23:46:47 2008
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 Feb 10 23:46:47 2008 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..

Posted Sun Feb 10 23:46:47 2008
preview changes

When editing a page, it would help to have a "preview changes" or "show diff" button, which brings up a diff from the current page content to the proposed new page content. --JoshTriplett

Some discussion from the main discussion page:

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?

It's doable, it could even be done by a plugin, I think. --Joey

See the editdiff plugin --JeremieKoenig

done

Posted Sun Feb 10 23:46:47 2008
aggregate locking

The aggregate plugin's locking is a suboptimal.

There should be no need to lock the wiki while aggregating -- it's annoying that long aggregate runs can block edits from happening. However, not locking would present problems. One is, if an aggregate run is happening, and the feed is removed, it could continue adding pages for that feed. Those pages would then become orphaned, and stick around, since the feed that had created them is gone, and thus there's no indication that they should be removed.

To fix that, garbage collect any pages that were created by aggregation once their feed is gone.

Are there other things that could happen while it's aggregating that it should check for?

Well, things like the feed url etc could change, and it would have to merge in such changes before saving the aggregation state. New feeds could also be added, feeds could be moved from one source page to another.

Merging that feed info seems doable, just re-load the aggregation state from disk, and set the message, lastupdate, numposts, and error fields to their new values if the feed still exists.


Another part of the mess is that it needs to avoid stacking multiple aggregate processes up if aggregation is very slow. Currently this is done by taking the lock in nonblocking mode, and not aggregating if it's locked. This has various problems, for example a page edit at the right time can prevent aggregation from happening.

Adding another lock just for aggregation could solve this. Check that lock (in checkconfig) and exit if another aggregator holds it.


The other part of the mess is that it currently does aggregation in checkconfig, locking the wiki for that, and loading state, and then dropping the lock, unloading state, and letting the render happen. Which reloads state. That state reloading is tricky to do just right.

A simple fix: Move the aggregation to the new 'render' hook. Then state would be loaded, and there would be no reason to worry about aggregating.

Or aggregation could be kept in checkconfig, like so:

done

Posted Sun Feb 10 23:46:47 2008
Option to disable date footer for inlines

inline, with the archive option, shows only page titles and post dates. I'd like an option to omit the post dates as well, leaving only the page titles. Such an option would streamline the users page, for instance. --JoshTriplett

Yes, indeed, something like "compact" mode would be useful. In fact, this would be better handled with a replacement of the "archive" on/off API with something like mode = normal|archive|compact|.... defaulting to normal --hb

You also don't need to be restricted to a fixed set of modes: the mode parameter could simply specify the template to be used: inlinepage-$mode.tmpl. For producing e.g. bulleted lists of the entries, some extra container template would be useful in addition to that...

In a related note, I'd like an option to include the creation date on some non-inlined pages too. I suppose that's doable with some template hook in a plugin, and a command-line parameter pagespec (suffices for me), but I haven't got around to that yet. --tuomov

Customised templates can now be specified with the templates parameter, so done --Joey

That definitely solves this problem in general; thanks!

For this specific case, I'd still like to see a titleonly.tmpl template included by default. How about this simple template, based on archivepage.tmpl?

<p><a href="<TMPL_VAR PAGEURL>"><TMPL_VAR TITLE></a></p>

--JoshTriplett

done

Posted Sun Feb 10 23:46:47 2008
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 Feb 10 23:46:47 2008 Tags:
userdir links

The userdir should be searched at the end of the search "path" for links, so that users can put their pages in the userdir, and still link to them easily when signing things, without giving a path.

done

Posted Sun Feb 10 23:46:47 2008
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 Feb 10 23:46:47 2008
syslog should show wiki name

We run many ikiwikis on wiki.cs.pdx.edu, and we occasionally get messages like this in the syslog user.log file:

Apr 26 07:31:41 svcs ikiwiki: bad page name 
Apr 26 07:43:26 svcs ikiwiki: bad page name

Those don't give us any information about which ikiwiki they came from. ikiwiki needs to provide the wiki name in syslog messages. --JoshTriplett

done

Posted Sun Feb 10 23:46:47 2008