* Make sure you have the tag plugin enabled, and tag posts using it. An
example of how to tag a post is:
- \[[tag tags/life]]
+ \[[!tag tags/life]]
* Enable the sidebar plugin to get a sidebar listing all the categories
you've tagged posts with.
> Jamey Sharp and I have a set of scripts in progress to convert other wikis to ikiwiki, including history, so that we can migrate a few of our wikis. We already have support for migrating MoinMoin wikis to ikiwiki, including conversion of the entire history to Git. We used this to convert the [XCB wiki](http://xcb.freedesktop.org/wiki/) to ikiwiki; until we finalize the conversion and put the new wiki in place of the old one, you can browse the converted result at <http://xcb.freedesktop.org/ikiwiki>. We already plan to add support for TWiki (including history, since you can just run parsecvs on the TWiki RCS files to get Git), so that we can convert the [Portland State Aerospace Society wiki](http://psas.pdx.edu) (currently in Moin, but with much of its history in TWiki, and with many of its pages still in TWiki format using Jamey's TWiki format for MoinMoin).
>
-> Our scripts convert by way of HTML, using portions of the source wiki's code to render as HTML (with some additional code to do things like translate MoinMoin's `\[[TableOfContents]]` to ikiwiki's `\[[toc ]]`), and then using a modified [[!cpan HTML::WikiConverter]] to turn this into markdown and ikiwiki. This produces quite satisfactory results, apart from things that don't have any markdown equivalent and thus remain HTML, such as tables and definition lists. Conversion of the history occurs by first using another script we wrote to translate MoinMoin history to Git, then using our git-map script to map a transformation over the Git history.
+> Our scripts convert by way of HTML, using portions of the source wiki's code to render as HTML (with some additional code to do things like translate MoinMoin's `\[[TableOfContents]]` to ikiwiki's `\[[!toc ]]`), and then using a modified [[!cpan HTML::WikiConverter]] to turn this into markdown and ikiwiki. This produces quite satisfactory results, apart from things that don't have any markdown equivalent and thus remain HTML, such as tables and definition lists. Conversion of the history occurs by first using another script we wrote to translate MoinMoin history to Git, then using our git-map script to map a transformation over the Git history.
>
> We will post the scripts as soon as we have them complete enough to convert our wikis.
>
Generally you will tag a page without putting a visible link on it.
The [[tag_plugin|plugins/tag]] allows you to do so, like this:
- \[[tag mytag othertag thirdtag]]
+ \[[!tag mytag othertag thirdtag]]
You can also tag a page with a visible link:
- \[[taglink mytag]]
+ \[[!taglink mytag]]
This tag will be displayed just like a regular [[ikiwiki/WikiLink]].
In another blog, I could tag a post with arbitrary words and not have to do
anything else for the software to recognize it as a tag. In Ikiwiki if you
-want to tag something \[[tag foo]] you also have to go to tags/ and create
+want to tag something \[[!tag foo]] you also have to go to tags/ and create
foo.mkdn (even if it's zero-length), because "tags are links", and links
don't actually *link* if they have no destination. This allows for
customization of how you present different tag feeds, but this (to me) is
their lifecycle. A developer can take ownership of a
bug by tagging it with something like "owner/Joey".
-To tag a wiki page, edit it and add text such as "\[[tag done]]". Note that
+To tag a wiki page, edit it and add text such as "\[[!tag done]]". Note that
adding a wiki link to "\[[done]]" will have the same categorisation effect
as a tag, but the link will show up in the body of the page, which is a
nice effect if used in a sentence such as "This was \[[done]] in version
* A typical list of all open bugs, with their full text, and a form to post new
bugs.
- \[[inline pages="bugs/* and !link(done) and !*/Discussion" actions=yes postform=yes show=0]]
+ \[[!inline pages="bugs/* and !link(done) and !*/Discussion" actions=yes postform=yes show=0]]
* Index of the 30 most recently fixed bugs.
- \[[inline pages="bugs/* and link(done) and !*/Discussion" sort=mtime show=30 archive=yes]]
+ \[[!inline pages="bugs/* and link(done) and !*/Discussion" sort=mtime show=30 archive=yes]]
* Index of the 10 most recently active bugs.
- \[[inline pages="bugs/* and !link(done) and !*/Discussion" sort=mtime show=10]]
+ \[[!inline pages="bugs/* and !link(done) and !*/Discussion" sort=mtime show=10]]
* Open security issues.
- \[[inline pages="bugs/* and link(security) and !link(done) and !*/Discussion"]]
+ \[[!inline pages="bugs/* and link(security) and !link(done) and !*/Discussion"]]
* Full text of bugs assigned to Joey.
- \[[inline pages="bugs/* and link(owner/Joey) and !link(done) and !*/Discussion" show=0]]
+ \[[!inline pages="bugs/* and link(owner/Joey) and !link(done) and !*/Discussion" show=0]]
It may seem strange to consider using a wiki for issue tracking when there
are several dedicated bug tracking systems, like Bugzilla, that handle all