. -- Brian May
+this adequately, see [[!debbug 466055]]. -- Brian May
+
+---
+
+I think [[!cpan Crypt::SSLeay]] already supports checking the certificate. The trick
+is to get [[!cpan LWP::UserAgent]], which is used by [[!cpan LWPx::ParanoidAgent]] to
+enable this checking.
+
+I think the trick is to set one of the the following environment variables before retrieving
+the data:
+
+$ENV{HTTPS\_CA\_DIR} = "/etc/ssl/certs/";
+$ENV{HTTPS\_CA\_FILE} = "/etc/ssl/certs/file.pem";
+
+Unfortunately I get weird results if the certificate verification fails, see [[!debbug 503440]].
+It still seems to work though, regardless.
+
+-- Brian May
diff --git a/doc/bugs/stray___60____47__p__62___tags.mdwn b/doc/bugs/stray___60____47__p__62___tags.mdwn
new file mode 100644
index 000000000..6e508ffda
--- /dev/null
+++ b/doc/bugs/stray___60____47__p__62___tags.mdwn
@@ -0,0 +1,15 @@
+When using the [[plugins/htmltidy]] plugin (and possibly in other circumstances), ikiwiki sometimes creates more `` tags than `` tags, causing unbalanced markup. I've previously noticed unbalanced tags when a `\[[!map]]` matches no pages. This is part of the reason I developed [[plugins/htmlbalance]].
+
+This is particularly noticeable if htmltidy is enabled when building the docwiki: on the 'contrib' plugin pages, the title becomes `foo
(third-party plugin)` (with the angle-brackets escaped - it seems the text gets sanitized but is then escaped anyway).
+
+I believe that this snippet in `IkiWiki.pm` might be the reason for the imbalance:
+
+ if ($oneline) {
+ # hack to get rid of enclosing junk added by markdown
+ # and other htmlizers
+ $content=~s/^//i;
+ $content=~s/<\/p>$//i;
+ chomp $content;
+ }
+
+The fact that HTML in a `\[[!meta title]]` is added but then escaped might indicate that some other bug is involved.
diff --git a/doc/bugs/support_for_openid2_logins.mdwn b/doc/bugs/support_for_openid2_logins.mdwn
new file mode 100644
index 000000000..f78d50c3c
--- /dev/null
+++ b/doc/bugs/support_for_openid2_logins.mdwn
@@ -0,0 +1,10 @@
+I have several complaints that users cannot contribute to my ikiwiki instances since they only have OpenID logins that support OpenID2. E.g. Yahoo!'s OpenID only supports 2.0+
+
+This is not the fault of ikiwiki, though the problem lies within the [perl openid consumer](http://packages.qa.debian.org/libn/libnet-openid-consumer-perl.html) in Debian which is a 1.x implementation AFAIK.
+
+I've contacted JanRain who have pointed me to:
+
+* [OpenID4Perl](http://code.sxip.com/openid4perl/)
+* Some [work](http://code.sixapart.com/svn/openid/trunk/perl/) by David Recordon
+
+However both Perl OpenID 2.x implementations have not been released and are incomplete implementations. :(
diff --git a/doc/bugs/table_external_file_links.mdwn b/doc/bugs/table_external_file_links.mdwn
new file mode 100644
index 000000000..7b35383c5
--- /dev/null
+++ b/doc/bugs/table_external_file_links.mdwn
@@ -0,0 +1,9 @@
+If wikilinks are put in an external table file, those links are not seen at
+scan time, and so ikiwiki does not know to update the page containing the
+table when the pages the links point to change (are added, removed, etc).
+
+There seem only two solutions to that bug -- either really make wikilinks
+in an external table file not work (probably by escaping them),
+or run the preprocess code also in scan (expensive!). --[[Joey]]
+
+[[done]]
diff --git a/doc/bugs/tags__44___backlinks_and_3.x.mdwn b/doc/bugs/tags__44___backlinks_and_3.x.mdwn
new file mode 100644
index 000000000..4fe9a4723
--- /dev/null
+++ b/doc/bugs/tags__44___backlinks_and_3.x.mdwn
@@ -0,0 +1,34 @@
+I think there might be an issue in the backlinks calculation in ikiwiki 3.04.
+
+I've just migrated to 3.04. In doing so, the following pagespec
+
+> "log/* and !link(tag/aggregation) and !link(tag/draft) and !*/Discussion"
+
+...started matching pages which contained
+
+> \[\[!template draft\]\]
+
+The page templates/draft.mdwn contains (amongst some markup)
+
+> \[\[!tag draft \]\]
+
+Prior to migration, the pagespec definitely took effect post-transclusion.
+
+An example: contains the
+template inclusion, which can be seen to have worked due to markup at the
+bottom of the page. It even includes a "Tags: draft" link at the bottom.
+
+Strangely, does not contain backlinks to pages
+which are tagged using the procedure above.
+
+After the first rebuild, it's broken, after a subsequent refresh, it is fixed.
+I've reproduced this twice (but assumed I'd done something wrong the first
+time, so went ahead and migrated live, spamming planet debian in the process
+:(). I will try and put together a testcase. -- [[users/Jon]], 2009/02/17
+
+> Looks like the same problem as
+> [[cannot_reliably_use_meta_in_template]]. AFAIK, this has never worked
+> reliably, although the linked page has a simple, though potentially
+> expensive fix. --[[Joey]]
+
+> fix made, [[done]] --[[Joey]]
diff --git a/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn b/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn
index ac895896a..db3917d21 100644
--- a/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn
+++ b/doc/bugs/tbasewiki__95__brokenlinks.t_broken.mdwn
@@ -25,12 +25,12 @@ After some digging I found that HTML::Template is being required after the new s
filter => sub {
my $text_ref = shift;
@@ -857,6 +856,7 @@
- } #}}}
+ }
- sub template ($;@) { #{{{
+ sub template ($;@) {
+ require HTML::Template;
HTML::Template->new(template_params(@_));
- } #}}}
+ }
**That** gave me:
diff --git a/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn b/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn
index 7ec1edc4e..bdd07210e 100644
--- a/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn
+++ b/doc/bugs/textile_plugin_dies_if_input_has_a_non-utf8_character.mdwn
@@ -9,6 +9,6 @@ The first two complaints happen if textile is not loaded, the third fatal one ha
0x92 is "single quote" in the evil windows default codepage. It would be nice to handle this gracefully and not abort ikiwiki at this point, or alternatively, die fatally but mention which input page caused the error.
-Interestingly enough, in my case, the input file has several other bad windows characters (0xFC, u-umlaut) which have not caused ikiwiki to abort. ikiwiki version 2.50. -- [[JonDowland]]
+Interestingly enough, in my case, the input file has several other bad windows characters (0xFC, u-umlaut) which have not caused ikiwiki to abort. ikiwiki version 2.50. -- [[users/Jon]]
> Fixed in git. [[done]] --[[Joey]]
diff --git a/doc/bugs/txt_plugin_having_problems_with_meta_directives.mdwn b/doc/bugs/txt_plugin_having_problems_with_meta_directives.mdwn
new file mode 100644
index 000000000..22224483e
--- /dev/null
+++ b/doc/bugs/txt_plugin_having_problems_with_meta_directives.mdwn
@@ -0,0 +1,19 @@
+When applying my usual copyright and licensing header to a [[plugins/txt]]
+page, garbled output is created.
+
+Here is the header:
+
+ \[[meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2008 Free
+ Software Foundation, Inc."]]
+
+ \[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable
+ id="license" text="Permission is granted to copy, distribute and/or modify
+ this document under the terms of the GNU Free Documentation License,
+ Version 1.2 or any later version published by the Free Software Foundation;
+ with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
+ A copy of the license is included in the section entitled
+ [[GNU_Free_Documentation_License|/fdl]]."]]"""]]
+
+--[[tschwinge]]
+
+> [[done]], made it less zealous about encoding html entities. --[[Joey]]
diff --git a/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
new file mode 100644
index 000000000..472597c46
--- /dev/null
+++ b/doc/bugs/unicode_chars_in_wikiname_break_auth.mdwn
@@ -0,0 +1,20 @@
+I spent hours trying to understand why my wiki suddenly refused me to log in (using passwordauth).
+The failure message was always: `login failed, perhaps you need to turn on cookies?`
+
+Inspecting the cookie information (thanks to Iceweasel's webdeveloper add-on), I realized there were some weird-looking encoded chars in the cookie name.
+
+Replacing "·" with "-" in `wikiname` fixed this login issue.
+
+> Hmm, Recai sent me a patch a long time ago to handle utf-8 here by encoding
+> the wikiname. But it doesn't seem to work, somehow the encoded utf-8
+> value still doesn't make it through. (CGI::Session seems to have underermined utf-8
+> issues too.) Seems like I will have to possibly break some sessions and
+> entity-encode the wikiname in the cookie.. [[done]]. --[[Joey]]
+
+>> I confirm it fixes the bug for me. --[[intrigeri]]
+
+(BTW, such a char was replaced by -I don't remember what encoding thingie- in my setup file, when running `ikiwiki-transition setupformat`.)
+
+> Thanks for the heads up, fixed that too. --[[Joey]]
+
+>> I confirm it fixes the bug for me. --[[intrigeri]]
diff --git a/doc/bugs/user_links_on_recentchanges_pages_problem.mdwn b/doc/bugs/user_links_on_recentchanges_pages_problem.mdwn
new file mode 100644
index 000000000..d00f6815b
--- /dev/null
+++ b/doc/bugs/user_links_on_recentchanges_pages_problem.mdwn
@@ -0,0 +1,12 @@
+When I click on a linked username for commits on the recentchanges page (on
+the live ikiwiki.info) I get a link such as
+
+which returns something like
+
+ ikiwiki/ Error
+ Error: unknown do parameter
+
+-- [[Jon]]
+
+> That was fixed in 3.04 but ikiwiki.info had not been upgraded to it yet.
+> [[done]] --[[Joey]]
diff --git a/doc/contact.mdwn b/doc/contact.mdwn
index 37fb59071..486a4d186 100644
--- a/doc/contact.mdwn
+++ b/doc/contact.mdwn
@@ -7,4 +7,5 @@ developers monitor [[RecentChanges]] closely, via the webpage, email,
[CIA](http://cia.navi.cx), and IRC, and respond in a timely fashion.
You could also drop by the IRC channel `#ikiwiki` on
-[OFTC](http://www.oftc.net/) (`irc.oftc.net`).
+[OFTC](http://www.oftc.net/) (`irc.oftc.net`), or use the
+[identi.ca ikiwiki group](http://identi.ca/group/ikiwiki).
diff --git a/doc/convert.mdwn b/doc/convert.mdwn
new file mode 100644
index 000000000..871cd31fe
--- /dev/null
+++ b/doc/convert.mdwn
@@ -0,0 +1,7 @@
+Do you have an existing wiki or blog using other software, and would like
+to convert it to ikiwiki? Various tools and techniques have been developed
+to handle such conversions.
+
+* [[tips/convert_mediawiki_to_ikiwiki]]
+* [[tips/convert_MoinMoin_and_TWiki_to_ikiwiki]]
+* [[tips/convert_blogger_blogs_to_ikiwiki]]
diff --git a/doc/css_market.mdwn b/doc/css_market.mdwn
index 26720196f..15e147513 100644
--- a/doc/css_market.mdwn
+++ b/doc/css_market.mdwn
@@ -1,12 +1,15 @@
[[!meta title="CSS Market"]]
-User contributed stylesheet files for ikiwiki. Feel free to add your own
-stylesheets here. (Upload as wiki pages; wiki gnomes will convert them to css
-files..)
+User contributed stylesheet files for ikiwiki. Unless otherwise noted,
+these style sheets can be installed by copying them into your wiki's source
+dir with a filename of `local.css`.
+
+Feel free to add your own stylesheets here. (Upload as wiki pages; wiki
+gnomes will convert them to css files..)
* **[[css_market/zack.css]]**, contributed by [[StefanoZacchiroli]],
customized mostly for *blogging purposes*, can be seen in action on
- [zack's blog](http://www.bononia.it/~zack/blog/)
+ [zack's blog](http://upsilon.cc/~zack/blog/)
[[!meta stylesheet="zack"]]
* **[[css_market/kirkambar.css]]**, contributed by [[Roktas]]. This far from perfect
@@ -51,6 +54,10 @@ files..)
* **[contraste.css][4]**, contributed by [[Blanko]]. Can be seen on [Contraste Demo][5]. Local.css and templates available [here][6].
+* **[[css_market/actiontabs.css]]**, contributed by [[svend]]. This style sheet displays
+ the action list (Edit, RecentChanges, etc.) as tabs.
+ [[!meta stylesheet="actiontabs"]]
+
If your web browser allows selecting between multiple stylesheets, this
page can be viewed using many of the stylesheets above. For example, if
using Epiphany with the Select Stylesheet extension enabled, use View ->
diff --git a/doc/css_market/actiontabs.css b/doc/css_market/actiontabs.css
new file mode 100644
index 000000000..a1dc47e92
--- /dev/null
+++ b/doc/css_market/actiontabs.css
@@ -0,0 +1,122 @@
+/* ikiwiki local style sheet */
+
+/* Add local styling here, instead of modifying style.css. */
+
+a {
+ text-decoration: none;
+ color: #005a9c;
+}
+
+a:hover {
+ text-decoration: underline;
+}
+
+
+hr {
+ border-style: none;
+ background-color: #999;
+ height: 1px;
+}
+
+code, pre {
+ background: #eee;
+}
+
+pre {
+ padding: .5em;
+}
+
+body {
+ margin: 0;
+ padding: 0;
+ font-family: sans-serif;
+ color: black;
+ background: white;
+}
+
+.pageheader {
+ margin: 0;
+ padding: 1em 2em 0 2em;
+ background: #eee;
+ border-color: #999;
+ border-style: none none solid none;
+ border-width: 1px;
+}
+
+.header {
+ font-size: 100%;
+ font-weight: normal;
+}
+
+.title {
+ display: block;
+ margin-top: .2em;
+ font: 140% sans-serif;
+ text-transform: capitalize;
+}
+
+.actions {
+ text-align: right;
+ padding: 0;
+}
+
+#content, #comments, #footer {
+ margin: 1em 2em;
+}
+
+#pageinfo {
+ border-color: #999;
+}
+
+.inlinepage {
+ margin: .4em 0;
+ padding: .4em 0;
+ border-style: none;
+ border-top: 1px solid #aaa;
+}
+
+.inlineheader {
+ font-size: 120%;
+ font-weight: normal;
+}
+
+h1 { font: 120% sans-serif }
+h2 { font: bold 100% sans-serif }
+h3 { font: italic 100% sans-serif }
+h4, h5, h6 { font: small-caps 100% sans-serif }
+
+/* Smaller headings for inline pages */
+.inlinepage h1 { font-size: 110% }
+.inlinepage h2 { font-size: 100% }
+.inlinepage h3 { font-size: 100% }
+
+.pageheader .actions ul {
+ border-style: none
+}
+
+.actions ul {
+ font-size: 75%;
+ padding: 0;
+ border-style: none;
+}
+
+.actions ul li a {
+ text-decoration: none;
+}
+
+.actions ul li {
+ margin: 0;
+ padding: .1em .5em 0 .5em;
+ background: white;
+ border-color: #999;
+ border-style: solid solid none solid;
+ border-width: 1px;
+}
+
+div.recentchanges {
+ border-style: none;
+}
+
+.pagecloud {
+ width: auto;
+}
diff --git a/doc/css_market/discussion.mdwn b/doc/css_market/discussion.mdwn
index cba13132e..f80053e38 100644
--- a/doc/css_market/discussion.mdwn
+++ b/doc/css_market/discussion.mdwn
@@ -5,3 +5,12 @@ What is the correct way to install the .tmpl files? -- [[JosephTurian]]
> ikiwiki's standard templates (in, eg `/usr/share/ikiwiki/templates`)
> --[[Joey]]
+----
+
+How can I update a .css file uploaded to the CSS market?
+My CSS has been updated to address comments (for the comments plugin), but I cannot find a way to update zack.css.
+The most recent version is always available at:
+
+-- [[StefanoZacchiroli]]
+
+> Just letting me know about the change works -- updated. --[[Joey]]
diff --git a/doc/css_market/zack.css b/doc/css_market/zack.css
index dbc2e5c44..5a0521d54 100644
--- a/doc/css_market/zack.css
+++ b/doc/css_market/zack.css
@@ -14,122 +14,180 @@
*/
body {
- font-family: sans;
- width: 760px;
- margin-left: 20px;
+ font-family: sans-serif;
+ font-size: medium;
}
+h1, h2, h3, h4 {
+ font-weight: normal;
+}
+h1 { font-size: 140%; }
+h2 { font-size: 120%; }
+h3 { font-size: 110%; }
+h4 { font-size: 105% }
-div#content {
- font-size: 11pt;
-}
+a { text-decoration: none; }
+a:hover { text-decoration: underline; }
-.header span {
- font-size: 14pt;
- font-weight: normal;
-}
-
-div.actions ul {
- font-size: 10pt;
-}
-
-h1 {
- font-weight: normal;
- font-size: 17pt;
-}
-h2 {
- font-weight: normal;
- font-size: 16pt;
-}
-h3 {
- font-weight: normal;
- font-size: 15pt;
-}
-h4 {
- font-weight: normal;
- font-size: 14pt;
-}
-h5 {
- font-weight: normal;
- font-size: 13pt;
-}
-h6 {
- font-weight: normal;
- font-size: 12pt;
-}
-
-div.inlinepage > span.header > a {
+.flow {
float: right;
- display: block;
- font-size: 11pt;
- font-weight: normal;
- margin: 0;
- padding: 0;
+ margin-left: 10px;
+ margin-bottom: 10px;
+ text-align: center;
}
-div.inlinepage > span.header > a:before {
- content: "permalink: ";
- font-size: smaller;
- text-decoration: none;
+
+.attrib-caption {
+ font-size: xx-small;
font-style: italic;
}
-div.inlinepage {
+input {
+ border: solid 1px;
+ border-color: #aaa;
+}
+
+.header { font-weight: normal; }
+
+.selflink { text-decoration: underline; }
+
+.pageheader .actions ul,
+#sitemeta {
+ border-top: solid 1px;
+ border-bottom: solid 1px;
+ font-size: small;
+ border-color: #aaa;
+ background: #eee;
+}
+.actions ul {
+ padding: 1px;
+ margin-top: 5px;
+}
+#sitemeta {
+ padding: 0;
+ margin-bottom: 5px;
+}
+#backlinks,
+.tags {
+ margin-top: 0;
+ margin-bottom: 0;
+}
+
+#pageinfo {
+ border: none;
+}
+
+#searchform div:before {
+ font-size: small;
+ content: "search:";
+}
+#searchform input {
+ border-top: none;
+ border-bottom: none;
+ vertical-align: bottom;
+ margin-right: 7px;
+}
+
+#sidebar {
+ border: solid;
+ border-width: 1px;
+ padding: 0;
+ margin-top: 15px;
+ border: 1px solid;
+ border-color: #aaa;
+ background: #eee;
+ width: 16ex;
+}
+#sidebar ul {
+ margin: 0;
+ padding-left: 1em;
+ list-style-type: none;
+}
+#sidebar ul ul {
+ padding-left: 1.5em;
+ font-size: 90%;
+}
+
+#pageinfo,
+#footer {
+ margin: 0;
+}
+#pageinfo {
+ font-size: small;
+}
+.pagecopyright,
+.pagelicense,
+.pagedate {
+ margin: 0;
+ display: inline;
+}
+#backlinks {
+ margin-top: 5px;
margin-bottom: 10px;
+ font-size: larger;
}
-
-div.inlinepage h1 {
- font-weight: normal;
- font-size: 14pt;
- margin: 0;
-}
-div.inlinepage h2 {
- font-weight: normal;
- font-size: 13pt;
- margin: 0;
-}
-div.inlinepage h3 {
- font-weight: normal;
- font-size: 12pt;
- margin: 0;
-}
-div.inlinepage h4 {
- font-weight: normal;
- font-size: 11pt;
- margin: 0;
-}
-div.inlinepage h5 {
- font-weight: normal;
- font-size: 11pt;
- margin: 0;
-}
-div.inlinepage h6 {
- font-weight: normal;
- font-size: 11pt;
- margin: 0;
-}
-
-div#blogform {
- padding: 0px 5px;
- margin-bottom: 10px;
-}
-
-pre {
- width: 90%;
- font-size: 10pt;
- font-family: monospace;
- background: #e1e1e1;
- margin-left: 4%;
- padding-top: 5px;
- padding-bottom: 5px;
+.validation {
+ display: inline;
+ float: right;
}
.pagecloud {
- width: 25%;
- border-top: 1px solid #aaa;
- border-bottom: 1px solid #aaa;
- background: #eee;
- color: black !important;
+ margin-left: 5px;
}
-.pagecloud a {
- text-decoration: none;
+table.identikit tr th {
+ text-align: right;
+ vertical-align: top;
+}
+table.identikit tr th:after {
+ content: ":";
+}
+table.identikit tr td {
+ text-align: left;
+ vertical-align: top;
+}
+
+.doi_logo , .doi_logo a {
+ background: #3965bd;
+ color: white !important;
+ font-size: 80%;
+ text-decoration: none;
+ font-family: times;
+ font-weight: bold;
+ padding: 0px 1px 0px 2px;
+}
+
+#comments {
+ margin-top: 5ex;
+ border-top: solid 1px;
+ border-color: #aaa;
+ font-size: small;
+}
+
+#comments #feedlink {
+ text-align: right;
+}
+#comments #feedlink:before {
+ content: "comment feeds: ";
+}
+
+.addcomment {
+ padding: 5px;
+ font-style: italic;
+}
+
+.comment {
+ border: none;
+ background-color: #eee;
+ margin: 5px;
+ margin-top: 10px;
+}
+
+.comment-subject {
+ font-style: normal;
+}
+
+.comment-header {
+ border-top: solid 1px;
+ border-color: #aaa;
+ text-align: right;
+ font-style: normal;
}
diff --git a/doc/download.mdwn b/doc/download.mdwn
index 6566dc122..507b250a5 100644
--- a/doc/download.mdwn
+++ b/doc/download.mdwn
@@ -10,12 +10,7 @@ Installation steps and requirements are listed on the [[install]] page.
## packages
-To install with apt, if using Debian (since 4.0), or Ubuntu (since 6.10):
-[[!template id=note text="""
-Note that Debian 4.0 and especially Ubuntu 6.10 contain older versions of
-ikiwiki, there have been lots of enhancements and bug fixes since those
-versions.
-"""]]
+To install with apt, if using Debian or Ubuntu:
apt-get install ikiwiki
@@ -24,7 +19,9 @@ Or download the deb from .
There is a backport of a recent version of ikiwiki for Debian 4.0 at
.
-There is also an unofficial backport of ikiwiki for Ubuntu Hardy, provided by
+Fedora versions 8 and newer have RPMs of ikiwiki available.
+
+There is also an unofficial backport of ikiwiki for Ubuntu Intrepid, provided by
[[Paweł_Tęcza|users/ptecza]],
at [http://gpa.net.icm.edu.pl/ubuntu/](http://gpa.net.icm.edu.pl/ubuntu/index-en.html).
@@ -38,6 +35,8 @@ Gentoo has an [ebuild](http://bugs.gentoo.org/show_bug.cgi?id=144453) in its bug
IkiWiki can be installed [from macports](http://www.macports.org/ports.php?by=name&substr=ikiwiki)
by running `sudo port install ikiwiki`.
+A [PKGBUILD for Arch Linux](http://aur.archlinux.org/packages.php?ID=12284) is in the AUR.
+
## revision control
Ikiwiki is developed in a [[git_repository|git]].
diff --git a/doc/examples/blog.mdwn b/doc/examples/blog.mdwn
index 3e89c4b99..2155d7fea 100644
--- a/doc/examples/blog.mdwn
+++ b/doc/examples/blog.mdwn
@@ -1,18 +1,25 @@
This is an [[example_blog|index]]. Just copy the blog subdirectory into
-your wiki to quickly get started blogging with ikiwiki.
+your wiki to quickly get started blogging with ikiwiki.
+
+Or, run this command to set up a blog with ikiwiki.
+
+ % ikiwiki -setup /etc/ikiwiki/auto-blog.setup
Some additional configuration you might want to do:
-* Change the name of the blog, by editing `index.mdwn` and changing
- the `title`.
-
* Make sure to configure ikiwiki to generate RSS or Atom feeds.
* 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]]
-* Enable the sidebar plugin to get a sidebar listing all the categories
- you've tagged posts with.
+* Enable the [[sidebar|plugins/sidebar]] plugin to get a sidebar listing all
+ the categories you've tagged posts with.
-* Enable the pagestats plugin to get a tag cloud display on the [[index]].
+* Enable the [[pagestats|plugins/pagestats]] plugin to get a tag cloud
+ to display on the [[index]].
+
+* Enable the [[comments|plugins/comments]] plugin and configure it to
+ enable comments to posts to the blog:
+
+ comments_pagespec => 'blog/posts/* and !*/Discussion',
diff --git a/doc/examples/blog/index.mdwn b/doc/examples/blog/index.mdwn
index 6daf9db50..84c732dd1 100644
--- a/doc/examples/blog/index.mdwn
+++ b/doc/examples/blog/index.mdwn
@@ -1,14 +1,13 @@
-[[!meta title="example blog"]]
-
[[!pagestats pages="./tags/*"]]
-Welcome to my blog. Have a look at the most recent posts below, or
-browse the tag cloud on the right. An archive of all [[posts]] is also
-available.
+Welcome to my blog.
+
+Have a look at the most recent posts below, or browse the tag cloud on the
+right. An archive of all [[posts]] is also available.
[[!inline pages="./posts/* and !*/Discussion" show="10"
actions=yes rootpage="posts"]]
----
-This wiki is powered by [ikiwiki](http://ikiwiki.info).
+This blog is powered by [ikiwiki](http://ikiwiki.info).
diff --git a/doc/examples/blog/posts/first_post.mdwn b/doc/examples/blog/posts/first_post.mdwn
index 3d7174ae8..d49432341 100644
--- a/doc/examples/blog/posts/first_post.mdwn
+++ b/doc/examples/blog/posts/first_post.mdwn
@@ -1,4 +1,4 @@
This is the first post to this example blog. To add new posts, just add
-files to the blog/posts/ subdirectory, or use the web form.
+files to the posts/ subdirectory, or use the web form.
[[!tag tags/tech]]
diff --git a/doc/examples/softwaresite/index.mdwn b/doc/examples/softwaresite/index.mdwn
index e2d180d1f..e03a969a0 100644
--- a/doc/examples/softwaresite/index.mdwn
+++ b/doc/examples/softwaresite/index.mdwn
@@ -1,7 +1,7 @@
FooBar is an amazing example program that does not exist. Use it for all
your example program needs. This is its wiki.
-* [[download]]
+* **[[download]]**
* [[news]]
* [[documentation|doc]]
* [[bugs]]
diff --git a/doc/forum.mdwn b/doc/forum.mdwn
index bab65cac6..729540774 100644
--- a/doc/forum.mdwn
+++ b/doc/forum.mdwn
@@ -5,4 +5,4 @@ _This is a bold experiment by me, since I have exactly such a question. This ove
## Current topics ##
[[!inline pages="forum/* and !forum/discussion and !forum/*/*"
-actions=yes rootpage="forum" postformtext="Add a new thread titled:" show=0]]
+archive=yes rootpage="forum" postformtext="Add a new thread titled:" show=0]]
diff --git a/doc/forum/Adding_new_markup_to_markdown.mdwn b/doc/forum/Adding_new_markup_to_markdown.mdwn
new file mode 100644
index 000000000..39d233add
--- /dev/null
+++ b/doc/forum/Adding_new_markup_to_markdown.mdwn
@@ -0,0 +1,11 @@
+I'm using ikiwiki to manage my personal wiki. One of the things I'm toying with is storing my grocery list in a wiki. The way I typically grocery-shop is to make one huge master list containing all the items I typically buy in a single cycle. Then, on any given trip, I make a subset list containing only the items I need. I'd like to streamline this process by making the master list a series of checkboxes. Before each trip, I load the list page on my phone, check off all the items I already have, then check off individual items as I get them.
+
+I'm not sure if there's a convenient way of adding checkboxes to wiki pages, and after a bit of thought I decided that "( )" would be a good markup for this. Ideally I'd like to still have access to other markdown conventions so I could, say, organize the list with headings and such when it grows large, so I don't want to create an entirely separate format, or a separate copy of the markdown plugin.
+
+Is there an existing means of, say, adding supersets to wiki markup? I suppose I could use an inline directive that inserts a multisellect HTML element, but I really like ( ). :)
+
+Ideal would be some sort of filter infrastructure. Plugins could register with a larger filter plugin that adds an inline directive. I could then invoke the checkbox filter at the top of my grocery list, and all instances of ( ) would be replaced with HTML. Might also make sense for the individual filters to specify whether or not they're invoked before or after the page template, or perhaps just always invoke them after. *shrug*
+
+Does something like this exist? I'd really like to avoid messing around with raw HTML or an inline for each of 40-50 list items. :)
+
+-- [[Nolan]]
diff --git a/doc/forum/Darcs_as_the_RCS___63__.mdwn b/doc/forum/Darcs_as_the_RCS___63__.mdwn
new file mode 100644
index 000000000..2635690f7
--- /dev/null
+++ b/doc/forum/Darcs_as_the_RCS___63__.mdwn
@@ -0,0 +1,11 @@
+Hi,
+
+I have successfully installed and set up my first instance of [[ikiwiki]] on my dedicated server. Following [[joey]]'s screencasts made this easy (thank you).
+
+Currently, I have set up the RCS to be git but I do not like this very much. I'd rather want darcs but if I replace rcs settings, it fails.
+
+What should I put in the configuration file to use darcs ?
+
+> Darcs is not yet supported. It's being [[worked_on|todo/darcs]].
+
+> > That's good news for me then ! Thank you.
diff --git a/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
new file mode 100644
index 000000000..5522cbf45
--- /dev/null
+++ b/doc/forum/How_does_ikiwiki_remember_times__63__.mdwn
@@ -0,0 +1,89 @@
+This is similar to the last post in this forum. I want to know exactly how ikiwiki remembers the times associated with pages, especially when using it for blogging, so I know whether I can trust it or not. From that last thread, I think what ikiwiki does is this:
+
+* The created time of a file is when that file was first committed into the versioning repository (in my case git)
+
+ > If `--getctime` it used, yes. In normal operation, when new files
+ > are added, ikiwiki sets the creation time to the ctime of the file
+ > on disk, rather than bothering to ask the VCS. --[[Joey]]
+
+* The modified time of a file is what that file was last updated in the repository
+
+ > Almost right, the modified time is actually taken from the
+ > modification time of the file in disk. --[[Joey]]
+
+And with a blog, by default, the posts are ordered by creation time, although an option can order them by modified time.
+
+Okay. So this should mean that the times are safe if, for example, I delete my working copy and then clone another one from the bare git repository, or otherwise mess up the creation times and mtimes stored as file metadata on the filesystem.
+
+Do I have it right?
+
+> Some VCS, like git, set the file mtimes to the current time
+> when making a new checkout, so they will be lost if you do that.
+> The creation times can be retrived using the `--getctime` option.
+> I suppose it might be nice if there were a `--getmtime` that pulled
+> true modification times out of the VCS, but I haven't found it a big
+> deal in practice for the last modification times to be updated to the
+> current time when rebuilding a wiki like this. --[[Joey]]
+>
+> > Thanks for the clarification. I ran some tests of my own to make sure I understand it right, and I'm satisfied
+> > that the order of posts in my blog can be retrieved from the VCS using the `--getctime` option, at least if I
+> > choose to order my posts by creation time rather than modification time. But I now know that I can't rely on
+> > page modification times in ikiwiki as these can be lost permanently.
+> >
+> > I would suggest that there should at least be a `--getmtime` option like you describe, and perhaps that
+> > `--getctime` and `--getmtime` be _on by default_. In my opinion the creation times and modification times of
+> > pages in ikiwiki are part of the user's content and are important to protect, because the user may be relying
+> > on them, especially if they use blogging or lists of recently modified pages, etc. Right now the modification
+> > times can be lost permanently.
+> >
+> > Is there a typo in the description of `--getctime` in the man page?
+> >
+> > > --getctime
+> > > Pull **last changed time** for each new page out of the revision
+> > > control system. This rarely used option provides a way to get
+> > > the real creation times of items in weblogs, such as when build‐
+> > > ing a wiki from a new Subversion checkout. It is unoptimised and
+> > > quite slow. It is best used with --rebuild, to force ikiwiki to
+> > > get the ctime for all pages.
+> >
+> > Surely it is not the _last changed time_ but the _first seen time_ of each page that is pulled out of the VCS?
+> > If the aim is to get the real creation times of items in weblogs, then the last times that the items were
+> > changed in the VCS is not going to help. -- [[seanh]]
+>>> Typo, fixed. --[[Joey]]
+
+> > > If you want to preserve the date of a page, the best way to do it is to
+> > > use [[ikiwiki/directive/meta]] date="foo". This will survive checkouts,
+> > > VCS migrations, etc. -- [[Jon]]
+> > >
+> > > > That's a good tip Jon. That would also survive renaming a page by renaming its mdwn file, which would
+> > > > normally lose the times also. (And in that case I think both times are irretrievable, even by
+> > > > `--getctime`). I might start using a simple script to make blog posts that creates a file for
+> > > > me, puts today's date in the file as a meta, and opens the file in my editor. -- [[seanh]]
+
+>>>>> I use a script that does that and also sets up templates and tags
+>>>>> for a new item:
+
+ #!/bin/sh
+ set -u
+ set -e
+
+ if [ $# -ne 1 ]; then
+ echo usage: $0 pagename >&2
+ exit 1
+ fi
+
+ pagename="$1"
+
+ if [ -e "$pagename" ]; then
+ echo error: "$pagename" exists >&2
+ exit 1
+ fi
+
+ date=$(date)
+ echo '\[[!template id=draft]]' >> "$pagename"
+ echo "\[[!meta date=\"$date\"]]" >> "$pagename"
+ echo "\[[!tag draft]]" >> "$pagename"
+ git add "$pagename"
+ $EDITOR "$pagename"
+
+>>>>> -- [[Jon]]
diff --git a/doc/forum/How_to_fix___34__does_not_map_to_Unicode__34___errors__63__.mdwn b/doc/forum/How_to_fix___34__does_not_map_to_Unicode__34___errors__63__.mdwn
new file mode 100644
index 000000000..0b3895357
--- /dev/null
+++ b/doc/forum/How_to_fix___34__does_not_map_to_Unicode__34___errors__63__.mdwn
@@ -0,0 +1,20 @@
+I'm getting a number of errors like this when running ikiwiki:
+
+ utf8 "\xA2" does not map to Unicode at /usr/local/share/perl/5.10.0/IkiWiki.pm line 739, <$in> chunk 1.
+
+I think it's because some of my files contain non-utf8, non-unicode, or somehow bad characters in them, probably fancy quotes and the like that have been copy-and-pasted from my web browser. The problem is that I have hundreds of files, I transferred them all over from pyblosxom to ikiwiki at once, and the error message doesn't tell me which file the error comes from. How can I fix this?
+
+Thanks
+-- seanh
+
+> Unfortunatly, these messages are logged by perl so there's no way to add
+> a filename to them.
+>
+> If you run the build in --verbose mode, you should see which page ikiwiki
+> is working on, and unless it inlines some other page, you can be pretty
+> sure that page contains invalid utf-8 if the message is then printed.
+>
+> Another option is to use the `isutf8` program from
+> moreutils](http://kitenet.net/~joey/code/moreutils/),
+> and run it on each file, it will tell you the line number
+> and character position that is invalid. --[[Joey]]
diff --git a/doc/forum/Is_there_a_pagespec_for_creation_dates_relative_to_today__63__.mdwn b/doc/forum/Is_there_a_pagespec_for_creation_dates_relative_to_today__63__.mdwn
index e88400cd4..53c70e50a 100644
--- a/doc/forum/Is_there_a_pagespec_for_creation_dates_relative_to_today__63__.mdwn
+++ b/doc/forum/Is_there_a_pagespec_for_creation_dates_relative_to_today__63__.mdwn
@@ -17,6 +17,10 @@ Paul
> somehow figure out that pages matched by it yesterday no longer match,
> and that pages containing the pagespec need to be rebuilt. Which means
> you'd also need a cron job.
->
+
+>> Thank you for the explanation.
+
> I suspect what you're trying to accomplish is
> [[todo/tagging_with_a_publication_date]]? --[[Joey]]
+
+>> Yeah, something like that. Thanks! --[[PaulePanter]]
diff --git a/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
new file mode 100644
index 000000000..fe67e6aba
--- /dev/null
+++ b/doc/forum/Migrating_old_repository_to_new_ikiwiki_system__63__.mdwn
@@ -0,0 +1,58 @@
+How do I setup an old ikiwiki repository on a new system?
+
+I have a git repository from an old ikiwiki system.
+I reformatted that hard drive, but saved the repository.
+
+I copied it the repository to my new system, which is now the "master" host.
+I installed ikiwiki on the new system.
+
+How do I set up an ikiwiki system using a pre-existing repository (instead of creating a new one)? --[[JosephTurian]]
+
+> Well, if you have:
+> * A git repository of the wiki
+> * A setup file for the wiki
+>
+> Then you should:
+>
+> 1. Manually set up a bare git repository, and push
+> your backed up repository to it.
+> 2. `git clone` from the bare git repository to
+> recreate the ikiwiki srcdir
+> 3. `git clone` from the bare git repository a second time,
+> to create a checkout you can manually edit (optional)
+> 4. run `ikiwiki --getctime --setup your.setup`
+> The getctime will ensure page creation times are accurate
+> by putting the info out of the git history,
+> and only needs to be done once.
+>
+> If you preserved your repository, but not the setup file,
+> the easiest way to make one is probably to run
+> `ikiwiki -dumpsetup` and edit the setup file. --[[Joey]]
+
+> > I get the following errors after running ikiwiki setup:
+
+ shortcut plugin will not work without shortcuts.mdwn
+ shortcut plugin will not work without shortcuts.mdwn
+ successfully generated /home/turian/public_html/iki/ikiwiki.cgi
+ shortcut plugin will not work without shortcuts.mdwn
+ successfully generated /home/turian/repos/iki.git/hooks/post-update
+ Can't stat /usr/share/ikiwiki/basewiki/../javascript: No such file or directory
+ at /home/turian/utils//lib/perl5/site_perl/5.8.8//IkiWiki/Plugin/autoindex.pm line 60
+ Can't stat /usr/share/ikiwiki/basewiki/../smiley: No such file or directory
+ at /home/turian/utils//lib/perl5/site_perl/5.8.8//IkiWiki/Plugin/autoindex.pm line 60
+ Can't stat /usr/share/ikiwiki/basewiki: No such file or directory
+ at /home/turian/utils//lib/perl5/site_perl/5.8.8//IkiWiki/Plugin/autoindex.pm line 60
+ Can't stat /usr/share/ikiwiki/basewiki/../javascript: No such file or directory
+ at /home/turian/utils//lib/perl5/site_perl/5.8.8//IkiWiki/Render.pm line 320
+ Can't stat /usr/share/ikiwiki/basewiki/../smiley: No such file or directory
+ at /home/turian/utils//lib/perl5/site_perl/5.8.8//IkiWiki/Render.pm line 320
+ Can't stat /usr/share/ikiwiki/basewiki: No such file or directory
+ at /home/turian/utils//lib/perl5/site_perl/5.8.8//IkiWiki/Render.pm line 320
+ internal error: smileys.mdwn cannot be found in /home/turian/iki or underlay
+
+> > How do I resolve these errors? I have my PERL5LIB location set correctly.
+
+>>> Well, that's unrelated to the original question, but
+>>> I guess you should set `underlaydir` in your setup file to
+>>> point to whereever you have installed the basewiki directory.
+>>> --[[Joey]]
diff --git a/doc/forum/What_is_wrong_with_my_recentchange_page___63__.mdwn b/doc/forum/What_is_wrong_with_my_recentchange_page___63__.mdwn
new file mode 100644
index 000000000..4914cba59
--- /dev/null
+++ b/doc/forum/What_is_wrong_with_my_recentchange_page___63__.mdwn
@@ -0,0 +1,13 @@
+Hi again,
+
+I have finally finished my setup *but* I still have a problem with RecentChanges page.
+
+Can somebody check it for me at [http://maillard.mobi/~xma/wiki/recentchanges/] and tell what is wrong ?
+
+Thank you.
+
+--[[xma]]
+
+> Looks to me like you don't have the meta plugin enabled. --[[Joey]]
+
+> > You are right. Now all is ok. --[[xma]]
diff --git a/doc/forum/chinese_character_problem.mdwn b/doc/forum/chinese_character_problem.mdwn
new file mode 100644
index 000000000..aea55703f
--- /dev/null
+++ b/doc/forum/chinese_character_problem.mdwn
@@ -0,0 +1,21 @@
+just finished setting up ikiwiki..
+
+I can type chinese, save and display it correctly in ikiwiki for the first time. However, when i try to edit the page again, the chinese character in the form is unrecognizable. you can see it here
+
+I am using the latest ikiwiki(manually installed as non-root user) and CGI::FormBuilder(3.0501) on Debian 4.0
+
+这个没问题 it is not a problem on ikiwiki website though.
+
+Thanks.
+
+
+> Is your system perhaps not configured with a utf-8 default locale? Or ikiwiki not configured to use it?
+> Make sure that some utf-8 locale is enabled (in /etc/locale.gen on Debian for example) and try setting `locale` in your > ikiwiki setup file. --[[Joey]]
+
+I have installed locales-all and locale -a shows that zh_CN.UTF-8 is installed(there is no /etc/local.gen file though). then I enabled this line "locale => 'zh_CN.UTF-8'" in my wiki setup and -setup again. but that generated lots error messages "Missing constant domain at (eval 30) line 3"
+
+sorry being a n00b on this thing what else can I do?
+
+> See [[bugs/Missing_constant_domain_at_IkiWiki.pm_line_842]].
+> Looks like you need to upgrade to a newer version of
+> [[!cpan Locale::gettext]] --[[Joey]]
diff --git a/doc/forum/discussion.mdwn b/doc/forum/discussion.mdwn
new file mode 100644
index 000000000..93cf4656e
--- /dev/null
+++ b/doc/forum/discussion.mdwn
@@ -0,0 +1,7 @@
+I like the idea of this forum heirarchy -- but I think a map would be clearer than inlining the sub-pages. -- [[users/Jon]]
+
+> The easier way to accomplish this is to set archive=yes in the inline.
+> Switching to archive view can be useful when there are a lot of long
+> posts and people tend to want to scan by title to find interesting ones
+> and not necessarily read them all, which probably fits this forum pretty
+> well --[[Joey]]
diff --git a/doc/forum/ikiwiki__39__s_notion_of_time.mdwn b/doc/forum/ikiwiki__39__s_notion_of_time.mdwn
new file mode 100644
index 000000000..ee564fcc9
--- /dev/null
+++ b/doc/forum/ikiwiki__39__s_notion_of_time.mdwn
@@ -0,0 +1,35 @@
+I'm having some difficulties with ikiwiki's notion of time.
+
+For (regular) pages, the *last edited* date is the one where the file
+was indeed last modified according to the file system information.
+The *created* date (commented out in the HTML) is, at least for
+`--getctime` operation, the date, where the file was last registered
+as changed with the VCS.
+
+Now, at least with git, the thing is that when you're checking out files,
+they'll get the checkout-time's current time stamp.
+
+What I strive for is the following: *created* be the date when the file
+(under its current name) was *first* registered with the VCS (which is
+more logical in my opinion), and *last edited* be the date the file was
+last registered as changed with the VCS, which is the current
+`--getctime` *created* date.
+
+This means that I can build the HTML files from different checkouts of the
+VCS and they won't differ in the time stamps they contain in the HTML.
+
+What is the rationale for ikiwiki's current behavior with respect to these
+time stamps?
+
+--[[tschwinge]]
+
+> Presumably it's the authors of the git and mercurial backends
+> not understanding the documentation for `rcs_getctime`,
+> which states:
+>
+>>This is used to get the page creation time for a file from the RCS, by
+>>looking it up in the history.
+>
+> I've fixed both broken implementations to correctly look
+> up the first, not the last, commit. Other VCS do not seem
+> to have the problem. --[[Joey]]
diff --git a/doc/forum/managing_todo_lists.mdwn b/doc/forum/managing_todo_lists.mdwn
new file mode 100644
index 000000000..0a69af805
--- /dev/null
+++ b/doc/forum/managing_todo_lists.mdwn
@@ -0,0 +1,44 @@
+I keep some TODO lists on ikiwiki pages. I'm half-tempted to write a plugin
+to make ticking items off and adding items easier via the web interface. I'm
+aware though that this is not really what ikiwiki is designed for. Would
+anyone else find this useful? -- [[users/jon]]
+
+----
+
+My subsequent thoughts about how to approach this are two-fold.
+
+Firstly, a filetype for todo lists, probably OPML, but I haven't looked to see
+if there is something more suitable. A plugin that converts this source into a
+traditional page output, i.e. a DOM tree of ul or ol and li elements.
+
+Secondly, some magic javascript to make editing the list via the web page
+more interactive: add items, strike items out, reorder items etc., without
+round-tripping to the cgi for each operation.
+
+Finally, a mechanism whereby the changes made to the page live can be
+committed back to the repository:
+
+ * ...perhaps the input → output conversion is reversible, and the HTML DOM
+ representing the list can be transformed back into the source and submitted
+ to the cgi like a regular edit: issues include the result of other
+ postprocessing: templates, wikilinks, etc.
+ * perhaps an embedded copy of the source is included in the output and the
+ javascript operates on that in tandem with the static copy
+ * perhaps the "output" is generated live by the JS at view time (with maybe
+ a plugin-generated rendered output for non JS environments)
+
+I envisage a button called "commit changes" appearing once some changes are
+made that submits the changes to the CGI, perhaps via a back channel. I'm not
+sure how to handle embeds or challenges from the CGI such as a login challenge
+(maybe the back channel would not be necessary in the first cut).
+
+> You might look at the [[plugins/hnb]] plugin. HNB supports checklists.
+> There's not a fancy web interface, but the hnb command-line program can
+> be used to edit them. --[[Joey]]
+
+>> thanks - I'll give it a look. I spent a few hours writing some javascript to manipulate a ul/li DOM tree in an outliner-fashion the other day. I might be able to join the puzzle pieces together sometime. [[Jon]]
+
+a solution for this could be similar to a solution for [[todo/structured page data]], as todo lists are definitely a form of structured data. (in both cases, the page's current content is rendered into a html form, whose result is then saved as the page's new contents) --[[chrysn]]
+
+> Thanks for the link: yup, there's definitely some common ground there.
+> -- [[Jon]]
diff --git a/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn b/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn
index d42a5c704..fa8b5010e 100644
--- a/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn
+++ b/doc/forum/multi-user_setup_of_ikiwiki__44___gitosis_and_apache2_in_Debian_Sid.mdwn
@@ -43,7 +43,7 @@ In the end, I did the following. I created a directory /srv/ikiwiki/ which is ow
## cgi_wrapper
-I do not understand those wrappers completely. The cgi is a script, which can be called by a webserver, e. g. [[Apache_2|/tips/apache_cgi]]. But www-data is normally not allowed to write to the source directory (which is owned by gitosis or push to the repository). Therefore it should be run as the user gitosis. And because cgi scripts can not be made suid, I wrapper (in this case a C program) is created (cgi\_wrapper) which can be made suid and therefore be run as the user gitosis. Is this correct?
+I do not understand those wrappers completely. The cgi is a script, which can be called by a webserver, e. g. [[Apache_2|/tips/dot_cgi]]. But www-data is normally not allowed to write to the source directory (which is owned by gitosis or push to the repository). Therefore it should be run as the user gitosis. And because cgi scripts can not be made suid, I wrapper (in this case a C program) is created (cgi\_wrapper) which can be made suid and therefore be run as the user gitosis. Is this correct?
> It seems to me like you understand the wrapper pretty well. It's main reson to exist is to safely be suid, yes.
diff --git a/doc/forum/usedirs___38___indexpages_using_problem.mdwn b/doc/forum/usedirs___38___indexpages_using_problem.mdwn
new file mode 100644
index 000000000..05c85e281
--- /dev/null
+++ b/doc/forum/usedirs___38___indexpages_using_problem.mdwn
@@ -0,0 +1,17 @@
+My ikiwiki setup file configed like:
+
+ usedirs => 0,
+ indexpages => 1,
+
+I create a directory and some .mdwn source file /Whatis/index.mdwn and /Whatis/OSS.mdwn . The html file ikiwiki generated is
+/Whatis/index.html and /Whatis/OSS.html .
+
+But in the page [OSS.html](http://atoz.org.cn/Whatis/OSS.html) , the auto generated link (on the page top)
+to “Whatis” is /Whatis.html file , not to /Whatis/index.html. So the link to “Whatis” is fail .
+
+Is it a bug , and how can I do for that ?
+
+> I suggest that you name your page `Whatis.mdwn`, and not
+> `Whatis/index.mdwn`. That will make ikiwiki's links work,
+> and allows you to link to the `Whatis` page by that name.
+> --[[Joey]]
diff --git a/doc/forum/wiki_name_in_page_titles.mdwn b/doc/forum/wiki_name_in_page_titles.mdwn
new file mode 100644
index 000000000..01ff8d817
--- /dev/null
+++ b/doc/forum/wiki_name_in_page_titles.mdwn
@@ -0,0 +1,26 @@
+I'd like to have the wiki name appear in page titles as in "WikiName:
+Page Title." If I use `: ` in the
+template this works for all pages except the index page itself which
+will have title "WikiName: WikiName" as its title. Does anyone know
+of a template-based solution to this or do I need to write a plugin
+that provides a `IS_HOMEPAGE` template variable? --[[JasonBlevins]]
+
+> Hmm, one way to work around this is to put a meta title directive on the
+> index page. Then TITLE will be that, rather than WIKINAME, and your
+> template should work. --[[Joey]]
+
+>> I ended up writing a [path][] plugin since I had some other
+>> path-specific conditional things to include in my templates.
+>>
+>> So now I can do things like this:
+>>
+>>
+>> :
+>>
+>>
+>> But also more complicated path-specific conditionals like
+>> `IN_DIR_SUBDIR` to indicate subpages of `/dir/subdir/`. I've got a
+>> few other small plugins brewing so I'll try to put up some contrib
+>> pages for them soon. --[[JasonBlevins]]
+
+[path]: http://code.jblevins.org/ikiwiki/plugins.git/plain/path.pm
diff --git a/doc/freesoftware/discussion.mdwn b/doc/freesoftware/discussion.mdwn
new file mode 100644
index 000000000..e71fd295d
--- /dev/null
+++ b/doc/freesoftware/discussion.mdwn
@@ -0,0 +1,3 @@
+And where is the code, please ?
+
+> [[download]] --[[Joey]]
diff --git a/doc/git.mdwn b/doc/git.mdwn
index e5fef6a5a..8a89546cf 100644
--- a/doc/git.mdwn
+++ b/doc/git.mdwn
@@ -1,5 +1,12 @@
-Ikiwiki is developed in a git repository and can be checked out
-like this:
+Ikiwiki, and this documentation wiki, are developed in a git repository and
+can be checked out like this:
+
+[[!template id=note text="""
+You can push changes back to ikiwiki's git repository over the `git://`
+transport, to update this wiki, if you'd like, instead of editing it on the
+web. Changes that could not be made via the web will be automatically
+rejected.
+"""]]
git clone git://git.ikiwiki.info/
@@ -9,16 +16,30 @@ Or like this if your firewall only passes http traffic (slow):
The gitweb is [here](http://git.ikiwiki.info/?p=ikiwiki).
-There is also a mirror [on github](http://github.com/joeyh/ikiwiki/tree/master).
-
Commits to this git repository are fed into [CIA](http://cia.vc), and can
be browsed, subscribed to etc on its
-[project page](http://cia.vc/stats/project/ikiwiki).
+[project page](http://cia.vc/stats/project/ikiwiki). They're also fed into
+[twitter](http://twitter.com/ikiwiki).
-## branches
+## personal git repositories
You are of course free to set up your own ikiwiki git repository with your
-own [[patches|patch]].
+own [[patches|patch]]. If you list it here, the `gitremotes` script will
+automatically add it to git remotes. Your repo will automatically be pulled
+into [[Joey]]'s working tree. This is recommended. :-)
+
+
+
+* github `git://github.com/joeyh/ikiwiki.git`
+ ([browse](http://github.com/joeyh/ikiwiki/tree/master))
+ A mirror of the main repo, automatically updated.
+* [[smcv]] `git://git.pseudorandom.co.uk/git/smcv/ikiwiki.git`
+* [[intrigeri]] `git://gaffer.ptitcanardnoir.org/ikiwiki.git`
+* [[gmcmanus]] `git://github.com/gmcmanus/ikiwiki.git`
+* [[jelmer]] `git://git.samba.org/jelmer/ikiwiki.git`
+* [[hendry]] `git://webconverger.org/git/ikiwiki`
+
+## branches
Some of the branches included in the main repository include:
@@ -30,9 +51,9 @@ Some of the branches included in the main repository include:
* `wikiwyg` adds [[todo/wikiwyg]] support. It is unmerged pending some
changes.
* `darcs` is being used to add darcs support.
-* `pristine-tar` contains deltas that
- [pristine-tar](http://kitenet.net/~joey/code/pristine-tar)
- can use to recreate released tarballs of ikiwiki
* `debian-stable` is used for updates to the old version included in
Debian's stable release, and `debian-testing` is used for updates to
Debian's testing release.
+* `pristine-tar` contains deltas that
+ [pristine-tar](http://kitenet.net/~joey/code/pristine-tar)
+ can use to recreate released tarballs of ikiwiki
diff --git a/doc/ikiwiki-makerepo.mdwn b/doc/ikiwiki-makerepo.mdwn
index d5034b2c7..3fbfbdc82 100644
--- a/doc/ikiwiki-makerepo.mdwn
+++ b/doc/ikiwiki-makerepo.mdwn
@@ -6,16 +6,17 @@ ikiwiki-makerepo - check an ikiwiki srcdir into revision control
ikiwiki-makerepo svn|git|monotone|darcs srcdir repository
-ikiwiki-makerepo mercurial|darcs srcdir
+ikiwiki-makerepo bzr|mercurial|darcs srcdir
# DESCRIPTION
`ikiwiki-makerepo` injects a `srcdir` directory, containing an ikiwiki wiki,
-into a `repository` that it creates. The repository can be a svn, git, or
-mercurial repository.
+into a `repository` that it creates. The repository can be created using
+any of a variety of revision control systems.
-Note that for mercurial, the srcdir is converted into a mercurial
-repository. There is no need to have a separate repository with mercurial.
+Note that for mercurial and bzr, the srcdir is converted into a
+repository. There is no need to have a separate repository with mercurial
+or bzr.
For darcs, the second (one-argument) form turns the given srcdir into a
darcs master repository with the (new) srcdir inside. Adjust your ikiwiki.setup
@@ -24,8 +25,8 @@ preconfigured to call a (hypothetical) ikiwiki wrapper. The command
reports the relevant file. Adjust it as needed or remove it if you don't use
the cgi script.
-Note that for monotone, you are assumed to already have run "mtn genkey" to generate
-key.
+Note that for monotone, you are assumed to already have run "mtn genkey"
+to generate key.
# AUTHOR
diff --git a/doc/ikiwiki-transition.mdwn b/doc/ikiwiki-transition.mdwn
index 8b7c3579f..18836d5f5 100644
--- a/doc/ikiwiki-transition.mdwn
+++ b/doc/ikiwiki-transition.mdwn
@@ -8,24 +8,23 @@ ikiwiki-transition type ...
# DESCRIPTION
-`ikiwiki-transition` aids in converting wiki pages when
-there's a major change in ikiwiki syntax. It also handles other transitions
-not involving wiki pages.
+`ikiwiki-transition` aids in converting wiki pages when there's a major
+change in ikiwiki syntax. It also handles other transitions not involving
+wiki pages.
-# prefix_directives
+# prefix_directives your.setup
-The `prefix_directives` mode converts the specified ikiwiki page from
-the old preprocessor directive syntax, requiring a space, to the new
-syntax, prefixed by '!'.
+The `prefix_directives` mode converts all pages from the old preprocessor
+directive syntax, requiring a space, to the new syntax, prefixed by '!'.
Preprocessor directives which already use the new syntax will remain
unchanged.
-Note that if the page contains wiki links with spaces, which some
+Note that if a page contains wiki links with spaces, which some
older versions of ikiwiki accepted, the prefix_directives transition will
treat these as preprocessor directives and convert them.
-# setupformat
+# setupformat your.setup
The `setupformat` mode converts a setup file from using a single `wrappers` block
to using `cgi_wrapper`, `git_wrapper`, etc.
@@ -33,25 +32,30 @@ to using `cgi_wrapper`, `git_wrapper`, etc.
Note that all comments and any unusual stuff like perl code in the setup
file will be lost, as it is entirely rewritten by the transition.
-# aggregateinternal
+# aggregateinternal your.setup
The `aggregateinternal` mode moves pages aggregated by the aggregate plugin
so that the `aggregateinternal` option can be enabled.
-# indexdb
+# moveprefs your.setup
+
+Moves values that used to be admin preferences into the setup file.
+
+Note that all comments and any unusual stuff like perl code in the setup
+file will be lost, as it is entirely rewritten by the move.
+
+# indexdb srcdir
The `indexdb` mode handles converting a plain text `.ikiwiki/index` file to
-a binary `.ikiwiki/indexdb`. In this mode, you should specify the srcdir of
-the wiki as the second parameter. You do not normally need to run
+a binary `.ikiwiki/indexdb`. You do not normally need to run
`ikiwiki-transition indexdb`; ikiwiki will automatically run it as
necessary.
-# hashpassword
+# hashpassword srcdir
The `hashpassword` mode forces any plaintext passwords stored in the
`.ikiwiki/userdb` file to be replaced with password hashes. (The
-Authen::Passphrase perl module is needed to do this.) In this mode, you
-should specify the srcdir of the wiki as the second parameter.
+Authen::Passphrase perl module is needed to do this.)
If this is not done explicitly, a user's plaintext password will be
automatically converted to a hash when a user logs in for the first time
diff --git a/doc/ikiwiki/directive.mdwn b/doc/ikiwiki/directive.mdwn
index c4342dee8..fb88aa72d 100644
--- a/doc/ikiwiki/directive.mdwn
+++ b/doc/ikiwiki/directive.mdwn
@@ -28,15 +28,13 @@ of text with triple-quotes:
3. "baz"
"""]]
-ikiwiki also has an older syntax for directives, which requires a
-space in directives to distinguish them from [[wikilinks|ikiwiki/wikilink]].
-This syntax has several disadvantages: it requires a space after directives
-with no parameters (such as `\[[pagecount ]]`), and it prohibits spaces in
-[[wikilinks|ikiwiki/wikilink]]. ikiwiki now provides the `!`-prefixed syntax
-shown above as the preferred alternative. However, ikiwiki still supports
-wikis using the older syntax, if the `prefix_directives` option is not enabled.
-For backward compatibility with existing wikis, this option currently
-defaults to off, so ikiwiki supports the old syntax.
+ikiwiki also has an older syntax for directives, which requires a space in
+directives to distinguish them from [[wikilinks|ikiwiki/wikilink]]. This
+syntax has several disadvantages: it requires a space after directives with
+no parameters (such as `\[[pagecount ]]`), and it prohibits spaces in
+[[wikilinks|ikiwiki/wikilink]]. ikiwiki now provides the `!`-prefixed
+syntax shown above as default. However, ikiwiki still supports wikis using
+the older syntax, if the `prefix_directives` option is disabled.
[[!if test="enabled(listdirectives)" then="""
Here is a list of currently available directives in this wiki:
diff --git a/doc/ikiwiki/directive/cutpaste.mdwn b/doc/ikiwiki/directive/cutpaste.mdwn
index 012367bdf..ca580e54f 100644
--- a/doc/ikiwiki/directive/cutpaste.mdwn
+++ b/doc/ikiwiki/directive/cutpaste.mdwn
@@ -17,11 +17,11 @@ follow the paste directive that uses its text. In fact, this is quite useful
to postpone big blocks of text like long annotations and have a more natural
flow. For example:
- \[[!toggleable id="cut" text="\[[!paste id=cutlongdesc]]"]]
- \[[!toggleable id="copy" text="\[[!paste id=copylongdesc]]"]]
- \[[!toggleable id="paste" text="\[[!paste id=pastelongdesc]]"]]
+ \[[!toggleable id="cut" text="[[!paste id=cutlongdesc]]"]]
+ \[[!toggleable id="copy" text="[[!paste id=copylongdesc]]"]]
+ \[[!toggleable id="paste" text="[[!paste id=pastelongdesc]]"]]
- \[...some time later...]
+ [...some time later...]
\[[!cut id=cutlongdesc text="""
blah blah blah
@@ -40,7 +40,7 @@ Since you can paste without using double quotes, copy and paste can be used to
nest directives that require multiline parameters inside each other:
\[[!toggleable id=foo text="""
- \[[!toggleable id=bar text="\[[!paste id=baz]]"]]
+ [[!toggleable id=bar text="[[!paste id=baz]]"]]
"""]]
\[[!cut id=baz text="""
diff --git a/doc/ikiwiki/directive/format.mdwn b/doc/ikiwiki/directive/format.mdwn
new file mode 100644
index 000000000..94cf1b04f
--- /dev/null
+++ b/doc/ikiwiki/directive/format.mdwn
@@ -0,0 +1,21 @@
+The `format` directive is supplied by the [[!iki plugins/format desc=format]]
+plugin.
+
+The directive allows formatting a chunk of text using any available page
+format. It takes two parameters. First is the type of format to use,
+ie the extension that would be used for a standalone file of this type.
+Second is the text to format.
+
+For example, this will embed an otl outline inside a page using mdwn or
+some other format:
+
+ \[[!format otl """
+ foo
+ 1
+ 2
+ bar
+ 3
+ 4
+ """]]
+
+[[!meta robots="noindex, follow"]]
diff --git a/doc/ikiwiki/directive/inline.mdwn b/doc/ikiwiki/directive/inline.mdwn
index 9889cda11..f69d55de3 100644
--- a/doc/ikiwiki/directive/inline.mdwn
+++ b/doc/ikiwiki/directive/inline.mdwn
@@ -73,6 +73,8 @@ Here are some less often needed parameters:
configured to `allowatom`, set to "yes" to enable.
* `feeds` - controls generation of all types of feeds. Set to "no" to
disable generating any feeds.
+* `emptyfeeds` - Set to "no" to disable generation of empty feeds.
+ Has no effect if `rootpage` or `postform` is set.
* `template` - Specifies the template to fill out to display each inlined
page. By default the `inlinepage` template is used, while
the `archivepage` template is used for archives. Set this parameter to
@@ -85,7 +87,10 @@ Here are some less often needed parameters:
inlining page.
* `sort` - Controls how inlined pages are sorted. The default, "age" is to
sort newest created pages first. Setting it to "title" will sort pages by
- title, and "mtime" sorts most recently modified pages first.
+ title, and "mtime" sorts most recently modified pages first. If
+ [[!cpan Sort::Naturally]] is installed, `sort` can be set to "title_natural"
+ to sort by title with numbers treated as such ("1 2 9 10 20" instead of
+ "1 10 2 20 9").
* `reverse` - If set to "yes", causes the sort order to be reversed.
* `feedshow` - Specify the maximum number of matching pages to include in
the rss/atom feeds. The default is the same as the `show` value above.
@@ -97,11 +102,16 @@ Here are some less often needed parameters:
in the blog. The format string is passed to the strftime(3) function.
* `feedpages` - A [[PageSpec]] of inlined pages to include in the rss/atom
feeds. The default is the same as the `pages` value above, and only pages
- matches by that value are included, but some of those can be excluded by
+ matched by that value are included, but some of those can be excluded by
specifying a tighter [[PageSpec]] here.
* `guid` - If a URI is given here (perhaps a UUID prefixed with `urn:uuid:`),
the Atom feed will have this as its ``. The default is to use the URL
of the page containing the `inline` directive.
+* `feedfile` - Can be used to change the name of the file generated for the
+ feed. This is particularly useful if a page contains multiple feeds.
+ For example, set "feedfile=feed" to cause it to generate `page/feed.atom`
+ and/or `page/feed.rss`. This option is not supported if the wiki is
+ configured not to use `usedirs`.
[[!meta robots="noindex, follow"]]
diff --git a/doc/ikiwiki/directive/inline/discussion.mdwn b/doc/ikiwiki/directive/inline/discussion.mdwn
index 91b2ff462..e301190bf 100644
--- a/doc/ikiwiki/directive/inline/discussion.mdwn
+++ b/doc/ikiwiki/directive/inline/discussion.mdwn
@@ -19,3 +19,14 @@ take it as far as implementing "replies" to other comments.
## More dynamic `rootpage` parameter of inline plugin?
(Moved to [[todo/dynamic_rootpage]])
+
+---
+
+## Excluding Images
+
+Is there a simple way to exclude images, stylesheets, and other
+"non-page" files other than a blacklist approach like
+`pages="* and !*.png and !*.css"`? --[[JasonBlevins]]
+
+> The [[plugins/filecheck]] plugin adds a 'ispage()' pagespec test that can do that.
+> --[[Joey]]
diff --git a/doc/ikiwiki/directive/linkmap.mdwn b/doc/ikiwiki/directive/linkmap.mdwn
index 8fdf40c9f..db79a1491 100644
--- a/doc/ikiwiki/directive/linkmap.mdwn
+++ b/doc/ikiwiki/directive/linkmap.mdwn
@@ -9,7 +9,7 @@ Only links between mapped pages will be shown; links pointing to or from
unmapped pages will be omitted. If the pages to include are not specified,
the links between all pages (and other files) in the wiki are mapped. For
best results, only a small set of pages should be mapped, since otherwise
-the map can become very large, unweildy, and complicated. Also, the map is
+the map can become very large, unwieldy, and complicated. Also, the map is
rebuilt whenever one of the mapped pages is changed, which can make the
wiki a bit slow.
diff --git a/doc/ikiwiki/directive/meta.mdwn b/doc/ikiwiki/directive/meta.mdwn
index 74db31943..f29a118bf 100644
--- a/doc/ikiwiki/directive/meta.mdwn
+++ b/doc/ikiwiki/directive/meta.mdwn
@@ -139,6 +139,15 @@ Supported fields:
pages unchanged and avoid_flooding_aggregators
(see [[!iki tips/howto_avoid_flooding_aggregators]]).
+* updated
+
+ Specifies a fake modification time for a page, to be output into RSS and
+ Atom feeds. This is useful to avoid flooding aggregators that sort by
+ modification time, like Planet: for instance, when editing an old blog post
+ to add tags, you could set `updated` to be one second later than the original
+ value. The date/time can be given in any format that
+ [[!cpan TimeDate]] can understand, just like the `date` field.
+
If the field is not one of the above predefined fields, the metadata will be
written to the generated html page as a <meta> header. However, this
won't be allowed if the [[!iki plugins/htmlscrubber desc=htmlscrubber]] plugin is enabled,
diff --git a/doc/ikiwiki/directive/pagestats/discussion.mdwn b/doc/ikiwiki/directive/pagestats/discussion.mdwn
new file mode 100644
index 000000000..3c9dc7104
--- /dev/null
+++ b/doc/ikiwiki/directive/pagestats/discussion.mdwn
@@ -0,0 +1,10 @@
+I am trying to create a tag cloud using:
+
+ \[[!pagestats pages="tags/*"]]
+
+Nothing shows up when I first used this directive. I found that I had to create a page for the tag for it to show up in pagestats.
+I would rather not find and create a page for every tag I have created or will create. Is there an easier way to create a list of tags?
+
+Thanks
+
+----
diff --git a/doc/ikiwiki/directive/tag.mdwn b/doc/ikiwiki/directive/tag.mdwn
index 267aee660..64736f8cd 100644
--- a/doc/ikiwiki/directive/tag.mdwn
+++ b/doc/ikiwiki/directive/tag.mdwn
@@ -21,6 +21,10 @@ located under a base directory, such as "tags/". This is a useful way to
avoid having to write the full path to tags, if you want to keep them
grouped together out of the way.
+Bear in mind that specifying a tagbase means you will need to incorporate it
+into the `link()` [[ikiwiki/PageSpec]] you use: e.g., if your tagbase is
+`tag`, you would match pages tagged "foo" with `link(tag/foo)`.
+
If you want to override the tagbase for a particular tag, you can use
something like this:
diff --git a/doc/ikiwiki/directive/testpagespec/discussion.mdwn b/doc/ikiwiki/directive/testpagespec/discussion.mdwn
new file mode 100644
index 000000000..66c9a9ca9
--- /dev/null
+++ b/doc/ikiwiki/directive/testpagespec/discussion.mdwn
@@ -0,0 +1,6 @@
+How does one test a user identity? I tried "pagename and user(username) for the match, and had a "no user specified" error.
+
+> You can't test them with this directive, because such pagespecs test to
+> see if logged in user, who is performing some action, matches. When the
+> page with the directive is built, the concept of a user being logged in
+> doesn't really apply. --[[Joey]]
diff --git a/doc/ikiwiki/markdown.mdwn b/doc/ikiwiki/markdown.mdwn
index a4190945f..684191929 100644
--- a/doc/ikiwiki/markdown.mdwn
+++ b/doc/ikiwiki/markdown.mdwn
@@ -4,9 +4,7 @@ is a minimal markup language that resembles plain text as used in
email messages. It is the markup language used by this wiki by default.
For documentation about the markdown syntax, see [[formatting]] and
-[Markdown: syntax](http://daringfireball.net/projects/markdown/syntax). A
-[markdown mode](http://jblevins.org/projects/markdown-mode/) for
-emacs can help in editing.
+[Markdown: syntax](http://daringfireball.net/projects/markdown/syntax).
Note that [[WikiLinks|WikiLink]] and [[directives|directive]] are not part
of the markdown syntax, and are the only bit of markup that this wiki
diff --git a/doc/ikiwiki/pagespec.mdwn b/doc/ikiwiki/pagespec.mdwn
index c78666c40..b476bde1f 100644
--- a/doc/ikiwiki/pagespec.mdwn
+++ b/doc/ikiwiki/pagespec.mdwn
@@ -25,6 +25,7 @@ match all pages except for Discussion pages and the SandBox:
Some more elaborate limits can be added to what matches using these functions:
* "`link(page)`" - match only pages that link to a given page (or glob)
+* "`tagged(tag)`" - match pages that are tagged or link to the given tag (or glob)
* "`backlink(page)`" - match only pages that a given page links to
* "`creation_month(month)`" - match only pages created on the given month
* "`creation_day(mday)`" - or day of the month
@@ -47,6 +48,8 @@ Some more elaborate limits can be added to what matches using these functions:
wiki admins.
* "`ip(address)`" - tests whether a modification is being made from the
specified IP address.
+* "`postcomment(glob)`" - matches only when comments are being
+ posted to a page matching the specified glob
For example, to match all pages in a blog that link to the page about music
and were written in 2005:
@@ -63,29 +66,10 @@ More complex expressions can also be created, by using parentheses for
grouping. For example, to match pages in a blog that are tagged with either
of two tags, use:
- blog/* and (link(tag/foo) or link(tag/bar))
+ blog/* and (tagged(foo) or tagged(bar))
Note that page names in PageSpecs are matched against the absolute
filenames of the pages in the wiki, so a pagespec "foo" used on page
"a/b" will not match a page named "a/foo" or "a/b/foo". To match
relative to the directory of the page containing the pagespec, you can
use "./". For example, "./foo" on page "a/b" matches page "a/foo".
-
-## Old syntax
-
-The old PageSpec syntax was called a "GlobList", and worked differently in
-two ways:
-
-1. "and" and "or" were not used; any page matching any item from the list
- matched.
-2. If an item was prefixed with "`!`", then no page matching that item
- matched, even if it matched an earlier list item.
-
-For example, here is the old way to match all pages except for the SandBox
-and Discussion pages:
-
- * !SandBox !*/Discussion
-
-Using this old syntax is still supported. However, the old syntax is
-deprecated and will be removed at some point, and using the new syntax is
-recommended.
diff --git a/doc/ikiwiki/pagespec/attachment.mdwn b/doc/ikiwiki/pagespec/attachment.mdwn
index 2d33db748..344a4a734 100644
--- a/doc/ikiwiki/pagespec/attachment.mdwn
+++ b/doc/ikiwiki/pagespec/attachment.mdwn
@@ -9,7 +9,7 @@ configuration setting.
For example, to limit arbitrary files to 50 kilobytes, but allow
larger mp3 files to be uploaded by joey into a specific directory, and
-check all attachments for virii, something like this could be used:
+check all attachments for viruses, something like this could be used:
virusfree() and ((user(joey) and podcast/*.mp3 and mimetype(audio/mpeg) and maxsize(15mb)) or (!ispage() and maxsize(50kb)))
diff --git a/doc/ikiwiki/pagespec/discussion.mdwn b/doc/ikiwiki/pagespec/discussion.mdwn
index 0733c90c8..4eed3722c 100644
--- a/doc/ikiwiki/pagespec/discussion.mdwn
+++ b/doc/ikiwiki/pagespec/discussion.mdwn
@@ -65,3 +65,30 @@ How can I fix this? --[[sabr]]
> I don't see why that wouldn't work. Can I download the source to your
> wiki from somewhere to investigate? --[[Joey]]
+
+----
+
+Should negation work with user(), with locked_pages in setup? I
+experimented with setting locked_pages => 'user(someuser)' and was able to
+edit as a different user. However, setting locked_pages =>
+'!user(someuser)' doesn't seem to allow edits for only 'someuser' - it
+locks out all users.
+
+> Negation works with anything in any PageSpec. I tested the case you
+> describe, and a negated pagespec worked for me; all users except the
+> listed user (and except wiki admins of course) were locked out.
+> --[[Joey]]
+
+>> It must be a local problem, then, cause I've tried it with two separate
+>> machines. Both are running the most recent release of ikiwiki in
+>> pkgsrc - 2.66. Perhaps an update to a newer version would solve the issue.
+
+----
+
+Is there a way to refer to all subpages of the current page, if the name of the
+current page is not known (i.e. the pagespec is used in a template)? The ./ syntax
+does not seem suitable for this, as
+
+> \[[!map pages="./*"]]
+
+also lists the current page and all its siblings.
diff --git a/doc/ikiwiki/wikilink/discussion.mdwn b/doc/ikiwiki/wikilink/discussion.mdwn
index b5cb848ed..0677ff7de 100644
--- a/doc/ikiwiki/wikilink/discussion.mdwn
+++ b/doc/ikiwiki/wikilink/discussion.mdwn
@@ -51,6 +51,19 @@ simply write [[wikilink]]s like `\[[../bar]]` (or even just `\[[..]]`?), but
this doesn't work, so I had to resort to using `\[[foo/bar]]` instead.
--[[tschwinge]]
+> I believe, that doesn't entirely solve the problem. Just assume, your hierarchy is `/foo/bar/foo/bar`.
+
+> How do you access from the page `/foo/bar/foo/bar` the `/foo/bar` and not `/foo/bar/foo/bar`?
+
+> Do we have a way to implement `\[[../..]]` or `\[[/foo/bar]]`?
+
+> Even worse, trying to link from `/foo/bar` to `/foo/bar/foo/bar` ... this will probably need `\[[./foo/bar]]` --[[Jan|jwalzer]]
+
+>> There is no ".." syntax in wikilinks, but if the link begins with "/" it
+>> is rooted at the top of the wiki, as documented in
+>> [[subpage/linkingrules]]. Therefore, every example page name you listed
+>> above will work unchanged as a wikilink to that page! --[[Joey]]
+
----
How do I make images clickable? The obvious guess, \[[foo.png|/index]], doesn't work. --[[sabr]]
@@ -64,3 +77,5 @@ How do I make images clickable? The obvious guess, \[[foo.png|/index]], doesn't
Is it possible to refer to a page, say \[[foobar]], such that the link text is taken from foobar's title [[directive/meta]] tag? --Peter
> Not yet. :-) Any suggestion for a syntax for it? Maybe something like \[[|foobar]] ? --[[Joey]]
+
+I like your suggestion because it's short and conscise. However, it would be nice to be able to refer to more or less arbitrary meta tags in links, not just "title". To do that, the link needs two parameters: the page name and the tag name, i.e. \[[pagename!metatag]]. Any sufficiently weird separater can be used instead of '!', of course. I like \[[pagename->metatag]], too, because it reminds me of accessing a data member of a structure (which is what referencing a meta tag is, really). --Peter
diff --git a/doc/ikiwikiusers.mdwn b/doc/ikiwikiusers.mdwn
index e5f978e12..94ae75046 100644
--- a/doc/ikiwikiusers.mdwn
+++ b/doc/ikiwikiusers.mdwn
@@ -1,8 +1,7 @@
-Projects
-========
+Projects & Organizations
+========================
* [This wiki](http://ikiwiki.info) (of course!)
-* [UK Software Patents info page](http://www.softwarepatents.co.uk/)
* [Planet Debian upstream](http://updo.debian.net/)
* The [ion window manager homepage](http://modeemi.fi/~tuomov/ion/)
* [Debian Mentors wiki](http://jameswestby.net/mentors/)
@@ -22,7 +21,7 @@ Projects
* The [Debian Packaging Handbook project](http://packaging-handbook.alioth.debian.org/wiki/)
* The [libkdtree project](http://libkdtree.alioth.debian.org)
* The [pcc](http://pcc.ludd.ltu.se/) (Portable C Compiler) project. (Simple rcs backend)
-* [The TOVA Company](http://www.tovatest.com) public site. We also use it for internal documentation and issue tracking, all with a [[rcs/Git]] backend.
+* [The TOVA Company](http://www.tovatest.com) public site. We also use it for internal documentation and issue tracking, all with a [[rcs/Git]] backend.
* Technical support websites for [Homebase](http://support.homebase.dk) and [Kaospilotene](http://support.kaospilot.no) (each with [source](http://source.homebase.dk/) [provided](http://source.kaospilot.no/))
* [CampusGrün Hamburg](http://www.campusgruen.org/)
* The [awesome window manager homepage](http://awesome.naquadah.org/)
@@ -39,10 +38,18 @@ Projects
* [Chaos Computer Club Düsseldorf](https://www.chaosdorf.de)
* [monkeysphere](http://web.monkeysphere.info/)
* [The Walden Effect](http://www.waldeneffect.org/)
+* The [Fortran Wiki](http://fortranwiki.org/)
+* [Monotone](http://monotone.ca/wiki/FrontPage/)
+* The support pages for [Trinity Centre for High Performance Computing](http://www.tchpc.tcd.ie/support/)
+* [St Hugh of Lincoln Catholic Primary School in Surrey](http://www.sthugh-of-lincoln.surrey.sch.uk/)
+* [Pigro Network](http://www.pigro.net) is running a hg based ikiwiki. (And provides ikiwiki hosting for $10/m.)
+* [Cosin Homepage](http://cosin.ch) uses an Ikiwiki with a subversion repository.
+* [Bosco Free Orienteering Software](http://bosco.durcheinandertal.ch)
Personal sites and blogs
========================
+* [Skirv's Wiki](http://wiki.killfile.org) - formerly Skirv's Homepage
* [[Joey]]'s [homepage](http://kitenet.net/~joey/), including his weblog
* [Kyle's MacLea Genealogy wiki](http://kitenet.net/~kyle/family/wiki) and [Livingstone and MacLea Emigration Registry](http://kitenet.net/~kyle/family/registry)
* [Ulrik's personal web page](http://kaizer.se/wiki/)
@@ -100,11 +107,23 @@ Personal sites and blogs
* [Olivier Berger's professional homepage](http://www-public.it-sudparis.eu/~berger_o/)
* [Andrey Tarantsov's homepage](http://www.tarantsov.com/)
* [Don Marti's blog](http://zgp.org/~dmarti/)
-* [[JonDowland]]'s [homepage](http://jmtd.net/)
-
+* [[users/Jon]]'s [homepage](http://jmtd.net/)
+* [[xma]] is using ikiwiki ()
+* [[JanWalzer|jwalzer]]'s [homepage](http://wa.lzer.net/) -- Work in Progress
+* [[Adam_Trickett|ajt]]'s home intranet/sanbox system ([Internet site & blog](http://www.iredale.net/) -- not ikiwiki yet)
+* [[Simon_McVittie|smcv]]'s [website](http://www.pseudorandom.co.uk/) and
+ [blog](http://smcv.pseudorandom.co.uk/)
+* Svend's [website](http://www.ciffer.net/~svend/) and [blog](http://www.ciffer.net/~svend/blog/)
+* [muammar's site](http://muammar.me)
+* [Per Bothner's blog](http://per.bothner.com/blog/)
+* [Bernd Zeimetz (bzed)](http://bzed.de/)
+* [Gaudenz Steinlin](http://gaudenz.durcheinandertal.ch)
+* [Simon Kjika'qawej C.](http://simonraven.kisikew.org/ikiwiki/) Please note it might change location at any time (likely wiki.k.o or under /wiki/ at simonraven.k.o).
+
+
Please feel free to add your own ikiwiki site!
-See also: [Debian ikiwiki popcon graph](http://people.debian.org/~igloo/popcon-graphs/index.php?packages=ikiwiki)
+See also: [Debian ikiwiki popcon graph](http://popcon.debian.org/~igloo/popcon-graphs/index.php?packages=ikiwiki)
and [google search for ikiwiki powered sites](http://www.google.com/search?q=%22powered%20by%20ikiwiki%22).
While nothing makes me happier than knowing that ikiwiki has happy users, dropping some change in the [[TipJar]] is a nice way to show extra appreciation.
diff --git a/doc/ikiwikiusers/discussion.mdwn b/doc/ikiwikiusers/discussion.mdwn
index 2da3668d4..39a9bb921 100644
--- a/doc/ikiwikiusers/discussion.mdwn
+++ b/doc/ikiwikiusers/discussion.mdwn
@@ -29,3 +29,7 @@ Thanks, --[[Chao]]
Thanks for the reply Joey! ikiwiki is a fantastic wiki complier, though I do
not have my own machine momentarily, i will pay close attention to its development.
Hopefully I will be one of the ikiwiki users one day :) cheers --[[Chao]]
+
+----
+
+Are there automated hosting sites for ikiwiki yet? If you know one, can you add one in a new section on [[ikiwikiusers]] please? If you don't know any and you're willing to pay to set one up (shouldn't be much more expensive than a single ikiwiki IMO), [contact me](http://www.ttllp.co.uk/contact.html) and let's talk. -- MJR
diff --git a/doc/index/discussion.mdwn b/doc/index/discussion.mdwn
index 89e12e6c2..d52cb0a2d 100644
--- a/doc/index/discussion.mdwn
+++ b/doc/index/discussion.mdwn
@@ -288,6 +288,10 @@ easily, perl is possible (but I'm not strong in perl).
>>> It appears the scripts were never posted? I recently imported my Mediawiki site into Iki. If it helps, my notes are here: --[[sabr]]
+>>>>> The scripts have been posted now, see [[joshtriplett]]'s user page,
+>>>>> and I've pulled together all ways I can find to [[convert]] other
+>>>>> systems into ikiwiki. --[[Joey]]
+
----
# LaTeX support?
diff --git a/doc/index/openid/discussion.mdwn b/doc/index/openid/discussion.mdwn
new file mode 100644
index 000000000..ae614e5ac
--- /dev/null
+++ b/doc/index/openid/discussion.mdwn
@@ -0,0 +1,29 @@
+# OpenID discussion
+
+## No return_to in OpenID server
+
+Hi, there's no return_to from a designated OpenID server page, specs requires (I think a "should" or "must", can't recall exact wording) that it redirects back to the RP, in order to complete the registration and authentication. Unless I'm missing something, and the doc is incomplete, I'd consider this a bug. I don't expect to be of much use WRT coming up with a patch, but I'm willing to test ;-) .
+
+> If this is a bug, could you please explain:
+>
+> * What happens when the bug occurs?
+> * How can one reproduce the bug?
+>
+> PS, please file bugs under [[bugs]] in future. --[[Joey]]
+
+>> Oops, my bad, didn't know that existed at the time I wrote this.
+>>
+>> What happened is that the process wouldn't complete, therefore I couldn't login with my OpenID.
+>>
+>> reproducibility: every time
+>>
+>> Should probably move this page, eh? ;)
+>> I'd do that, but I dunno know other than using the SCM backend in question....
+
+Here's some actual output (with my OpenID URL stripped out):
+
+do=postsignin&oic.time=1238224497-1450566d93097caa707f&openid.assoc_handle=%7BHMAC-SHA1%7D%7B49cdce76%7D%7BBhuXXw%3D%3D%7D&openid.identity=|<==== MY OPENID URL GOES HERE ====>|&openid.mode=id_res&openid.op_endpoint=http%3A%2F%2Fwww.myopenid.com%2Fserver&openid.response_nonce=2009-03-28T07%3A15%3A02ZDUFmG3&openid.return_to=http%3A%2F%2Fsimonraven.kisikew.org%2Fbin%2Fikiwiki.cgi%3Fdo%3Dpostsignin%26oic.time%3D1238224497-1450566d93097caa707f&openid.sig=E51Xh6Gnjku%2B0se57qCyhHbT5QY%3D&openid.signed=assoc_handle%2Cidentity%2Cmode%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2Csigned
+
+The `return_to` arg should NOT be `signed`, it should be the originating URL where you initially logged in.
+
+Also, I dunno what the assoc_handle is doing spitting out an arg like `{HMAC-SHA1}{49cdce76}{BhuXXw%3D%3D}` it should be processed further. I have the needed perl packages installed (latest for Lenny). Hrm, would endianness matter?
diff --git a/doc/install.mdwn b/doc/install.mdwn
index d745737aa..cc3a4c29f 100644
--- a/doc/install.mdwn
+++ b/doc/install.mdwn
@@ -19,15 +19,6 @@ they are available.
Various [[plugins]] use other perl modules and utilities; see their individual
documentation for details.
-### Installing dependencies with yum
-
-Here's an example of how to install ikiwiki's dependencies using yum
-on Fedora 7:
-
- yum install perl-Text-Markdown perl-Mail-Sendmail perl-HTML-Scrubber \
- perl-XML-Simple perl-TimeDate perl-HTML-Template perl-CGI-FormBuilder \
- perl-CGI-Session perl-File-MimeInfo perl-gettext perl-Authen-Passphrase
-
### Installing dependencies by hand
If you want to install by hand from the tarball, you should make sure that
diff --git a/doc/install/discussion.mdwn b/doc/install/discussion.mdwn
index abe909a94..c1129a435 100644
--- a/doc/install/discussion.mdwn
+++ b/doc/install/discussion.mdwn
@@ -169,3 +169,62 @@ good. Date::Parse was already installed. --[[vibrog]]
usemymalloc=n, bincompat5005=undef
Not sure how to provide proper version information for you.--[[vibrog]]
+
+---
+
+I've tried a couple of times and my cpan has never recognised Bundle::IkiWiki. Is that section of the page still accurate? -- [[users/Jon]]
+
+> Are you running perl with the environemnt settings specified on the page?
+> Can you show how it fails to find the bundle? --[[Joey]]
+
+>> I was not. Next time I build I will have to try that (I'll need to tweak it as I already override PERL5LIB; also I need to specify http proxies). Thanks for your help! -- [[users/Jon]]
+
+---
+
+##Further problems with Bundle::IkiWiki
+I'm also having trouble with finding Bundle::IkiWiki. I've tried it with the environment settings and without them, and also using the interactive
+form of the cpan command. I've also gone to cpan.org and searched -- eg
+
+ http://search.cpan.org/search?query=ikiwiki&mode=all
+
+and no Bundle for IkiWiki comes up at all.
+
+The error I get from the various cpan attempts is basically always the same:
+
+ Warning: Cannot install Bundle::IkiWiki, don't know what it is.
+ Try the command
+
+ i /Bundle::IkiWiki/
+
+ to find objects with matching identifiers.
+
+When I try that command, BTW, it basically seems to find the same stuff I get when searching on the cpan web site.
+
+This happens both on Ubuntu 8.04 and CentOS 5.1
+
+Any help would be greatly appreciated... --kent
+
+> Bundle::IkiWiki is included in ikiwiki itself, so of course cpan.org
+> does not know about it.
+>
+> If you can show me exactly what command you ran (the tested, working
+> commands on the parent page?) and how it failed, I can try to debug
+> your problem.
+
+Just today I noticed the "Bundle" subdirectory. What a moron I am! :-) Also, I misunderstood the PERL5LIB=`pwd` part --
+I glibly thought it indicated the sink for the installation of the modules, rather than the source, and I was running
+the cpan command from another window in a different directory, and just spiraled down into error...
+
+> The real question in my mind is why you'd want to do this at all when
+> using Ubuntu, which incldues packages of ikiwiki and all its
+> dependencies. --[[Joey]]
+
+For ubuntu 8.04:
+
+ $ ikiwiki --version
+ ikiwiki version 2.32.3ubuntu2.1
+ $
+
+I was just trying to get the latest version.
+
+In any case, thanks for the help, and thanks for the superb software. I really like it a lot.
diff --git a/doc/news/code_swarm.mdwn b/doc/news/code_swarm.mdwn
index bdc373432..09b68523e 100644
--- a/doc/news/code_swarm.mdwn
+++ b/doc/news/code_swarm.mdwn
@@ -1,7 +1,7 @@
I've produced a [code_swarm](http://vis.cs.ucdavis.edu/~ogawa/codeswarm/)
visualization of the first 2+ years of ikiwiki's commit history.
-[[!img screenshot.png size="480x360"]]
+[[!img screenshot.png size="480x360" alt="screenshot"]]
* [15 mb avi](http://kitenet.net/~joey/screencasts/ikiwiki_swarm.avi)
* [stream on vimeo](http://vimeo.com/1324348)
diff --git a/doc/news/git_push_to_this_wiki.mdwn b/doc/news/git_push_to_this_wiki.mdwn
new file mode 100644
index 000000000..4b3fcbe69
--- /dev/null
+++ b/doc/news/git_push_to_this_wiki.mdwn
@@ -0,0 +1,3 @@
+Now you can use [[git]] to clone this wiki, and push your changes back,
+thanks to ikiwiki's new support for [[tips/untrusted_git_push]]. Enjoy
+working on the wiki while offline! --[[Joey]]
diff --git a/doc/news/git_push_to_this_wiki/discussion.mdwn b/doc/news/git_push_to_this_wiki/discussion.mdwn
new file mode 100644
index 000000000..33230c7ef
--- /dev/null
+++ b/doc/news/git_push_to_this_wiki/discussion.mdwn
@@ -0,0 +1,37 @@
+Thanks, Joey! This is awesome...I had to try it out :)
+--[[JasonBlevins]]
+
+I am really happy to hear of this new feature, that I was (more or less)
+secretly dreaming of. But - and that's why I'm still insanely editing
+this wiki inside a web browser - I wonder how I'll use it for real: my
+own master branch contains a few dozens merge commits, and one is created
+every time I `git pull` ikiwiki repository (or another clone of it, living
+on one of my other boxes that by chance had Internet access more recently).
+I do not want to clutter Joey's repository with these commits, so I guess
+I have to learn some more of Git everything-is-possible world (a nice thing
+is: I am not limited anymore to "Emacs can do it", and I'm now in a position
+to say "Git can do it" or "ikiwiki already does it", depending on the
+situation). Well, let's focus. Git wizards amongst us (let's use this wiki
+as if it were users@ikiwiki.info, ok?), what would you suggest? I was thinking
+of having a new branch in my cloned repository, dedicated to editing this wiki;
+I could use `rebase` instead of `fetch+merge` to get the new upstream commits
+into this special-purpose branch. I guess it would work nicely if I had only
+one offline box with not-yet-pushed changes at the same time, but would break
+in awful and various ways when it is not the case. Any alternative idea?
+--[[intrigeri]]
+
+> Not that I'm very careful to avoid pushing merge commits (see git log ;-),
+> but I sometimes use `git pull --rebase` to pull changes from a repo. That
+> will rebase your local changes on top of the changes pulled, avoiding the
+> merge commits. I'm sure more involved solutions are possible. --[[Joey]]
+
+> I decided to use my local `master` branch as a copy of `origin/master`
+> (kitenet) and move my local modifications to a separate branch. I'm using
+> `master` to edit the wiki but there is still the problem of new upstream
+> commits since the last pull. I already had this problem as Joey had pushed
+> some changes while I was editing locally. Not knowing about
+> `pull --rebase`, I took the long way out: branch, roll back HEAD, rebase,
+> and merge. That was too much work...It looks like `pull --rebase` is the
+> way to go. --[[JasonBlevins]]
+
+Awesome ! --[[xma]]
diff --git a/doc/news/ikiwiki_version_3.0.mdwn b/doc/news/ikiwiki_version_3.0.mdwn
new file mode 100644
index 000000000..7ca636cf2
--- /dev/null
+++ b/doc/news/ikiwiki_version_3.0.mdwn
@@ -0,0 +1,42 @@
+Ikiwiki has reached version 3.0 and entered a new phase in its
+[[development_cycle|roadmap]].
+
+The 3.0 release of ikiwiki changes several defaults and finishes
+some transitions. You will need to modify your wikis to work with
+ikiwiki 3.0. A document explaining the process is available
+in [[tips/upgrade_to_3.0]].
+
+The highlights of the changes in version 3.0 include:
+
+* Support for uploading [[attachments|plugins/attachment]].
+* Can [[plugins/rename]] and [[plugins/remove]] pages and files via the web.
+* [[Web_based_setup|plugins/websetup]].
+* Blog-style [[plugins/comments]] as an alternative to Discussion pages.
+* Many other new plugins including [[plugins/htmlbalance]], [[plugins/format]],
+ [[plugins/progress]], [[plugins/color]], [[plugins/autoindex]],
+ [[plugins/cutpaste]], [[plugins/hnb]], [[plugins/creole]], [[plugins/txt]],
+ [[plugins/amazon_s3]], [[plugins/pinger]], [[plugins/pingee]],
+ [[plugins/edittemplate]]
+* The RecentChanges page is compiled statically, not generated from the CGI.
+* Support for additional revision control systems: [[rcs/bzr]],
+ [[rcs/monotone]]
+* Support for [[tips/untrusted_git_push]].
+* A new version (3.00) of the plugin API, exporting additional
+ commonly used functions from `IkiWiki.pm`.
+* Nearly everything in ikiwiki is now a plugin, from WikiLinks to
+ page editing, to RecentChanges.
+* Far too many bug fixes, features, and enhancements to list here.
+
+Thanks to the many contributors to ikiwiki 3.0, including:
+
+ Jelmer Vernooij, Recai Oktaş, William Uther, Simon McVittie, Axel Beckert,
+ Bernd Zeimetz, Gabriel McManus, Paweł Tęcza, Peter Simons, Manoj
+ Srivastava, Patrick Winnertz, Jeremie Koenig, Josh Triplett, thm, Michael
+ Gold, Jason Blevins, Alexandre Dupas, Henrik Brix Andersen, Thomas Keller,
+ Enrico Zini, intrigeri, Scott Bronson, Brian May, Adeodato Simó, Brian
+ Downing, Nis Martensen. (And anyone I missed.)
+
+Also, thanks to the users, bug submitters, and documentation wiki editors.
+Without you, ikiwiki would just be a little thing I use for my home page.
+
+--[[Joey]]
diff --git a/doc/news/openid.mdwn b/doc/news/openid.mdwn
index ad76606aa..c2a871f0a 100644
--- a/doc/news/openid.mdwn
+++ b/doc/news/openid.mdwn
@@ -10,4 +10,4 @@ log back in, try out the OpenID signup process if you don't already have an
OpenID, and see how OpenID works for you. And let me know your feelings about
making such a switch. --[[Joey]]
-[[!poll 59 "Accept only OpenID for logins" 18 "Accept only password logins" 35 "Accept both"]]
+[[!poll 61 "Accept only OpenID for logins" 18 "Accept only password logins" 36 "Accept both"]]
diff --git a/doc/news/openid/discussion.mdwn b/doc/news/openid/discussion.mdwn
index 3d5e9dc22..aa9f3f0be 100644
--- a/doc/news/openid/discussion.mdwn
+++ b/doc/news/openid/discussion.mdwn
@@ -42,7 +42,7 @@ only Apache/iptables rules for this? Maybe it's related to
> Error: /srv/web/ikiwiki.info/todo/Configurable_minimum_length_of_log_message_for_web_edits/index.html independently created, not overwriting with version from todo/Configurable_minimum_length_of_log_message_for_web_edits
-[[jondowland]]
+[[users/jon]]
----
diff --git a/doc/news/version_2.62.1.mdwn b/doc/news/version_2.62.1.mdwn
deleted file mode 100644
index e82ccfa21..000000000
--- a/doc/news/version_2.62.1.mdwn
+++ /dev/null
@@ -1,3 +0,0 @@
-ikiwiki 2.62.1 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * filecheck: Fixed two bits broken in move from attachment."""]]
\ No newline at end of file
diff --git a/doc/news/version_2.63.mdwn b/doc/news/version_2.63.mdwn
deleted file mode 100644
index 165f60ceb..000000000
--- a/doc/news/version_2.63.mdwn
+++ /dev/null
@@ -1,21 +0,0 @@
-ikiwiki 2.63 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * Set cookies HttpOnly.
- * Typo. Closes: #[497003](http://bugs.debian.org/497003)
- * Ignore failure to install files into /etc, in case install is running as
- non-root.
- * Work around perl $\_ scoping nonsense that caused breakage when loading
- external plugins.
- * style.css: Add missing semicolon. Closes: #[497176](http://bugs.debian.org/497176)
- * filecheck: Fall back to testing for binary or plain text files
- if no mime type is detected.
- * table: Support header=column to make the table header be the first
- column of the data. (AlexandreDupas)
- * For fine control over what characters are allowed, unescaped in
- source filenames, the wiki\_file\_chars setting is added. For example,
- set to "-[:alnum:]+/.\_" to disable colons from being used in source files
- (which can cause troubl om Windows).
- * po/Makefile: update po files when the pot file has changed.
- Closes: #[497951](http://bugs.debian.org/497951)
- * editpage: New core plugin factoring out page editing to allow disabling it
- if desired."""]]
\ No newline at end of file
diff --git a/doc/news/version_2.64.mdwn b/doc/news/version_2.64.mdwn
deleted file mode 100644
index 137ca1a5c..000000000
--- a/doc/news/version_2.64.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-ikiwiki 2.64 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * Avoid uninitialised value when --dumpsetup is used and no srcdir/destdir
- specified.
- * ddate: Stop clobbering timeformat when not enabled.
- * progress: New plugin to generate progress bars (willu)
- * Add allow\_symlinks\_before\_srcdir to config so websetup doesn't eat it.
- * img: Support sizes like 200x. Closes: #[475149](http://bugs.debian.org/475149)
- * goodstuff: Remove otl plugin from the bundle since it needs a significant
- external dependency and is not commonly used. If you use otl, make sure
- you explicitly enable it now.
- * goodstuff: Add more, progress, and table plugins to the bundle.
- * Improve error message if external plugin fails to load. Closes: #[498458](http://bugs.debian.org/498458)
- * Directive documentation broken out of the plugin documentation and into
- pages suitable to be used as an underlay. Thanks to Willu for doing most
- of the tedious work.
- * Move the directive documentation into its own underlay, separate from
- basewiki, since it's sorta large compared to the rest of basewiki.
- * listdirectives: Enable use of the directives underlay.
- * Removed the obsolete blog page from the basewiki. ikiwiki/blog still
- remains, but is now deprecated too.
- * Removed old redirecton pages from basewiki (helponformatting,
- markdown, openid, pagespec, preprocessordirective, subpage, wikilink).
- * inline: Treat rootpage as a link, so that it can refer to a subpage
- without hardcoding the path."""]]
\ No newline at end of file
diff --git a/doc/news/version_2.65.mdwn b/doc/news/version_2.65.mdwn
deleted file mode 100644
index db6afd988..000000000
--- a/doc/news/version_2.65.mdwn
+++ /dev/null
@@ -1,25 +0,0 @@
-ikiwiki 2.65 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * aggregate: Expire excess or old items on the same pass that adds them,
- not only on subsequent passes.
- * editdiff: Broken since 2.62 due to wrong syntax, now fixed.
- * aggregate: Support atom feeds with only a summary element, and no content
- elements.
- * progress: Display an error if the progress cannot be parsed, and allow
- the percent parameter to only optionally end with "%".
- * Fix reversion in use of ikiwiki -verbose -setup with a setup file that
- enables syslog. Setup output is once again output to stdout in this
- case.
- * edittemplate: Default new page file type to the same type as the template.
- (willu)
- * edittemplate: Add "silent" parameter. (Willu)
- * edittemplate: Link to template, to allow creating it. (Willu)
- * editpage: Add a missing check that the page name contains only legal
- characters, in addition to the existing check for pruned filenames.
- * Print a debug message if a page has multiple source files.
- * Add keepextension parameter to htmlize hook. (Willu)
- * rename, remove: Don't rely on a form parameter to tell whether the page
- should be treated as an attachment.
- * rename: Add support for moving SubPages of a page when renaming it.
- (Sponsored by The TOVA Company.)
- * rename: Hide type field from rename form when renaming attachments."""]]
\ No newline at end of file
diff --git a/doc/news/version_2.66.mdwn b/doc/news/version_2.66.mdwn
deleted file mode 100644
index 029c7a1b9..000000000
--- a/doc/news/version_2.66.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-ikiwiki 2.66 released with [[!toggle text="these changes"]]
-[[!toggleable text="""
- * recentchanges: Fix redirects to non-page files.
- * aggregate: Avoid uninitialized value warnings for pages with no recorded
- ctime.
- * attachment: Add admin() pagespec to test if the uploading user is a wiki
- admin.
- * git: Fix handling of utf-8 filenames in recentchanges.
- * tag: Make edit link for new tags ensure that the tags are created
- inside tagbase, when it's set.
- * template: Make edit link for new templates ensure the page is located
- under toplevel templates directory.
- * htmlscrubber: Add a config setting that can be used to disable the
- scrubber acting on a set of pages.
- * Expand usage message and add --help. Closes: #[500344](http://bugs.debian.org/500344)
- * Beautify urls used in various places. (smcv)
- * Export pagetitle, titlepage, linkpage.
- * htmltidy: Avoid returning undef if tidy fails. Also avoid returning the
- untidied content if tidy crashes. In either case, it seems best to tidy
- the content to nothing.
- * htmltidy: Avoid spewing tidy errors to stderr.
- * Reorganize index file, add a format version field. Upgrades to the new
- index format should be transparent.
- * Add %wikistate, which is like %pagestate except not specific to a given
- page, and is preserved across rebuilds.
- * editpage: Be more aggressive (and less buggy) about cleaning up
- temporary files rendered during page preview.
- * Add an indexpages option, which causes foo/index.mdwn to be the source
- for page foo when foo.mdwn doesn't exist. Also, when it's enabled,
- creating a new page will save it to foo/index.mdwn by default.
- Closes: #[474611](http://bugs.debian.org/474611)
- (Sponsored by The TOVA Company.)
- * httpauth: Document that ikiwiki.cgi has to be in a directory subject to
- authentication. Closes: #[500524](http://bugs.debian.org/500524)
- * inline: Fix handling of rootpage that doesn't exist.
- * attachment: Support adding attachments to pages even as they are being
- created.
- * remove, rename: Allow acting on attachments as a page is being created.
- * Updated French translation. Closes: #[500929](http://bugs.debian.org/500929)"""]]
\ No newline at end of file
diff --git a/doc/news/version_2.68.mdwn b/doc/news/version_2.68.mdwn
new file mode 100644
index 000000000..b7e625026
--- /dev/null
+++ b/doc/news/version_2.68.mdwn
@@ -0,0 +1,44 @@
+ikiwiki 2.68 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Add support for checking pushes from untrusted git committers. This can be
+ used to set up anonymous git pushes, and other similar things.
+ * format: New plugin, allows embedding differently formatted text inside a
+ page (ie, otl inside a mdwn page, or syntax highlighted code inside a
+ page).
+ * relativedate: New javascript-alicious plugin that makes all dates display
+ relative, in a very nice way, if I say so myself.
+ * Optimise the no-op post-commit hook, to speed up web edits by a fraction
+ of a second.
+ * git: Allow [[sha1\_commit]] to be used in the diffurl, to support cgit.
+ * shortcut: Fix display of shortcuts while previewing.
+ * Plugins that used to override displaytime should instead override
+ formattime. displaytime will call that, and may wrap markup around the
+ formatted time.
+ * Add an underlay for javascript, and add ikiwiki.js containing some utility
+ code.
+ * toggle: Stop embedding the full toggle code on each page using it, and
+ move it to toggle.js in the javascript underlay.
+ * recentchanges: Make feed links point back to anchors on the recentchanges
+ page. (JasonBlevins)
+ * Fix issue with utf-8 in wikiname breaking session cookies, by
+ entity-encoding the wikiname in the session cookie.
+ * Use the pure perl Data::Dumper when generating setup files to ensure that
+ utf-8 characters are written out as such, and not as the encoded perl
+ strings the C Data::Dumper produces.
+ * inline: Only the last feed link was put on the page, fix this to include
+ all feed links. So rss will be included along with atom, and pages with
+ multiple feeds will get links added for all feeds.
+ * tag: When tagpage is set, force the links created by tagging to point at
+ the toplevel tagpage, and not closer subpages. The html links already went
+ there, but internally the links were not recorded as absolute, which could
+ cause confusing backlinks etc.
+ * Add an inject function, that can be used by plugins that want to
+ replace one of ikiwiki's functions with their own version.
+ (This is a scary thing that grubs through the symbol table, and replaces
+ all exported occurances of a function with the injected version.)
+ * external: RPC functions can be injected to replace exported functions.
+ * Updated French translation. Closes: #[502694](http://bugs.debian.org/502694)
+ * Updated Spanish translation from the ever vigilant Victor Moral.
+ * Updated Danish translation from Jonas Smedegaard. Closes: #[503117](http://bugs.debian.org/503117)
+ * Preserve syslog setting when doing `ikiwiki -setup foo -dumpsetup bar`
+ * Several fixes to --render mode."""]]
\ No newline at end of file
diff --git a/doc/news/version_2.69.mdwn b/doc/news/version_2.69.mdwn
new file mode 100644
index 000000000..a277541fe
--- /dev/null
+++ b/doc/news/version_2.69.mdwn
@@ -0,0 +1,24 @@
+ikiwiki 2.69 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Avoid multiple ikiwiki cgi processes piling up, eating all memory,
+ and thrashing, by making the cgi wrapper wait on a cgilock.
+ If you had to set apache's MaxClients low to avoid ikiwiki thrashing your
+ server, you can now turn it up to a high value.
+ * Stop busy-waiting in lockwiki, as this could delay ikiwiki from waking up
+ for up to one second. The bailout code is no longer needed after above
+ change.
+ * Remove support for unused optional wait parameter from lockwiki.
+ * aggregate: Try to query XML::Feed for the base url when derelevatising
+ links. Since this needs the just released XML::Feed 0.3, as well
+ as a not yet released XML::RSS, it will fall back to the old method
+ if no xml:base info is available.
+ * meta: Plugin is now enabled by default since the basewiki uses it.
+ * txt: Do not encode quotes when filtering the txt, as that broke
+ later parsing of any directives on the page.
+ * Fix the link() pagespec to match links that are internally recorded as
+ absolute.
+ * Add rel=nofollow to recentchanges\_links for the same (weak) reasons it
+ was earlier added to edit links.
+ * tag: Normalize tagbase so leading/trailing slashes in it don't break
+ things.
+ * bzr: Fix dates for recentchanges."""]]
\ No newline at end of file
diff --git a/doc/news/version_2.70.mdwn b/doc/news/version_2.70.mdwn
new file mode 100644
index 000000000..f0830efa1
--- /dev/null
+++ b/doc/news/version_2.70.mdwn
@@ -0,0 +1,3 @@
+ikiwiki 2.70 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Avoid crash on malformed utf-8 discovered by intrigeri."""]]
\ No newline at end of file
diff --git a/doc/news/version_2.71.mdwn b/doc/news/version_2.71.mdwn
new file mode 100644
index 000000000..2c8609988
--- /dev/null
+++ b/doc/news/version_2.71.mdwn
@@ -0,0 +1,28 @@
+ikiwiki 2.71 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * comments: Blog-style comment support, contributed by Simon McVittie.
+ * htmlbalance: New plugin contributed by Simon McVittie.
+ * Change deb dependencies to list Text::Markdown before markdown (really
+ this time).
+ * Improve escaping of wikilinks and preprocessor directives in content
+ produced by aggregate and recentchanges.
+ * French translation update from Philippe Batailler. Closes: #[506250](http://bugs.debian.org/506250)
+ * Spanish translation update from Victor Moral.
+ * Fix handling of wrappergroup option.
+ * Correct --dumpsetup to include the srcdir in the setup file.
+ * German translation update from Kai Wasserbäch. Closes: #[507056](http://bugs.debian.org/507056)
+ * inline: Support emptyfeeds=no option to skip generating empty feeds.
+ * inline: Support feedfile option to change the filename of the feed
+ generated.
+ * meta: Pass info to htmlscrubber so htmlscrubber\_skip can take effect.
+ * htmlbalance: don't compact whitespace, and set misc other options (smcv)
+ * rename: Fix double-escaping of page name in edit box.
+ * monotone: When getting the log, tell monotone how many entries
+ we want, rather than closing the pipe, which it dislikes. (thm)
+ * Coding style change: Remove explcit vim folding markers.
+ * aggregate: If a feed fails to be downloaded, try again immediatly
+ next time aggregation is run, even if the usual time has not passed.
+ Closes: #[508622](http://bugs.debian.org/508622) (Michael Gold)
+ * meta: Process meta date during scan pass so that the date will always
+ affect sorting in inlines.
+ * Improve display of some openids (smcv)"""]]
\ No newline at end of file
diff --git a/doc/news/version_2.72.mdwn b/doc/news/version_2.72.mdwn
new file mode 100644
index 000000000..26274a3c8
--- /dev/null
+++ b/doc/news/version_2.72.mdwn
@@ -0,0 +1,9 @@
+ikiwiki 2.72 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * Avoid comments in recentchanges being broken links (smcv)
+ * Add deprecation warning for GlobLists, which will stop working in 3.0.
+ * camelcase: Add camelcase\_ignore setting.
+ * googlecalendar: Add runtime deprecation warning.
+ * comments: Deal with users entering unqualified or partial urls.
+ * inline: Run format hook first, to ensure other format hooks can affect
+ inlined content. Closes: #[509710](http://bugs.debian.org/509710)"""]]
\ No newline at end of file
diff --git a/doc/news/version_3.09.mdwn b/doc/news/version_3.09.mdwn
new file mode 100644
index 000000000..d5e1a6545
--- /dev/null
+++ b/doc/news/version_3.09.mdwn
@@ -0,0 +1,16 @@
+ikiwiki 3.09 released with [[!toggle text="these changes"]]
+[[!toggleable text="""
+ * inline: Add title\_natural sort order, using Sort::Naturally
+ (chrysn)
+ * inline: Fix urls to feed when feedfile is used on an index page.
+ * git, mercurial: Fix --getctime to return file creation time,
+ not last commit time.
+ * Updated French translation (Jean-Luc Coulon). Closes: #[521072](http://bugs.debian.org/521072)
+ * css: Add clear: both to inlinefooter.
+ * comments: Fix too loose test for comments pages that matched
+ normal pages with "comment\_" in their name. Closes: #[521322](http://bugs.debian.org/521322)
+ * comments: Fix anchor ids to be legal xhtml. Closes: #[521339](http://bugs.debian.org/521339)
+ * Fix documentation of anonok\_pagespec. Closes: #[521793](http://bugs.debian.org/521793)
+ * Add missing suggests on libtext-textile-perl. Closes: #[522039](http://bugs.debian.org/522039)
+ * recentchanges: change to using do=goto links for user links.
+ * Fix git test suite to use a bare repo."""]]
\ No newline at end of file
diff --git a/doc/pagehistory.mdwn b/doc/pagehistory.mdwn
index fc2a3f543..465062736 100644
--- a/doc/pagehistory.mdwn
+++ b/doc/pagehistory.mdwn
@@ -3,3 +3,6 @@ revison history of a page. This is enabled by the `historyurl` setting,
which is used to specify the URL to a web interface such as [[ViewVC]]
(for Subversion) or [[Gitweb]]. In that url, "\[[file]]" is replaced with
the name of the file to view.
+
+The [[plugins/repolist]] plugin can suppliment this information with
+urls to the underlying repository of the wiki.
diff --git a/doc/plugins/404.mdwn b/doc/plugins/404.mdwn
new file mode 100644
index 000000000..ad332ee04
--- /dev/null
+++ b/doc/plugins/404.mdwn
@@ -0,0 +1,20 @@
+[[!template id=plugin name=404 author="[[Simon_McVittie|smcv]]"]]
+[[!tag type/useful]]
+
+This plugin lets you use the IkiWiki CGI script as an Apache 404 handler,
+to give the behaviour of various other wiki engines where visiting a
+nonexistent page provides you with a link to create it.
+
+To achieve this, put something like this in the wiki's Apache configuration
+file:
+
+ ErrorDocument 404 /ikiwiki.cgi
+
+(The path here needs to be whatever the path is to the ikiwiki.cgi from
+the root of your web server.)
+
+Or put something like this in the wiki's Lighttpd (>=1.4.17) configuration file:
+
+ server.error-handler-404 = "/ikiwiki.cgi"
+
+
diff --git a/doc/plugins/aggregate.mdwn b/doc/plugins/aggregate.mdwn
index c40a6dc22..e2efcd83f 100644
--- a/doc/plugins/aggregate.mdwn
+++ b/doc/plugins/aggregate.mdwn
@@ -5,13 +5,9 @@ This plugin allows content from other feeds to be aggregated into the
wiki. To specify feeds to aggregate, use the
[[ikiwiki/directive/aggregate]] [[ikiwiki/directive]].
-New users of aggregate should enable the `aggregateinternal => 1` option in the
-.setup file. If you don't do so, you will need to enable the [[html]] plugin
-as well as aggregate itself, since feed entries will be stored as HTML.
-
-The [[meta]] and [[tag]] plugins are also recommended. The
-[[htmltidy]] plugin is suggested, since feeds can easily contain html
-problems, some of which tidy can fix.
+The [[meta]] and [[tag]] plugins are also recommended. Either the
+[[htmltidy]] or [[htmlbalance]] plugin is suggested, since feeds can easily
+contain html problems, some of which these plugins can fix.
You will need to run ikiwiki periodically from a cron job, passing it the
--aggregate parameter, to make it check for new posts. Here's an example
@@ -27,37 +23,19 @@ visit is `http://whatever/ikiwiki.cgi?do=aggregate_webtrigger`. Anyone
can visit the url to trigger an aggregation run, but it will only check
each feed if its `updateinterval` has passed.
-## internal pages and `aggregateinternal`
+## aggregated pages
This plugin creates a page for each aggregated item.
If the `aggregateinternal` option is enabled in the setup file (which is
-recommended), aggregated pages are stored in the source directory with a
+the default), aggregated pages are stored in the source directory with a
"._aggregated" extension. These pages cannot be edited by web users, and
do not generate first-class wiki pages. They can still be inlined into a
blog, but you have to use `internal` in [[PageSpecs|IkiWiki/PageSpec]],
like `internal(blog/*)`.
-For backward compatibility, the default is that these pages have the
-".html" extension, and are first-class wiki pages -- each one generates
-a separate HTML page in the output, and they can even be edited.
-
-That turns out to not be ideal for aggregated content, because publishing
-files for each of those pages is a waste of disk space and CPU, and you
-probably don't want to allow them to be edited. So, there is an alternative
-method that can be used (and is recommended), turned on by the
-`aggregateinternal` option in the setup file.
-
-If you are already using aggregate and want to enable `aggregateinternal`,
-you should follow this process:
-
-1. Update all [[PageSpecs|ikiwiki/PageSpec]] that refer to the aggregated
- pages -- such as those in inlines. Put "internal()" around globs
- in those PageSpecs. For example, if the PageSpec was `foo/*`, it should
- be changed to `internal(foo/*)`. This has to be done because internal
- pages are not matched by regular globs.
-2. Turn on `aggregateinternal` in the setup file.
-3. Use [[ikiwiki-transition]] to rename all existing aggregated `.html`
- files in the srcdir. The command to run is
- `ikiwiki-transition aggregateinternal $setupfile`,
-4. Refresh the wiki. (`ikiwiki -setup your.setup -refresh`)
+If `aggregateinternal` is disabled, you will need to enable the [[html]]
+plugin as well as aggregate itself, since feed entries will be stored as
+HTML, and as first-class wiki pages -- each one generates
+a separate HTML page in the output, and they can even be edited. This
+option is provided only for backwards compatability.
diff --git a/doc/plugins/aggregate/discussion.mdwn b/doc/plugins/aggregate/discussion.mdwn
index 1db6240d5..1a9844577 100644
--- a/doc/plugins/aggregate/discussion.mdwn
+++ b/doc/plugins/aggregate/discussion.mdwn
@@ -35,7 +35,7 @@ Two things aren't working as I'd expect:
> problem. You can see the feed validator complain about it here:
>
>
-> It's sorta unfortunate that [[cpan XML::Feed]] doesn't just assume the
+> It's sorta unfortunate that [[!cpan XML::Feed]] doesn't just assume the
> un-esxaped html is part of the description field. Probably other feed
> parsers are more lenient. --[[Joey]]
diff --git a/doc/plugins/anonok.mdwn b/doc/plugins/anonok.mdwn
index 2a8a922cd..a3fec4d89 100644
--- a/doc/plugins/anonok.mdwn
+++ b/doc/plugins/anonok.mdwn
@@ -7,3 +7,8 @@ by default.
The plugin also has a configuration setting, `anonok_pagespec`. This
[[PageSpec]] can be used to allow anonymous editing of matching pages.
+
+If you're using the [[comments]] plugin, you can allow anonymous comments
+to be posted by setting:
+
+ anonok_pagespec => "postcomment(*)"
diff --git a/doc/plugins/autoindex/discussion.mdwn b/doc/plugins/autoindex/discussion.mdwn
new file mode 100644
index 000000000..82e30aab1
--- /dev/null
+++ b/doc/plugins/autoindex/discussion.mdwn
@@ -0,0 +1,7 @@
+Would it be possible to add an option to only generate the index files
+for the html output and not place the markdown files in the wiki source?
+
+The reason being that I have a lot of directories which need to be autoindexed,
+but I would prefer if the index files didn't clutter up my git repository.
+
+even without that feature the plugin is a great help, thanks
diff --git a/doc/plugins/blogspam.mdwn b/doc/plugins/blogspam.mdwn
new file mode 100644
index 000000000..1d152faac
--- /dev/null
+++ b/doc/plugins/blogspam.mdwn
@@ -0,0 +1,26 @@
+[[!template id=plugin name=blogspam author="[[Joey]]"]]
+[[!tag type/auth]]
+
+This plugin adds antispam support to ikiwiki, using the
+[blogspam.net](http://blogspam.net/) API. Both page edits and
+[[comment|comments]] postings can be checked for spam. Page edits that
+appear to contain spam will be rejected; comments that look spammy will be
+stored in a queue for moderation by an admin.
+
+The plugin requires the [[!cpan RPC::XML]] perl module.
+
+You can control how content is tested via the `blogspam_options` setting.
+The list of options is [here](http://blogspam.net/api/testComment.html#options).
+By default, the options are configured in a way that is appropriate for
+wiki content. This includes turning off some of the more problimatic tests.
+
+The `blogspam_pagespec` setting is a [[ikiwiki/PageSpec]] that can be
+used to configure which pages are checked for spam. The default is to check
+all edits. If you only want to check [[comments]] (not wiki page edits),
+set it to "postcomment(*)".
+
+By default, the blogspam.net server is used to do the spam checking. To
+change this, the `blogspam_server` option can be set to the url for a
+different server implementing the same API. Note that content is sent
+unencrypted over the internet to the server, and the server sees
+the full text of the content.
diff --git a/doc/plugins/calendar.mdwn b/doc/plugins/calendar.mdwn
index c9e95ce7e..d695762b7 100644
--- a/doc/plugins/calendar.mdwn
+++ b/doc/plugins/calendar.mdwn
@@ -6,7 +6,7 @@ The directive displays a calendar, similar to the typical calendars shown on
some blogs.
Since ikiwiki is a wiki compiler, to keep the calendar up-to-date,
-wikis that include it need to be preiodically refreshes, typically by cron
+wikis that include it need to be periodically refreshes, typically by cron
at midnight. Example crontab:
0 0 * * * ikiwiki -setup ~/ikiwiki.setup -refresh
diff --git a/doc/plugins/calendar/discussion.mdwn b/doc/plugins/calendar/discussion.mdwn
index 65c2459c6..9d57b7a1e 100644
--- a/doc/plugins/calendar/discussion.mdwn
+++ b/doc/plugins/calendar/discussion.mdwn
@@ -1,2 +1,6 @@
It would be nice if the "month" type calendar could collect all of the
matching pages on a given date in some inline type way. --[[DavidBremner]]
+
+Is it possible to get the calendar to link to pages based not on their timestamp (as I understand that it does now, or have I misunderstood this?) and instead on for example their location in a directory hierarchy. That way the calendar could be used as a planning / timeline device which I think would be great. --[[Alexander]]
+
+I would like the ability to specify relative previous months. This way I could have a sidebar with the last three months by specifying no month, then 'month="-1"' and 'month="-2"'. Negative numbers for the month would otherwise be invalid, so this shouldn't produce any conflicts with expected behavior. (Right?) -- [[StevenBlack]]
diff --git a/doc/plugins/comments.mdwn b/doc/plugins/comments.mdwn
new file mode 100644
index 000000000..c13a6daa6
--- /dev/null
+++ b/doc/plugins/comments.mdwn
@@ -0,0 +1,52 @@
+[[!template id=plugin name=comments author="[[Simon_McVittie|smcv]]"]]
+[[!tag type/useful]]
+
+This plugin adds "blog-style" comments. Unlike the wiki-style freeform
+Discussion pages, these comments are posted by a simple form, cannot later
+be edited, and rss/atom feeds are provided of each page's comments.
+
+When using this plugin, you should also enable [[htmlscrubber]] and either
+[[htmltidy]] or [[htmlbalance]]. Directives are filtered out by default, to
+avoid commenters slowing down the wiki by causing time-consuming
+processing. As long as the recommended plugins are enabled, comment
+authorship should hopefully be unforgeable by CGI users.
+
+The intention is that on a non-wiki site (like a blog) you can lock all
+pages for admin-only access, then allow otherwise unprivileged (or perhaps
+even anonymous) users to comment on posts. See the documentation of the
+[[lockedit]] and [[anonok]] pages for details on locking down a wiki so
+users can only post comments.
+
+Individual comments are stored as internal-use pages named something like
+`page/comment_1`, `page/comment_2`, etc. These pages internally use a
+`\[[!_comment]]` [[ikiwiki/directive]].
+
+There are some global options for the setup file:
+
+* `comments_pagespec`: [[ikiwiki/PageSpec]] of pages where comments are
+ allowed. The default is not to allow comments on any pages. To allow
+ comments to all posts to a blog, you could use
+ `blog/posts/* and !*/Discussion`.
+* `comments_closed_pagespec`: [[ikiwiki/PageSpec]] of pages where
+ posting of new comments is closed, but any existing comments will still
+ be displayed. Often you will list a set of individual pages here.
+ For example: `blog/controversial or blog/flamewar`
+* `comments_pagename`: if this is e.g. `comment_` (the default), then
+ comment pages will be named something like `page/comment_12`
+* `comments_allowdirectives`: if true (default false), comments may
+ contain IkiWiki [[directives|ikiwiki/directive]]
+* `comments_commit`: if true (default true), comments will be committed to
+ the version control system
+* `comments_allowauthor`: if true (default false), anonymous commenters may
+ specify a name for themselves, and the \[[!meta author]] and
+ \[[!meta authorurl]] directives will not be overridden by the comments
+ plugin
+
+## comment moderation
+
+If you enable the [[blogspam]] plugin, comments that appear spammy will be
+held for moderation. Wiki admins can access the comment moderation queue
+via a button on their Preferences page.
+
+The comments are stored in `.ikiwiki/comments_pending/`, and can be
+deleted, or moved into the wiki's srcdir to be posted.
diff --git a/doc/plugins/comments/discussion.mdwn b/doc/plugins/comments/discussion.mdwn
new file mode 100644
index 000000000..3d7452b9a
--- /dev/null
+++ b/doc/plugins/comments/discussion.mdwn
@@ -0,0 +1,163 @@
+## Why internal pages? (unresolved)
+
+Comments are saved as internal pages, so they can never be edited through the CGI,
+only by direct committers.
+
+> So, why do it this way, instead of using regular wiki pages in a
+> namespace, such as `$page/comments/*`? Then you could use [[plugins/lockedit]] to
+> limit editing of comments in more powerful ways. --[[Joey]]
+
+>> Er... I suppose so. I'd assumed that these pages ought to only exist as inlines
+>> rather than as individual pages (same reasoning as aggregated posts), though.
+>>
+>> lockedit is actually somewhat insufficient, since `check_canedit()`
+>> doesn't distinguish between creation and editing; I'd have to continue to use
+>> some sort of odd hack to allow creation but not editing.
+>>
+>> I also can't think of any circumstance where you'd want a user other than
+>> admins (~= git committers) and possibly the commenter (who we can't check for
+>> at the moment anyway, I don't think?) to be able to edit comments - I think
+>> user expectations for something that looks like ordinary blog comments are
+>> likely to include "others can't put words into my mouth".
+>>
+>> My other objection to using a namespace is that I'm not particularly happy about
+>> plugins consuming arbitrary pieces of the wiki namespace - /discussion is bad
+>> enough already. Indeed, this very page would accidentally get matched by rules
+>> aiming to control comment-posting... :-) --[[smcv]]
+
+>>> Thinking about it, perhaps one way to address this would be to have the suffix
+>>> (e.g. whether commenting on Sandbox creates sandbox/comment1 or sandbox/c1 or
+>>> what) be configurable by the wiki admin, in the same way that recentchanges has
+>>> recentchangespage => 'recentchanges'? I'd like to see fewer hard-coded page
+>>> names in general, really - it seems odd to me that shortcuts and smileys
+>>> hard-code the name of the page to look at. Perhaps I could add
+>>> discussionpage => 'discussion' too? --[[smcv]]
+
+>>> (I've now implemented this in my branch. --[[smcv]])
+
+>> The best reason to keep the pages internal seems to me to be that you
+>> don't want the overhead of every comment spawning its own wiki page. --[[Joey]]
+
+## Formats (resolved)
+
+The plugin now allows multiple comment formats while still using internal
+pages; each comment is saved as a page containing one `\[[!comment]]` directive,
+which has a superset of the functionality of [[ikiwiki/directives/format]].
+
+## Access control (unresolved?)
+
+By the way, I think that who can post comments should be controllable by
+the existing plugins opendiscussion, anonok, signinedit, and lockedit. Allowing
+posting comments w/o any login, while a nice capability, can lead to
+spam problems. So, use `check_canedit` as at least a first-level check?
+--[[Joey]]
+
+> This plugin already uses `check_canedit`, but that function doesn't have a concept
+> of different actions. The hack I use is that when a user comments on, say, sandbox,
+> I call `check_canedit` for the pseudo-page "sandbox[postcomment]". The
+> special `postcomment(glob)` [[ikiwiki/pagespec]] returns true if the page ends with
+> "[postcomment]" and the part before (e.g. sandbox) matches the glob. So, you can
+> have postcomment(blog/*) or something. (Perhaps instead of taking a glob, postcomment
+> should take a pagespec, so you can have postcomment(link(tags/commentable))?)
+>
+> This is why `anonok_pagespec => 'postcomment(*)'` and `locked_pages => '!postcomment(*)'`
+> are necessary to allow anonymous and logged-in editing (respectively).
+>
+>> I changed that to move the flag out of the page name, and into a variable that the `match_postcomment`
+>> function checks for. Other ugliness still applies. :-) --[[Joey]]
+>
+> This is ugly - one alternative would be to add `check_permission()` that takes a
+> page and a verb (create, edit, rename, remove and maybe comment are the ones I
+> can think of so far), use that, and port the plugins you mentioned to use that
+> API too. This plugin could either call `check_can("$page/comment1", 'create')` or
+> call `check_can($page, 'comment')`.
+>
+> One odd effect of the code structure I've used is that we check for the ability to
+> create the page before we actually know what page name we're going to use - when
+> posting the comment I just increment a number until I reach an unused one - so
+> either the code needs restructuring, or the permission check for 'create' would
+> always be for 'comment1' and never 'comment123'. --[[smcv]]
+
+>> Now resolved, in fact --[[smcv]]
+
+> Another possibility is to just check for permission to edit (e.g.) `sandbox/comment1`.
+> However, this makes the "comments can only be created, not edited" feature completely
+> reliant on the fact that internal pages can't be edited. Perhaps there should be a
+> `editable_pages` pagespec, defaulting to `'*'`? --[[smcv]]
+
+## comments directive vs global setting (resolved?)
+
+When comments have been enabled generally, you still need to mark which pages
+can have comments, by including the `\[[!comments]]` directive in them. By default,
+this directive expands to a "post a comment" link plus an `\[[!inline]]` with
+the comments. [This requirement has now been removed --[[smcv]]]
+
+> I don't like this, because it's hard to explain to someone why they have
+> to insert this into every post to their blog. Seems that the model used
+> for discussion pages could work -- if comments are enabled, automatically
+> add the comment posting form and comments to the end of each page.
+> --[[Joey]]
+
+>> I don't think I'd want comments on *every* page (particularly, not the
+>> front page). Perhaps a pagespec in the setup file, where the default is "*"?
+>> Then control freaks like me could use "link(tags/comments)" and tag pages
+>> as allowing comments.
+>>
+>>> Yes, I think a pagespec is the way to go. --[[Joey]]
+
+>>>> Implemented --[[smcv]]
+
+>>
+>> The model used for discussion pages does require patching the existing
+>> page template, which I was trying to avoid - I'm not convinced that having
+>> every possible feature hard-coded there really scales (and obviously it's
+>> rather annoying while this plugin is on a branch). --[[smcv]]
+
+>>> Using the template would allow customising the html around the comments
+>>> which seems like a good thing? --[[Joey]]
+
+>>>> The \[[!comments]] directive is already template-friendly - it expands to
+>>>> the contents of the template `comments_embed.tmpl`, possibly with the
+>>>> result of an \[[!inline]] appended. I should change `comments_embed.tmpl`
+>>>> so it uses a template variable `INLINE` for the inline result rather than
+>>>> having the perl code concatenate it, which would allow a bit more
+>>>> customization (whether the "post" link was before or after the inline).
+>>>> Even if you want comments in page.tmpl, keeping the separate comments_embed.tmpl
+>>>> and having a `COMMENTS` variable in page.tmpl might be the way forward,
+>>>> since the smaller each templates is, the easier it will be for users
+>>>> to maintain a patched set of templates. (I think so, anyway, based on what happens
+>>>> with dpkg prompts in Debian packages with monolithic vs split
+>>>> conffiles.) --[[smcv]]
+
+>>>>> I've switched my branch to use page.tmpl instead; see what you think? --[[smcv]]
+
+## Raw HTML (resolved?)
+
+Raw HTML was not initially allowed by default (this was configurable).
+
+> I'm not sure that raw html should be a problem, as long as the
+> htmlsanitizer and htmlbalanced plugins are enabled. I can see filtering
+> out directives, as a special case. --[[Joey]]
+
+>> Right, if I sanitize each post individually, with htmlscrubber and either htmltidy
+>> or htmlbalance turned on, then there should be no way the user can forge a comment;
+>> I was initially wary of allowing meta directives, but I think those are OK, as long
+>> as the comment template puts the \[[!meta author]] at the *end*. Disallowing
+>> directives is more a way to avoid commenters causing expensive processing than
+>> anything else, at this point.
+>>
+>> I've rebased the plugin on master, made it sanitize individual posts' content
+>> and removed the option to disallow raw HTML. Sanitizing individual posts before
+>> they've been htmlized required me to preserve whitespace in the htmlbalance
+>> plugin, so I did that. Alternatively, we could htmlize immediately and always
+>> save out raw HTML? --[[smcv]]
+
+>>> There might be some use cases for other directives, such as img, in
+>>> comments.
+>>>
+>>> I don't know if meta is "safe" (ie, guaranteed to be inexpensive and not
+>>> allow users to do annoying things) or if it will continue to be in the
+>>> future. Hard to predict really, all that can be said with certainty is
+>>> all directives will contine to be inexpensive and safe enough that it's
+>>> sensible to allow users to (ab)use them on open wikis.
+>>> --[[Joey]]
diff --git a/doc/plugins/contrib.mdwn b/doc/plugins/contrib.mdwn
index 7a28edaba..e22b13f71 100644
--- a/doc/plugins/contrib.mdwn
+++ b/doc/plugins/contrib.mdwn
@@ -2,6 +2,6 @@ Contributed [[plugins]]:
(See [[install]] for installation help.)
-[[!inline pages="plugins/contrib/* !*/Discussion"
+[[!inline pages="plugins/contrib/* and !*/Discussion"
feedpages="created_after(plugins/contrib/navbar)" archive="yes"
rootpage="plugins/contrib" postformtext="Add a new plugin named:" show=0]]
diff --git a/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn b/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn
index b4a7cd5d6..adb414ffb 100644
--- a/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn
+++ b/doc/plugins/contrib/default_content_for___42__copyright__42___and___42__license__42__.mdwn
@@ -20,14 +20,14 @@ template variable somebody wants to use.
--[[bma]]
Copyright and license values are not "template values", they are values
-tracked by the meta plugin, and that various code compares and uses to fill
+tracked by the [[meta]] plugin, and that various code compares and uses to fill
out the templates. Something like varioki cannot do that. --[[Joey]]
Somewhat more detailed usage documentation would be appreciated. I tried to setup
those plugins with a current ikiwiki release, i.e. 2.61, but they appeared to do
nothing, really. Also, those example pages don't seem to use those plugins, even;
they set "copyright" and "license" properties using ordinary [[meta]] tags. Maybe
-I'm missing something terribly obvious? --[[Peter]]
+I'm missing something terribly obvious? --Peter
> Only obvious if you read the source :-). You need to put a file named "copyright.html"
>(respectively "license.html") in your wiki. Everything underneath that (in the wikilink sense) will use that
>content for the license or copyright. Saves putting \[[meta license="foo"]] in every page [[DavidBremner]]
diff --git a/doc/plugins/contrib/gallery.mdwn b/doc/plugins/contrib/gallery.mdwn
index 7148de3ef..72df13bd0 100644
--- a/doc/plugins/contrib/gallery.mdwn
+++ b/doc/plugins/contrib/gallery.mdwn
@@ -2,7 +2,7 @@
This plugin would create a nice looking gallery of the images. It has been build over the img plugin in Ikiwiki
-SVN repository of plugin is located at
+GIT repo of the plugin is located at
USAGE :
diff --git a/doc/plugins/contrib/headinganchors.mdwn b/doc/plugins/contrib/headinganchors.mdwn
index ef2fa122a..c80cc0b49 100644
--- a/doc/plugins/contrib/headinganchors.mdwn
+++ b/doc/plugins/contrib/headinganchors.mdwn
@@ -12,9 +12,9 @@ rst and any other format that produces html. The code is available here:
use strict;
use IkiWiki 2.00;
- sub import { #{{{
+ sub import {
hook(type => "sanitize", id => "headinganchors", call => \&headinganchors);
- } # }}}
+ }
sub text_to_anchor {
my $str = shift;
@@ -26,11 +26,11 @@ rst and any other format that produces html. The code is available here:
return $str;
}
- sub headinganchors (@) { #{{{
+ sub headinganchors (@) {
my %params=@_;
my $content=$params{content};
$content=~s{([^>]*)}{''.$2.''}gie;
return $content;
- } # }}}
+ }
1
diff --git a/doc/plugins/contrib/highlightcode.mdwn b/doc/plugins/contrib/highlightcode.mdwn
index 9b43a106c..8abb76583 100644
--- a/doc/plugins/contrib/highlightcode.mdwn
+++ b/doc/plugins/contrib/highlightcode.mdwn
@@ -1,3 +1,6 @@
+[[!template id=plugin name=highlightcode author="[[sabr]]"]]
+[[!tag type/format]]
+
A small plugin to allow Ikiwiki to display source files complete with syntax highlighting. Files with recognized extensions (i.e. my-file.cpp) are be rendered just like any other Ikiwiki page. You can even edit your source files with Ikiwiki's editor.
It uses the Syntax::Highlight::Engine::Kate Perl module to do the highlighting.
diff --git a/doc/plugins/contrib/linguas.mdwn b/doc/plugins/contrib/linguas.mdwn
index 0c3366846..bf502606e 100644
--- a/doc/plugins/contrib/linguas.mdwn
+++ b/doc/plugins/contrib/linguas.mdwn
@@ -10,7 +10,8 @@ Download: [linguas.pm](http://ettin.org/pub/ikiwiki/linguas.pm) (2006-08-21).
Note that even though it is still available for download, this plugin is no
longer actively maintained. If you are interested in multilingual wiki pages, you
-can also take a look at other approaches such as [[todo/l10n]] or Lars Wirzenius's
+can also take a look at other approaches such as [[todo/l10n]], [[plugins/contrib/po]],
+or Lars Wirzenius's
[Static website, with translations, using IkiWiki](http://liw.iki.fi/liw/log/2007-05.html#20070528b).
Usage
diff --git a/doc/plugins/contrib/mediawiki.mdwn b/doc/plugins/contrib/mediawiki.mdwn
new file mode 100644
index 000000000..c0a23254f
--- /dev/null
+++ b/doc/plugins/contrib/mediawiki.mdwn
@@ -0,0 +1,5 @@
+[[!template id=plugin name=mediawiki author="[[sabr]]"]]
+[[!tag type/format]]
+
+[The Mediawiki plugin](http://u32.net/Mediawiki_Plugin/) allows ikiwiki to
+process pages written using MediaWiki markup.
diff --git a/doc/plugins/contrib/opml.mdwn b/doc/plugins/contrib/opml.mdwn
new file mode 100644
index 000000000..3f98e8065
--- /dev/null
+++ b/doc/plugins/contrib/opml.mdwn
@@ -0,0 +1,11 @@
+[[!template id=plugin name=opml author="[[JanWalzer|jwalzer]]"]]
+[[!tag type/format]]
+
+The idea of this plugin is to parse in an OPML-File and output a linklist, maybe some customization.
+OPML-Files are xml-files that most RSS-Readers write out, to summarize their subscribes feedlist.
+
+I have a "dumb" perlscript running on my website, that tries to do a opml2mdwn transformation, but its quite bad on that.
+
+This Plugin is **NOT Ready** in any way. I'm just putting this page up as a hook, to discuss it.
+
+I intend to work on this, but I'd appreciate any help on this.
diff --git a/doc/plugins/contrib/opml/discussion.mdwn b/doc/plugins/contrib/opml/discussion.mdwn
new file mode 100644
index 000000000..3a145c79a
--- /dev/null
+++ b/doc/plugins/contrib/opml/discussion.mdwn
@@ -0,0 +1,4 @@
+If this is the wrong place for the development of the plugin, please mode it on to a more appropriate one.
+
+Currently I'm quite stuck with the perl-stuff itself. I'm trying to become comfortable with the language, but it seems, the language doesn't like me. I'm lost in complex datastructures, when trying to iterate through the output of XML::Simple. --[[Jan|jwalzer]]
+
diff --git a/doc/plugins/contrib/po.mdwn b/doc/plugins/contrib/po.mdwn
new file mode 100644
index 000000000..61ec53ea8
--- /dev/null
+++ b/doc/plugins/contrib/po.mdwn
@@ -0,0 +1,386 @@
+I've been working on a plugin called "po", that adds support for multi-lingual wikis,
+translated with gettext, using [po4a](http://po4a.alioth.debian.org/).
+
+More information:
+
+* It can be found in my "po" branch:
+ `git clone git://gaffer.ptitcanardnoir.org/ikiwiki.git`
+* It is self-contained, *i.e.* it does not modify ikiwiki core at all.
+* It is documented (including TODO and plans for next work steps) in
+ `doc/plugins/po.mdwn`, which can be found in the same branch.
+* No public demo site is available so far, I'm working on this.
+
+My plan is to get this plugin clean enough to be included in ikiwiki.
+
+The current version is a proof-of-concept, mature enough for me to dare submitting it here,
+but I'm prepared to hear various helpful remarks, and to rewrite parts of it as needed.
+
+Any thoughts on this?
+
+> Well, I think it's pretty stunning what you've done here. Seems very
+> complete and well thought out. I have not read the code in great detail
+> yet.
+>
+> Just using po files is an approach I've never seen tried with a wiki. I
+> suspect it will work better for some wikis than others. For wikis that
+> just want translations that match the master language as closely as
+> possible and don't wander off and diverge, it seems perfect. (But what happens
+> if someone edits the Discussion page of a translated page?)
+>
+> Please keep me posted, when you get closer to having all issues solved
+> and ready for merging I can do a review and hopefully help with the
+> security items you listed. --[[Joey]]
+
+>> Thanks a lot for your quick review, it's reassuring to hear such nice words
+>> from you. I did not want to design and write a full translation system, when
+>> tools such as gettext/po4a already have all the needed functionality, for cases
+>> where the master/slave languages paradigm fits.
+>> Integrating these tools into ikiwiki plugin system was a pleasure.
+>>
+>> I'll tell you when I'm ready for merging, but in the meantime,
+>> I'd like you to review the changes I did to the core (3 added hooks).
+>> Can you please do this? If not, I'll go on and hope I'm not going to far in
+>> the wrong direction.
+>>
+>>> Sure.. I'm not completly happy with any of the hooks since they're very
+>>> special purpose, and also since `run_hooks` is not the best interface
+>>> for a hook that modifies a variable, where only the last hook run will
+>>> actually do anything. It might be better to just wrap
+>>> `targetpage`, `bestlink`, and `beautify_urlpath`. But, I noticed
+>>> the other day that such wrappers around exported functions are only visible by
+>>> plugins loaded after the plugin that defines them.
+>>>
+>>> Update: Take a look at the new "Function overriding" section of
+>>> [[plugins/write]]. I think you can just inject wrappers about a few ikiwiki
+>>> functions, rather than adding hooks. The `inject` function is pretty
+>>> insane^Wlow level, but seems to work great. --[[Joey]]
+>>>
+>>>> Thanks a lot, it seems to be a nice interface for what I was trying to achieve.
+>>>> I may be forced to wait two long weeks before I have a chance to confirm
+>>>> this. Stay tuned. --[[intrigeri]]
+>>>>
+>>>>> I've updated the plugin to use `inject`. It is now fully self-contained,
+>>>>> and does not modify the core anymore. --[[intrigeri]]
+>>
+>> The Discussion pages issue is something I am not sure about yet. But I will
+>> probably decide that "slave" pages, being only translations, don't deserve
+>> a discussion page: the discussion should happen in the language in which the
+>> pages are written for real, which is the "master" one. --[[intrigeri]]
+>>
+>> I think that's a good decision, you don't want to translate discussion,
+>> and if the discussion page turns out multilingual, well, se la vi. ;-)
+>>
+>> Relatedly, what happens if a translated page has a broken link, and you
+>> click on it to edit it? Seems you'd first have to create a master page
+>> and could only then translate it, right? I wonder if this will be clear
+>> though to the user.
+>>
+>>> Right: a broken link points to the URL that allows to create
+>>> a page that can either be a new master page or a non-translatable
+>>> page, depending on `po_translatable_pages` value. The best
+>>> solution I can thing of is to use [[plugins/edittemplate]] to
+>>> insert something like "Warning: this is a master page, that must
+>>> be written in $MASTER_LANGUAGE" into newly created master pages,
+>>> and maybe another warning message on newly created
+>>> non-translatable pages. It seems quite doable to me, but in order
+>>> to avoid breaking existing functionality, it implies to hack a bit
+>>> [[plugins/edittemplate]] so that multiple templates can be
+>>> inserted at page creation time. [[--intrigeri]]
+>>>
+>>>> I implemented such a warning using the formbuilder_setup hook.
+>>>> --[[intrigeri]]
+>>
+>> And also, is there any way to start a translation of a page into a new
+>> lanauge using the web interface?
+>>
+>>> When a new language is added to `po_slave_languages`, a rebuild is
+>>> triggered, and all missing PO files are created and checked into
+>>> VCS. An unpriviledged wiki user can not add a new language to
+>>> `po_slave_languages`, though. One could think of adding the needed
+>>> interface to translate a page into a yet-unsupported slave
+>>> language, and this would automagically add this new language to
+>>> `po_slave_languages`. It would probably be useful in some
+>>> usecases, but I'm not comfortable with letting unpriviledged wiki
+>>> users change the wiki configuration as a side effect of their
+>>> actions; if this were to be implemented, special care would be
+>>> needed. [[--intrigeri]]
+>>>
+>>>> Actually I meant into any of the currently supported languages.
+>>>> I guess that if the template modification is made, it will list those
+>>>> languages on the page, and if a translation to a language is missing,
+>>>> the link will allow creating it?
+>>>>
+>>>>> Any translation page always exist for every supported slave
+>>>>> language, even if no string at all have been translated yet.
+>>>>> This implies the po plugin is especially friendly to people who
+>>>>> prefer reading in their native language if available, but don't
+>>>>> mind reading in English else.
+>>>>>
+>>>>> While I'm at it, there is a remaining issue that needs to be
+>>>>> sorted out: how painful it could be for non-English speakers
+>>>>> (assuming the master language is English) to be perfectly able
+>>>>> to navigate between translation pages supposed to be written in
+>>>>> their own language, when their translation level is most
+>>>>> often low.
+>>>>>
+>>>>> (It is currently easy to display this status on the translation
+>>>>> page itself, but then it's too late, and how frustrating to load
+>>>>> a page just to realize it's actually not translated enough for
+>>>>> you. The "other languages" loop also allows displaying this
+>>>>> information, but it is generally not the primary
+>>>>> navigation tool.)
+>>>>>
+>>>>> IMHO, this is actually a social problem (i.e. it's no use adding
+>>>>> a language to the supported slave ones if you don't have the
+>>>>> manpower to actually do the translations), that can't be fully
+>>>>> solved by technical solutions, but I can think of some hacks
+>>>>> that would limit the negative impact: a given translation's
+>>>>> status (currently = percent translated) could be displayed next
+>>>>> to the link that leads to it; a color code could as well be used
+>>>>> ("just" a matter of adding a CSS id or class to the links,
+>>>>> depending on this variable). As there is already work to be done
+>>>>> to have the links text generation more customizable through
+>>>>> plugins, I could do both at the same time if we consider this
+>>>>> matter to be important enough. --[[intrigeri]]
+>>>>>
+>>>>>> The translation status in links is now implemented in my
+>>>>>> `po`branch. It requires my `meta` branch changes to
+>>>>>> work, though. I consider the latter to be mature enough to
+>>>>>> be merged. --[[intrigeri]]
+
+>> FWIW, I'm tracking your po branch in ikiwiki master git in the po
+>> branch. One thing I'd like to try in there is setting up a translated
+>> basewiki, which seems like it should be pretty easy to do, and would be
+>> a great demo! --[[Joey]]
+>>
+>>> I've merged your changes into my own branch, and made great
+>>> progress on the various todo items. Please note my repository
+>>> location has changed a few days ago, my user page was updated
+>>> accordingly, but I forgot to update this page at the same time.
+>>> Hoping it's not too complicated to relocated an existing remote...
+>>> (never done that, I'm a Git beginner as well as a Perl
+>>> newbie) --[[intrigeri]]
+>>>>
+>>>> Just a matter of editing .git/config, thanks for the heads up.
+>>>>>
+>>>>> Joey, please have a look at my branch, your help would be really
+>>>>> welcome for the security research, as I'm almost done with what
+>>>>> I am able to do myself in this area. --[[intrigeri]]
+>>>>>>
+>>>>>> I came up with a patch for the WrapI18N issue --[[Joey]]
+
+I've set this plugin development aside for a while. I will be back and
+finish it at some point in the first quarter of 2009. --[[intrigeri]]
+
+> Abstract: Joey, please have a look at my po and meta branches.
+>
+> Detailed progress report:
+>
+> * it seems the po branch in your repository has not been tracking my
+> own po branch for two months. any config issue?
+> * all the plugin's todo items have been completed, robustness tests
+> done
+> * I've finished the detailed security audit, and the fix for po4a
+> bugs has entered upstream CVS last week
+> * I've merged your new `checkcontent` hook with the `cansave` hook
+> I previously introduced in my own branch; blogspam plugin updated
+> accordingly
+> * the rename hook changes we discussed elsewhere are also part of my
+> branch
+> * I've introduced two new hooks (`canremove` and `canrename`), not
+> a big deal; IMHO, they extend quite logically the plugin interface
+> * as highlighted on [[bugs/pagetitle_function_does_not_respect_meta_titles]],
+> my `meta` branch contains a new feature that is really useful in a
+> translatable wiki
+>
+> As a conclusion, I'm feeling that my branches are ready to be
+> merged; only thing missing, I guess, are a bit of discussion and
+> subsequent adjustments.
+>
+> --[[intrigeri]]
+
+> I've looked it over and updated my branch with some (untested)
+> changes.
+>
+>> I've merged your changes into my branch. Only one was buggy.
+>
+> Sorry, I'd forgotten about your cansave hook.. sorry for the duplicate
+> work there.
+>
+> Reviewing the changes, mostly outside of `po.pm`, I have
+> the following issues.
+>
+> * renamepage to renamelink change would break the ikiwiki
+> 3.x API, which I've promised not to do, so needs to be avoided
+> somehow. (Sorry, I guess I dropped the ball on not getting this
+> API change in before cutting 3.0..)
+>>
+>> Fixed, see [[todo/need_global_renamepage_hook]].
+>>
+> * I don't understand the parentlinks code change and need to figure it
+> out. Can you explain what is going on there?
+>>
+>> I'm calling `bestlink` there so that po's injected `bestlink` is
+>> run. This way, the parent links of a page link to the parent page
+>> version in the proper language, depending on the
+>> `po_link_to=current` and `po_link_to=negotiated` settings.
+>> Moreover, when using my meta branch enhancements plus meta title to
+>> make pages titles translatable, this small patch is needed to get
+>> the translated titles into parentlinks.
+>>
+> * canrename's mix of positional and named parameters is way too
+> ugly to get into an ikiwiki API. Use named parameters
+> entirely. Also probably should just use named parameters
+> for canremove.
+> * `skeleton.pm.example`'s canrename needs fixing to use either
+> the current or my suggested parameters.
+>>
+>> Done.
+>>
+> * I don't like the exporting of `%backlinks` and `$backlinks_calculated`
+> (the latter is exported but not used).
+>>
+>> The commit message for 85f865b5d98e0122934d11e3f3eb6703e4f4c620
+>> contains the rationale for this change. I guess I don't understand
+>> the subtleties of `our` use, and perldoc does not help me a lot.
+>> IIRC, I actually did not use `our` to "export" these variables, but
+>> rather to have them shared between `Render.pm` uses.
+>>
+>>> My wording was unclear, I meant exposing. --[[Joey]]
+>>>
+>>>> I guess I still don't know Perl's `our` enough to understand clearly.
+>>>> No matter whether these variables are declared with `my` or `our`,
+>>>> any plugin can `use IkiWiki::Render` and then access
+>>>> `$IkiWiki::backlinks`, as already does e.g. the pagestat plugin.
+>>>> So I guess your problem is not with letting plugins use these
+>>>> variables, but with them being visible for every piece of
+>>>> (possibly external) code called from `Render.pm`. Am I right?
+>>>> If I understand clearly, using a brace block to lexically enclose
+>>>> these two `our` declarations, alongside with the `calculate_backlinks`
+>>>> and `backlinks` subs definitions, would be a proper solution, wouldn't
+>>>> it? --[[intrigeri]]
+>>>>
+>>>>> No, %backlinks and the backlinks() function are not the same thing.
+>>>>> The variable is lexically scoped; only accessible from inside
+>>>>> `Render.pm` --[[Joey]]
+>>>>
+> * What is this `IkiWiki::nicepagetitle` and why are you
+> injecting it into that namespace when only your module uses it?
+> Actually, I can't even find a caller of it in your module.
+>>
+>> I guess you should have a look to my `meta` branch and to
+>> [[bugs/pagetitle_function_does_not_respect_meta_titles]] in order
+>> to understand this :)
+>>
+>>> It would probably be good if I could merge this branch without
+>>> having to worry about also immediatly merging that one. --[[Joey]]
+>>>
+>>>> I removed all dependencies on my `meta` branch from the `po` one.
+>>>> This implied removing the `po_translation_status_in_links` and
+>>>> `po_strictly_refresh_backlinks` features, and every link text is now
+>>>> displayed in the master language. I believe the removed features really
+>>>> enhance user experience of a translatable wiki, that's why I was
+>>>> initially supposing the `meta` branch would be merged first.
+>>>> IMHO, we'll need to come back to this quite soon after `po` is merged.
+>>>> --[[intrigeri]]
+>>>>
+>>>> Maybe you should keep those features in a meta-po branch?
+>>>> I did a cursory review of your meta last night, have some issues with it,
+>>>> but this page isn't the place for a detailed review. --[[Joey]]
+>>>>
+>>>>> Done. --[[intrigeri]]
+>>>
+> * I'm very fearful of the `add_depends` in `postscan`.
+> Does this make every page depend on every page that links
+> to it? Won't this absurdly bloat the dependency pagespecs
+> and slow everything down? And since nicepagetitle is given
+> as the reason for doing it, and nicepagetitle isn't used,
+> why do it?
+>>
+>> As explained in the 85f865b5d98e0122934d11e3f3eb6703e4f4c620 log:
+>> this feature hits performance a bit. Its cost was quite small in my
+>> real-world use-cases (a few percents bigger refresh time), but
+>> could be bigger in worst cases. When using the po plugin with my
+>> meta branch changes (i.e. the `nicepagetitle` thing), and having
+>> enabled the option to display translation status in links, this
+>> maintains the translation status up-to-date in backlinks. Same when
+>> using meta title to make the pages titles translatable. It does
+>> help having a nice and consistent translated wiki, but as it can
+>> also involve problems, I just turned it into an option.
+>>
+>>> This has been completely removed for now due to the removal of
+>>> the dependency on my `meta` branch. --[[intrigeri]]
+>>
+> * The po4a Suggests should be versioned to the first version
+> that can be used safely, and that version documented in
+> `plugins/po.mdwn`.
+>>
+>> Done.
+>>
+>> --[[intrigeri]]
+>
+> --[[Joey]]
+
+I reverted the `%backlinks` and `$backlinks_calculated` exposing.
+The issue they were solving probably will arise again when I'll work
+on my meta branch again (i.e. when the simplified po one is merged),
+but the po thing is supposed to work without these ugly `our`.
+Seems like it was the last unaddressed item from Joey's review, so I'm
+daring a timid "please pull"... or rather, please review again :)
+--[[intrigeri]]
+
+> Ok, I've reviewed and merged into my own po branch. It's looking very
+> mergeable.
+>
+> * Is it worth trying to fix compatability with `indexpages`?
+>>
+>> Supporting `usedirs` being enabled or disabled was already quite
+>> hard IIRC, so supporting all four combinations of `usedirs` and
+>> `indexpages` settings will probably be painful. I propose we forget
+>> about it until someone reports he/she badly needs it, and then
+>> we'll see what can be done.
+>>
+> * Would it make sense to go ahead and modify `page.tmpl` to use
+> OTHERLANGUAGES and PERCENTTRANSLATED, instead of documenting how to modify it?
+>>
+>> Done in my branch.
+>>
+> * Would it be better to disable po support for pages that use unsupported
+> or poorly-supported markup languages?
+>
+>> I prefer keeping it enabled, as:
+>>
+>> * most wiki markups "almost work"
+>> * when someone needs one of these to be fully supported, it's not
+>> that hard to add dedicated support for it to po4a; if it were
+>> disabled, I fear the ones who could do this would maybe think
+>> it's blandly impossible and give up.
+>>
+
+> * What's the reasoning behind checking that the link plugin
+> is enabled? AFAICS, the same code in the scan hook should
+> also work when other link plugins like camelcase are used.
+> * In `pagetemplate` there is a comment that claims the code
+> relies on `genpage`, but I don't see how it does; it seems
+> to always add a discussion link?
+> * Is there any real reason not to allow removing a translation?
+> I'm imagining a spammy translation, which an admin might not
+> be able to fix, but could remove.
+> * Re the meta title escaping issue worked around by `change`.
+> I suppose this does not only affect meta, but other things
+> at scan time too. Also, handling it only on rebuild feels
+> suspicious -- a refresh could involve changes to multiple
+> pages and trigger the same problem, I think. Also, exposing
+> this rebuild to the user seems really ugly, not confidence inducing.
+>
+> So I wonder if there's a better way. Such as making po, at scan time,
+> re-run the scan hooks, passing them modified content (either converted
+> from po to mdwn or with the escaped stuff cheaply de-escaped). (Of
+> course the scan hook would need to avoid calling itself!)
+>
+> (This doesn't need to block the merge, but I hope it can be addressed
+> eventually..)
+>
+> --[[Joey]]
+>>
+>> --[[intrigeri]]
diff --git a/doc/plugins/contrib/siterel2pagerel.mdwn b/doc/plugins/contrib/siterel2pagerel.mdwn
index 956b6728f..9b09657bf 100644
--- a/doc/plugins/contrib/siterel2pagerel.mdwn
+++ b/doc/plugins/contrib/siterel2pagerel.mdwn
@@ -13,11 +13,11 @@ other format that produces html. The code is available here:
use strict;
use IkiWiki 2.00;
- sub import { #{{{
+ sub import {
hook(type => "sanitize", id => "siterel2pagerel", call => \&siterel2pagerel);
- } # }}}
+ }
- sub siterel2pagerel (@) { #{{{
+ sub siterel2pagerel (@) {
my %params=@_;
my $baseurl=IkiWiki::baseurl($params{page});
my $content=$params{content};
@@ -25,6 +25,6 @@ other format that produces html. The code is available here:
$content=~s/(
You might also like to look at the [[todo/source_link]] todo. -- [[Will]]
- Is there a way to configure the colors used by source-highlight (other than editing the globally installed "default.style" file)? It would help if I could pass the command arbitrary command-line arguments; then I could configure which config file it's supposed to use. For instance, I'm not a fan of hard-coding the colors into the HTML output. IMHO, css-style formatting should be preferred. All that can be set via the command line ... --Peter
> I don't really have time right now, but it should be easy to add, if you look at how src-lang is handled. Patches are welcome :-) --[[DavidBremner]]
+
+Note that [[Will]] wrote a plugin that uses source-highlight also. It's
+available
+[[here|todo/automatic_use_of_syntax_plugin_on_source_code_files/discussion]].
+--[[Joey]]
+
+To be honest, [[Will]]'s version of this looks more polished. I will try his
+plugin and see if it can just replace mine. --[[DavidBremner]]
+
+
+*Updated* Now uses keepextension so multiple extensions should be OK
diff --git a/doc/plugins/contrib/unixauth.mdwn b/doc/plugins/contrib/unixauth.mdwn
index d91ed45f1..76a847744 100644
--- a/doc/plugins/contrib/unixauth.mdwn
+++ b/doc/plugins/contrib/unixauth.mdwn
@@ -22,7 +22,7 @@ __Security__: [As with passwordauth](/security/#index14h2), be wary of sending u
--- Wrapper.pm.orig 2008-07-29 00:09:10.000000000 -0400
+++ Wrapper.pm
- @@ -28,7 +28,7 @@ sub gen_wrapper () { #{{{
+ @@ -28,7 +28,7 @@ sub gen_wrapper () {
my @envsave;
push @envsave, qw{REMOTE_ADDR QUERY_STRING REQUEST_METHOD REQUEST_URI
CONTENT_TYPE CONTENT_LENGTH GATEWAY_INTERFACE
@@ -46,16 +46,16 @@ __Security__: [As with passwordauth](/security/#index14h2), be wary of sending u
use strict;
use IkiWiki 2.00;
- sub import { #{{{
+ sub import {
hook(type => "getsetup", id => "unixauth", call => \&getsetup);
hook(type => "formbuilder_setup", id => "unixauth",
call => \&formbuilder_setup);
hook(type => "formbuilder", id => "unixauth",
call => \&formbuilder);
hook(type => "sessioncgi", id => "unixauth", call => \&sessioncgi);
- } # }}}
+ }
- sub getsetup () { #{{{
+ sub getsetup () {
return
unixauth_type => {
type => "string",
@@ -83,10 +83,10 @@ __Security__: [As with passwordauth](/security/#index14h2), be wary of sending u
safe => 0,
rebuild => 1,
},
- } #}}}
+ }
# Checks if a string matches a user's password, and returns true or false.
- sub checkpassword ($$;$) { #{{{
+ sub checkpassword ($$;$) {
my $user=shift;
my $password=shift;
my $field=shift || "password";
@@ -131,9 +131,9 @@ __Security__: [As with passwordauth](/security/#index14h2), be wary of sending u
}
return $ret;
- } #}}}
+ }
- sub formbuilder_setup (@) { #{{{
+ sub formbuilder_setup (@) {
my %params=@_;
my $form=$params{form};
@@ -204,7 +204,7 @@ __Security__: [As with passwordauth](/security/#index14h2), be wary of sending u
}
}
- sub formbuilder (@) { #{{{
+ sub formbuilder (@) {
my %params=@_;
my $form=$params{form};
@@ -225,12 +225,12 @@ __Security__: [As with passwordauth](/security/#index14h2), be wary of sending u
my $user_name=$form->field('name');
}
}
- } #}}}
+ }
- sub sessioncgi ($$) { #{{{
+ sub sessioncgi ($$) {
my $q=shift;
my $session=shift;
- } #}}}
+ }
1
diff --git a/doc/plugins/contrib/unixauth/discussion.mdwn b/doc/plugins/contrib/unixauth/discussion.mdwn
index dfa4fe6cc..232649863 100644
--- a/doc/plugins/contrib/unixauth/discussion.mdwn
+++ b/doc/plugins/contrib/unixauth/discussion.mdwn
@@ -32,3 +32,7 @@ I've added support for [checkpassword](http://cr.yp.to/checkpwd/interface.html),
> to disentangle the two locks. --[[Joey]]
>> Ah, ok, I misunderstood your comment. I'll see what I can figure out. --[[schmonz]]
+
+>>> My time's been limited for this, but I just saw [[todo/avoid_thrashing]]. How does that interact with pwauth or checkpassword? --[[schmonz]]
+
+>>>> The DOS still happens, it just uses less memory. --[[Joey]]
diff --git a/doc/plugins/creole.mdwn b/doc/plugins/creole.mdwn
index c6491f754..6961e8d1d 100644
--- a/doc/plugins/creole.mdwn
+++ b/doc/plugins/creole.mdwn
@@ -13,4 +13,10 @@ wiki markup formats, so should be fairly easy to guess at. There is also a
Links are standard [[WikiLinks|ikiwiki/WikiLink]]. Links and
[[directives|ikiwiki/directive]] inside `{{{ }}}` blocks are still expanded,
-since this happens before the creole format is processed.
+since this happens before the creole format is processed. (You need to escape
+them manually, via \\\[[directives]], the ~ escaping of creole doesn't work on
+this.)
+
+The standard ikiwiki [[WikiLinks|ikiwiki/WikiLink]] is almost the same as Creole link, except that creole uses \[[pagename|description]] while ikiwiki uses \[[description|pagename]].
+
+
diff --git a/doc/plugins/creole/discussion.mdwn b/doc/plugins/creole/discussion.mdwn
index 36b7ba869..38ee2bd78 100644
--- a/doc/plugins/creole/discussion.mdwn
+++ b/doc/plugins/creole/discussion.mdwn
@@ -8,4 +8,8 @@ I've installed Text::WikiCreole 0.05 and enabled the plugin, but I get an error
>> I've added the patch to pkgsrc as well. Thanks. --[[schmonz]]
+>> Currently the creole plugin is included in ikiwiki but the ikiwiki deb (3.0.3) doesn't suggests libtext-wikicreole-perl. Why? --[[weakish]]
+
+>>> forgot, done now --[[Joey]]
+
I'm moving over a really stinkingly old UseMod and creole seems the nearest match. I've worked out that Bare /Subpage links need to become \[\[Subpage\]\], and Top/Sub links need to be \[\[Top/Sub\]\] (or \[\[Top/Sub|Top/Sub\]\], to display in exactly the same way), but I'm stuck on generic hyperlinks. The creole cheat sheet says I should be able to do \[\[http://url.path/foo|LinkText\]\], but that comes out as a link to create the "linktext" page, and Markdown-style \[Link Text\](http://url.path/foo) just gets rendered as is. Any suggestions? --[[schmonz]]
diff --git a/doc/plugins/cutpaste.mdwn b/doc/plugins/cutpaste.mdwn
index 1b78e60fc..f74f8a269 100644
--- a/doc/plugins/cutpaste.mdwn
+++ b/doc/plugins/cutpaste.mdwn
@@ -1,4 +1,4 @@
-[[!template id=plugin name=toggle author="[[Enrico]]"]]
+[[!template id=plugin name=cutpaste author="[[Enrico]]"]]
[[!tag type/chrome]]
This plugin provides the [[ikiwiki/directive/cut]],
diff --git a/doc/plugins/ddate.mdwn b/doc/plugins/ddate.mdwn
index e82760d88..741606a6e 100644
--- a/doc/plugins/ddate.mdwn
+++ b/doc/plugins/ddate.mdwn
@@ -1,5 +1,6 @@
[[!template id=plugin name=ddate author="[[Joey]]"]]
[[!tag type/fun]]
+[[!tag type/date]]
Enables use of Discordian dates. `--timeformat` can be used to change
the date format; see `ddate(1)`.
diff --git a/doc/plugins/discussion.mdwn b/doc/plugins/discussion.mdwn
index 70157f1e2..854307a98 100644
--- a/doc/plugins/discussion.mdwn
+++ b/doc/plugins/discussion.mdwn
@@ -34,12 +34,3 @@ Any objections to listing plugins alphabetically rather than by creation date?
>> "recently changed" list with the 10 most recently changed plugins
>> at the top. That would allow what you suggested, but still allow
>> the main list to be alphabetical. -- [[Will]]
-
-How about adding a deprecated tag in order to clean up the plugin list?
-
-> AFAIK it's currently the only one. --[[Joey]]
-
-For instance [[googlecalendar]] is listed as plugin but should probably be removed from Ikiwiki in a future major version (v3?).
-
--- [[AlexandreDupas]]
-
diff --git a/doc/plugins/embed.mdwn b/doc/plugins/embed.mdwn
index 1d43061e0..85592cb72 100644
--- a/doc/plugins/embed.mdwn
+++ b/doc/plugins/embed.mdwn
@@ -13,6 +13,14 @@ In the examples below, the parts of the html that you can change are denoted
with "XXX"; everything else must appear exactly as shown to be accepted by the
plugin.
+**This plugin is deprecated.** Rather than relying on these complex lists
+of safe content, which constantly fall out of date, you're recommended to
+configure the [[htmlscrubber]] to not scrub some pages, which only trusted
+users can edit. Then you can embed anything from anywhere on those pages.
+See [[tips/embedding_content]] for details and examples.
+This plugin's lists of safe embedded content will not be maintained, and
+the plugin will be removed in a future release.
+
## google maps
Use html like this to embed a map:
diff --git a/doc/plugins/format.mdwn b/doc/plugins/format.mdwn
new file mode 100644
index 000000000..91e707fcf
--- /dev/null
+++ b/doc/plugins/format.mdwn
@@ -0,0 +1,9 @@
+[[!template id=plugin name=format core=0 author="[[Joey]]"]]
+[[!tag type/format]]
+
+This plugin allows mixing different page formats together, by embedding
+text formatted one way inside a page formatted another way. This is done
+using the [[ikiwiki/directive/format]] [[ikiwiki/directive]].
+
+For example, it could be used to embed an [[otl]] outline inside a page
+that is formatted as [[mdwn]].
diff --git a/doc/plugins/format/discussion.mdwn b/doc/plugins/format/discussion.mdwn
new file mode 100644
index 000000000..df8448ed6
--- /dev/null
+++ b/doc/plugins/format/discussion.mdwn
@@ -0,0 +1,15 @@
+Is there any way to tell if an htmlize hook have been called from a format directive?
+
+I am currently modifying the [[contrib/highlightcode]] plugin by [[sabr]] and I wanted to have a different behavior depending on the fact that the htmlize hook is called from a format directive or not. For instance, this could disable the raw copy of the highlighted code. Since I have enabled the keepextension option, I tried to rely on the page extension to decide whenever I have to create the raw file or not but this does not seems a reliable approach.
+
+One possible solution is to add an optional parameter to the htmlize hook (and thus to htmlize function in IkiWiki.pm) which could tell if this is the format directive that called the function but I am not sure that is a good way to do this.
+
+> It's (probably) not just the format directive that has a potential problem here.
+> Imagine a syntax highlighted source code file that contains some other
+> directive, such as table or meta. Such a directive calls `htmlize` on the
+> parameters passed to it.
+>
+> There is one way to detect this ATM. If `%IkiWiki::preprocessing` has
+> anything in it, then ikiwiki is in the middle of handling a preprocessing
+> directive. So you could check that. It's getting into internals, so not
+> ideal.. --[[Joey]]
diff --git a/doc/plugins/goodstuff.mdwn b/doc/plugins/goodstuff.mdwn
index 83b60f4fa..ee1bffcfa 100644
--- a/doc/plugins/goodstuff.mdwn
+++ b/doc/plugins/goodstuff.mdwn
@@ -12,7 +12,6 @@ Currently included:
* [[brokenlinks]]
* [[img]]
* [[map]]
-* [[meta]]
* [[more]]
* [[orphans]]
* [[pagecount]]
@@ -25,5 +24,6 @@ Currently included:
* [[template]]
* [[toc]]
* [[toggle]]
+* [[repolist]]
New plugins will be added to this bundle from time to time.
diff --git a/doc/plugins/google/discussion.mdwn b/doc/plugins/google/discussion.mdwn
new file mode 100644
index 000000000..babc919d2
--- /dev/null
+++ b/doc/plugins/google/discussion.mdwn
@@ -0,0 +1,6 @@
+This plugin uses the googleform.tmpl
+which produces valid HTML but invalid XHTML.
+This is not very good since the default ikiwiki
+templates produce XHTML instead of HTML.
+
+> Fixed, thanks for the patch! --[[Joey]]
diff --git a/doc/plugins/googlecalendar.mdwn b/doc/plugins/googlecalendar.mdwn
deleted file mode 100644
index bca2ae74f..000000000
--- a/doc/plugins/googlecalendar.mdwn
+++ /dev/null
@@ -1,20 +0,0 @@
-[[!template id=plugin name=googlecalendar author="[[Joey]]"]]
-[[!tag type/special-purpose]]
-
-*Note*: This plugin is deprecated. Please switch to the [[embed]] plugin.
-
-This plugin allows embedding a google calendar iframe in the wiki.
-Normally, if the [[htmlscrubber]] is enabled, such iframes are scrubbed out
-of the wiki content since they're not very safe if created by malicious
-users. But some iframes are legitimate, and safe, if you trust the embedded
-content. This plugin is an example of how to deal with this in ikiwiki.
-
-Example use:
-
- \[[!googlecalendar html="""
-
- """]]
-
-The iframe should be the one provided by google. Note that it's used in a
-way that avoids cross-site scripting attacks, assuming you trust google's
-content.
diff --git a/doc/plugins/goto.mdwn b/doc/plugins/goto.mdwn
new file mode 100644
index 000000000..9c401c5d2
--- /dev/null
+++ b/doc/plugins/goto.mdwn
@@ -0,0 +1,10 @@
+[[!template id=plugin name=goto author="[[Simon_McVittie|smcv]]"]]
+[[!tag type/useful]]
+
+This plugin adds a `do=goto` mode for the IkiWiki CGI script. It's mainly
+for internal use by the [[404]], [[comments]] and [[recentchanges]]
+plugins, which enable it automatically.
+
+With this plugin enabled you can link to `ikiwiki.cgi?do=goto&page=some/where`
+to make a link that will redirect to the page `/some/where` if it exists, or
+offer a link to create it if it doesn't.
diff --git a/doc/plugins/htmlbalance.mdwn b/doc/plugins/htmlbalance.mdwn
new file mode 100644
index 000000000..f4e2298ee
--- /dev/null
+++ b/doc/plugins/htmlbalance.mdwn
@@ -0,0 +1,9 @@
+[[!template id=plugin name=htmlbalance author="[[Simon_McVittie|smcv]]"]]
+[[!tag type/html]]
+
+This plugin ensures that the HTML emitted by ikiwiki contains well-balanced
+HTML tags, by parsing it with [[!cpan HTML::TreeBuilder]] and re-serializing it. This
+acts as a lighter-weight alternative to [[plugins/htmltidy]]; it doesn't
+ensure validity, but it does at least ensure that formatting from a
+blog post pulled in by the [[ikiwiki/directive/inline]] directive doesn't
+leak into the rest of the page.
diff --git a/doc/plugins/htmlbalance/discussion.mdwn b/doc/plugins/htmlbalance/discussion.mdwn
new file mode 100644
index 000000000..c66528a4f
--- /dev/null
+++ b/doc/plugins/htmlbalance/discussion.mdwn
@@ -0,0 +1,10 @@
+Would it be possible to use [[!cpan HTML::Entities]] rather than
+`XML::Atom::Util` for encoding entities? The former is already an ikiwiki
+dependency (via [[!cpan HTML::Parser]]).
+
+> Now switched to HTML::Entities --[[Joey]]
+
+I also wonder if there's any benefit to using this plugin aside from with
+aggregate. Perhaps a small one but aggregate seems like the main case..
+wondering if it would be better to just have aggregate balanace the html
+automatically and do away with the separate plugin. --[[Joey]]
diff --git a/doc/plugins/htmlscrubber.mdwn b/doc/plugins/htmlscrubber.mdwn
index 7db372e1b..c59b46e14 100644
--- a/doc/plugins/htmlscrubber.mdwn
+++ b/doc/plugins/htmlscrubber.mdwn
@@ -32,10 +32,10 @@ other HTML-related functionality, such as whether [[meta]] allows
potentially unsafe HTML tags.
The `htmlscrubber_skip` configuration setting can be used to skip scrubbing
-of some pages. Set it to a [[PageSpec]], such as "!*/Discussion", and pages
-matching that can have all the evil CSS, JavsScript, and unsafe html
-elements you like. One safe way to use this is to use [[lockedit]] to lock
-those pages, so only admins can edit them.
+of some pages. Set it to a [[ikiwiki/PageSpec]], such as "!*/Discussion",
+and pages matching that can have all the evil CSS, JavsScript, and unsafe
+html elements you like. One safe way to use this is to use [[lockedit]] to
+lock those pages, so only admins can edit them.
----
diff --git a/doc/plugins/htmltidy.mdwn b/doc/plugins/htmltidy.mdwn
index f675a01ae..580e56f59 100644
--- a/doc/plugins/htmltidy.mdwn
+++ b/doc/plugins/htmltidy.mdwn
@@ -7,4 +7,5 @@ emitted by ikiwiki. Besides being nicely formatted, this helps ensure that
even if users enter suboptimal html, your wiki generates valid html.
Note that since tidy is an external program, that is run each time a page
-is built, this plugin will slow ikiwiki down somewhat.
+is built, this plugin will slow ikiwiki down somewhat. [[plugins/htmlbalance]]
+might provide a faster alternative.
diff --git a/doc/plugins/img/discussion.mdwn b/doc/plugins/img/discussion.mdwn
index 02d46e380..e1bb2d15b 100644
--- a/doc/plugins/img/discussion.mdwn
+++ b/doc/plugins/img/discussion.mdwn
@@ -5,3 +5,8 @@ logo link to \[[hurd/logo]] /
instead of linking to the PNG image file. --[[tschwinge]]
> Done, use link=somepage --[[Joey]]
+
+It would be handy if the `class` and `id` tags were passed through to the surrounding `table` in the case of `caption` being present. Would this break anything? --[[neale]]
+
+> Seems unlikely to break *too* much. I can imagine css that styles the img
+> unexpectedly applying the table. --[[Joey]]
diff --git a/doc/plugins/lockedit.mdwn b/doc/plugins/lockedit.mdwn
index 71bf232ab..c8f64ea47 100644
--- a/doc/plugins/lockedit.mdwn
+++ b/doc/plugins/lockedit.mdwn
@@ -4,7 +4,7 @@
This plugin allows the administrator of a wiki to lock some pages, limiting
who can edit them using the online interface. This doesn't prevent anyone
who can commit to the underlying revision control system from editing the
-pages, however.
+pages, however. (Unless you set up [[tips/untrusted_git_push]].)
The `locked_pages` setting configures what pages are locked. It is a
[[ikiwiki/PageSpec]], so you have lots of control over what kind of pages
@@ -17,6 +17,10 @@ One handy thing to do if you're using ikiwiki for your blog is to lock
posts in your blog, while still letting them comment via the Discussion
pages.
+Alternatively, if you're using the [[comments]] plugin, you can lock
+"!postcomment(*)" to allow users to comment on pages, but not edit anything
+else.
+
Wiki administrators can always edit locked pages. The [[ikiwiki/PageSpec]]
can specify that some pages are not locked for some users. For example,
"important_page and !user(joey)" locks `important_page` while still
diff --git a/doc/plugins/mdwn/discussion.mdwn b/doc/plugins/mdwn/discussion.mdwn
new file mode 100644
index 000000000..4b05e7f4e
--- /dev/null
+++ b/doc/plugins/mdwn/discussion.mdwn
@@ -0,0 +1,7 @@
+Unlike other format, ikiwiki is somehow depends
+on mdwn, since the underlay dir
+is written in mdwn. If you want to disable mdwn,
+you need to overwrite the underlay
+dir (set underlaydir in ikiwiki.setup
+to your own underlay dir or replace underlay pages
+in your $SRC).
diff --git a/doc/plugins/meta.mdwn b/doc/plugins/meta.mdwn
index afd554993..e49bdcc50 100644
--- a/doc/plugins/meta.mdwn
+++ b/doc/plugins/meta.mdwn
@@ -1,4 +1,4 @@
-[[!template id=plugin name=meta author="[[Joey]]"]]
+[[!template id=plugin name=meta core=1 author="[[Joey]]"]]
[[!tag type/meta]]
This plugin provides the [[ikiwiki/directive/meta]] [[ikiwiki/directive]],
diff --git a/doc/plugins/pagecount.mdwn b/doc/plugins/pagecount.mdwn
index 6235963d3..a56027e60 100644
--- a/doc/plugins/pagecount.mdwn
+++ b/doc/plugins/pagecount.mdwn
@@ -6,5 +6,5 @@ This plugin provides the [[ikiwiki/directive/pagecount]]
currently in the wiki.
If it is turned on it can tell us that this wiki includes
-[[!pagecount pages="* and !recentchanges"]]
-pages, of which [[!pagecount pages="*/Discussion"]] are discussion pages.
+[[!pagecount ]] pages, of which
+[[!pagecount pages="*/Discussion"]] are discussion pages.
diff --git a/doc/plugins/passwordauth/discussion.mdwn b/doc/plugins/passwordauth/discussion.mdwn
index f4e7ae7a1..672970c21 100644
--- a/doc/plugins/passwordauth/discussion.mdwn
+++ b/doc/plugins/passwordauth/discussion.mdwn
@@ -9,3 +9,71 @@ the *Preferences -- Subscriptions*. --[[tschwinge]]
>> Aha, then the problem is Firefox, which is automatically filling the
>> *Password* field with its previous value, but not filling the
>> *Confirm Password* one. --[[tschwinge]]
+
+## easy access to the userdb for apache auth?
+
+My use case is:
+
+* restricted ikiwiki
+* read/edit only allowed from the local network (done with apache restrictions)
+* edit only for people authenticated (done with vanilla ikiwiki passwordauth)
+
+I would like to allow people to read/edit the wiki from outside of the
+local network, if and only if they already have an ikiwiki account.
+
+[[httpauth]] doesn't fit since it doesn't allow anonymous local users
+to create their own account. I want a single, local, simple auth
+database.
+
+My (naïve?) idea would be:
+
+* keep the [[passwordauth]] system
+* provide a way for Apache to use the userdb for authentication if
+people want to connect from outside
+
+I looked at the various auth modules for apache2. It seems that none
+can use a "perl Storable data" file. So, I think some solutions could
+be:
+
+* use a sqlite database instead of a perl Storable file
+ * can be used with
+ [mod_auth_dbd](http://httpd.apache.org/docs/2.2/mod/mod_authn_dbd.html)
+ * requires a change in ikiwiki module [[passwordauth]]
+* use an external program to read the userdb and talk with
+ [mod_auth_external](http://unixpapa.com/mod_auth_external.html)
+ * requires the maintainance of this external auth proxy over ikiwiki
+ userdb format changes
+ * (I don't know perl)
+* include this wrapper in ikiwiki
+ * something like `ikiwiki --auth user:pass:userdb` check the
+ `user:pass` pair in `userdb` and returns an Accept/Reject flag to
+ Apache
+ * requires a change in ikiwiki core
+ * still requires
+ [mod_auth_external](http://unixpapa.com/mod_auth_external.html)
+* do it with Apache perl sections
+ * (I don't know perl)
+
+Any opinion/suggestion/solution to this is welcome and appreciated.
+
+--
+[[NicolasLimare]]
+
+For a similar use case, I've been intending to implement
+[[todo/httpauth_feature_parity_with_passwordauth]], but your idea may
+actually be the way to go. IMHO, the Perl sections idea is the
+easiest to setup, but on the long run, I'd prefer ikiwiki to optionnally
+use a userdb storage backend supported at least by Apache and lighttpd.
+--[[intrigeri]]
+
+Tons of CPAN modules may help, but most of them are specific to `mod_perl`,
+and AFAIK, ikiwiki is generally not run with `mod_perl`. It's not clear to me
+wether these modules depend on the webapp to be run with `mod_perl` set
+as the script handler, or only on `mod_perl` to be installed and loaded.
+
+* CPAN's `Apache::AuthenHook` allows to plug arbitrary Perl handlers as
+ Apache authentication providers.
+* CPAN's `Apache::Authen::Program` (`mod_perl`)
+* [http://www.openfusion.com.au/labs/mod_auth_tkt/](mod_auth_tkt) along with CPAN's
+ `Apache::AuthTkt`
+--[[intrigeri]]
diff --git a/doc/plugins/pingee.mdwn b/doc/plugins/pingee.mdwn
index d012004f9..6156c235f 100644
--- a/doc/plugins/pingee.mdwn
+++ b/doc/plugins/pingee.mdwn
@@ -3,7 +3,7 @@
This plugin causes ikiwiki to listen for pings, typically delivered from
another ikiwiki instance using the [[pinger]] plugin. When a ping is
-recieved, ikiwiki will update the wiki, the same as if `ikiwiki --refresh`
+received, ikiwiki will update the wiki, the same as if `ikiwiki --refresh`
were ran at the command line.
An url such as the following is used to trigger a ping:
diff --git a/doc/plugins/prettydate.mdwn b/doc/plugins/prettydate.mdwn
index 9a67f5dca..11ad4252f 100644
--- a/doc/plugins/prettydate.mdwn
+++ b/doc/plugins/prettydate.mdwn
@@ -1,5 +1,5 @@
[[!template id=plugin name=prettydate author="[[Joey]]"]]
-[[!tag type/format]]
+[[!tag type/date]]
Enabling this plugin changes the dates displayed on pages in the wiki to
a format that is nice and easy to read. Examples: "late Wednesday evening,
diff --git a/doc/plugins/relativedate.mdwn b/doc/plugins/relativedate.mdwn
new file mode 100644
index 000000000..3ada0864b
--- /dev/null
+++ b/doc/plugins/relativedate.mdwn
@@ -0,0 +1,16 @@
+[[!template id=plugin name=relativedate author="[[Joey]]"]]
+[[!tag type/date]]
+
+This plugin lets dates be displayed in relative form. Examples: "2 days ago",
+"1 month and 3 days ago", "30 minutes ago". Hovering over the date will
+cause a tooltip to pop up with the absolute date.
+
+This only works in browsers with javascript enabled; other browsers will
+show the absolute date instead. Also, this plugin can be used with other
+plugins like [[prettydate]] that change how the absolute date is displayed.
+
+If this plugin is enabled, you may also add relative dates to pages in the
+wiki, by using html elements in the "relativedate" class. For example, this
+will display as a relative date:
+
+ Tue Jan 20 12:00:00 EDT 2009
diff --git a/doc/plugins/repolist.mdwn b/doc/plugins/repolist.mdwn
new file mode 100644
index 000000000..9b3a7575e
--- /dev/null
+++ b/doc/plugins/repolist.mdwn
@@ -0,0 +1,17 @@
+[[!template id=plugin name=repolist author="[[Joey]]"]]
+[[!tag type/useful]]
+
+This plugin allows you to configure ikiwiki with the location of
+[[rcs]] repositories for your wiki's source. This is done via the
+"repositories" setting in the setup file. Once you tell it where the source
+to your wiki can be downloaded from, this information can be published on
+your wiki in various ways.
+
+This plugin supports the [rel-vcs-*](http://kitenet.net/~joey/rfc/rel-vcs/)
+microformat, and uses it to embed the repository location information in
+every wiki page.
+
+By using this plugin, you will make [[Joey]] very happy, as he will be able
+to easily check out the source of your wiki, for purposes of debugging and
+general curiosity. More generally, making it easy for others to find the
+repository for your wiki is just a Plain Good Idea(TM).
diff --git a/doc/plugins/rst.mdwn b/doc/plugins/rst.mdwn
index 9355597ac..5e97e2d80 100644
--- a/doc/plugins/rst.mdwn
+++ b/doc/plugins/rst.mdwn
@@ -11,7 +11,7 @@ ikiwiki. Limitations include:
* There are issues with inserting raw html into documents, as ikiwiki
does with [[WikiLinks|ikiwiki/WikiLink]] and many
- preprocessor [[directives|ikiwiki/directive]].
+ [[directives|ikiwiki/directive]].
So while you may find this useful for importing old files into your wiki,
using this as your main markup language in ikiwiki isn't recommended at
diff --git a/doc/plugins/shortcut/discussion.mdwn b/doc/plugins/shortcut/discussion.mdwn
index 8b1378917..4e11ce08c 100644
--- a/doc/plugins/shortcut/discussion.mdwn
+++ b/doc/plugins/shortcut/discussion.mdwn
@@ -1 +1,12 @@
+The plugin depends on [[mdwn]]. If you have
+disabled [[mdwn]], to get [[shortcut]] work, you need
+commit in a shortcuts.ext (ext is `rcs|creole|html|txt|etc`),
+and edit/patch [[shortcut]].
+
+Maybe use the `default_pageext` is better than hardcode .mdwn?
+
+--[[weakish]]
+
+> done, it will use `default_pageext` now --[[Joey]]
+
diff --git a/doc/plugins/tag.mdwn b/doc/plugins/tag.mdwn
index 17bb086a1..8ff70a069 100644
--- a/doc/plugins/tag.mdwn
+++ b/doc/plugins/tag.mdwn
@@ -5,6 +5,9 @@ This plugin provides the [[ikiwiki/directive/tag]] and
[[ikiwiki/directive/taglink]] [[directives|ikiwiki/directive]].
These directives allow tagging pages.
+It also provides the `tagged()` [[ikiwiki/PageSpec]], which can be used to
+match pages that are tagged with a specific tag.
+
[[!if test="enabled(tag)" then="""
This wiki has the tag plugin enabled, so you'll see a note below that this
page is tagged with the "tags" tag.
diff --git a/doc/plugins/tag/discussion.mdwn b/doc/plugins/tag/discussion.mdwn
index 7e7b88bc5..b6dab5358 100644
--- a/doc/plugins/tag/discussion.mdwn
+++ b/doc/plugins/tag/discussion.mdwn
@@ -22,3 +22,9 @@ AOLMODE=true echo "I too would really like this feature, which would make cgi fr
better" --[[DavidBremner]]
Please make the actual text used a template some way or another. I may want `map` instead of `inline`. --[[madduck]]
+
+
+See [[todo/auto-create tag pages according to a template]]
+
+-- Jeremy Schultz
+
diff --git a/doc/plugins/textile/discussion.mdwn b/doc/plugins/textile/discussion.mdwn
deleted file mode 100644
index 945c9b46d..000000000
--- a/doc/plugins/textile/discussion.mdwn
+++ /dev/null
@@ -1 +0,0 @@
-.
\ No newline at end of file
diff --git a/doc/plugins/type/date.mdwn b/doc/plugins/type/date.mdwn
new file mode 100644
index 000000000..eae1226da
--- /dev/null
+++ b/doc/plugins/type/date.mdwn
@@ -0,0 +1 @@
+These plugins control how ikiwiki displays dates.
diff --git a/doc/plugins/underlay.mdwn b/doc/plugins/underlay.mdwn
new file mode 100644
index 000000000..09d096a6e
--- /dev/null
+++ b/doc/plugins/underlay.mdwn
@@ -0,0 +1,14 @@
+[[!template id=plugin name=underlay author="[[Simon_McVittie|smcv]]"]]
+[[!tag type/useful]]
+
+This plugin adds an `add_underlays` option to the `.setup` file.
+Its value is a list of underlay directories whose content is added to the wiki.
+
+Multiple underlays are normally set up automatically by other plugins (for
+instance, the images used by the [[plugins/smiley]] plugin), but they can also be
+used as a way to pull in external files that you don't want in revision control,
+like photos or software releases.
+
+Directories in `add_underlays` should usually be absolute. If relative, they're
+interpreted as relative to the parent directory of the basewiki underlay, which
+is probably not particularly useful in this context.
diff --git a/doc/plugins/wmd.mdwn b/doc/plugins/wmd.mdwn
new file mode 100644
index 000000000..dc9a30703
--- /dev/null
+++ b/doc/plugins/wmd.mdwn
@@ -0,0 +1,16 @@
+[[!template id=plugin name=wmd author="[[Will]]"]]
+[[!tag type/chrome]]
+
+[WMD](http://wmd-editor.com/) is a What You See Is What You Mean editor for
+[[mdwn]]. This plugin makes WMD be used for editing pages in the wiki.
+
+To use the plugin, you will need to install WMD. Download the [WMD
+source](http://wmd-editor.com/downloads/wmd-1.0.1.zip). In that zip file
+you'll find a few example html files, a readme and `wmd` directory. Create
+a 'wmd' subdirectory in the ikiwiki `underlaydir` directory (ie `sudo mkdir
+/usr/share/ikiwiki/wmd`). Move the `wmd` directory into the directory you
+made. You should now have a `wmd/wmd/wmd.js` file as well as some other
+javascript files and an images directory in the same place.
+
+Note that the WMD plugin does **not** handle ikiwiki directives. For this
+reason the normal `preview` button remains.
diff --git a/doc/plugins/write.mdwn b/doc/plugins/write.mdwn
index 1b78f5900..696bc6bc3 100644
--- a/doc/plugins/write.mdwn
+++ b/doc/plugins/write.mdwn
@@ -19,7 +19,7 @@ that can be fleshed out to make a useful plugin.
`IkiWiki::Plugin::pagecount` is another simple example. All perl plugins
should `use IkiWiki` to import the ikiwiki plugin interface. It's a good
idea to include the version number of the plugin interface that your plugin
-expects: `use IkiWiki 2.00`.
+expects: `use IkiWiki 3.00`.
An external plugin is an executable program. It can be written in any
language. Its interface to ikiwiki is via XML RPC, which it reads from
@@ -55,8 +55,8 @@ plugin, and a "call" parameter, which tells what function to call for the
hook.
An optional "last" parameter, if set to a true value, makes the hook run
-after all other hooks of its type. Useful if the hook depends on some other
-hook being run first.
+after all other hooks of its type, and an optional "first" parameter makes
+it run first. Useful if the hook depends on some other hook being run first.
## Types of hooks
@@ -107,7 +107,7 @@ adding or removing files from it.
This hook is called early in the process of building the wiki, and is used
as a first pass scan of the page, to collect metadata about the page. It's
-mostly used to scan the page for WikiLinks, and add them to `%links`.
+mostly used to scan the page for [[WikiLinks|ikiwiki/WikiLink]], and add them to `%links`.
Present in IkiWiki 2.40 and later.
The function is passed named parameters "page" and "content". Its return
@@ -168,7 +168,7 @@ htmlize the page) along with the rest of the page.
hook(type => "linkify", id => "foo", call => \&linkify);
-This hook is called to convert [[WikiLinks|WikiLink]] on the page into html
+This hook is called to convert [[WikiLinks|ikiwiki/WikiLink]] on the page into html
links. The function is passed named parameters "page", "destpage", and
"content". It should return the linkified content. Present in IkiWiki 2.40
and later.
@@ -189,14 +189,18 @@ The function is passed named parameters: "page" and "content" and should
return the htmlized content.
If `hook` is passed an optional "keepextension" parameter, set to a true
-value, then this extension will not be stripped from the source filename when
+value, then the extension will not be stripped from the source filename when
generating the page.
+If `hook` is passed an optional "noextension" parameter, set to a true
+value, then the id parameter specifies not a filename extension, but
+a whole filename that can be htmlized. This is useful for files
+like `Makefile` that have no extension.
+
### pagetemplate
hook(type => "pagetemplate", id => "foo", call => \&pagetemplate);
-
[[Templates|wikitemplates]] are filled out for many different things in
ikiwiki, like generating a page, or part of a blog page, or an rss feed, or
a cgi. This hook allows modifying the variables available on those
@@ -304,7 +308,7 @@ can check if the session object has a "name" parameter set.
### canedit
- hook(type => "canedit", id => "foo", call => \&pagelocked);
+ hook(type => "canedit", id => "foo", call => \&canedit);
This hook can be used to implement arbitrary access methods to control when
a page can be edited using the web interface (commits from revision control
@@ -322,6 +326,26 @@ This hook should avoid directly redirecting the user to a signin page,
since it's sometimes used to test to see which pages in a set of pages a
user can edit.
+### checkcontent
+
+ hook(type => "checkcontent", id => "foo", call => \&checkcontent);
+
+This hook is called to check the content a user has entered on a page,
+before it is saved, and decide if it should be allowed.
+
+It is passed named parameters: `content`, `page`, `cgi`, and `session`. If
+the content the user has entered is a comment, it may also be passed some
+additional parameters: `author`, `url`, and `subject`. The `subject`
+parameter may also be filled with the user's comment about the change.
+
+Note: When the user edits an existing wiki page, the passed `content` will
+include only the lines that they added to the page, or modified.
+
+The hook should return `undef` on success. If the content is disallowed, it
+should return a message stating what the problem is, or a function
+that can be run to perform whatever action is necessary to allow the user
+to post the content.
+
### editcontent
hook(type => "editcontent", id => "foo", call => \&editcontent);
@@ -415,7 +439,7 @@ describes the plugin as a whole. For example:
* `example` can be set to an example value.
* `description` is a short description of the option.
* `link` is a link to further information about the option. This can either
- be a wikilink, or an url.
+ be a [[ikiwiki/WikiLink]], or an url.
* `advanced` can be set to true if the option is more suitable for advanced
users.
* `safe` should be false if the option should not be displayed in unsafe
@@ -432,7 +456,7 @@ describes the plugin as a whole. For example:
To import the ikiwiki plugin interface:
- use IkiWiki '2.00';
+ use IkiWiki '3.00';
This will import several variables and functions into your plugin's
namespace. These variables and functions are the ones most plugins need,
@@ -487,7 +511,7 @@ use the following hashes, using a page name as the key:
destination file.
* `%pagesources` contains the name of the source file for each page.
-Also, the %IkiWiki::version variable contains the version number for the
+Also, the `%IkiWiki::version` variable contains the version number for the
ikiwiki program.
### Library functions
@@ -610,6 +634,16 @@ A failure to write the file will result in it dying with an error.
If the destination directory doesn't exist, it will first be created.
+The filename and directory are separate parameters because of
+some security checks done to avoid symlink attacks. Before writing a file,
+it checks to make sure there's not a symlink with its name, to avoid
+following the symlink. If the filename parameter includes a subdirectory
+to put the file in, it also checks if that subdirectory is a symlink, etc.
+The directory parameter, however, is not checked for symlinks. So,
+generally the directory parameter is a trusted toplevel directory like
+the srcdir or destdir, and any subdirectories of this are included in the
+filename parameter.
+
#### `will_render($$)`
Given a page name and a destination file name (not including the base
@@ -651,7 +685,7 @@ a wiki page name.
#### `linkpage($)`
This converts text that could have been entered by the user as a
-[[WikiLink]] into a wiki page name.
+[[ikiwiki/WikiLink]] into a wiki page name.
#### `srcfile($;$)`
@@ -697,11 +731,15 @@ This can be called when creating a new page, to determine what filename
to save the page to. It's passed a page name, and its type, and returns
the name of the file to create, relative to the srcdir.
-#### `targetpage($$)`
+#### `targetpage($$;$)`
Passed a page and an extension, returns the filename that page will be
rendered to.
+Optionally, a third parameter can be passed, to specify the preferred
+filename of the page. For example, `targetpage("foo", "rss", "feed")`
+will yield something like `foo/feed.rss`.
+
## Miscellaneous
### Internal use pages
@@ -712,7 +750,7 @@ are collected together to form the RecentChanges page, for example.
To make an internal use page, register a filename extension that starts
with "_". Internal use pages cannot be edited with the web interface,
-generally shouldn't contain wikilinks or preprocessor directives (use
+generally shouldn't contain [[WikiLinks|ikiwiki/WikiLink]] or preprocessor directives (use
either on them with extreme caution), and are not matched by regular
PageSpecs glob patterns, but instead only by a special `internal()`
[[ikiwiki/PageSpec]].
@@ -821,6 +859,30 @@ it up in the history.
It's ok if this is not implemented, and throws an error.
+#### `rcs_receive()`
+
+This is called when ikiwiki is running as a pre-receive hook (or
+equivalent), and is testing if changes pushed into the RCS from an
+untrusted user should be accepted. This is optional, and doesn't make
+sense to implement for all RCSs.
+
+It should examine the incoming changes, and do any sanity
+checks that are appropriate for the RCS to limit changes to safe file adds,
+removes, and changes. If something bad is found, it should exit
+nonzero, to abort the push. Otherwise, it should return a list of
+files that were changed, in the form:
+
+ {
+ file => # name of file that was changed
+ action => # either "add", "change", or "remove"
+ path => # temp file containing the new file content, only
+ # needed for "add"/"change", and only if the file
+ # is an attachment, not a page
+ }
+
+The list will then be checked to make sure that each change is one that
+is allowed to be made via the web interface.
+
### PageSpec plugins
It's also possible to write plugins that add new functions to
@@ -847,3 +909,82 @@ to a hash containing all the config items. They should also implement a
By the way, to parse a ikiwiki setup file and populate `%config`, a
program just needs to do something like:
`use IkiWiki::Setup; IkiWiki::Setup::load($filename)`
+
+### Function overriding
+
+Sometimes using ikiwiki's pre-defined hooks is not enough. Your plugin
+may need to replace one of ikiwiki's own functions with a modified version,
+or wrap one of the functions.
+
+For example, your plugin might want to override `displaytime`, to change
+the html markup used when displaying a date. Or it might want to override
+`IkiWiki::formattime`, to change how a date is formatted. Or perhaps you
+want to override `bestlink` and change how ikiwiki deals with [[WikiLinks|ikiwiki/WikiLink]].
+
+By venturing into this territory, your plugin is becoming tightly tied to
+ikiwiki's internals. And it might break if those internals change. But
+don't let that stop you, if you're brave.
+
+Ikiwiki provides an `inject()` function, that is a powerful way to replace
+any function with one of your own. This even allows you to inject a
+replacement for an exported function, like `bestlink`. Everything that
+imports that function will get your version instead. Pass it the name of
+the function to replace, and a new function to call.
+
+For example, here's how to replace `displaytime` with a version using HTML 5
+markup:
+
+ inject(name => 'IkiWiki::displaytime', call => sub {
+ return "";
+ });
+
+Here's how to wrap `bestlink` with a version that tries to handle
+plural words:
+
+ my $origbestlink=\&bestlink;
+ inject(name => 'IkiWiki::bestlink', call => \&mybestlink);
+
+ sub deplural ($) {
+ my $word=shift;
+ $word =~ s/e?s$//; # just an example :-)
+ return $word;
+ }
+
+ sub mybestlink ($$) {
+ my $page=shift;
+ my $link=shift;
+ my $ret=$origbestlink->($page, $link);
+ if (! length $ret) {
+ $ret=$origbestlink->($page, deplural($link));
+ }
+ return $ret;
+ }
+
+### Javascript
+
+Some plugins use javascript to make ikiwiki look a bit more web-2.0-ish.
+
+All javascript code should be put in `.js` files in the `javascript`
+underlay, and plugins using those files can enable use of the underlay by
+calling `add_underlay("javascript");` in their `import` function.
+
+You'll have to arrange for `
+ -
+ -EOF
+ + $form->field("do") eq "create" ||
+ + $form->field("do") eq "comment";
+ +
+ + my $useAPI = $config{wmd_use101api}?'true':'false';
+ + my $ikiwikijs = urlto("ikiwiki.js", undef, 1);
+ + my $wmdIkiwikijs = urlto("wmd-ikiwiki.js", undef, 1);
+ + my $wmdjs = urlto("wmd.js", undef, 1);
+ +
+ + my $previewScripts = <<"EOS";
+ +
+ +
+ +
+ +
+ +EOS
+ +
+ + $form->tmpl_param("wmd_preview", $previewScripts);
+ }
+
+ 1
+ diff --git a/doc/style.css b/doc/style.css
+ index a6e6734..36c2b13
+ --- a/doc/style.css
+ +++ b/doc/style.css
+ @@ -76,9 +76,16 @@ div.tags {
+ float: right;
+ }
+
+ +/*
+ #editcontent {
+ width: 100%;
+ }
+ +*/
+ +
+ +#wmd-preview-container {
+ + width: 49%;
+ + float: right;
+ +}
+
+ img {
+ border-style: none;
+ diff --git a/templates/editpage.tmpl b/templates/editpage.tmpl
+ index b1cf015..1d2f080 100644
+ --- a/templates/editpage.tmpl
+ +++ b/templates/editpage.tmpl
+ @@ -15,6 +15,14 @@ Page type:
+
+
+
+ +
+ +
+ +
+
+
+ Optional comment about this change:
diff --git a/doc/todo/mercurial.mdwn b/doc/todo/mercurial.mdwn
index f0dbf9806..e71c8106a 100644
--- a/doc/todo/mercurial.mdwn
+++ b/doc/todo/mercurial.mdwn
@@ -14,6 +14,10 @@
It seems that with the current mercurial commit code, it will always
blindly overwrite the current file with the web edited version, losing
any other changes.
+* `rcs_commit_staged`, `rcs_rename`, `rcs_remove`, and `rcs_diff` are not
+ implemented for mercurial, and so attachments, remove and rename plugins
+ and recentchangesdiff cannot be used with it. (These should be fairly
+ easy to add..)
Posthook: in `$srcdir/.hg/hgrc`, I have the following
@@ -29,6 +33,62 @@ This should update the working directory and run ikiwiki every time a change is
> It can deadlock if the post-commit hook runs with --refresh in the
> former case. --[[Joey]]
+The problem with --post-commit is that if you delete some pages in $SRC, ikiwiki --setup setupfile --post-commit will not delete them in $DEST. --[[users/weakish]]
+
+> You should really be using a setup file that has `mercurial_wrapper`
+> set, and running the wrapper generated by that from your hook.
+> That will work. I think that the `--setup --post-commit` on the command
+> line is currently broken and does the same expensive rebuild process as --setup
+> alone (which doesn't delete files from $DEST either). Will fix that.
+> (fixed)
+> --[[Joey]]
+
+>> Mercurial doesn't support put hooks in .hg/hooks/* (like git). In Mercurial, the only way to run
+>> your own hooks is specifying them in the hgrc file. (Or write a new extension.)
+>> I guess use a very long command will work.
+>> (e.g. ikiwiki --post-commit --a-lot-of-switches --set var=value $SRC $DEST)
+>> (Fortunately ikiwiki supports --set var=value so without --setup works.)
+>>
+>> Alternative is always editing via cgi or pushing. Never work on the $SRC/repo directly.
+>> --[[users/weakish]]
+
+>>> I don't see anything preventing you from using a setup file with
+>>> `mercurial_wrapper => ".hg/ikiwiki-hook",` and then modifying the hgrc
+>>> to run that wrapper. --[[Joey]]
+
+>> Thanks for pointing out this. I have some stupid misunderstanding on the
+>> usage of mercurial_wrapper before. The wrapper works nicely! --[[weakish]]
+
+I add the following to .hg/hgrc:(I use changegroup since I don't think we need refresh per changeset, please point out if I am wrong.)
+
+ [hooks]
+ changegroup = hg update >&2 && ikiwiki --setup path.to.setup.file --refresh
+ post-commit = path.to.the.mercurial.wrapper
+
+-----
+
+I have no idea when the deadlock will happen. --[[users/weakish]]
+
+> For the deadlock to occur, a edit has to be made via the web.
+>
+> Ikiwiki,
+> running as a CGI, takes a lock on the wiki, and commits the edit,
+> continuing to run in the background, with the lock still held.
+> When the edit is committed, the hg hook runs, running `ikwiki --refresh`.
+> Nearly the first thing that process does it try to lock the wiki..
+> which is already locked. This lock is taken in a blocking manner,
+> thus the deadlock -- the cgi is waiting for the commit to finish before
+> dropping the lock, and the commit is blocked waiting for the lock to be
+> released.
+>
+> --post-commit avoids this problem by checking if the cgi is running
+> and avoiding doing anything in that case. (While still handing the
+> refresh if the commit was not made by the CGI.)
+> So in that case, the commit finishes w/o ikiwiki doing anything,
+> and the ikiwiki CGI handles the wiki refresh.
+> --[[Joey]]
+
+
***
I have a few notes on mercurial usage after trying it out for a while:
diff --git a/doc/todo/meta_rcsid.mdwn b/doc/todo/meta_rcsid.mdwn
index 81a2c1328..158edea6e 100644
--- a/doc/todo/meta_rcsid.mdwn
+++ b/doc/todo/meta_rcsid.mdwn
@@ -26,7 +26,7 @@ of CVS/SVN-style keywords (like '$Id$', etc.) from the source file in the page t
my %copyright;
+my %rcsid;
- sub import { #{{{
+ sub import {
hook(type => "preprocess", id => "meta", call => \&preprocess, scan => 1);
@@ -110,6 +111,9 @@
$meta{$page}.="\n";
diff --git a/doc/todo/missingparents.pm.mdwn b/doc/todo/missingparents.pm.mdwn
index 0cc7137ba..c5f2ab535 100644
--- a/doc/todo/missingparents.pm.mdwn
+++ b/doc/todo/missingparents.pm.mdwn
@@ -82,15 +82,15 @@ Index: IkiWiki/Plugin/missingparents.pm
+my %ownfiles;
+my @pagespecs;
+
-+sub import { #{{{
++sub import {
+ hook(type => "checkconfig", id => "missingparents", call => \&checkconfig);
+ hook(type => "needsdelete", id => "missingparents", call => \&needsdelete);
+ hook(type => "needsbuild", id => "missingparents", call => \&needsbuild);
+ hook(type => "savestate", id => "missingparents", call => \&savestate);
+ hook(type => "preprocess", id => "missingparents", call => \&preprocess_missingparents);
-+} # }}}
++}
+
-+sub checkconfig () { #{{{
++sub checkconfig () {
+ IkiWiki::preprocess("missingparents", "missingparents",
+ readfile(srcfile("missingparents.mdwn")));
+ loadstate();
@@ -99,9 +99,9 @@ Index: IkiWiki/Plugin/missingparents.pm
+ unlink $config{srcdir}.'/'.$file;
+ }
+ }
-+} #}}}
++}
+
-+sub preprocess_missingparents (@) { #{{{
++sub preprocess_missingparents (@) {
+ my %params=@_;
+
+ if (! defined $params{pages} || ! defined $params{generate}) {
@@ -115,10 +115,10 @@ Index: IkiWiki/Plugin/missingparents.pm
+ #translators: is text for pages that match that pagespec.
+ return sprintf(gettext("missingparents in %s will be %s"),
+ '`'.$params{pages}.'`', '`\\'.$params{generate}.'`');
-+} # }}}
++}
+
+my $state_loaded=0;
-+sub loadstate() { #{{{
++sub loadstate() {
+ my $filename = "$config{wikistatedir}/missingparents";
+ if (-e $filename) {
+ open (IN, $filename) ||
@@ -132,9 +132,9 @@ Index: IkiWiki/Plugin/missingparents.pm
+
+ $state_loaded=1;
+ }
-+} #}}}
++}
+
-+sub savestate() { #{{{
++sub savestate() {
+ my $filename = "$config{wikistatedir}/missingparents.new";
+ my $cleanup = sub { unlink ($filename) };
+ open (OUT, ">$filename") || error("open $filename: $!", $cleanup);
@@ -143,9 +143,9 @@ Index: IkiWiki/Plugin/missingparents.pm
+ }
+ rename($filename, "$config{wikistatedir}/missingparents") ||
+ error("rename $filename: $!", $cleanup);
-+} #}}}
++}
+
-+sub needsdelete (@) { #{{{
++sub needsdelete (@) {
+ my $files=shift;
+
+ my @mydel;
@@ -167,9 +167,9 @@ Index: IkiWiki/Plugin/missingparents.pm
+ foreach my $page (@mydel){
+ push @{$files}, $page;
+ }
-+} #}}}
++}
+
-+sub check_matches($) { #{{{
++sub check_matches($) {
+ my $page = shift;
+ return if $IkiWiki::pagesources{$page};
+
@@ -183,9 +183,9 @@ Index: IkiWiki/Plugin/missingparents.pm
+ return $output;
+ }
+ return "";
-+} #}}}
++}
+
-+sub needsbuild ($) { #{{{
++sub needsbuild ($) {
+ my $files=shift;
+ my @new;
+
@@ -209,7 +209,7 @@ Index: IkiWiki/Plugin/missingparents.pm
+ $ownfiles{$file} = 1;
+ push @{$files}, $file;
+ }
-+} #}}}
++}
+
+1
Index: IkiWiki.pm
@@ -227,18 +227,18 @@ Index: IkiWiki.pm
our $version='unknown'; # VERSION_AUTOREPLACE done by Makefile, DNE
@@ -330,6 +336,30 @@
error("failed renaming $newfile to $destdir/$file: $!", $cleanup);
- } #}}}
+ }
-+sub newpage($$) { #{{{
++sub newpage($$) {
+ my $file=shift;
+ my $page=shift;
+
+ $pagemtime{$page} = $pagectime{$page} = time;
+ $pagesources{$page} = $file;
+ $pagecase{lc $page} = $page;
-+} #}}}
++}
+
-+sub delpage($) { #{{{
++sub delpage($) {
+ my $page=shift;
+ $links{$page}=[];
+ $renderedfiles{$page}=[];
@@ -251,10 +251,10 @@ Index: IkiWiki.pm
+ delete $destsources{$_};
+ }
+ }
-+} #}}}
++}
+
my %cleared;
- sub will_render ($$;$) { #{{{
+ sub will_render ($$;$) {
my $page=shift;
diff --git a/doc/todo/modify_page_filename_in_plugin.mdwn b/doc/todo/modify_page_filename_in_plugin.mdwn
index 7c0a909eb..a13c8b62f 100644
--- a/doc/todo/modify_page_filename_in_plugin.mdwn
+++ b/doc/todo/modify_page_filename_in_plugin.mdwn
@@ -6,11 +6,13 @@ The problem is that I occasionally have xxx.c and xxx.h in the same directory an
My solution is to allow plugins to provide a hook that sets the pagename. --[[/users/bstpierre]]
+> You might also find the solution to [[bugs/multiple_pages_with_same_name]] helps you. That patch is already applied. -- [[Will]]
+
--- /usr/share/perl5/IkiWiki.pm.ORIG 2008-10-03 14:12:50.000000000 -0400
+++ /usr/share/perl5/IkiWiki.pm 2008-10-07 11:57:26.000000000 -0400
@@ -196,11 +196,32 @@
- sub pagename ($) { #{{{
+ sub pagename ($) {
my $file=shift;
my $type=pagetype($file);
@@ -27,7 +29,7 @@ My solution is to allow plugins to provide a hook that sets the pagename. --[[/u
$page=~s/\Q.$type\E*$// if defined $type;
return $page;
+ }
- } #}}}
+ }
- sub htmlpage ($) { #{{{
+ sub htmlpage ($) {
diff --git a/doc/todo/natural_sorting.mdwn b/doc/todo/natural_sorting.mdwn
new file mode 100644
index 000000000..5df17e95b
--- /dev/null
+++ b/doc/todo/natural_sorting.mdwn
@@ -0,0 +1,21 @@
+[[!tag wishlist]]
+[[!tag patch]]
+
+the inline plugin's sorting is plain lexical, thich may not be appropriate for
+page titles if they have numeric components. the
+[Sort::Naturally](http://search.cpan.org/dist/Sort-Naturally/) perl module
+provides an algorithm for that.
+
+there is a
+[patch](http://git.ikiwiki.info/?p=ikiwiki;a=commit;h=55b83cb7bd1cd7c60bb45dc22c3745dd80a63fed)
+attached that makes the [[plugins/inline]] plugin use Sort::Naturally if sort
+is set to "title_natural".
+
+the current patch uses `require Sort::Naturally`, so
+[libsort-naturally-perl](http://packages.debian.org/libsort-naturally-perl)
+does not become a dependency; it might be worth suggesting, though.
+
+> See also: [[inline:_numerical_ordering_by_title]] (I probably prefer your
+> approach..) --[[Joey]]
+
+> [[applied|done]]
diff --git a/doc/todo/need_global_renamepage_hook.mdwn b/doc/todo/need_global_renamepage_hook.mdwn
new file mode 100644
index 000000000..b123340af
--- /dev/null
+++ b/doc/todo/need_global_renamepage_hook.mdwn
@@ -0,0 +1,115 @@
+As documented in [[plugins/write]], the current `renamepage` hook is
+heavily oriented towards updating links in pages' content: it is run
+once per page linking to the renamed page.
+
+That's fine, but it can't be used to trigger more general actions on
+page rename. E.g. it won't be run at all if the page being renamed is
+an orphan one.
+
+This is a real issue for the [[plugins/contrib/po]] development: what
+I'm about to achieve is:
+
+- when a master page is renamed, the plugin takes notice of it (using
+ the `rename` hook), and later renames the translation pages
+ accordingly (in the `change` hook)
+- when a master page is deleted, the plugin deletes its translations
+ (using the `delete` hook)
+
+With the current `renamepage` hook behavior, combining these two goals
+has an annoying drawback: a plugin can't notice an orphan master page
+has been renamed, so instead of renaming (and preserving) its
+translations, it considers the oldpage as deleted, and deletes its
+translations. Game over.
+
+It may seem like a corner case, but I want to be very careful when
+deleting files automatically in `srcdir`, which is not always under
+version control.
+
+As a sad workaround, I can still disable any deletion in `srcdir`
+when it is not under version control. But I think ikiwiki deserves
+a global `renamepage` hook that would be run once per rename
+operation.
+
+My proposal is thus:
+
+- keep the documented `renamepage` hook as it is
+- use something inspired by the trick `preprocess` uses: when `hook`
+ is passed an optional "global" parameter, set to a true value, the
+ declared `renamepage` hook is run once per rename operation, and is
+ passed named parameters: `src`, `srcfile`, `dest` and `destfile`.
+
+I'm of course volunteering to implement this, or anything related that
+would solve my problem. Hmmm? --[[intrigeri]]
+
+> I think it would be better to have a different hook that is called for
+> renames, since the two hook actions are very different (unlike the
+> preprocess hook, which does a very similar thing in scan mode).
+>
+> Just calling it `rename` seems like a reasonable name, by analogy with
+> the `delete` and `change` hooks.
+>
+> It might make sense to rename `renamepage` to `renamelink` to make it
+> clearer what it does. (I'm not very worried about this breaking things, at
+> this point.) --[[Joey]]
+
+>> In my `po` branch, I renamed `renamepage` to `renamelink`, and
+>> created a `rename` hook that is passed a reference to `@torename`.
+>> --[[intrigeri]]
+
+>>> As Joey highlights it on [[plugins/contrib/po]], it's too late to
+>>> merge such a change, as the 3.x plugin API is released and should
+>>> not be broken. I will thus keep the existing `renamepage` as it
+>>> is, and call `rename` the global hook I need. --[[intrigeri]]
+
+>>>> Done in my `po` branch. --[[intrigeri]]
+
+I think I see a problem in the rename hook. The hook is called
+before the plugin adds any subpages to the set of pages to rename.
+So, if the user choses to rename subpages, po will not notice
+they are moving, and will not move their po files.
+
+Perhaps the hooks should be moved to come after subpages are added.
+This would, though, mean that if the hook somehow decides to add
+entirely other pages to the list, their subpages would not be
+automatically added.
+
+I also have some qualms about the design of the hook. In particular,
+passing the mutable array reference probably makes it impossible
+to use from external plugins. Instead it could return any additional
+rename hashes it wants to add. Or, if the ability to modify existing
+hashes is desired, it could return the full set of hashes.
+
+--[[Joey]]
+
+> I fixed the last part, i.e. a rename hook function now returns the
+> full set of hashes. As I also converted it to take named parameters,
+> such a function still is passed a reference to the original array,
+> though, because one can't build a hash containing an array of hashes
+> as a value, without passing this array as a reference.
+>
+>> Sure.
+>
+> I'm not entirely sure about your first concern. Calling the hook
+> before or after the subpages addition both have their own problems.
+>
+> What about running the hook before *and* after the subpages
+> addition, with an additional `when` named parameter, so that
+> a given hook function can choose to act only before or after, or both?
+>
+> --[[intrigeri]]
+>>
+>> Have you thought about making the hook be run once *per* file that is
+>> selected to be renamed? This would even handle the case where two
+>> plugins use the hook; plugin A would see when plugin B adds a new file
+>> to be renamed. And the subpage renaming stuff could probably be moved
+>> into the rename hook too. --[[Joey]]
+>>>
+>>> I've implemented this nice solution in my po branch, please review.
+>>> I'm slowly coming back to do the last bits needed to get my po and
+>>> meta branch merged. --[[intrigeri]]
+
+>>>> It looks good. I made some small changes to it in my own po branch.
+>>>> Nothing significant really. If this were not tied up in the po branch,
+>>>> I've have merged it to master already. --[[Joey]]
+
+>>>> Thanks, this is great :) --[[intrigeri]]
diff --git a/doc/todo/overriding_displayed_modification_time.mdwn b/doc/todo/overriding_displayed_modification_time.mdwn
new file mode 100644
index 000000000..160d31519
--- /dev/null
+++ b/doc/todo/overriding_displayed_modification_time.mdwn
@@ -0,0 +1,27 @@
+Some aggregators, like Planet, sort by mtime rather than ctime. This
+means that posts with modified content come to the top (which seems odd
+to me, but is presumably what the aggregator's author or operator
+wants),
+
+> Hah! That's so charitable I hope you can deduct it from your taxes. ;-)
+> --[[Joey]]
+
+but it also means that posts with insignificant edits (like
+adding tags) come to the top too. Atom defines `` to be the date
+of the last *significant* change, so it's fine that ikiwiki defaults to
+using the mtime, but it would be good to have a way for the author to
+say "that edit was insignificant, don't use that mtime".
+
+> Yes, this is a real limitiation of ikiwiki's atom support. --[[Joey]]
+
+See smcv's 'updated' branch for a basic implementation, which only affects
+the Atom `` field or the RSS equivalent.
+
+Other places the updated metadata item could be used (opinions on whether
+each should use it or not, please):
+
+* sorting by mtime in the inline directive
+* displaying "last edited" on ordinary pages
+
+> Tending toward no for both, but willing to be convinced otherwise..
+> [[merged|done]] --[[Joey]]
diff --git a/doc/todo/pagespec_relative_to_a_target.mdwn b/doc/todo/pagespec_relative_to_a_target.mdwn
index f7b248670..4757988e0 100644
--- a/doc/todo/pagespec_relative_to_a_target.mdwn
+++ b/doc/todo/pagespec_relative_to_a_target.mdwn
@@ -57,7 +57,7 @@ diff -urNX ignorepats ikiwiki/IkiWiki/Plugin/relative.pm ikidev/IkiWiki/Plugin/r
+
+package IkiWiki::PageSpec;
+
-+sub match_relative($$;@) { #{{{
++sub match_relative($$;@) {
+ my $parent = shift;
+ my $spec = shift;
+ my %params = @_;
@@ -69,21 +69,21 @@ diff -urNX ignorepats ikiwiki/IkiWiki/Plugin/relative.pm ikidev/IkiWiki/Plugin/r
+ }
+ }
+ return IkiWiki::FailReason->new("$parent can't match $spec against anything");
-+} #}}}
++}
+
-+sub match_has_child($$;@) { #{{{
++sub match_has_child($$;@) {
+ my $page = shift;
+ my $childname = shift;
+ my $spec;
-+ if ($childname) { #{{{
++ if ($childname) {
+ $spec = "$page/$childname or $page/*/$childname";
-+ } #}}}
-+ else { #{{{
++ }
++ else {
+ $spec = "$page/*";
-+ } #}}}
++ }
+
+ return match_relative($page, $spec, @_);
-+} #}}}
++}
+
+1
diff --git a/doc/todo/pingback_support.mdwn b/doc/todo/pingback_support.mdwn
new file mode 100644
index 000000000..b10366bda
--- /dev/null
+++ b/doc/todo/pingback_support.mdwn
@@ -0,0 +1,39 @@
+A "pingback" is a system whereby URLs you might reference in a blog post are
+contacted by the blog publishing software at publishing time (i.e., once) so
+that they might update a list of "pingbacks" to the URL. The originating
+URL's blog software might then display a list of pingbacks, or an excerpt of
+the text from your blog, perhaps interleaved with comments, etc.
+
+At a technical level, external URLs are extracted from your blog post by the
+blogging software, fetched, inspected for information to determine whether the
+remote server is configured to support pingbacks (look for link tags, or HTTP
+headers) and the relevant pingback URL sent an XML-RPC packet.
+
+There are other technologies to achieve the same thing: trackbacks predate
+pingbacks but are more vulnerable to spam due to design problems.
+
+The spec for pingbacks is at .
+
+I would like to somehow use pingbacks in conjunction with ikiwiki. I suppose
+this could be achieved using a commit hook and some external software in which
+case I will consider this done with an entry in [[tips]]; otherwise a
+[[plugins|plugin]] to implement pingbacks would be great.
+
+-- [[Jon]] (Wed Jan 14 13:48:47 GMT 2009)
+
+> I think it's now possible to implement trackback and pingback receiving
+> support in ikiwiki. One easy way to do it would be to hook it into the
+> existing [[plugins/comments]] plugin -- each pingback/trackback that
+> ikiwiki recieves would result in the creation if a new comment, which
+> would be subject to the usual comment filtering (ie, blogspam) and
+> moderation and would then show up amoung the other, regular comments on
+> the page.
+>
+> (One wrinkle: would need to guard against duplicate pings. Maybe by
+> checking existing comments for any that have the same url?)
+>
+> As for sending trackbacks and pingbacks, this could fairly easily be
+> implemented using a `editcontent` hook. Since this hook is called
+> whenever a page is posted or edited, and gets the changed content, it can
+> simply scan it for urls (may have to htmlize first?), and send pings to
+> all urls found. --[[Joey]]
diff --git a/doc/todo/plugin.mdwn b/doc/todo/plugin.mdwn
index 132de4480..b3e3a7889 100644
--- a/doc/todo/plugin.mdwn
+++ b/doc/todo/plugin.mdwn
@@ -70,10 +70,6 @@ Suggestions of ideas for plugins:
> web-server-specific code to list all users, and openid can't feasibly do so
> at all. --[[JoshTriplett]]
-* 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?
- Using a plugin?
-
* For PlaceWiki I want to be able to do some custom plugins, including one
that links together subpages about the same place created by different
users. This seems to call for a plugin that applies to every page w/o any
diff --git a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn
index 7724576f5..39a35d0c6 100644
--- a/doc/todo/provide_inline_diffs_in_recentchanges.mdwn
+++ b/doc/todo/provide_inline_diffs_in_recentchanges.mdwn
@@ -1,3 +1,8 @@
It would rock if I could view diffs from the web without going via feeds. I envision toggle-style buttons on the recentchanges page, or just links to the CGI, which then displays the diff... --[[madduck]]
+> The diffs are actually there, enabled by the `recentchangesdiff`
+> plugin, but they are hidden in the XHTML version by the stylesheet.
+> You might try a user stylesheet with `div.diff { display: block }`.
+> --[[JasonBlevins]]
+
[[!tag wishlist]]
diff --git a/doc/todo/provide_sha1_for_git_diffurl.mdwn b/doc/todo/provide_sha1_for_git_diffurl.mdwn
new file mode 100644
index 000000000..01aa512f8
--- /dev/null
+++ b/doc/todo/provide_sha1_for_git_diffurl.mdwn
@@ -0,0 +1,26 @@
+This [[patch]] allows for `\[[sha1]]` substitution in the `diffurl`
+for git repositories. This is useful for use with [cgit][] which has
+diffurls of the following form:
+
+ /project.git/diff/\[[file]]?id=\[[sha1_commit]]
+
+ [cgit]: http://hjemli.net/git/cgit/
+
+ diff --git a/IkiWiki/Plugin/git.pm b/IkiWiki/Plugin/git.pm
+ index 5bef928..164210d 100644
+ --- a/IkiWiki/Plugin/git.pm
+ +++ b/IkiWiki/Plugin/git.pm
+ @@ -518,6 +518,7 @@ sub rcs_recentchanges ($) {
+
+ my $diffurl = defined $config{'diffurl'} ? $config{'diffurl'} : "";
+ $diffurl =~ s/\[\[file\]\]/$file/go;
+ + $diffurl =~ s/\[\[sha1\]\]/$sha1/go;
+ $diffurl =~ s/\[\[sha1_parent\]\]/$ci->{'parent'}/go;
+ $diffurl =~ s/\[\[sha1_from\]\]/$detail->{'sha1_from'}/go;
+ $diffurl =~ s/\[\[sha1_to\]\]/$detail->{'sha1_to'}/go;
+
+> [[done]], but I called it `sha1_commit` since I think that's what it's
+> actually a sha1 of. --[[Joey]]
+
+>> I was at a loss for something more descriptive...I like that much
+>> better :) Thanks! --[[JasonBlevins]]
diff --git a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn b/doc/todo/rcs_updates_needed.mdwn
similarity index 54%
rename from doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn
rename to doc/todo/rcs_updates_needed.mdwn
index 2af659c3b..472a5800f 100644
--- a/doc/todo/rcs_updates_needed_for_rename_and_remove.mdwn
+++ b/doc/todo/rcs_updates_needed.mdwn
@@ -3,3 +3,8 @@ renaming and removing files using the web interface. The mercurial and
tla [[rcs]] backends need implementions of these functions.
(The maintainers of these backends have been mailed. --[[Joey]])
+
+Also, currently git is the only VCS to have support for
+[[untrusted_push|tips/untrusted_git_push]]. It _may_ be possible to
+implement it for other DVCS, if they offer a hook that can be used to check
+incoming pushes early.
diff --git a/doc/todo/redirect_automatically_after_rename.mdwn b/doc/todo/redirect_automatically_after_rename.mdwn
new file mode 100644
index 000000000..1cbb824d2
--- /dev/null
+++ b/doc/todo/redirect_automatically_after_rename.mdwn
@@ -0,0 +1,10 @@
+In some wikis, (e.g. Mediawiki) after [[renaming|plugins/rename]]
+a page, the old page still exist but only redirect to the
+new page. This is convenient since external sites may
+have links pointing to the old url.
+
+If [[plugins/meta]] plugin is enabled, users can manually edit the
+page, and put in '\[[!meta redir=newpage]]', but this is
+not very convenient.
+
+
diff --git a/doc/todo/relative_pagespec_deficiency.mdwn b/doc/todo/relative_pagespec_deficiency.mdwn
new file mode 100644
index 000000000..4500581c7
--- /dev/null
+++ b/doc/todo/relative_pagespec_deficiency.mdwn
@@ -0,0 +1,8 @@
+While a relative pagespec like `./posts/*` will work, when used in a page
+such as `bdale/blog`, you cannot do
+`created_after(./posts/foo)` -- only `glob()` supports relative page
+references.
+
+The other pagespec functions should too, where appropriate.
+
+[[done]]
diff --git a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
index dfeacbabd..c4e78ca0b 100644
--- a/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
+++ b/doc/todo/replace_HTML::Template_with_Template_Toolkit.mdwn
@@ -54,3 +54,7 @@ the templates. I'd prefer not having to touch Perl though...
-----
Yes, Template::Toolkit is very powerful. But I think it's somehow overkill for a wiki. HTML::Template can keep things simple, though. --[weakish](http://weakish.int.eu.org/blog/)
+
+I'd have to agree that Template::Toolkit is overkill and personally I'm not a fan, but it is very popular (there is even a book) and the new version (3) is alleged to be much more nimble than current version. --[[ajt]]
+
+HTML::Template's HTML-like markup prevents me from editing templates in KompoZer or other WYSIWYG HTML editors. The editor tries to render the template markup rather than display it verbatim, and large parts of the template become invisible. A markup syntax that doesn't confuse editors (such as Template::Toolkit's "[% FOO %]") may promote template customization. The ability to replace the template engine would be within the spirit of ikiwiki's extensibility. --Rocco
diff --git a/doc/todo/require_CAPTCHA_to_edit.mdwn b/doc/todo/require_CAPTCHA_to_edit.mdwn
index 110b4167f..83ba07eb0 100644
--- a/doc/todo/require_CAPTCHA_to_edit.mdwn
+++ b/doc/todo/require_CAPTCHA_to_edit.mdwn
@@ -91,15 +91,15 @@ ignored.
--- a/IkiWiki/Plugin/openid.pm
+++ b/IkiWiki/Plugin/openid.pm
-@@ -18,6 +18,7 @@ sub getopt () { #{{{
+@@ -18,6 +18,7 @@ sub getopt () {
error($@) if $@;
Getopt::Long::Configure('pass_through');
GetOptions("openidsignup=s" => \$config{openidsignup});
+ GetOptions("openidneedscaptcha=s" => \$config{openidneedscaptcha});
- } #}}}
+ }
- sub formbuilder_setup (@) { #{{{
-@@ -61,6 +62,7 @@ sub formbuilder_setup (@) { #{{{
+ sub formbuilder_setup (@) {
+@@ -61,6 +62,7 @@ sub formbuilder_setup (@) {
# Skip all other required fields in this case.
foreach my $field ($form->field) {
next if $field eq "openid_url";
@@ -107,7 +107,7 @@ ignored.
$form->field(name => $field, required => 0,
validate => '/.*/');
}
-@@ -96,6 +98,18 @@ sub validate ($$$;$) { #{{{
+@@ -96,6 +98,18 @@ sub validate ($$$;$) {
}
}
@@ -152,19 +152,19 @@ use warnings;
use strict;
use IkiWiki 2.00;
-sub import { #{{{
+sub import {
hook(type => "formbuilder_setup", id => "recaptcha", call => \&formbuilder_setup);
-} # }}}
+}
-sub getopt () { #{{{
+sub getopt () {
eval q{use Getopt::Long};
error($@) if $@;
Getopt::Long::Configure('pass_through');
GetOptions("reCaptchaPubKey=s" => \$config{reCaptchaPubKey});
GetOptions("reCaptchaPrivKey=s" => \$config{reCaptchaPrivKey});
-} #}}}
+}
-sub formbuilder_setup (@) { #{{{
+sub formbuilder_setup (@) {
my %params=@_;
my $form=$params{form};
@@ -274,7 +274,7 @@ EOTAGS
});
}
}
-} # }}}
+}
# The following function is borrowed from
# Captcha::reCAPTCHA by Andy Armstrong and are under the PERL Artistic License
diff --git a/doc/todo/rewrite_ikiwiki_in_haskell.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
new file mode 100644
index 000000000..204c48cd7
--- /dev/null
+++ b/doc/todo/rewrite_ikiwiki_in_haskell.mdwn
@@ -0,0 +1,68 @@
+[[!tag wishlist blue-sky]]
+
+In the long term, I have been considering rewriting ikiwiki in haskell.
+It's appealing for a lot of reasons, including:
+
+* No need to depend on a C compiler and have wrappers. Instead, ikiwiki
+ binaries could be built on demand to do the things wrappers are used for
+ now (cgi, post-commit, etc).
+* Potentially much faster. One problem with the now very modular ikiwiki is
+ that it has to load up dozens of perl modules each time it runs, which
+ means both opening lots of files and evaluating them. A haskell version
+ could run from one pre-compiled file. Other speed efficienies are also
+ likely with haskell. For example, pandoc is apparently an order of
+ magnitude faster than perl markdown implementations.
+* Many plugins could be written in pure functional code, with no side
+ effects. Not all of them, of course.
+* It should be much easier to get ikiwiki to support parallel compilation
+ on multi-core systems using haskell.
+* A rewrite would be an opportunity to utterly break compatability and
+ redo things based on experience. Since the haskell libraries used for
+ markdown, templates, etc, are unlikely to be very compatable with the perl
+ versions, and since perl plugins obviously wouldn't work, and perl setup
+ files wouldn't be practical to keep, a lot of things would unavoidably
+ change, and at that point changinge everything else I can think of
+ probably wouldn't hurt (much).
+
+ - Re templates, it would be nice to have a template library that
+ doesn't use html-ish templating tags, since those are hard for users to
+ edit in html editors currently.
+ - This would be a chance to make WikiLinks with link texts read
+ "the right way round" (ie, vaguely wiki creole compatably).
+ - The data structures would probably be quite different.
+ - I might want to drop a lot of the command-line flags, either
+ requiring a setup file be used for those things, or leaving the
+ general-purpose `--set var=value` flag.
+ - Sometimes the current behavior of `--setup` seems confusing; it might
+ only cause a setup file to be read, and not force rebuild mode.
+ - Hard to say how the very high level plugin interface design would change,
+ but at the least some of the names of hooks could stand a rename, and
+ their parameter passing cleaned up.
+
+We know that a big, break-the-world rewrite like this can be a very
+bad thing for a project to attempt. It would be possible to support
+external plugins written in haskell today, without any rewrite; and a few
+of the benefits could be obtained by, eg, making the mdwn plugin be a
+haskell program that uses pandoc. I doubt that wouod be a good first step
+to converting ikiwiki to haskell, because such a program would have very
+different data structures and intercommuniucation than a pure haskell
+version.
+
+Some other things to be scared about:
+
+* By picking perl, I made a lot of people annoyed (and probably turned
+ several people away from using ikiwiki). But over time there turned out
+ to be a lot of folks who knew perl already (even if rustily), and made
+ some *very* useful contributions. I doubt there's as large a pool of haskell
+ programmers, and it's probably harder for a python user to learn haskell
+ than perl if they want to contribute to ikiwiki.
+* It might be harder for users of hosting services to install a haskell based
+ ikiwiki than the perl version. Such systems probably don't have ghc and
+ a bunch of haskell libraries. OTOH, it might be possible to build a
+ static binary at home and upload it, thus avoiding a messy installation
+ procedure entirely.
+* I can barely code in haskell yet. I'm probably about 100x faster at
+ programming in perl. I need to get some more practical experience before
+ I´m fast and seasoned enough in haskell to attempt such a project.
+ (And so far, progress at learning has been slow and I have not managed
+ to write anything serious in haskell.) --[[Joey]]
diff --git a/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
new file mode 100644
index 000000000..1edebe4e8
--- /dev/null
+++ b/doc/todo/rewrite_ikiwiki_in_haskell/discussion.mdwn
@@ -0,0 +1,14 @@
+Ok, I have to admit, I have no idea if this is an April fool's joke or not.
+Congratulations for demonstrating that April fools jokes can still be subtle
+(whether intentionally or not!) -- [[Jon]]
+
+> Having said all that, have you looked at erlang? Have you heard of couchdb?
+> I'd strongly recommend looking at that. -- [[Jon]]
+
+>> I've glanced at couchdb, but don't see how it would tie in with ikiwiki.
+>> --[[Joey]]
+
+
+>>> It doesn't really. I recently (re-)read about couchdb and thought that
+>>> what it was trying to do had some comparisons with the thinking going on
+>>> in [[todo/structured_page_data]]. -- [[Jon]]
diff --git a/doc/todo/source_link.mdwn b/doc/todo/source_link.mdwn
index 93791c81a..b051361a8 100644
--- a/doc/todo/source_link.mdwn
+++ b/doc/todo/source_link.mdwn
@@ -1,6 +1,6 @@
How about a direct link from the page header to the source of the latest version, to avoid the need to either use edit or navigate to the current version via the history link?
- I'd like this too (and might try to implement it). -- [[jondowland]]
+ I'd like this too (and might try to implement it). -- [[users/jon]]
I just implemented this. There is one [[patch]] to the default page template, and a new plugin. -- [[Will]]
@@ -31,13 +31,13 @@ I just implemented this. There is one [[patch]] to the default page template, a
use IkiWiki;
use open qw{:utf8 :std};
- sub import { #{{{
+ sub import {
hook(type => "getsetup", id => "getsource", call => \&getsetup);
hook(type => "pagetemplate", id => "getsource", call => \&pagetemplate);
hook(type => "sessioncgi", id => "getsource", call => \&cgi_getsource);
- } # }}}
+ }
- sub getsetup () { #{{{
+ sub getsetup () {
return
plugin => {
safe => 1,
@@ -50,9 +50,9 @@ I just implemented this. There is one [[patch]] to the default page template, a
safe => 1,
rebuild => 0,
},
- } #}}}
+ }
- sub pagetemplate (@) { #{{{
+ sub pagetemplate (@) {
my %params=@_;
my $page=$params{page};
@@ -62,9 +62,9 @@ I just implemented this. There is one [[patch]] to the default page template, a
$template->param(getsourceurl => IkiWiki::cgiurl(do => "getsource", page => $page));
$template->param(have_actions => 1);
}
- } # }}}
+ }
- sub cgi_getsource ($$) { #{{{
+ sub cgi_getsource ($$) {
my $cgi=shift;
my $session=shift;
diff --git a/doc/todo/structured_page_data.mdwn b/doc/todo/structured_page_data.mdwn
index 2a196ed23..22f67cc0a 100644
--- a/doc/todo/structured_page_data.mdwn
+++ b/doc/todo/structured_page_data.mdwn
@@ -257,21 +257,21 @@ in a large number of other cases.
use CGI::FormBuilder;
use IkiWiki 2.00;
- sub import { #{{{
+ sub import {
hook(type => "getsetup", id => "form", call => \&getsetup);
hook(type => "htmlize", id => "form", call => \&htmlize);
hook(type => "sessioncgi", id => "form", call => \&cgi_submit);
- } # }}}
+ }
- sub getsetup () { #{{{
+ sub getsetup () {
return
plugin => {
safe => 1,
rebuild => 1, # format plugin
},
- } #}}}
+ }
- sub makeFormFromYAML ($$$) { #{{{
+ sub makeFormFromYAML ($$$) {
my $page = shift;
my $YAMLString = shift;
my $q = shift;
@@ -350,9 +350,9 @@ in a large number of other cases.
# IkiWiki::decode_form_utf8($form);
return $form;
- } #}}}
+ }
- sub htmlize (@) { #{{{
+ sub htmlize (@) {
my %params=@_;
my $content = $params{content};
my $page = $params{page};
@@ -360,9 +360,9 @@ in a large number of other cases.
my $form = makeFormFromYAML($page, $content, undef);
return $form->render(submit => 'Update Form');
- } # }}}
+ }
- sub cgi_submit ($$) { #{{{
+ sub cgi_submit ($$) {
my $q=shift;
my $session=shift;
@@ -425,11 +425,11 @@ in a large number of other cases.
}
exit;
- } #}}}
+ }
package IkiWiki::PageSpec;
- sub match_form_eq ($$;@) { #{{{
+ sub match_form_eq ($$;@) {
my $page=shift;
my $argSet=shift;
my @args=split(/,/, $argSet);
@@ -460,7 +460,7 @@ in a large number of other cases.
} else {
return IkiWiki::FailReason->new("field value does not match");
}
- } #}}}
+ }
1
@@ -476,22 +476,22 @@ in a large number of other cases.
my $inTable = 0;
- sub import { #{{{
+ sub import {
hook(type => "getsetup", id => "data", call => \&getsetup);
hook(type => "needsbuild", id => "data", call => \&needsbuild);
hook(type => "preprocess", id => "data", call => \&preprocess, scan => 1);
hook(type => "preprocess", id => "datatable", call => \&preprocess_table, scan => 1); # does this need scan?
- } # }}}
+ }
- sub getsetup () { #{{{
+ sub getsetup () {
return
plugin => {
safe => 1,
rebuild => 1, # format plugin
},
- } #}}}
+ }
- sub needsbuild (@) { #{{{
+ sub needsbuild (@) {
my $needsbuild=shift;
foreach my $page (keys %pagestate) {
if (exists $pagestate{$page}{data}) {
@@ -506,7 +506,7 @@ in a large number of other cases.
}
}
- sub preprocess (@) { #{{{
+ sub preprocess (@) {
my @argslist = @_;
my %params=@argslist;
@@ -546,9 +546,9 @@ in a large number of other cases.
}
return $html;
- } # }}}
+ }
- sub preprocess_table (@) { #{{{
+ sub preprocess_table (@) {
my %params=@_;
my @lines;
@@ -568,11 +568,11 @@ in a large number of other cases.
push @lines, '';
return join("\n", @lines);
- } #}}}
+ }
package IkiWiki::PageSpec;
- sub match_data_eq ($$;@) { #{{{
+ sub match_data_eq ($$;@) {
my $page=shift;
my $argSet=shift;
my @args=split(/,/, $argSet);
@@ -592,9 +592,9 @@ in a large number of other cases.
} else {
return IkiWiki::FailReason->new("value does not match");
}
- } #}}}
+ }
- sub match_data_link ($$;@) { #{{{
+ sub match_data_link ($$;@) {
my $page=shift;
my $argSet=shift;
my @params=@_;
@@ -618,6 +618,6 @@ in a large number of other cases.
}
return IkiWiki::FailReason->new("No data link on page $page with key $key matches glob $value");
- } #}}}
+ }
1
diff --git a/doc/todo/support_creole_markup.mdwn b/doc/todo/support_creole_markup.mdwn
index b0ebf5b9e..5a1e1286d 100644
--- a/doc/todo/support_creole_markup.mdwn
+++ b/doc/todo/support_creole_markup.mdwn
@@ -12,7 +12,7 @@ And there is a perl module: Text::WikiCreole
Syntax file for vim: http://www.peter-hoffmann.com/code/vim/ (Since a typical ikiwiki user usually use external editors. :))
-> Should be pretty easy to add a plugin to do it using [[cpan
+> Should be pretty easy to add a plugin to do it using [[!cpan
> Text::WikiCreole]]. --[[Joey]]
[[done]]
diff --git a/doc/todo/supporting_comments_via_disussion_pages.mdwn b/doc/todo/supporting_comments_via_disussion_pages.mdwn
index e0495c8c2..aae0b3008 100644
--- a/doc/todo/supporting_comments_via_disussion_pages.mdwn
+++ b/doc/todo/supporting_comments_via_disussion_pages.mdwn
@@ -91,14 +91,14 @@ Each comment is processed to something like this:
use strict;
use IkiWiki '1.02';
- sub import { #{{{
+ sub import {
hook(type => "formbuilder_setup", id => "comments",
call => \&formbuilder_setup);
hook(type => "preprocess", id => "blogcomment",
call => \&preprocess);
- } # }}}
+ }
- sub formbuilder_setup (@) { #{{{
+ sub formbuilder_setup (@) {
my %params=@_;
my $cgi = $params{cgi};
my $form = $params{form};
@@ -138,9 +138,9 @@ Each comment is processed to something like this:
$content.=qq{[[!blogcomment from="""$name""" timestamp="""$timestamp""" subject="""$subject""" text="""$comment"""]]\n\n};
$content=~s/\n/\r\n/g;
$form->field(name => "editcontent", value => $content, force => 1);
- } # }}}
+ }
- sub preprocess (@) { #{{{
+ sub preprocess (@) {
my %params=@_;
my ($text, $date, $from, $subject, $r);
@@ -159,7 +159,7 @@ Each comment is processed to something like this:
$r .= "\n" . $text . "