+

+----

+

+I'm using boa and getting some odd behaviour if I don't set the `umask`

+option in the config file. Editing a page through the web interface and

+hitting "Save Page" regenerates the `index.html` file with no world-read

+permissions. As a result, the server serves a "403 - Forbidden" error page

+instead of the page I was expecting to return to.

+

+There are only two ways I found to work around this: adding a `umask 022`

+option to the config file, or re-compiling the wiki from the command line

+using `ikiwiki --setup`. Setting up a git back-end and re-running `ikiwiki

+--setup` from inside a hook had no effect; it needed to be at the terminal.

+--Paul

+

+> Since others seem to have gotten ikiwiki working with boa,

+> I'm guessing that this is not a generic problem with boa, but that

+> your boa was started from a shell that had an unusual umask and inherited

+> that. --[[Joey]]

+

+>> That's right; once I'd worked out what was wrong, it was clear that any

+>> webserver should have been refusing to serve the page. I agree about the

+>> inherited umask; I hadn't expected that. Even if it's unusual, though, it

+>> probably won't be uncommon - this was a stock Ubuntu 9.04 install. --Paul

+

+(I'm new to wiki etiquette - would it be more polite to leave these details

+on the wiki, or to remove them and only leave a short summary? Thanks.

+--Paul)

+

+> Well, I just try to keep things understandable and clear, whether than

+> means deleting bad old data or not. That said, this page is a bug report,

+> that was already closed. It's generally better to open a new bug report

+> rather than edit an old closed one. --[[Joey]]

+

+>> Thanks for the feedback, I've tidied up my comment accordingly. I see

+>> your point about the bug; sorry for cluttering the page up. I doubt it's

+>> worth opening a new page at this stage, but will do so if there's a next

+>> time. The solution seems worth leaving, though, in case anyone else in my

+>> situation picks it up. --Paul

+I'm using ikiwiki 3.12 on Mac OS X (installed via mac ports)

+

+When trying to rename a file via the web interface (using the rename plugin) I get the following error:

+

+Error: Undefined subroutine &IkiWiki::Plugin::svn::dirname called at /opt/local/lib/perl5/vendor_perl/5.8.9/IkiWiki/Plugin/svn.pm line 246.

+

+Applying the following patch fixed it:

+

+ --- IkiWiki/Plugin/svn.pm.orig 2009-07-08 12:25:23.000000000 -0400

+ +++ IkiWiki/Plugin/svn.pm 2009-07-08 12:28:36.000000000 -0400

+ @@ -243,10 +243,10 @@

+

+ if (-d "$config{srcdir}/.svn") {

+ # Add parent directory for $dest

+ - my $parent=dirname($dest);

+ + my $parent=IkiWiki::dirname($dest);

+ if (! -d "$config{srcdir}/$parent/.svn") {

+ while (! -d "$config{srcdir}/$parent/.svn") {

+ - $parent=dirname($dest);

+ + $parent=Ikiwiki::dirname($dest);

+ }

+ if (system("svn", "add", "--quiet", "$config{srcdir}/$parent") != 0) {

+ warn("svn add $parent failed\n");

+

+

+> Thank you very much for the patch, which I've applied. I wonder how

+> that snuck in (aside from the obvious, that the svn plugin is not often

+> used and the code was added w/o being tested..). [[done]] --[[Joey]]

+

+> It occurs to me that at least one place in ikiwiki optimizes by assuming

+> that pagespecs not mentioning the word "internal" never match internal

+> pages. I wonder whether this bug could be solved by making that part of

+> the definition of a pagespec, rather than a risky optimization

+> like it is now? That seems strange, though - having this special case

+> would make pagespecs significantly harder to understand. --[[smcv]]

+[[!template id=gitbranch branch=hendry/html5 author="[[Kai_Hendry|hendry]]"]]

+

+* [HTML5 outliner tool](http://gsnedders.html5.org/outliner/) -- to check you have the structure of your markup correct

+

+# htmlscrubber.pm needs to not scrub new HTML5 elements

+

+* [new elements](http://www.w3.org/TR/html5-diff/#new-elements)

+Internet Explorer will display it as a block, though you can't seem to be able to further control the style.

+# Validator complains about no h1-h6 in header

+The [[ikiwiki/directive/img]] directive emits an extra double quote if alt=x is

+specified (as is necessary for valid HTML). This results in malformed HTML,

+like this:

+

+ <img src="U" width="W" height="H"" alt="A" />

+ ^

+

+This [[patch]] is available from the img-bugfix branch in my git repository:

+

+ commit a648c439f3467571374daf597e9b3a659ea2008f

+ Author: Simon McVittie <smcv@ http://smcv.pseudorandom.co.uk/>

+ Date: 2009-06-16 17:15:06 +0100

+

+ img plugin: do not emit a redundant double-quote before alt attribute

+

+ diff --git a/IkiWiki/Plugin/img.pm b/IkiWiki/Plugin/img.pm

+ index a697fea..a186abd 100644

+ --- a/IkiWiki/Plugin/img.pm

+ +++ b/IkiWiki/Plugin/img.pm

+ @@ -121,7 +121,7 @@ sub preprocess (@) {

+ my $imgtag='<img src="'.$imgurl.

+ '" width="'.$im->Get("width").

+ '" height="'.$im->Get("height").'"'.

+ - (exists $params{alt} ? '" alt="'.$params{alt}.'"' : '').

+ + (exists $params{alt} ? ' alt="'.$params{alt}.'"' : '').

+ (exists $params{title} ? ' title="'.$params{title}.'"' : '').

+ (exists $params{class} ? ' class="'.$params{class}.'"' : '').

+ (exists $params{id} ? ' id="'.$params{id}.'"' : '').

+

+--[[smcv]]

+

+[[done]] --[[Joey]]

+[[!tag plugins/map patch]]

+

+Patch:

+

+> Strictly speaking, a `<ul>` with no `<li>`s isn't valid HTML either...

+> could `map` instead delay emitting the first `<ul>` until it determines that

+> it will have at least one item? Perhaps refactoring that function into

+> something easier to regression-test would be useful. --[[smcv]]

+

+>> You are right (just checked 4.01 DTD to confirm). I suspect refactoring

+>> the function would be wise. From my brief look at it to formulate the

+>> above I thought it was a bit icky. I'm not a good judge of what would

+>> be regression-test friendly but I might have a go at reworking it. With

+>> this variety of problem I have a strong inclination to use HOFs like map,

+>> grep. - [[Jon]]

+

+>>> The patch in [[map/discussion|plugins/map/discussion]] has the same

+>>> problem, but does suggest a simpler approach to solving it (bail out

+>>> early if the map has no items at all). --[[smcv]]

+

+>>>> Thanks for pointing out the problem. I guess this patch should solve it.

+>>>> --[[harishcm]]

+

+>>>>> Well, I suppose that's certainly a minimal patch for this bug :-)

+>>>>> I'm not the IkiWiki maintainer, but if I was, I'd apply it, so I've put

+>>>>> it in a git branch for Joey's convenience. Joey, Jon: any opinion?

+>>>>>

+>>>>> If you want to be credited for this patch under a name other than

+>>>>> "harishcm" (e.g. your real name), let me know and I'll amend the branch.

+>>>>> (Or, make a git branch of your own and replace the reference just below,

+>>>>> if you prefer.) --[[smcv]]

+

+>>>>>> The current arrangement looks fine to me. Thanks. --[[harishcm]]

+

+[[!template id=gitbranch author="[[harishcm]]" branch=smcv/ready/harishcm-map-fix]]

+

+Patch:

+

+ --- /usr/local/share/perl/5.8.8/IkiWiki/Plugin/map.pm

+ +++ map.pm

+ @@ -80,7 +80,17 @@

+ my $indent=0;

+ my $openli=0;

+ my $addparent="";

+ - my $map = "<div class='map'>\n<ul>\n";

+ + my $map = "<div class='map'>\n";

+ +

+ + # Return empty div if %mapitems is empty

+ + if (!scalar(keys %mapitems)) {

+ + $map .= "</div>\n";

+ + return $map;

+ + }

+ + else { # continue populating $map

+ + $map .= "<ul>\n";

+ + }

+ +

+ foreach my $item (sort keys %mapitems) {

+ my @linktext = (length $mapitems{$item} ? (linktext => $mapitems{$item}) : ());

+ $item=~s/^\Q$common_prefix\E\///

+I have the following structure:

+

+## page0

+ # Page 0

+ \[[!inline raw="yes" pages="page1"]]

+

+## page1

+ # Page 1

+ \[[!inline pages="page2"]]

+

+## page2

+ # Page 2

+ test

+

+In this situation, a change in page 2 will trigger a rebuild of page1 but not of page0.

+

+ refreshing wiki..

+ scanning page2.mdwn

+ rendering page2.mdwn

+ rendering page1.mdwn, which depends on page2

+ done

+

+In my real world situation, page1 is actually listing all pages that match a certain tag and page0 is the home page.

+Whenever a page got tagged, it will appear on page1 but not on page0.

+

+Am I missing something? Is this a bug or Ikiwiki not supposed to support this use case?

+

+> Perhaps the inline plugin isn't being clever enough about dependencies -

+> strictly speaking, when a page is inlined with full content, the inlining

+> page should probably inherit all the inlined page's dependencies.

+> That might be prohibitively slow in practise due to the way IkiWiki

+> currently merges pagespecs, though - maybe the patches I suggested for

+> [[separating_and_uniquifying_pagespecs|todo/should_optimise_pagespecs]]

+> would help? --[[smcv]]

+The git commit (in my `openid` branch) says it all:

+

+ Update IkiWiki::openiduser to work with Net::OpenID 2.x

+

+ openiduser previously used a constructor that no longer works in 2.x.

+ However, all we actually want is the (undocumented) DisplayOfURL function

+ that is invoked by the display method, so try to use that.

+

+This bug affects ikiwiki.info (my commits show up in [[RecentChanges]] as http://smcv.pseudorandom.co.uk/ rather than smcv [pseudorandom.co.uk]).

+

+> Cherry picked, thanks. --[[Joey]]

+

+Relatedly, the other commit on the same branch would be nice to have

+(edited to add: I've now moved it, and its discussion, to

+[[todo/pretty-print_OpenIDs_even_if_not_enabled]]). --[[smcv]]

+

+[[!tag done]]

+[[!tag patch plugins/inline patch/core]]

+

+reused in parentlinks. This patch may fix it.

+>> Thus tagging patch. --[[intrigeri]]

+Prettydate creates strings like this: _Last edited in the wee hours of Tuesday night, July 1st, 2009_. However, July 1st is a Wednesday, so either date or Weekday should be modified. In the spirit is probably _Tuesday night, June 30th_. --ulrik

+

+> The default prettydate times are fairly idiosyncratic to

+> how [[Joey]] thinks about time. Specifically, it's still

+> Tuesday night until he wakes up Wednesday morning -- which

+> could be in the afternoon. :-P But, Joey also realizes

+> that dates change despite his weird time sense, and so

+> July 1st starts at midnight on Tuesday and continues

+> through Tuesday night and part of Wednesday.

+>

+> (This might not be as idiosyncratic as I make it out to be..

+> I think that many people would agree that in the wee hours

+> of New Years Eve, when they're staggering home ahead of

+> the burning daylight, the date is already January 1st.)

+>

+> I think the bug here is that prettydate can't represent

+> all views of time. While the times

+> of day can be configured, and it's possible to configure it

+> to call times after midnight "Wednesday morning, July 1st",

+> it is not possible to configure the date or weekday based

+> on the time of day.

+>

+> In order to do so, prettydate's timetable would need to be

+> extended to include the "%B %o, %Y" part, and that extended

+> to include "%B-", "%o-", and "%Y-" to refer to the day

+> before.

+>

+> --[[Joey]]

+

+>> fair enough, I think I can get converted to a warped time perspective. --ulrik

+

+>>> Perhaps we can consider this [[done]], then? --[[smcv]]

+[[!tag patch patch/core]]

+If I set a meta value on a page (lets say \[[!meta author="Adam Shand"]] is there some way to retrieve the value of author and put it somewhere visible on the page? Eg. can I write:

+

+author: $author

+

+I know I can update the raw templates but it'd be nice to be able to do this in the pages them selves.

+

+Cheers,

+Adam.

+I've just finished an upgrade to 3.141 and am trying to give myself admin rights to play with the new webadmin features. My login is via OpenID but from reading on the wiki I believe that OpenID users should be able to be granted admin rights. However I'm obviously doing something wrong as when I click on the "Preferences" link at the top of the page I don't see any admin features.

+

+My login is: http://adam.shand.net/

+

+In .ikiwiki/userdb I see:

+

+> adam@shand.net

+> email <br>

+> password <br>

+> locked_pages <br>

+> banned <br>

+> 1229722296 <br>

+> regdate <br>

+> http://adam.shand.net/ <br>

+

+And in my config file I have:

+

+> adminuser => [qw{http://adam.shand.net/}],

+

+Any pointers to what I'm doing wrong would be much appreciated.

+

+Thanks,

+Adam.

+

+> This is certianly supposed to work. For example, the admin

+> user on my ikiwikis is `http://joey.kitenet.net/`

+>

+> The only caveat I know of to make it work is that the

+> adminuser openid url has to exactly match the openid url that

+> ikiwiki sees when you log in. Including any trailing slash,

+> and the `http://`. --[[Joey]]

+

+>> Hrm, it's not working. I'm sure I've made a silly mistake somewhere but

+>> I've looked and looked and just can't find it. Any suggestions on where

+>> to look for debugging information would be much appreciated. -- [[Adam]]

+

+>>> Well, you could use this patch to add debugging info about admin

+>>> username comparisons:

+

+<pre>

+diff --git a/IkiWiki/UserInfo.pm b/IkiWiki/UserInfo.pm

+index 0bf100a..77b467a 100644

+--- a/IkiWiki/UserInfo.pm

++++ b/IkiWiki/UserInfo.pm

+@@ -71,6 +71,8 @@ sub userinfo_setall ($$) {

+ sub is_admin ($) {

+ my $user_name=shift;

+

++ print STDERR "is_admin test @{$config{adminuser}} vs $user_name: ".(grep { $_ eq $user_name } @{$config{adminuser}})."\n";

++

+ return grep { $_ eq $user_name } @{$config{adminuser}};

+ }

+

+</pre>

+

+>>>> After applying that change to what is probably

+>>>> `/usr/share/perl5/IkiWiki/UserInfo.pm` on your system,

+>>>> when you go to the preferences page it should log in your web server's

+>>>> error.log, something like this:

+

+ [Wed Jul 08 12:54:35 2009] [error] [client 127.0.1.1] is_admin test http://joey.kitenet.net/ vs http://joey.kitenet.net/: 1

+

+>>>> So you can see if the two usernames/openids match. If the end is "0",

+>>>> they don't match. If nothing is logged, you have not enabled the websetup plugin.

+>>>> If the end if "1" you should see the "Wiki Setup" button, if not the

+>>>> problem is not in determining if you're an admin, but elsewhere..

+>>>> --[[Joey]]

+

+I was being incredibly stupid and missed that websetup is a **plugin** and thus needed to be enabled. Many thanks for your patient assistance, by helping me eliminate the unlikely it eventually led me to the obvious. Cheers. -- [[Adam]]

+My website takes a fairly long time to render. It takes a long time to do

+things like add pages, too. I'd like to try and understand what takes the

+time and what I might be able to do to speed things up.

+

+I have 1,234 objects on my site (yikes!). 717 are items under "/log" which

+I think might be the main culprit because there are some complex pagespecs

+operating in that area (e.g. log/YYYY/MM/DD, YYYY/MM and YYYY for YYYY >=

+2003, YYYY <= 2008 which include every page under log/ which was modified

+in the corresponding YYYY or YYYY/MM or YYYY/MM/DD). There is very little

+linking between the world outside of /log and that within it.

+

+I was interested in generating a graphical representation of ikiwiki's idea of

+page inter-dependencies. I started by looking at the '%links' hash using the

+following plugin:

+

+ #!/usr/bin/perl

+ package IkiWiki::Plugin::deps;

+

+ use warnings;

+ use strict;

+ use IkiWiki 3.00;

+

+

+ sub import {

+ hook(type => "format", id => "deps", call => \&fooble);

+ }

+

+ my $hasrun = 0;

+

+ sub fooble ($$) {

+ if(0 == $hasrun) {

+ $hasrun = 1;

+ open MYFILE, ">/home/jon/deps.dot";

+ foreach my $key (keys %links) {

+ my $arrref = $links{$key};

+ foreach my $page (@$arrref) {

+ print MYFILE "$key -> $page;\n";

+ }

+ }

+ close MYFILE;

+ }

+ }

+

+ 1

+

+The resulting file was enormous: 2,734! This turns out to be because of the following code in scan() in Render.pm:

+

+ if ($config{discussion}) {$

+ # Discussion links are a special case since they're

+ # not in the text of the page, but on its template.

+ $links{$page}=[ $page."/".gettext("discussion") ];

+

+Worst case (no existing discussion pages) this will double the number of link

+relationships. Filtering out all of those, the output drops to 1,657. This

+number is still too large to really visualize: the graphviz PNG and PDF output

+engines segfault for me, the PS one works but I can't get any PS software to

+render it without exploding.

+

+Now, the relations in the links hash are not the same thing as IkiWiki's notion of dependencies. Can anyone point me at that data structure / where I might be able to add some debugging foo to generate a graph of it?

+

+Once I've figured out that I might be able to optimize some pagespecs. I

+understand pagespecs are essentially translated into sequential perl code. I

+might gain some speed if I structure my complex pagespecs so that the tests

+which have the best time complexity vs. "pages ruled out" ratio are performed

+first.

+

+I might also be able to find some dependencies which shouldn't be there and

+remove the dependency.

+

+In general any advice people could offer on profiling ikiwiki would be great.

+I did wonder about invoking the magic profiling arguments to perl via the CGI

+wrapper.

+

+

+-- [[Jon]]

+

+> Dependencies go in the `%IkiWiki::depends` hash, which is not exported. It

+> can also be dumped out as part of the wiki state - see [[tips/inside_dot_ikiwiki]].

+>

+> It's a map from page name to increasingly complex pagespec, although

+> the `optimize-depends` branch in my git repository changes that to a

+> map from a page name to a *list* of pagespecs which are automatically

+> or'd together for use (this at least means duplicates can be weeded out).

+>

+> See [[todo/should_optimise_pagespecs]] for more on that.

+>

+> I've been hoping to speed up IkiWiki too - making a lot of photo albums

+> with my [[plugins/contrib/album]] plugin makes it pretty slow.

+>

+> One thing that I found was a big improvement was to use `quick=yes` on all

+> my `archive=yes` [[ikiwiki/directive/inline]]s. --[[smcv]]

+* [[jonas|JonasSmedegaard]] `git://source.jones.dk/ikiwiki-upstream`

+* [[arpitjain]] `git://github.com/arpitjain11/ikiwiki.git`

+* [[chrysn]] `git://github.com/github076986099/ikiwiki.git`

+* [[simonraven]] `git://github.com/kjikaqawej/ikiwiki-simon.git`

+You can also pass `alt`, `title`, `class`, `align` and `id` parameters.

+These are passed through unchanged to the html img tag. If you include a

+`caption` parameter, the caption will be displayed centered beneath the image.

+

+>> Thank you for the explanation. Can you think of another way to accomplish

+>> my goals?

+>>

+>> Right now, I only see the option to edit the title with the

+>> `[[/ikiwiki/directive/meta]]` directive and the field `title`.

+>>

+>> How could a solution look like?

+>>

+>> 1. The possibility to add custom fields to the `meta` directive.

+>> 1. The possibility to specify in a page, how the page should be displayed

+>> when used by inlined. That could be done by a new directive `cinlined`

+>> (for »custom inlined«) which is chosen by the `inline` directive to

+>> display if told to do so.

+>>

+>> [[!cinlined text="""Text which can also use Parameter, bla blubb …"""]]

+>> --[[PaulePanter]]

+>>> You can make the body of a page change depending on whether it's being

+>>> inlined, with the [[ikiwiki/directive/if]] directive from the

+>>> [[plugins/conditional]] plugin:

+>>>

+>>> \[[!if test="inlined()"

+>>> then="""[[!template id=productsummary

+>>> location="Warehouse 23" price=20

+>>> ]]"""

+>>> else="""[[!template id=productdetail

+>>> location="Warehouse 23" price=20

+>>> description="Every home should have one"

+>>> ]]"""

+>>> ]]

+>>>

+>>> Perhaps that does some of what you want?

+>>>

+>>> If you want to go beyond that, my inclination would be to write

+>>> a simple plugin to deal with whatever it is you want to do (bug

+>>> metadata or product metadata or whatever) rather than prematurely

+>>> generalizing. --[[smcv]]

+

+## meta parameters are not enough

+

+I think I have the same problem as Paule, as I want extra arbitary parameters in my template.

+

+This is what I am doing currently, which makes my skin crawl. In `wgts/foo.mdwn`

+I have resorted to using AUTHORURL as the location of this widgets icon:

+

+ [[!meta authorurl="/ico/aHR0cDovL2JvbmRpLm9tdHAub3JnL3dpZGdldHMvYmF0dGVyeQ==.png" ]]

+

+In templates I have a file called `wgtlist.tmpl`:

+

+ <div class="widget">

+ <TMPL_IF NAME="AUTHORURL">

+ <img src="<TMPL_VAR AUTHORURL>" />

+ </TMPL_IF>

+ <TMPL_IF NAME="PERMALINK">

+ <a href="<TMPL_VAR PERMALINK>"><TMPL_VAR TITLE></a><br />

+ <TMPL_ELSE>

+ <a href="<TMPL_VAR PAGEURL>"><TMPL_VAR TITLE></a><br />

+ </TMPL_IF>

+ Posted <TMPL_VAR CTIME>

+ </div>

+

+My index page has:

+

+ [[!inline pages="./wgts/*" show=5 feeds=no actions=no rootpage="wgts" archive="yes" template=wgtlist]]

+

+Else can you please suggest a smarter way of getting certain data out from pages for a inline index?

+

+--[[hendry]]

+The optional `among` parameter limits counting to pages that match a

+[[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog

+entries, you could use:

+

+ \[[!pagestats pages="tags/*" among="blog/posts/*"]]

+

+or to display a cloud of tags related to Linux, you could use:

+

+ \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]]

+

+* "`link(page)`" - matches only pages that link to a given page (or glob)

+* "`tagged(tag)`" - matches pages that are tagged or link to the given tag (or

+ tags matched by a glob)

+* "`backlink(page)`" - matches only pages that a given page links to

+* "`creation_month(month)`" - matches only pages created on the given month

+* "`created_after(page)`" - matches only pages created after the given page

+* "`created_before(page)`" - matches only pages created before the given page

+* "`glob(someglob)`" - matches pages that match the given glob. Just writing

+* "`maxsize(size)`" - tests whether the attachment is no larger than the

+* "`minsize(size)`" - tests whether the attachment is no smaller than the

+* "`ispage()`" - tests whether the attachment will be treated by ikiwiki as a

+* "`mimetype(foo/bar)`" - checks the MIME type of the attachment. You can

+* "`virusfree()`" - checks the attachment with an antiviral program.

+[[!if test="enabled(po)"

+ then="This wiki has po support **enabled**."

+ else="This wiki has po support **disabled**."]]

+

+If the [[!iki plugins/po desc=po]] plugin is enabled, the regular

+[[ikiwiki/PageSpec]] syntax is expanded with the following additional

+tests that can be used to improve user navigation in a multi-lingual

+wiki:

+

+* "`lang(LL)`" - tests whether a page is written in the language

+ specified as a ISO639-1 (two-letter) language code.

+* "`currentlang()`" - tests whether a page is written in the same

+ language as the current page.

+

+Note that every non-po page is considered to be written in

+`po_master_language`, as specified in `ikiwiki.setup`.

+* The [Free Software Foundation](http://fsf.org) uses it for their internal wiki, with subversion.

+* [Simon Kjika'qawej C.](http://simonraven.kisikew.org/) - several other sites, too.

+* [tumashu's page](http://tumashu.github.com) This is my personal site in github created with ikiwiki and only a page,you can get the [source](http://github.com/tumashu/tumashu/tree/master)

+See also: [Debian ikiwiki popcon graph](http://qa.debian.org/popcon.php?package=ikiwiki)

+

+---

+

+## Prerequisite modules not found for non-root user

+Hi, I'm a non-root user trying to use IkiWiki on an academic webserver with Perl 5.8.8 but several missing modules, so I grab them from CPAN (edited):

+

+ cd ~; PERL5LIB=`pwd`/ikiwiki:`pwd`/ikiwiki/cpan:`pwd`/lib/perl5 PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'CPAN::Shell->install("Bundle::IkiWiki")'

+

+That puts a lot of files in ~/.cpan. Then when I go into the directory where I untarred IkiWiki and try to run the Perl makefile:

+

+ cd ~/ikiwiki; perl Makefile.PL PREFIX=$HOME/ikiwiki

+

+I get warnings that all the modules needed were not found:

+

+Warning: prerequisite CGI::FormBuilder not found.

+Warning: prerequisite CGI::Session 0 not found.

+Warning: prerequisite Date::Parse 0 not found.

+Warning: prerequisite HTML::Scrubber 0 not found.

+Warning: prerequisite HTML::Template 0 not found.

+Warning: prerequisite Mail::Sendmail 0 not found.

+Warning: prerequisite Text::Markdown 0 not found.

+

+CORRECTION 1: I played around with CPAN and got the installation to the point of succeeding with >99% of tests in "make test".

+

+> What was the magic CPAN rune that worked for you? --[[Joey]]

+

+An attempt of "make install" failed while trying to put files in /etc/IkiWiki but per the output's instructions, I reran "make install" and that seemed to work, until this error, which doesn't seem to be satisfiable:

+

+ Warning: You do not have permissions to install into /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi at /usr/lib/perl5/5.8.8/ExtUtils/Install.pm line 114.

+ Installing /usr/lib/perl5/site_perl/5.8.8/IkiWiki.pm

+ mkdir /usr/lib/perl5/site_perl/5.8.8/IkiWiki: Permission denied at /usr/lib/perl5/5.8.8/ExtUtils/Install.pm line 176

+

+Any suggestions? Whew!

+

+> When you build ikiwiki, try doing it like this to make it

+> install to your home directory. Then you can run `~/bin/ikiwiki`

+> --[[Joey]]

+

+ perl Makefile.PL INSTALL_BASE=$HOME PREFIX=

+ make

+ make install

+ikiwiki 3.1415 released with [[!toggle text="these changes"]]

+[[!toggleable text="""

+ * img: Fix extra double quote with alt text. (smcv)

+ * Updated French debconf templates translation. Closes: #[535103](http://bugs.debian.org/535103)

+ * openid: Support Net::OpenID 2.x when pretty-printing

+ openids. (smcv)

+ * highlight: Fix utf-8 encoding bug. Closes: #[535028](http://bugs.debian.org/535028)"""]] \ No newline at end of file

+ikiwiki 3.14159 released with [[!toggle text="these changes"]]

+[[!toggleable text="""

+ * svn: Fix rcs\_rename to properly scope call to dirname.

+ * img: Pass the align parameter through to the generated img tag.

+ * Move OpenID pretty-printing from openid plugin to core (smcv)"""]] \ No newline at end of file

+revision history of a page. This is enabled by the `historyurl` setting,

+The [[plugins/repolist]] plugin can supplement this information with

+Some [[patches|patch]] affect the ikiwiki core, rather than just a plugin.

+This tag collects those patches. Please tag such patches with 'patch/core'

+as well as 'patch'.

+

+[[!inline pages="(todo/* or bugs/*) and link(patch/core)

+ and !link(bugs/done) and !link(todo/done) and !*/Discussion"

+ rootpage="todo" archive="yes"]]

+Please think twice before enabling this plugin. If your wiki is accessible

+to the internet, it *will* be subject to spamming if this plugin is

+enabled. Such spam is not only a pain to deal with, but it bloats the

+revision control history of your wiki.

+

+The plugin has a configuration setting, `anonok_pagespec`. This

+[[ikiwiki/PageSpec]] can be used to allow anonymous editing of matching pages.

+

+----

+

+I have a test ikiwiki setup somewhere to investigate adopting the comments

+plugin. It is setup with no auth enabled and I got hammered with a spam attack

+over the last weekend (predictably). What surprised me was the scale of the

+attack: ikiwiki eventually triggered OOM and brought the box down. When I got

+it back up, I checked out a copy of the underlying git repository, and it

+measured 280M in size after being packed. Of that, about 300K was data prior

+to the spam attack, so the rest was entirely spam text, compressed via git's

+efficient delta compression.

+

+I had two thoughts about possible improvements to the comments plugin in the

+wake of this:

+

+ * comment pagination - there is a hard-to-define upper limit on the number

+ of comments that can be appended to a wiki page whilst the page remains

+ legible. It would be useful if comments could be paginated into sub-pages.

+

+ * crude flood control - asides from spam attacks (and I am aware of

+ [[plugins/blogspam]]), people can crap flood or just aggressively flame

+ repeatedly. An interesting prevention measure might be to not let an IP

+ post more than 3 sequential comments to a page, or to the site, without

+ at least one other comment being interleaved. I say 3 rather than 2 since

+ correction follow-ups are common.

+

+-- [[Jon]]

+[[!template id=plugin name=album author="[[Simon_McVittie|smcv]]"]]

+[[!template id=gitbranch branch=smcv/album author="[[Simon_McVittie|smcv]]"]]

+[[!tag type/chrome]]

+

+Available from [[smcv]]'s git repository, in the `album` branch

+([[users/smcv/gallery|users/smcv/gallery]] contains some older

+thoughts about this plugin).

+

+This plugin formats a collection of images into a photo album,

+in the same way as many websites: good examples include the

+PHP application [Gallery](http://gallery.menalto.com/), Flickr,

+and Facebook's Photos "application". I've called it `album`

+to distinguish it from [[contrib/gallery|plugins/contrib/gallery]],

+although `gallery` might well be a better name for this functionality.

+

+The web UI I'm trying to achieve consists of one

+[HTML page of thumbnails](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/)

+as an entry point to the album, where each thumbnail links to

+[a "viewer" HTML page](http://www.pseudorandom.co.uk/2008/2008-03-08-panic-cell-gig/img_0068/)

+with a full size image, next/previous thumbnail links, and

+[[plugins/comments]].

+

+(The Summer of Code [[plugins/contrib/gallery]] plugin does the

+next/previous UI in Javascript using Lightbox, which means that

+individual photos can't be bookmarked in a meaningful way, and

+the best it can do as a fallback for non-Javascript browsers

+is to provide a direct link to the image.)

+

+## Writing the viewers

+

+ \[[!albumimage image=foo.jpg album=myalbum

+ title=...

+ caption=...

+ copyright=...

+ size=...

+ viewertemplate=...

+ ]]

+

+Each viewer contains one `\[[!albumimage]]` directive. This

+sets the `image` filename, the `album` in which this image appears,

+and an optional `caption`, and can override the `size` at which to

+display the image and the `viewertemplate` to use to display the

+image.

+

+It can also have `title`, `copyright` and `date` parameters, which

+are short-cuts for [[ikiwiki/directive/meta]] directives.

+

+The viewer can also have any other content, but typically the

+directive will be the only thing there.

+

+Eventually, there will be a specialized CGI user interface to

+edit all the photos of an album at once, upload a new photo

+(which will attach the photo but also write out a viewer page

+for it), or mark an already-uploaded photo as a member of an

+album (which is done by writing out a viewer page for it).

+

+The `\[[!albumimage]]` directive is replaced by an

+[[ikiwiki/directive/img]], wrapped in some formatting using a

+template (by default `albumviewer.tmpl`). The template can (and

+should) also include "next photo", "previous photo" and

+"up to gallery" links.

+

+The next/previous links are themselves implemented by

+[[inlining|ikiwiki/directive/inline]] the next or previous

+photo, using a special template (by default `albumnext.tmpl`

+or `albumprev.tmpl`), in `archive`/`quick` mode.

+

+## Writing the album

+

+The album contains one `\[[!album]]` directive. It may also

+contain any number of `\[[!albumsection]]` directives, for

+example the demo album linked above could look like:

+

+ \[[!album]]

+ <!-- replaced with one uncategorized photo -->

+

+ ## Gamarra

+

+ \[[!albumsection filter="link(gamarra)"]]

+ <!-- all the Gamarra photos -->

+

+ ## Smokescreen

+

+ \[[!albumsection filter="link(smokescreen)"]]

+ <!-- all the Smokescreen photos -->

+

+ ...

+

+The `\[[!album]]` directive is replaced by an

+[[ikiwiki/directive/inline]] which automatically includes every

+page that has an `\[[!albumimage]]` directive linking it to this

+album, except those that will appear in an `\[[!albumsection]]`.

+

+The `inline` is in `archive`/`quick` mode, but includes some

+extra information about the images, including file size and a

+thumbnail (again, made using [[ikiwiki/directive/img]]). The

+default template is `albumitem.tmpl`, which takes advantage

+of these things.

+

+Each `\[[!albumsection]]` is replaced by a similar inline, which

+selects a subset of the photos in the album.

+

+> Jon has done something similar in [[todo/allow_site-wide_meta_definitions]];

+> his version has the advantages that it doesn't invent magical page names,

+> and can extend beyond just copyright and license, but has the disadvantage

+> that it doesn't support setting defaults for a given "subdirectory"

+> only. --[[smcv]]

+

+Available at <http://alcopop.org/~jon/mediawiki.pm>

+Anyone know a safe place where this plugin can be found? -- mjr at phonecoop.coop

+

+> I ended up doing a backassward way of doing it, as described at the [convert discussion page](http://ikiwiki.info/tips/convert_mediawiki_to_ikiwiki/discussion/). -[[simonraven]]

+

+>> I've mirrored it at <http://alcopop.org/~jon/mediawiki.pm>. -- [[Jon]]

+[[!tag type/chrome patch]]

+[[!template id=gitbranch branch=smcv/trail author="[[smcv]]"]]

+

+Available from [[smcv]]'s git repository, in the `trail` branch. This

+plugin aims to solve [[todo/wikitrails]] in a simpler way.

+

+Joey: what do you think of this plugin? If you like the general approach

+and are likely to include it in ikiwiki, I'll try to modify

+[[plugins/contrib/album]] to be based on it, rather than partially

+reinventing it.

+

+This plugin can benefit from

+[[another_of_my_branches|todo/inline_plugin:_specifying_ordered_page_names]]

+but does not require it.

+

+----

+

+[[!template id=plugin name=trail author="[[Simon_McVittie|smcv]]"]]

+

+It's sometimes useful to have "trails" of pages in a wiki, as a guided

+tour, sequence of chapters etc. In this plugin, a trail is represented

+by a page, and the pages in the trail are indicated by specially marked

+links within that page.

+

+If using the default `page.tmpl`, each page automatically displays the

+trails that it's a member of (if any), with links to the trail and to

+the next and previous members.

+

+The `traillink` [[ikiwiki/directive]] is used to record which pages

+are in a trail, and simultaneously link to them. Alternatively, the

+[[ikiwiki/directive/inline]] directive can be used with `trail=yes`

+to record the inlined pages as part of the trail, in the order in

+which they are inlined.

+

+## Directives

+

+(These will go to the appropriate pages in [[ikiwiki/directive]] if this

+plugin is included in ikiwiki.)

+

+### traillink

+

+The `traillink` directive is supplied by the [[!iki plugins/contrib/trail desc=trail]]

+plugin. This directive appears on the page representing a trail. It acts

+as a visible [[ikiwiki/WikiLink]], but also records the linked page as

+a member of the trail.

+

+Various syntaxes can be used:

+

+ \[[!traillink Badgers]]

+ \[[!traillink How_to_find_mushrooms_using_badgers|badgers]]

+ \[[!traillink badgers text="How to find mushrooms using badgers"]]

+

+### trailoptions

+

+The `trailoptions` directive is supplied by the [[!iki plugins/contrib/trail desc=trail]]

+plugin. This directive appears on the page representing a trail, and

+produces no output.

+

+Currently, the only option supported is `[[!trailoptions circular=yes]]`,

+which adds links between the first and last pages, turning the trail into

+a circle.

+

+----

+

+I noticed that when the pagespec returns no map items, the map plugin does not close off the ul and div tags. Below is a simple patch

+that seems to work on the examples I tried. I am a beginner so please help me out here. Thanks. --[[harishcm]]

+

+ --- a/map.pm

+ +++ b/map.pm

+ @@ -81,6 +81,13 @@

+ my $openli=0;

+ my $addparent="";

+ my $map = "<div class='map'>\n<ul>\n";

+ +

+ + # Return properly closed $map if %mapitems is empty

+ + if (!scalar(keys %mapitems)) {

+ + $map .= "</ul>\n</div>\n";

+ + return $map;

+ + }

+ +

+ foreach my $item (sort keys %mapitems) {

+ my @linktext = (length $mapitems{$item} ? (linktext => $mapitems{$item}) : ());

+ $item=~s/^\Q$common_prefix\E\///

+

+> This was also reported as [[bugs/map_fails_to_close_ul_element_for_empty_list]];

+> this patch is simpler than the one there, but has the same problem (it emits

+> `<ul></ul>`, which technically isn't valid HTML either). --[[smcv]]

+

+>> Thanks for the tip, I added another patch addressing the issue at

+>> [[bugs/map_fails_to_close_ul_element_for_empty_list]]. --[[harishcm]]

+[[!template id=plugin name=po core=0 author="[[intrigeri]]"]]

+[[!tag type/format]]

+

+This plugin adds support for multi-lingual wikis, translated with

+gettext, using [po4a](http://po4a.alioth.debian.org/).

+

+It depends on the Perl `Locale::Po4a::Po` library (`apt-get install po4a`).

+As detailed bellow in the security section, `po4a` is subject to

+denial-of-service attacks before version 0.35.

+

+[[!toc levels=2]]

+

+Introduction

+============

+

+A language is chosen as the "master" one, and any other supported

+language is a "slave" one.

+

+A page written in the "master" language is a "master" page. It can be

+of any page type supported by ikiwiki, except `po`. It does not have to be

+named a special way: migration to this plugin does not imply any page

+renaming work.

+

+Example: `bla/page.mdwn` is a "master" Markdown page written in

+English; if `usedirs` is enabled, it is rendered as

+`bla/page/index.en.html`, else as `bla/page.en.html`.

+

+Any translation of a "master" page into a "slave" language is called

+a "slave" page; it is written in the gettext PO format. `po` is now

+a page type supported by ikiwiki.

+

+Example: `bla/page.fr.po` is the PO "message catalog" used to

+translate `bla/page.mdwn` into French; if `usedirs` is enabled, it is

+rendered as `bla/page/index.fr.html`, else as `bla/page.fr.html`

+

+(In)Compatibility

+=================

+

+This plugin does not support the `indexpages` mode. If you don't know

+what it is, you probably don't care.

+

+

+Configuration

+=============

+

+Supported languages

+-------------------

+

+`po_master_language` is used to set the "master" language in

+`ikiwiki.setup`, such as:

+

+ po_master_language => { 'code' => 'en', 'name' => 'English' }

+

+`po_slave_languages` is used to set the list of supported "slave"

+languages, such as:

+

+ po_slave_languages => { 'fr' => 'Français',

+ 'es' => 'Español',

+ 'de' => 'Deutsch',

+ }

+

+Decide which pages are translatable

+-----------------------------------

+

+The `po_translatable_pages` setting configures what pages are

+translatable. It is a [[ikiwiki/PageSpec]], so you have lots of

+control over what kind of pages are translatable.

+

+The `.po` files are not considered as being translatable, so you don't need to

+worry about excluding them explicitly from this [[ikiwiki/PageSpec]].

+

+Internal links

+--------------

+

+### Links targets

+

+The `po_link_to` option in `ikiwiki.setup` is used to decide how

+internal links should be generated, depending on web server features

+and site-specific preferences.

+

+#### Default linking behavior

+

+If `po_link_to` is unset, or set to `default`, ikiwiki's default

+linking behavior is preserved: `\[[destpage]]` links to the master

+language's page.

+

+#### Link to current language

+

+If `po_link_to` is set to `current`, `\[[destpage]]` links to the

+`destpage`'s version written in the current page's language, if

+available, *i.e.*:

+

+* `foo/destpage/index.LL.html` if `usedirs` is enabled

+* `foo/destpage.LL.html` if `usedirs` is disabled

+

+#### Link to negotiated language

+

+If `po_link_to` is set to `negotiated`, `\[[page]]` links to the

+negotiated preferred language, *i.e.* `foo/page/`.

+

+(In)compatibility notes:

+

+* if `usedirs` is disabled, it does not make sense to set `po_link_to`

+ to `negotiated`; this option combination is neither implemented

+ nor allowed.

+* if the web server does not support Content Negotiation, setting

+ `po_link_to` to `negotiated` will produce a unusable website.

+

+Server support

+==============

+

+Apache

+------

+

+Using Apache `mod_negotiation` makes it really easy to have Apache

+serve any page in the client's preferred language, if available.

+This is the default Debian Apache configuration.

+

+When `usedirs` is enabled, one has to set `DirectoryIndex index` for

+the wiki context.

+

+Setting `DefaultLanguage LL` (replace `LL` with your default MIME

+language code) for the wiki context can help to ensure

+`bla/page/index.en.html` is served as `Content-Language: LL`.

+

+lighttpd

+--------

+

+lighttpd unfortunately does not support content negotiation.

+

+**FIXME**: does `mod_magnet` provide the functionality needed to

+ emulate this?

+

+

+Usage

+=====

+

+Templates

+---------

+

+When `po_link_to` is not set to `negotiated`, one should replace some

+occurrences of `BASEURL` with `HOMEPAGEURL` to get correct links to

+the wiki homepage.

+

+The `ISTRANSLATION` and `ISTRANSLATABLE` variables can be used to

+display things only on translatable or translation pages.

+

+### Display page's versions in other languages

+

+The `OTHERLANGUAGES` loop provides ways to display other languages'

+versions of the same page, and the translations' status.

+

+An example of its use can be found in the default

+`templates/page.tmpl`. In case you want to customize it, the following

+variables are available inside the loop (for every page in):

+

+* `URL` - url to the page

+* `CODE` - two-letters language code

+* `LANGUAGE` - language name (as defined in `po_slave_languages`)

+* `MASTER` - is true (1) if, and only if the page is a "master" page

+* `PERCENT` - for "slave" pages, is set to the translation completeness, in percents

+

+### Display the current translation status

+

+The `PERCENTTRANSLATED` variable is set to the translation

+completeness, expressed in percent, on "slave" pages. It is used by

+the default `templates/page.tmpl`.

+

+Additional PageSpec tests

+-------------------------

+

+This plugin enhances the regular [[ikiwiki/PageSpec]] syntax with some

+additional tests that are documented [[here|ikiwiki/pagespec/po]].

+

+Automatic PO file update

+------------------------

+

+Committing changes to a "master" page:

+

+1. updates the POT file and the PO files for the "slave" languages;

+ the updated PO files are then put under version control;

+2. triggers a refresh of the corresponding HTML slave pages.

+

+Also, when the plugin has just been enabled, or when a page has just

+been declared as being translatable, the needed POT and PO files are

+created, and the PO files are checked into version control.

+

+Discussion pages and other sub-pages

+------------------------------------

+

+Discussion should happen in the language in which the pages are

+written for real, *i.e.* the "master" one. If discussion pages are

+enabled, "slave" pages therefore link to the "master" page's

+discussion page.

+

+Likewise, "slave" pages are not supposed to have sub-pages;

+[[WikiLinks|wikilink]] that appear on a "slave" page therefore link to

+the master page's sub-pages.

+

+Translating

+-----------

+

+One can edit the PO files using ikiwiki's CGI (a message-by-message

+interface could also be implemented at some point).

+

+If [[tips/untrusted_git_push]] is setup, one can edit the PO files in one's

+preferred `$EDITOR`, without needing to be online.

+

+Markup languages support

+------------------------

+

+[[Markdown|mdwn]] is well supported. Some other markup languages supported

+by ikiwiki mostly work, but some pieces of syntax are not rendered

+correctly on the slave pages:

+

+* [[reStructuredText|rst]]: anonymous hyperlinks and internal

+ cross-references

+* [[wikitext]]: conversion of newlines to paragraphs

+* [[creole]]: verbatim text is wrapped, tables are broken

+* [[html]] and LaTeX: not supported yet; the dedicated po4a modules

+ could be used to support them, but they would need a security audit

+* other markup languages have not been tested.

+

+Security

+========

+

+[[po/discussion]] contains a detailed security analysis of this plugin

+and its dependencies.

+

+When using po4a older than 0.35, it is recommended to uninstall

+`Text::WrapI18N` (Debian package `libtext-wrapi18n-perl`), in order to

+avoid a potential denial of service.

+

+TODO

+====

+

+Better links

+------------

+

+Once the fix to

+[[bugs/pagetitle_function_does_not_respect_meta_titles]] from

+[[intrigeri]]'s `meta` branch is merged into ikiwiki upstream, the

+generated links' text will be optionally based on the page titles set

+with the [[meta|plugins/meta]] plugin, and will thus be translatable.

+It will also allow displaying the translation status in links to slave

+pages. Both were implemented, and reverted in commit

+ea753782b222bf4ba2fb4683b6363afdd9055b64, which should be reverted

+once [[intrigeri]]'s `meta` branch is merged.

+

+An integration branch, called `meta-po`, merges [[intrigeri]]'s `po`

+and `meta` branches, and thus has thise additional features.

+

+Self links

+----------

+

+If a page contains a WikiLink to itself, ikiwiki does not normally

+turn that into a hyperlink. However, if a translated page contains a

+WikiLink to itself, a hyperlink is inserted, at least with the default

+`po_link_to` the link points to the English version of the page. Is there a

+good reason for that to be done? --[[Joey]]

+

+Language display order

+----------------------

+

+Jonas pointed out that one might want to control the order that links to

+other languages are listed, for various reasons. Currently, there is no

+order, as `po_slave_languages` is a hash. It would need to be converted

+to an array to support this. (If twere done, twere best done quickly.)

+--[[Joey]]

+

+Duplicate %links ?

+------------------

+

+I notice code in the scan hook that seems to assume

+that %links will accumulate duplicate links for a page.

+That used to be so, but the bug was fixed. Does this mean

+that po might be replacing the only link on a page, in error?

+--[[Joey]]

+

+Bug when editing underlay file

+------------------------------

+

+While I've gotten translated underlays working, there is a bug

+if the wiki is currently using a page from the underlay, and the master

+language version is edited. This causes the edited page to be saved

+to srcdir.. and all the translations get set to 0% and their

+po files have the translated strings "emptied". What's really going on

+is that these are entirely new po files not based on the old ones

+in the basewiki, and thus lacking translations. --[[Joey]]

+

+Documentation

+-------------

+

+Maybe write separate documentation depending on the people it targets:

+translators, wiki administrators, hackers. This plugin may be complex

+enough to deserve this.

+[[!toc ]]

+

+----

+

+# Security review

+

+## Probable holes

+

+_(The list of things to fix.)_

+

+### po4a-gettextize

+

+* po4a CVS 2009-01-16

+* Perl 5.10.0

+

+`po4a-gettextize` uses more or less the same po4a features as our

+`refreshpot` function.

+

+Without specifying an input charset, zzuf'ed `po4a-gettextize` quickly

+errors out, complaining it was not able to detect the input charset;

+it leaves no incomplete file on disk. I therefore had to pretend the

+input was in UTF-8, as does the po plugin.

+

+ zzuf -c -s 13 -r 0.1 \

+ po4a-gettextize -f text -o markdown -M utf-8 -L utf-8 \

+ -m GPL-3 -p GPL-3.pot

+

+Crashes with:

+

+ Malformed UTF-8 character (UTF-16 surrogate 0xdfa4) in substitution

+ iterator at /usr/share/perl5/Locale/Po4a/Po.pm line 1449.

+ Malformed UTF-8 character (fatal) at /usr/share/perl5/Locale/Po4a/Po.pm

+ line 1449.

+

+An incomplete pot file is left on disk. Unfortunately Po.pm tells us

+nothing about the place where the crash happens.

+

+> It's fairly standard perl behavior when fed malformed utf-8. As long

+> as it doesn't crash ikiwiki, it's probably acceptable. Ikiwiki can

+> do some similar things itself when fed malformed utf-8 (doesn't

+> crash tho) --[[Joey]]

+

+----

+

+## Potential gotchas

+

+_(Things not to do.)_

+

+

+### Blindly activating more po4a format modules

+

+The format modules we want to use have to be checked, as not all are

+safe (e.g. the LaTeX module's behaviour is changed by commands

+included in the content); they may use regexps generated from

+the content.

+

+----

+

+## Hopefully non-holes

+

+_(AKA, the assumptions that will be the root of most security holes...)_

+

+### PO file features

+

+No [documented](http://www.gnu.org/software/gettext/manual/gettext.html#PO-Files)

+directive that can be put in po files is supposed to cause mischief

+(ie, include other files, run commands, crash gettext, whatever).

+

+### gettext

+

+#### Security history

+

+The only past security issue I could find in GNU gettext is

+[CVE-2004-0966](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2004-0966),

+*i.e.* [Debian bug #278283](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=278283):

+the autopoint and gettextize scripts in the GNU gettext package (1.14

+and later versions) may allow local users to overwrite files via

+a symlink attack on temporary files.

+

+This plugin would not have allowed to exploit this bug, as it does not

+use, either directly or indirectly, the faulty scripts.

+

+Note: the lack of found security issues can either indicate that there

+are none, or reveal that no-one ever bothered to find or publish them.

+

+#### msgmerge

+

+`refreshpofiles()` runs this external program.

+

+* I was not able to crash it with `zzuf`.

+* I could not find any past security hole.

+

+#### msgfmt

+

+`isvalidpo()` runs this external program.

+

+* I was not able to make it behave badly using zzuf: it exits cleanly

+ when too many errors are detected.

+* I could not find any past security hole.

+

+### po4a

+

+#### Security history

+

+The only past security issue I could find in po4a is

+[CVE-2007-4462](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4462):

+`lib/Locale/Po4a/Po.pm` in po4a before 0.32 allowed local users to

+overwrite arbitrary files via a symlink attack on the

+gettextization.failed.po temporary file.

+

+This plugin would not have allowed to exploit this bug, as it does not

+use, either directly or indirectly, the faulty `gettextize` function.

+

+Note: the lack of found security issues can either indicate that there

+are none, or reveal that no-one ever bothered to find or publish them.

+

+#### General feeling

+

+Are there any security issues on running po4a on untrusted content?

+

+To say the least, this issue is not well covered, at least publicly:

+

+* the documentation does not talk about it;

+* grep'ing the source code for `security` or `trust` gives no answer.

+

+On the other hand, a po4a developer answered my questions in

+a convincing manner, stating that processing untrusted content was not

+an initial goal, and analysing in detail the possible issues.

+The following analysis was done with his help.

+

+#### Details

+

+* the core (`Po.pm`, `Transtractor.pm`) should be safe

+* po4a source code was fully checked for other potential symlink

+ attacks, after discovery of one such issue

+* the only external program run by the core is `diff`, in `Po.pm` (in

+ parts of its code we don't use)

+* `Locale::gettext` is only used to display translated error messages

+* Nicolas François "hopes" `DynaLoader` is safe, and has "no reason to

+ think that `Encode` is not safe"

+* Nicolas François has "no reason to think that `Encode::Guess` is not

+ safe". The po plugin nevertheless avoids using it by defining the

+ input charset (`file_in_charset`) before asking `TransTractor` to

+ read any file. NB: this hack depends on po4a internals.

+

+##### Locale::Po4a::Text

+

+* does not run any external program

+* only `do_paragraph()` builds regexp's that expand untrusted

+ variables; according to [[Joey]], this is "Freaky code, but seems ok

+ due to use of `quotementa`".

+

+##### Text::WrapI18N

+

+`Text::WrapI18N` can cause DoS

+([Debian bug #470250](http://bugs.debian.org/470250)).

+It is optional, and we do not need the features it provides.

+

+If a recent enough po4a (>=0.35) is installed, this module's use is

+fully disabled. Else, the wiki administrator is warned about this

+at runtime.

+

+##### Term::ReadKey

+

+`Term::ReadKey` is not a hard dependency in our case, *i.e.* po4a

+works nicely without it. But the po4a Debian package recommends

+`libterm-readkey-perl`, so it will probably be installed on most

+systems using the po plugin.

+

+`Term::ReadKey` has too far reaching implications for us to

+be able to guarantee anything wrt. security.

+

+If a recent enough po4a (>=2009-01-15 CVS, which will probably be

+released as 0.35) is installed, this module's use is fully disabled.

+

+##### Fuzzing input

+

+###### po4a-translate

+

+* po4a CVS 2009-01-16

+* Perl 5.10.0

+

+`po4a-translate` uses more or less the same po4a features as our

+`filter` function.

+

+Without specifying an input charset, same behaviour as

+`po4a-gettextize`, so let's specify UTF-8 as input charset as of now.

+

+`LICENSES` is a 21M file containing 100 concatenated copies of all the

+files in `/usr/share/common-licenses/`; I had no existing PO file or

+translated versions at hand, which renders these tests

+quite incomplete.

+

+ zzuf -cv -s 0:10 -r 0.001:0.3 \

+ po4a-translate -d -f text -o markdown -M utf-8 -L utf-8 \

+ -k 0 -m LICENSES -p LICENSES.fr.po -l test.fr

+

+... seems to lose the fight, at the `readpo(LICENSES.fr.po)` step,

+against some kind of infinite loop, deadlock, or any similar beast.

+

+The root of this bug lies in `Text::WrapI18N`, see the corresponding

+section.

+

+

+----

+

+## Fixed holes

+

+

+----

+

+# original contrib/po page, with old commentary

+

+>>> I have a complete translation of basewiki into danish, available merged into

+>>> ikiwiki at git://source.jones.dk/ikiwiki-upstream (branch underlay-da), and am working with

+>>> translatable strings there too). My most recent po4a Markdown improvements

+>>> adopted upstream but not yet in Debian (see

+>>> [bug#530574](http://bugs.debian.org/530574)) correctly handles multiple

+

+# Robustness tests

+

+### Enabling/disabling the plugin

+

+* enabling the plugin with `po_translatable_pages` set to blacklist: **OK**

+* enabling the plugin with `po_translatable_pages` set to whitelist: **OK**

+* enabling the plugin without `po_translatable_pages` set: **OK**

+* disabling the plugin: **OK**

+

+### Changing the plugin config

+

+* adding existing pages to `po_translatable_pages`: **OK**

+* removing existing pages from `po_translatable_pages`: **OK**

+* adding a language to `po_slave_languages`: **OK**

+* removing a language from `po_slave_languages`: **OK**

+* changing `po_master_language`: **OK**

+* replacing `po_master_language` with a language previously part of

+ `po_slave_languages`: needs two rebuilds, but **OK** (this is quite

+ a perverse test actually)

+

+### Creating/deleting/renaming pages

+

+All cases of master/slave page creation/deletion/rename, both via RCS

+and via CGI, have been tested.

+

+### Misc

+

+* general test with `usedirs` disabled: **OK**

+* general test with `indexpages` enabled: **not OK**

+* general test with `po_link_to=default` with `userdirs` enabled: **OK**

+* general test with `po_link_to=default` with `userdirs` disabled: **OK**

+There may be a few others; my eyes glazed over. --Ethan

+

+rst support for ikiwiki seems to be on hold. rst is much more elegant

+than markdown in my opinion, so I tried it out in ikiwiki. I found out

+in other places that some directives work just fine, like [[meta]] and

+[[tag]], others work fine if you wrap them in `.. raw::`, like [[inline]].

+

+But to make a wiki we need [[WikiLinks]]; they can't be escape-inserted or

+such since they are inline elements in the text.. But images work fine in

+rst's syntax.. what about using rst syntax for wikilinks as well?

+Is it possible to inject something into the parser to turn unmached links

+``WikiLink`_` into ikiwiki links? --ulrik

+### canremove

+

+ hook(type => "canremove", id => "foo", call => \&canremove);

+

+This hook can be used to implement arbitrary access methods to control

+when a page can be removed using the web interface (commits from

+revision control bypass it). It works exactly like the `canedit` hook,

+but is passed the named parameters `cgi` (a CGI object), `session`

+(a session object) and `page` (the page subject to deletion).

+

+### canrename

+

+ hook(type => "canrename", id => "foo", call => \&canrename);

+

+This hook can be used to implement arbitrary access methods to control when

+a page can be renamed using the web interface (commits from revision control

+bypass it). It works exactly like the `canedit` hook,

+but is passed the named parameters `cgi` (a CGI object), `session` (a

+session object), `src`, `srcfile`, `dest` and `destfile`.

+

+Note: When the user edits an existing wiki page, this hook is also

+passed a `diff` named parameter, which will include only the lines

+that they added to the page, or modified.

+something, once per page linking to the renamed page's old location.

+The hook is passed named parameters: `page`, `oldpage`, `newpage`, and

+`content`, and should try to modify the content of `page` to reflect

+the name change. For example, by converting links to point to the

+new page.

+

+### rename

+

+ hook(type => "rename", id => "foo", call => \&rename);

+

+When a page or set of pages is renamed, the referenced function is

+called for every page, and is passed named parameters:

+

+* `torename`: a reference to a hash with keys: `src`, `srcfile`,

+ `dest`, `destfile`, `required`.

+* `cgi`: a CGI object

+* `session`: a session object.

+

+Such a hook function returns any additional rename hashes it wants to

+add. This hook is applied recursively to returned additional rename

+hashes, so that it handles the case where two plugins use the hook:

+plugin A would see when plugin B adds a new file to be renamed.

+`htmllink` is:

+Changes can be staged by calls to `rcs_add`, `rcs_remove`, and

+

+-----

+

+I'm working on an [[rcs]] plugin for CVS, adapted from `svn.pm`, in order to integrate ikiwiki at sites where that's all they've got. What's working so far: web commit (post-commit hook and all), diff, add (under certain conditions), and remove. What's not working: with rcs_add(), iff any of the new page's parent dirs aren't already under CVS control and the post-commit hook is enabled, the browser and ikiwiki stall for several seconds trying to add it, then time out. (If I kill ikiwiki when this is happening, it cvs adds the topmost parent that needed adding; if I wait for timeout, it doesn't. I think.) If I disable the post-commit hook and do the same kind of thing, the page is created and saved.

+

+In case you're lucky enough not to know, cvs adds on directories are weird -- they operate immediately against the repository, unlike file adds:

+

+ $ cvs add randomdir

+ Directory /Users/schmonz/Documents/cvswiki/repository/ikiwiki/randomdir added to the repository

+

+I was able to work out that when I'm seeing this page save misbehavior, my plugin is somewhere inside `system("cvs", "-Q", "add", "$file")`, which was never returning. If I changed it to anything other than cvs it iterated correctly over all the parent dirs which needed to be added to CVS, in the proper order. (cvs add isn't recursive, sadly.)

+

+Can you offer an educated guess what's going wrong here? --[[Schmonz]]

+

+> Got `rcs_recentchanges` working, believe it or not, thanks to [cvsps](http://www.cobite.com/cvsps/). If I can figure out this interaction between the post-commit hook and `cvs add` on directories, the CVS plugin is mostly done. Could it be a locking issue? Where should I be looking? Any suggestions appreciated. --[[Schmonz]]

+2009/7/13 Monday Blue...\\

+While working on [[http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199|[97] Phpbb 與 Dokuwiki 之間的往來]] (External Link to //http://eoffice.im.fju.edu.tw/phpbb/viewtopic.php?p=27199// not working?), surf Internet for Wikis supporting //Creole V1.0//, found this site.

+

+<<<<<<< HEAD:doc/sandbox.mdwn

+* I thought that creole markup is used by ikiwiki...

+* Thought about using //SVN/CVS// server, however with different idea

+* Kinda curious why **Tcl** does not show her face in this Wiki arena

+=======

+* Thought about using //SVN/CVS// server, however with different idea

+* Kinda curious why **Tcl** does not show her face in this Wiki arena

+* It looks like that I was wrong, from Wikipedia Creole page it mention that ikiwiki is also adopting Creole markup.

+>>>>>>> 55c1a37cce91d4fd01bf80fcaeeaf56535218a5c:doc/sandbox.mdwn

+

+----

+#中文标题一

+##中文标题二

+###中文标题三

+...

+######中文标题六

+

+###正文:

+

+君不见，黄河之水天上来，奔流到海不复回。

+

+君不见，高堂明镜悲白发，朝如青丝暮成雪。

+

+人生得意须尽欢，莫使金樽空对月。

+

+天生我材必有用，千金散尽还复来。

+

+###列表：

+

+* 天空

+

+ 1. 蓝色的

+ 2. 好高啊

+

+* 海洋

+

+ 1. 有鱼

+

+ * 鲸鱼

+ * 鲨鱼

+

+

+* 大地

+

+###链接：

+

+[谷歌](http://www.google.com)

+

+###引用：

+

+> 一级引用

+>

+> 一级引用

+>

+> > 二级引用

+>

+>> 没有空格也可以

+>>> 三级引用

+>

+> 回到一级引用

+

+

+[[Mamma Mia]]

+<span class="infobox">

+Available in a [[!taglink /git]] repository.<br />

+Branch: <TMPL_VAR branch><br />

+Author: <TMPL_VAR author><br />

+</span>

+<TMPL_UNLESS NAME="branch">

+This template is used to create an infobox for a git branch. It uses

+these parameters:

+

+<ul>

+<li>branch - the name of the branch, prefixed with the name of one of the

+ remotes listed on the [[/git]] page and provided by the gitremotes script

+ (e.g. github/master)</li>

+<li>author - the author of the branch</li>

+</ul>

+

+It also automatically tags the branch with `/git`.

+</TMPL_UNLESS>

+* Mick Pollard

+[[!tag patch patch/core plugins/inline]]

+>> Joey, would I be right to summarize your position on this as "people who

+>> want to change the text of the templates should maintain their own version

+>> of the `.tmpl` files"? It's not clear to me how this todo item could be

+>> closed in a way acceptable to you, except perhaps as WONTFIX. --[[smcv]]

+

+

+----

+

+It's almost implicit in some of the discussion above but this can be achieved locally if you fork your templates directory from ikiwiki's, with an ammendment such as

+

+ <h1><TMPL_LOOP NAME="PARENTLINKS"><a

+ href="<TMPL_VAR NAME=URL>"><TMPL_VAR NAME=PAGE></a>

+ &rarr;

+ </TMPL_LOOP><TMPL_VAR TITLE></h1>

+

+This is what I do on my site for example. -- [[Jon]]

+

+> You don't actually need to fork the whole directory, "only" `page.tmpl` -

+> put `templatedir => "/foo/templates"` in your setup file, copy `page.tmpl`

+> to that directory, and modify it there. IkiWiki will look in `templatedir`

+> first, then fall back to its default templates if any are missing from

+> `templatedir`.

+>

+> (Admittedly, `page.tmpl` is the hardest to maintain a fork of, because it

+> tends to change whenever a new plugin is added...) --[[smcv]]

+> Um, what is this for? :-) It would probably be a lot easier to review if it

+> had documentation, and/or a plugin that used it. --[[smcv]]

+

+[[!tag patch patch/core]]

+[[!template id=gitbranch branch=origin/gallery author="[[arpitjain]]"]]

+

+>> In [[todo/source_link]], Will does this via the CGI instead of delegating

+>> to gitweb/etc. I think Will's patch is a good approach, and have improved

+>> on it a bit in a git branch.

+

+[[!tag patch plugins/calendar]]

+>> This sounds like WONTFIX to me? --[[smcv]]

+

+>> [[done]] some time ago, as the [[plugins/404]] plugin --[[smcv]]

+

+[[!tag plugins/meta patch]]

+[[!template id=gitbranch branch=jon/defaultmeta author="[[Jon]]"]]

+

+Here's a patch to achieve this (also in the "defaultmeta" branch of

+

+> This doesn't support multiple-argument meta directives like

+> `link=x rel=y`, or meta directives with special side-effects like

+> `updated`.

+>

+> The first could be solved (if you care) by a syntax like this:

+>

+> meta_defaults => [

+> { copyright => "© me" },

+> { link => "about:blank", rel => "silly", },

+> ]

+>

+> The second could perhaps be solved by invoking `meta::preprocess` from within

+> `scan` (which might be a simplification anyway), although this is complicated

+> by the fact that some (but not all!) meta headers are idempotent.

+>

+> --[[smcv]]

+> I'd be inclined to implement that one by writing them to a nominated

+> underlay, I think, rather than having them in the srcdir but not in

+> the VCS. My [[plugins/contrib/album]] plugin could benefit from this

+> functionality, although in that case the photos should probably just

+> stay in the underlay forever (I already use an underlay on my own

+> websites for photos and software releases, which are too big to want

+> them in the VCS permanently.) --[[smcv]]

+

+[[!tag wishlist plugins/tag patch]]

+[[!tag patch patch/core]]

+[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]]

+

+IkiWiki::backlinks returns a form of $backlinks{$page} that has undergone a

+lossy transformation (to get it in the form that page templates want), making

+it more difficult to use in other contexts (like pagestats).

+

+A commit on my `among` branch splits it into IkiWiki::backlink_pages

+(which returns the keys of $backlinks{$page}, and might be suitable for

+exporting) and IkiWiki::backlinks (which calls backlink_pages, then performs

+the same lossy transformation as before on the result).

+

+[[done]] --[[Joey]]

+[[!tag patch patch/core]]

+

+> This is basically the same request as

+> [[todo/inline_postform_autotitles]]. --[[smcv]]

+[[!tag patch patch/core]]

+>> It looks to me as though this functionality won't be included in ikiwiki

+>> unless someone who wants it takes responsibility for updating the patch

+>> from that Debian bug to be applicable to current versions, so that there's a

+>> setup file parameter for extra filenames to allow, defaulting to none

+>> (i.e. a less simplistic patch than the one at the top of this page).

+>> Joey, is this an accurate summary? --[[smcv]]

+

+---

++1 I want `.htaccess` so I can rewrite some old Wordpress URLs to make feeds work again. --[[hendry]]

+

+---

++1 for various purposes (but sometimes the filename isn't `.htaccess`, so please make it configurable) --[[schmonz]]

+[[!tag patch patch/core plugins/rst]]

+[[!template id=gitbranch branch=smcv/gitignore author="[[smcv]]"]]

+[[!tag patch]]

+

+The recent merge of the po branch didn't come with a .gitignore.

+It eventually annoyed me enough to fix it :-) --[[smcv]]

+

+[[done]]

+

+> [[!cpan Geo::Coordinates::UTM]] would probably be useful. --[[smcv]]

+[[!tag patch patch/core]]

+[[!template id=gitbranch branch=smcv/ready/inline-pagenames author="[[smcv]]"]]

+

+A [[!taglink patch]] in my git repository (the inline-pagenames branch) adds

+the following parameter to the [[ikiwiki/directive/inline]] directive:

+

+> * `pagenames` - If given instead of `pages`, this is interpreted as a

+> space-separated list of links to pages (with the same

+> [[ikiwiki/SubPage/LinkingRules]] as in a [[ikiwiki/WikiLink]]), and they are inlined

+> in exactly the order given: the `sort` and `pages` parameters cannot be used

+> in conjunction with this one.

+

+This is on my [[wishlist]] for my [[plugins/contrib/album]] plugin, which currently

+uses it internally (as it has already collected the pages in order). It could also

+be useful for other things, like [[todo/wikitrails]]. --[[smcv]]

+

+[[!tag plugins/inline]]

+[[!tag wishlist patch plugins/inline]]

+[[!template id=gitbranch branch=chrysn/patches author="[[chrysn]]"]]

+> Something similar was requested in [[todo/more_customisable_titlepage_function]],

+> in which [[Joey]] outlined a similar solution.

+>

+> What's your use-case for not prompting for the title at all? I can see

+> [[madduck]]'s requirement for the title he typed in (say, "foo")

+> being transformed into 2009/07/26/foo or something (I name blog posts

+> like that myself), but I can't quite see the use for *entirely* automatic

+> titles.

+>

+> However, if that's really what you want, I suspect your code could be

+> extended so it also solves madduck's second request on

+> [[todo/more_customisable_titlepage_function]].

+>

+> --[[smcv]]

+

+>

+> The now merged po plugin also handles some of this.

+>> I don't see any problem with having this in meta? meta is on by default, and

+>> other plugins are free to use it or even depend on it (e.g. inline does).

+>>

+>> My only comments on this patch beyond what Joey said are that the page

+>> language could usefully go into `$pagestate{$page}{meta}{lang}` for other

+>> plugins to be able to see it (is that what you meant?), and that

+>> restricting to 2 characters is too restrictive (HTML 4.01 mentions

+>> `en`, `en-US` and `i-navajo` as possible language codes).

+>> This slightly complicates parsing the locale to get the default language:

+>> it'll need `tr/_/-/` after the optional `.encoding` is removed.

+>> --[[smcv]]

+

+>>> Now that po has been merged, this patch should probably also be adapted

+>>> so that the po plugin forces the meta::lang of every page to what po

+>>> thinks it should be. Perhaps [[the_special_po_pagespecs|ikiwiki/pagespec/po]]

+>>> should also work with meta-assigned languages? --[[smcv]]

+

+The following patch adds an 'rcsid' parameter to the [[!taglink plugins/Meta]] plugin, to allow inclusion

+[[!tag patch patch/core]]

+----

+

+> fails the test suite. --[[Joey]]

+>> This Markdown issue seems to have been worked around by the optimization

+>> in which \[[!inline]] is replaced with a placeholder, and the

+>> placeholder is later replaced by the HTML. Meanwhile, this patch

+>> has been obsoleted by applying a similar one (wrapping things in a div

+>> with class inlinefooter). That was the last remaining unapplied patch

+>> on this page, so I think this whole page can be considered [[done]].

+>> --[[smcv]]

+

+----

+

+Since `IkiWiki::titlepage` basically translates characters, it would be cool to be able to define a lookup hash in the configuration, which would be consulted before falling back to the generic `__xx__` `ord()` representation of a letter. For instance, in German, I might prefer to have 'ä' become 'ae' instead of something illegible.

+

+> This is [[todo/unaccent_url_instead_of_encoding]]. --[[smcv]]

+> This somewhat resembles [[todo/inline_postform_autotitles]].

+> Another way to do this, suggested in that todo, would be to

+> pre-fill the title field with YYYY/MM/DD/ using Javascript.

+> --[[smcv]]

+

+--[[Joey]]

+

+> I'll pass on these comments to the two similar todo items. --[[smcv]]

+

+

+> Perhaps what we need is a `postform` plugin/directive that inline depends

+> on (automatically enables); its preprocess method could automatically be

+> invoked from preprocess_inline when needed. --[[smcv]]

+>>>> [[Done]] in my `po` branch. --[[intrigeri]]

+[[!tag patch plugins/pagestats]]

+[[!template id=gitbranch branch=smcv/ready/among author="[[smcv]]"]]

+

+My `among` branch fixes [[todo/backlinks_result_is_lossy]], then uses that

+to provide pagestats for links from a subset of pages. From the docs included

+in the patch:

+

+> The optional `among` parameter limits counting to pages that match a

+> [[ikiwiki/PageSpec]]. For instance, to display a cloud of tags used on blog

+> entries, you could use:

+>

+> \[[!pagestats pages="tags/*" among="blog/posts/*"]]

+>

+> or to display a cloud of tags related to Linux, you could use:

+>

+> \[[!pagestats pages="tags/* and not tags/linux" among="tagged(linux)"]]

+

+I use this on my tag pages on one site, with the following template:

+

+ \[[!pagestats pages="tags/* and !tags/<TMPL_VAR raw_tag>

+ and !tags/photogallery"

+ among="tagged(<TMPL_VAR raw_tag>)"]]

+

+ \[[!inline pages="tagged(<TMPL_VAR raw_tag>)"

+ archive="yes" quick="yes" reverse="yes" timeformat="%x"]]

+

+--[[smcv]]

+

+> [[merged|done]] thanks --[[Joey]]

+[[!tag wishlist plugins/passwordauth]]

+

+> Debian now has Mail::Sender, Mail::SendEasy, and Email::Sender

+> (which, according to its dpkg description, "replaces the old and sometimes

+> problematic Email::Send library, which did a decent job at handling very

+> simple email sending tasks, but was not suitable for serious use, for a

+> variety of reasons"). Are any of those any better? It's unfortunate that

+> there doesn't seem to be a clear "best practice"... --[[smcv]]

+A feature I originally requested on

+[[a_related_bug|bugs/openid_no_longer_pretty-prints_OpenIDs]]:

+

+ Allow the openid plugin to be loaded but disabled, for its side-effect of defining IkiWiki::openiduser

+

+ On various sites I have two IkiWiki instances running from the same

+ repository: one accessible via http and only accepting openid logins,

+ and one accessible via authenticated https and only accepting httpauth.

+ Ideally, the https version should still pretty-print OpenIDs seen in

+ git history.

+

+--[[smcv]]

+

+> I wonder if an option is the best approach. Maybe it would be better to

+> simply move `openiduser` into `userlink`, and thus always support openid

+> usernames whether the plugin is enabled or not. --[[Joey]]

+

+>> OK, implemented that as 'smcv/always-openid'; if you don't think that's

+>> bloating the IkiWiki core too much, please consider merging. The poll on

+>> [[news/openid]] indicates fairly strong support for *only* accepting OpenID

+>> logins, so I think recognising OpenIDs can reasonably be considered core

+>> functionality! --[[smcv]]

+

+>>> That seemed easier than expected, [[done]].

+>>> (I do wonder if the call to openiduser still needs to be evaled --

+>>> it was probably only evaled before in case it was not available, but

+>>> I have not carefully checked it to make sure it doesn't ever die. --[[Joey]]

+

+[[!tag patch]]

+[[!template id=gitbranch branch=smcv/ready/optimize-depends author="[[smcv]]"]]

+

+>> I've been looking at optimizing ikiwiki for a site using

+>> [[plugins/contrib/album]] (which produces a lot of pages) and it seems

+>> that checking which pages depend on which pages does take a significant

+>> amount of time. The optimize-depends branch in my git repository

+>> avoids using `pagespec_merge()` for this (indeed it's no longer used

+>> at all), and instead represents dependencies as a list of pagespecs

+>> rather than a single pagespec. This does turn out to be faster, although

+>> not as much as I'd like. --[[smcv]]

+

+>>> I just wanted to note that there is a whole long discussion of dependencies and pagespecs on the [[todo/tracking_bugs_with_dependencies]] page. -- [[Will]]

+

+>>>> Yeah, I had a look at that (as the only other mention of `pagespec_merge`).

+>>>> I think I might have solved some of the problems mentioned there,

+>>>> actually - `pagespec_merge` no longer needs to exist in my branch (although

+>>>> I haven't actually deleted it), because the "or" operation is now done in

+>>>> the Perl code, rather than by merging pagespecs and translating. --[[smcv]]

+

+[[!template id=gitbranch branch=smcv/ready/remove-pagespec-merge author="[[smcv]]"]]

+

+>>>>> I've now added a patch to the end of that branch that deletes

+>>>>> `pagespec_merge` almost entirely (we do need to keep a copy around, in

+>>>>> ikiwiki-transition, but that copy doesn't have to be optimal or support

+>>>>> future features like [[tracking_bugs_with_dependencies]]). --[[smcv]]

+

+[[!tag wishlist patch patch/core]]

+> The use of sessioncgi here seems undesirable: on wikis where anonymity is

+> not allowed, you'll be asked to log in. Couldn't you achieve the same thing

+> by loading the index with IkiWiki::loadindex, like [[plugins/goto]] does?

+> --[[smcv]]

+

+[[!template id=gitbranch branch=smcv/ready/getsource

+ author="[[Will]]/[[smcv]]"]]

+

+>> I've applied the patch below in a git branch, fixed my earlier criticism,

+>> and also fixed a couple of other issues I noticed:

+>>

+>> * missing pages could be presented better as a real 404 page

+>> * the default Content-type should probably be UTF-8 since the rest of

+>> IkiWiki tends to assume that

+>> * emitting attachments (images, etc.) as text/plain isn't going to work :-)

+>>

+>> Any opinions on my branch? I think it's ready for merge, if Joey approves.

+>>

+>> --[[smcv]]

+

+>>> I need a copyright&license statement, so debian/copyright can be updated for

+>>> the plugin, before I can merge this. Otherwise ready. --[[Joey]]

+

+>>> That looks like a nice set of fixes. One more that might be worthwhile: instead of reading the page source into a var, and then writing it out later, it might be nice to just

+>>> `print readfile(srcfile(pagesources{$page}));` at the appropriate point. -- [[Will]]

+

+>>>> OK, I've committed that. --[[smcv]]

+

+> The implementation looks fine to me (assuming it works with current ikiwiki),

+> apart from the "XXX" already noted in the patch. The design could reasonably

+> be considered premature generalization, though - how often do you actually

+> need to define new tmplvars?

+>

+> As for the page/destpage/preview thing, it would be good if the preprocess

+> hook could distinguish between software-supplied and user-supplied

+> parameters (the [[plugins/tag]] plugin could benefit from this too). Perhaps

+> the IkiWiki core could be modified so that

+> `hook(type => "preprocess", splitparams => 1, ...)` would invoke preprocess

+> with { page => "foo", destpage => "bar", ... } as a special first argument,

+> and the user-supplied parameters as subsequent arguments? Then plugins like

+> tag could use:

+>

+> my $ikiparams = shift;

+> my %params = @_;

+>

+> add_tags($ikiparams->{page}, keys %params);

+>

+> --[[smcv]]

+

+----

+

+[[!tag patch patch/core]]

+

+>>> Alternatively, my [[remove-pagespec-merge|should_optimise_pagespecs]]

+>>> branch solves this, in a Gordian knot sort of way :-) --[[smcv]]

+

+--[[cstamas]]

+> This was previously requested in [[todo/more_customisable_titlepage_function]],

+> in which [[Joey]] said "I don't think that changing titlepage is a good idea,

+> there are compatability problems".

+>

+> The problem is that altering titlepage changes the meaning of your wiki,

+> by resolving all wiki links to different page names. That means that:

+>

+> * unaccenting can't be automatic, it has to be a configuration option

+> (so you don't accidentally get different behaviour by installing

+> Text::Unaccent)

+> * upgrading Text::Unaccent becomes risky, as I doubt it guarantees to

+> have stable rules for how to transliterate into ASCII!

+>

+> --[[smcv]]

+

+[[!tag wishlist patch patch/core]]

+>>> It seems worth mentioning here that the `libdir` configuration parameter

+>>> lets you install additional plugins in a user-controlled directory

+>>> (*libdir*`/IkiWiki/Plugin`), avoiding needing root; indeed, a full local

+>>> ikiwiki installation without any involvement from the sysadmin is

+>>> [[possible|tips/DreamHost]]. --[[smcv]]

+

+

+----

+

+Revisiting this, after effectively reimplementing a small version of it

+in [[plugins/contrib/album]]: it occurs to me that might be a more

+"ikiwiki-like" way we could get this functionality.

+

+In the index page, you either want an [[ikiwiki/directive/inline]], or

+a list of links. In the former case, maybe we could extend inline like

+this:

+

+ \[[!inline ... blah blah ... trail=yes]]

+

+to make it remember the pages it inlined, in order, in the pagestate;

+in the latter case, we could replace the wikilinks with a directive,

+an operation something like this in diff notation:

+

+ - \[[one]] - the unit

+ - \[[two]] - the base of binary

+ - \[[three|3]] - is a crowd

+ + \[[!trailitem one]] - the unit

+ + \[[!trailitem two]] - the base of binary

+ + \[[!trailitem three|3]] - is a crowd

+

+and have that directive remember the pages in order.

+

+In both cases, a scan() hook could clear the list before starting to

+scan, then the inline or trailitem preprocessor directive could run in

+the scan stage as well as the render stage (in the case of inline,

+there'd be a very early return if trail=yes was not given, and

+an early return after collecting and sorting the pages if not

+actually rendering).

+

+This would mean that the contents of the trail, and a list of

+trails in which each page can be found, would already be in

+the pagestate by the time any page was rendered, so we'd be able

+to use them for output, either in a pagetemplate() hook or

+a \[[!trail]] preprocessor directive.

+

+This way, my album plugin could be turned inside out: instead

+of precomputing the pages to be inlined, then using

+[[pagenames|todo/inline plugin: specifying ordered page names]]

+to get them into the inline, it could just do the inline, then

+incorporate the output of \[[!trail]] into the template rendered

+for \[[!albumimage]] on each viewer page. (Also, the viewers

+wouldn't necessarily need to reference the album, only the other

+way round.)

+

+Using a pagetemplate() hook to stuff the next/previous links

+into page.tmpl would actually be a bit unfortunate for \[[!album]],

+because that plugin definitely wants to style the next/previous

+links as a thumbnail, which means there'd have to be a way to

+affect the style - perhaps by arranging for album's pagetemplate

+hook to run *after* trail's, or perhaps by having trail's

+pagetemplate hook disable itself for pages that contain

+a \[[!trail]] directive.

+

+I have now implemented this at [[plugins/contrib/trail]].

+What do you think? I'm still not sure how it would relate

+to [[plugins/contrib/album]], but if trail is reviewed

+and approved in principle, I'll try to adapt album as

+outlined above. --[[smcv]]

+1. The [[basewiki]] needs to be translated. The

+ [[plugins/contrib/po]] ikiwiki plugin will allow translating

+ wikis using po files and can be used for this.

+

+ To generate the po and pot files for translating the basewiki,

+ get ikiwiki's source, edit the `po/underlay.setup` file,

+ adding your language. Then run 'make -C po underlays`.

+ This will generate many po files under `po/underlays`. The first

+ ones you'll want to translate are in the `po/underlays/basewiki` directory,

+ which is really not very large, just a few thousand words.

+ After that is done, you can tackle those under

+ `po/underlays/directives`, which are a much larger (tens of

+ thousands of words).

+

+ > We use git now, so you can clone my repo, commit to your clone, and

+ > use git to mail me patches. --[[Joey]]

+>> Thank you very much! It also will be a big help for me. --[[Paweł|ptecza]]

+Using ikiwiki for my yet to be publish personal website :)

+## personal/site info

+

+New ikiwiki site at my web site, blog, kisikew.org home site, for indigenews, and our indigenous-centric wiki (mostly East Coast/Woodlands area). Mediawiki stuff was imported successfully (as noted on this web site).

+

+## ikiwiki branch at github

+

+Maintain my own branch, partly to learn about VCS, git, ikiwiki, Debian packaging, and Perl. I don't recommend anyone pull from it, as I use third-party plugins included on this site that people may not want in a default installation of ikiwiki. This is why I don't push to Joey's -- so it's nothing personal, I just don't want to mess things up for other people, from my mistakes and stumbles.

+This plugin has now been implemented as [[plugins/contrib/album]]; this

+page has older thoughts about it.

+(Edited to add: this is what [[plugins/contrib/album]] implements. --[[smcv]])

+

+> Coming back to this: a specialized web UI to mark attachments as part of

+> the gallery would make this easy too - you'd put the photos in the

+> underlay, then go to the CGI and say "add all". --[[smcv]]

+

+> Coming back to this later: the clever lookup rules make dependency tracking

+> hard, though. --[[smcv]]

+