ikiwiki/ todo

Welcome to ikiwiki's todo list. Link items to done when done.

spell check plug-in

A speel chek plug-in woold be fantaztik. Anyone working on this?


Knot adz fair ass eye no --Joey

Posted Sun 20 Apr 2008 12:29:11 CEST
multiple templates

Another useful feature might be to be able to choose a different template file for some pages; blog pages would use a template different from the home page, even if both are managed in the same repository, etc.

Well, that would probably be fairly easy to add if it used pagespecs to specify which pages use the non-default template.

Hmm, I think the pagetemplate hook should allow one to get close enough to this in a plugin now.

Posted Sun 20 Apr 2008 12:29:11 CEST
spam fighting

Admins need the ability to block IP ranges. They can already ban users.

Posted Sun 20 Apr 2008 12:29:11 CEST
sigs

Need a way to sign name in page that's easier to type than "--Joey" and that includes the date.

What syntax do other wikis use for this? I'm considering "?--" (with spaces removed) as it has a nice nmemonic.

OTOH, adding additional syntax for this would be counter to one of the design goals for ikiwiki: keeping as much markup as possible out of the wiki and not adding nonstandard markup. And it's not significantly hard to type "--Joey", and as to the date, we do have page history.

I'm also unsure how to possibly implement this. Seems ikiwiki would need to expand the rune to the user's name when a page is saved, but that leaves out svn commits.


Alternate idea: Make a sig plugin, which would expand --Name to --?Name (the "user/" bit would be configurable). This would be very easy to do, although it would need to try to avoid false positives, such as --foo in C code..

Posted Sun 20 Apr 2008 12:29:11 CEST
automatic use of syntax plugin on source code files

Wishlist: optionally use the syntax plugin automatically on source code files in the repository with recognized extensions or shebangs, and render them as though they consisted of an .mdwn page containing nothing but a single call to the syntax plugin with the file contents as the text argument and the recognized type as the type argument.

Together with the ability to have wiki-formatted comments, this would allow the use of ikiwiki for literate programming.

Posted Sun 20 Apr 2008 12:29:11 CEST
tla Posted Sun 20 Apr 2008 12:29:11 CEST
wiki-formatted comments with syntax plugin

Wishlist item: I'd love to see the ability to optionally switch back to wiki syntax within the comments of code pretty-printed with the syntax plugin. This would allow the use of links and formatting in comments.

Posted Sun 20 Apr 2008 12:29:11 CEST
html

Create some nice(r) stylesheets.

Should be doable w/o touching a single line of code, just editing the templates and/or editing style.css.

Posted Sun 20 Apr 2008 12:29:11 CEST
plugin

Suggestions of ideas for plugins:

All the kinds of plugins that blogging software has is also a possibility:

Posted Sun 20 Apr 2008 12:29:11 CEST
mercurial Posted Sun 20 Apr 2008 12:29:11 CEST
onlinepageediting

(I left this comment in discussion, but it might be better here on the main page) This is a function I would really like. I am dealing with a situation, in creating a link for my family history, for instance to "Peter Richard MacLea (1888-c.1946)" and fleshing out an article with pictures and so on. Then, I later find out that Peter died in 1948. So, I want to move that page to "Peter Richard MacLea (1888-1948)". There doesn't seem to be an easy way to do this. The main problem being that I can easily create a second page with that data, but what happens to the old one? Does it remain? I would like to see at least a rename or page move function.... Kyle=

Posted Sun 20 Apr 2008 12:29:11 CEST
recentchanges Posted Sun 20 Apr 2008 12:29:11 CEST
Moving Pages

I thought I'd draw attention to a desire of mine for ikiwiki. I'm no power-user, and mostly I do fairly simple stuff with my wiki.

However, I would like the ability (now) to rename/move/delete pages. As part of having a genealogy wiki, I've put name and dates of birth/death as part of the title of each article (so to avoid cases where people have the same name, but are children/cousins/etc of others with that name). However, some of this information changes. For instance, I didn't know a date of death and now I do, or I had it wrong originally, or it turns out someone is still alive I didn't know about. All of these cases leave me with bad article titles.

So, I can go ahead and move the file to a new page with the correct info, orphan that page, provide a link for the new page if desired, and otherwise ignore that page. But then, it clutters up the wiki and serves no useful purpose.

Anyway to consider implementing rename/move/delete ? I certainly lack the skills to appreciate what this would entail, but feel free to comment if it appears impossible, and then I'll go back to the aforementioned workaround. I would prefer simple rename, however.

Thanks again to Joey for putting ikiwiki together. I love the program.

Kyle=


The MediaWiki moving/renaming mechanism is pretty nice. It's easy to get a list of pages that point to the current page. When renaming a page it sticks a forwarding page in the original place. The larger the size of the wiki the more important organization tools become.

I see the need for:

Brad

Posted Sun 20 Apr 2008 12:29:11 CEST
tags

Stuff still needing to be done with tags:

Posted Sun 20 Apr 2008 12:29:11 CEST
Option to make title an h1?

Currently, the page title (either the name of the page or the title specified with [[meta title="..."]]) shows up in a <div class="header">. I tend to follow the w3c guideline recommending the use of h1 for the title; for this purpose, how about an option to make the page title an <h1 class="header">, and shift the markdown headings down by one (making # an h2, ## an h3, etc; or alternatively making # equivalent to [[meta title="..."]])?

Posted Sun 20 Apr 2008 12:29:11 CEST
plugin dependency calulation

A few plugins need more complex dependency calculations than ikiwiki can do on its own:

These suggest there should be a way for plugins to have hooks that tweak the list of pages to rebuild.

Which in turn suggests that there should be a list of pages to rebuild; currently there's not, and the best such an interface could do would be to rebuild the pages even if they were already going to be rebuilt for some other reason. (See optimisations.)

It also suggests that plugins will want to examine pages and/or store data about them to use in the dependency calculations. For example, the version plugin would need to store info about what pages use it.

Posted Sun 20 Apr 2008 12:29:11 CEST
plugin data storage

ikiwiki currently stores some key data in .ikiwiki/index. Some plugins need a way to store additional data, and ideally it would be something managed by ikiwiki instead of ad-hoc because:

The aggregate plugin is a use-case: of 324 lines, 70 are data storage and another 10 handle deletion. Also, it's able to use a format very like ikiwiki's, but it does need to store some lists in there, which complicates it some and means that a very naive translation between a big per-page hash and the .index won't be good enough.

The current ikiwiki index format is not very flexible, although it is at least fairly easy and inexpensive to parse as well as hand-edit.

Would this do: ?

Hmm, that's potentially a lot of function calls per page eave load/save though.. For less function calls, only call each hook once per load/save, and it is passed/returns a big hash of pages and the values for each page. (Which probably means %state=@_ for load and return %state for save.)

It may also be better to just punt on lists, and require plugins that need even lists to encode them. Especially since in many cases, join(" ", @list) will do. Er hmm, if I do that though, I'm actually back to a big global %page_data that plugins can just toss data into, arn't I? So maybe that's %the right approach after all, hmm.. Except that needing to decode/encode list data all the time when using it would quite suck, so no, let's not do that.

Note that for the aggregate plugin to use this, it will need some changes:

If I do this, I might as well also:

Posted Sun 20 Apr 2008 12:29:11 CEST
optimisations

Ikiwiki has already been optimised a lot, however..

Posted Sun 20 Apr 2008 12:29:11 CEST
toplevel index

Some inconsistences around the toplevel index page:


I would like to suggest another tack, namely a bigger, better special case. The basic idea is that all indices of the form foo/bar/index get the wiki path foo/bar. This makes some things more elegant:

  • All files having to do with foo/bar are in the foo/bar directory, rather than the (admittedly minor) wart of having the index be in foo/.
  • This sort of addresses broken parentlinks in that example/ is guaranteed to be a valid path. (There might be no index there, though.)
  • This is more in line with standard HTML practice, as far as I understand it, namely that linking to a/b means a/b/index.html rather than a/b.html.

This would change the inline plugin in strange ways -- I think if foo/index.html contains [[inline "* and !*/Discussion"]], it should skip inlining foo/index.html explicitly, but would inline index pages in child directories foo/bar/baz/index.html as bar/baz.

It always bothers me that foo/bar/ files need a foo/bar.html in front of them, rather than a foo/bar/index.html, as is (to my mind) traditional.

Ethan

Hmm, now I've had time to think about this, and this does conflict pretty hard with foo.html/Discussion pages. Well, back to the drawing board.

Well, it seems unlikely that you'll have both foo/bar.html and foo/bar/index.html, so why not accept either as foo/bar? This would both preserve backwards compatibility, as well as allow foo/bar/Discussion.

Ethan

No, in order for this to work, the wiki path foo/bar/baz could be any of:

  • foo/bar/baz.html
  • foo/index/bar/index/baz.html
  • foo/bar/index/baz.html
  • foo/bar/index/baz/index.html

Or many others. Which is probably even hackier than having both foo.html and foo/.

Ethan

Posted Sun 20 Apr 2008 12:29:11 CEST
adding new pages by using the web interface

Perhaps I'm just too stupid to find the proper way to do this, but how would I add a new page to the wiki without selecting to edit an already installed one and frobbing the URL to direct to the to-be-created page? --?ThomasSchwinge

Good point. Of course one way is to start with creating a link to the page, which also helps prevent orphans. But other wikis based on CGI do have this a bit easier, since they can detect an attempt to access a nonexistant page and show an edit page. Ikiwiki can't do that (unless its web server is configured to do smart things on a 404, like maybe call ikiwiki.cgi which could be modified to work as a smart 404 -> edit handler).

Some wikis also provide a UI means for creating a new page. If we can find something good, that can be added to ikiwiki's UI. --Joey

Hmm, maybe just a preprocessor directive that creates a form inside a page, like is used for blog posting already would suffice? Then the main page of a wiki could have a form for adding new pages, if that directive were included there. Won't work for subpages though, unless the directive were added to the parent page. However, unconnected subpages are surely an even rarer thing to want than unconnected top level pages. --Joey

Here is a simple plugin that does that. Perhaps options could be added to it, but I couldn't really think of any. http://jameswestby.net/scratch/create.diff -- JamesWestby

Maybe a very simple PHP frontend for serving the statically generated pages, that would display a page editing form or something like that for non-existent pages, wouldn't be too bad a thing and resource hog? Just a thought... --?Tuomov

Posted Sun 20 Apr 2008 12:28:35 CEST
tagging with a publication date

Feature idea: I'd like to be able to tag pages in an ikiwiki blog with a publication date, and have the option of building a blog that excludes publication dates in the future. (meta pubdate= ?)

I'm using ikiwiki on git for a "tip of the day" RSS feed, and I'd like to be able to queue up a bunch of items instead of literally putting in one tip per day. In the future I think this will come in handy for other Mainstream Media-oriented requirements such as "embargo dates" and "editor on vacation".

The problem with implementing a feature like this is that, since ikwiiki is a wiki compiler, if something causes content to change based on the date, then the wiki needs to be rebuilt periodically. So you'd need a cron job or something.

Implemeting this feature probably needs plugin dependency calulation to be implemented. --Joey

Posted Sun 20 Apr 2008 12:28:35 CEST