ikiwiki/ todo/ done

recently fixed TODO items

user-subdir mechanism like etc ikiwiki wikilist

Currently, ikiwiki has the configuration file /etc/ikiwiki/wikilist, which ikiwiki-mass-rebuild can use to rebuild all the ikiwikis on the system, such as when upgrading ikiwiki. This file includes usernames, and ikiwiki-mass-rebuild (which must run as root) changes to the specified user to rebuild their wiki. However, this means that adding new ikiwikis to the list must require administrator action, since editing the file would allow you to run ikiwiki as any user. What about a user-subdirectory mechanism for this? If each user could have their own /etc/ikiwiki/users/$user/wikilist, which only contained wikis (no users), ikiwiki-mass-rebuild could rebuild each wiki in this list as the corresponding user only. This would mean that an administrator need only create the directory and provide user or group write permission, and the user or group can then create wikis as needed.

Done, though somewhat differently. --Joey

Posted Tue Nov 28 05:16:36 2006
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 Mon Nov 20 11:14:48 2006
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. ?skip option for inline plugin --Ethan

done --Joey

Posted Wed Nov 8 20:36:59 2006
blogging

Here is the last of those items. Using the meta plugin you can give the appropriate info, and the enclosure will be added to the entry. It will also add a tag at the top, but I don't know if this is necessary. It also includes a fix for when make is used without PREFIX.

http://jameswestby.net/scratch/podcast.diff

-- JamesWestby

Hmm. Not quite how I'd envisioned podcasts would work, my idea was more that the sound files would be kept inside the wiki, and the inline plugin could be told to eg, inline *.mp3, and would add those to the rss feed as enclosures. Maybe you'd also inline some regular blog pages to describe the files or the like.

Do you think that would work or that it's worth pursuing that approach? I haven't looked at podcasts enough to know if that method would be technically feasable; for one thing it would limit the blog items for podcasts to just having an enclosure but no description.

Even if that doesn't work and pages are needed to desribe the items like you did, it still seems better to keep the podcast items in the wiki..

--Joey

That's fair enough. I'm a little unsure of how it all works, so I just did the simplest thing I could.

You don't need a description for podcasts it seems. So there's nothing stopping you there.

I have another patch that I think does what you want. It only supports .mp3 files, .ogg or similar could be added easily.

It has the disadvantage that the filename is all there is to go on, as I can't think of a way to associate any information with the mp3 file. I don't want to add a dependency on a IDv3 tag library. You could add another file .mp3.info with the title/description in.

It's obviously up to you which way you want to go.

http://jameswestby.net/scratch/podcast2.diff

-- JamesWestby

Hmm, this could be taken a step further, and assume that if IkiWiki::pagetype doesn't return a defined page type for the page in the blog, then no matter the extension it should be fed into the rss feed in an enclosure. This would allow for not only podcasting, but vidcasting and a form of photo blogging. Or even an rss feed containing the source of ikiwiki. ;-)

--Joey

Yes I agree that this would be great, but rss2 spec says that enclosure must have mime-type. How about I use the File::MimeInfo trick from the first patch to do this? I don't know why I didn't do this before. This will probably clean the code up a little as well.

What do you think of the change that when using raw, if the filetype is not known it adds an entry anyway? I did this so that the entries appear if this mode is used. It might be that this is not necessary, as can we assume that people wont use raw if they want to pod/vid/whatevercast?

-- JamesWestby

Using File::Mimeinfo makes sense to me.

I think it probably makes sense to make the (html) blog page add an entry with a link to the file that's in the enclosure in the rss feed. Whether or not raw is being used.

Note: I'm still unsure about whether podcasts should support descriptions for the enclosures or not. Here's an early podcast that did use descriptions: http://static.userland.com/gems/backend/gratefulDead.xml Here's a contemporary podcast, which also uses descriptions: http://www.lugradio.org/episodes.rss

The podcast client I use certianly doesn't care about the descriptions. But it's podracer, probably not the thing most podcast users use. :-)

--Joey

I tested with amarok, and that also ignored the description. I am thinking of those where you have a mixed feed, and people using clients that ignore enclsures get pretty much a blank post, with just the filename, and the html page, which also just displays the filename.

I don't think this is a big issue though, so I guess it's just which you think is the cleaner interface.

I have also added the first of your ideas as well (though you seem to have removed it). It adds a parameter to inline archive_after which limits showing full entries to that number.

http://jameswestby.net/scratch/limit.diff

-- JamesWestby

I removed it because I don't really see the need for it anymore. The added complexity doesn't seem worth it, unless someone needs the features. --Joey

And here is the updated podcast patch supporting any file type.

http://jameswestby.net/scratch/podcast2.diff

-- JamesWestby

And here is a patch for the remaining item. It adds links to the bottom of inlined entries for edit and discuss (if they are enabled). It doesn't add links for edit if the filetype is not known.

The stylesheet should probably be done slightly better than I have. I just added a bit of spacing as the links were too close to the date. I have no skill in this area though. Perhaps you would like to use the list system that you have for the links at the top.

http://jameswestby.net/scratch/actions.diff

-- JamesWestby

Thanks! I did tweak the css a bit. Not totally happy with it, but pretty good I think. (I'll try to get to the other patches soon.) --Joey


I'm very happy to report that this is done. Podcasting patch applied (finally!) --Joey

Posted Wed Nov 1 06:47:42 2006
aggregation

done

Posted Wed Nov 1 06:06:01 2006
firm up plugin interface

I don't want this interface to be too firm; it's ok for a plugin like ddate to redefine an internal function like IkiWiki::displaytime if it wants to.. But plugins that still access stuff through IkiWiki:: should be aware that that stuff can change at any time and break them. Possibly without perl's type checking catching the breakage, in some cases. Plugins that only use exported symbols should not be broken by future ikiwiki changes.

Functions used by only some plugins, undecided about exporting:

Variables used by plugins but not exported yet:

done

Posted Wed Nov 1 06:02:50 2006
link map

An idea: Use graphviz to generate a map of all the links between pages. (Could it be made clickable somehow?)

Graphviz can output image maps. -- ChristofferSawicki

done

Posted Thu Sep 7 04:03:47 2006
RSS links

The RSS feeds on a page should be indicated with <link rel>, so that they can be found by aggregators.

--tumov

I've been wondering about this. Ikiwiki's rss buttons include a type="application/rss+xml" and link to the rss file, and this is enough for at least some auto-discovery tools to find the rss feed. But apparently not all of them.

For example, firefox requires the following:

<link rel="alternate" type="application/rss+xml" title="RSS" href="index.rss" />

done

--Joey

Posted Wed Sep 6 20:44:18 2006
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 Mon Aug 28 19:48:17 2006
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 Mon Aug 28 06:24:55 2006