Hello,

I studied this guy's problem and I propose here a (dirty) hack to correct it.

Bug summary: when using the calendar plugin in French (LANG=fr_FR.UTF-8), "Décembre" (French for "December") is rendered as "Décembre".

I managed to track this problem down to an encoding problem of POSIX::strftime in Ikiwiki/Plugin/calendar.pm. I used this guy's solution to solve the problem (the diff is printed below).

The problem is that I do not know Perl, encoding is one of the thing I would be happy not to dive into, and it is the first time I contribute to Ikiwiki: I copied and made a few changes to the code I found without understanding it. So I am not sure that my code is neat, or works in every situation. Feel free to (help me to) improve it!

Cheers,
Louis

Yes, this seems basically right. I've applied a modified version of this. done --Joey

diff --git a/IkiWiki/Plugin/calendar.pm b/IkiWiki/Plugin/calendar.pm
index c7d2b7c..1345939 100644
--- a/IkiWiki/Plugin/calendar.pm
+++ b/IkiWiki/Plugin/calendar.pm
@@ -22,7 +22,14 @@ use warnings;
 use strict;
 use IkiWiki 3.00;
 use Time::Local;
-use POSIX ();
+
+use POSIX qw/setlocale LC_TIME strftime/;
+use Encode;
+my ($strftime_encoding)= setlocale(LC_TIME)=~m#\.([^@]+)#;
+sub strftime_utf8 {
+# try to return an utf8 value from strftime
+   $strftime_encoding ? Encode::decode($strftime_encoding, &strftime) : &strftime;
+}

 my $time=time;
 my @now=localtime($time);
@@ -123,10 +130,10 @@ sub format_month (@) {
    }

    # Find out month names for this, next, and previous months
-   my $monthabbrev=POSIX::strftime("%b", @monthstart);
-   my $monthname=POSIX::strftime("%B", @monthstart);
-   my $pmonthname=POSIX::strftime("%B", localtime(timelocal(0,0,0,1,$pmonth-1,$pyear-1900)));
-   my $nmonthname=POSIX::strftime("%B", localtime(timelocal(0,0,0,1,$nmonth-1,$nyear-1900)));
+   my $monthabbrev=strftime_utf8("%b", @monthstart);
+   my $monthname=strftime_utf8("%B", @monthstart);
+   my $pmonthname=strftime_utf8("%B", localtime(timelocal(0,0,0,1,$pmonth-1,$pyear-1900)));
+   my $nmonthname=strftime_utf8("%B", localtime(timelocal(0,0,0,1,$nmonth-1,$nyear-1900)));

    my $archivebase = 'archives';
    $archivebase = $config{archivebase} if defined $config{archivebase};
@@ -182,7 +189,7 @@ EOF
    my %dowabbr;
    for my $dow ($week_start_day..$week_start_day+6) {
        my @day=localtime(timelocal(0,0,0,$start_day++,$params{month}-1,$params{year}-1900));
-       my $downame = POSIX::strftime("%A", @day);
+       my $downame = strftime_utf8("%A", @day);
        my $dowabbr = substr($downame, 0, 1);
        $downame{$dow % 7}=$downame;
        $dowabbr{$dow % 7}=$dowabbr;
@@ -329,8 +336,8 @@ EOF
    for (my $month = 1; $month <= 12; $month++) {
        my @day=localtime(timelocal(0,0,0,15,$month-1,$params{year}-1900));
        my $murl;
-       my $monthname = POSIX::strftime("%B", @day);
-       my $monthabbr = POSIX::strftime("%b", @day);
+       my $monthname = strftime_utf8("%B", @day);
+       my $monthabbr = strftime_utf8("%b", @day);
        $calendar.=qq{\t<tr>\n}  if ($month % $params{months_per_row} == 1);
        my $tag;
        my $mtag=sprintf("%02d", $month);

I have ikiwiki_3.20111229 installed on Debian Squeeze (Perl 5.10.1, UTF-8 locale). The attachment plugin mangles UTF8-encoded attachment filenames if the name contains multibyte characters, e.g. "lää.png" becomes "lää.png". Apparently glob returns byte strings which are subject to implicit upgrading when concatenated with Perl strings. The following patch fixes the problem for me:

---

diff -r -U 1 a/attachment.pm b/attachment.pm
--- a/attachment.pm 2012-01-13 23:07:29.000000000 +0200
+++ b/attachment.pm 2012-01-13 23:33:07.000000000 +0200
@@ -274,2 +274,3 @@
    foreach my $filename (glob("$dir/*")) {
+       $filename=Encode::decode_utf8($filename);
        next unless -f $filename;
@@ -347,2 +348,3 @@
    foreach my $file (glob("$dir/*")) {
+       $file = Encode::decode_utf8($file);
        next unless -f $file;

Seems it only mangled display of the just-uploaded attachment's filename, the attachment was otherwise saved to disk with a valid UTF-8 name, and doing other stuff with it also was ok. In any case, I applied your patch, thanks. done --Joey

It seems backlink(.) doesn't work, that is, it doesn't match pages linked to from the current page.

If I have two test pages, foo, which links to bar, then (on the foo page):

• backlink(foo) lists 'bar'
• backlink(.) lists nothing

tested with 3.20120109.

— Jon

The attached patch should fix it:

applied thanks --Joey

From 30512ac5f6a724bafb1095ab246e0648999f7b6c Mon Sep 17 00:00:00 2001
From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Fri, 13 Jan 2012 11:02:11 +0100
Subject: [PATCH] backlink(.) should behave like backlink(<current page>)

Since commit c4d4cad3befbbd444d094cbeb0b6ebba3910a025, the single dot in
a pagespec can be used to mean the current page. While this worked
correctly in link() it didn't work in backlink(). Fix this by explicitly
checking the testpage in backlink against . and replacing it with the
current location if necessary.
---
 IkiWiki.pm |   10 ++++++++--
 1 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/IkiWiki.pm b/IkiWiki.pm
index 08e242a..bc56501 100644
--- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -2647,8 +2647,14 @@ sub match_link ($$;@) {
 }

 sub match_backlink ($$;@) {
-   my $ret=match_link($_[1], $_[0], @_);
-   $ret->influences($_[1] => $IkiWiki::DEPEND_LINKS);
+   my $page=shift;
+   my $testpage=shift;
+   my %params=@_;
+   if ($testpage eq '.') {
+       $testpage = $params{'location'}
+   }
+   my $ret=match_link($testpage, $page, @_);
+   $ret->influences($testpage => $IkiWiki::DEPEND_LINKS);
    return $ret;
 }

-- 
1.7.8.rc2.253.gdbf3

(you need to re-make IkiWiki for it to work)

I can't check the last changes in Ikiwiki using gitweb. It looks like XML validation problem with HTML entity.

When I click a appropriate link on a git page, then I can only see the following error message. --Paweł

<div class="title">&nbsp;</div>
-------------------^

I don't see or understand the problem. I've tried History links as well as the diff links in RecentChanges, both seem to be working. --Joey

Hm. It's strange. I really could see the error message like above when I sent my report. It seems that works now. So, we should be happy that it was self-fixed bug --Paweł

If it happens again, maybe take a full dump of the page? done

I can't add any attachment to my wiki. When I select file using "Browse" button and click "Upload Attachment", then ikiwiki.cgi file displays the error message like below:

Błąd: failed to get filehandle

Can you do some debugging? If you edit attachment.pm line 136, to print out what it did get, and show me what that yields, maybe I can figure this out.

error("failed to get filehandle ($fh)");

Sure. I've done the change and it seems that $fh variable is undefined:

Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/IkiWiki/Plugin/attachment.pm line 135.
failed to get filehandle ()

Also, what web server and version of perl is this? --Joey

It's Apache2 2.2.8-1ubuntu0.3 and Perl 5.8.8-12 from Ubuntu Hardy. --Paweł

Hmm, is your CGI.pm perhaps creating the attachment temp file, but not providing an open filehandle to it via the upload method? Change the debugging line to this: --Joey

error("failed to get filehandle:$fh ; file:$filename ; is ref:".ref($q->param('attachment')));

Now my Ikiwiki returns:

failed to get filehandle: ; file:sandbox/test.txt ; is ref:

Is it helpful for you? --Paweł

Yes, this suggests that CGI.pm's upload function is not working, but that it is returning a filehandle pointing at the attachment using the old method. Hmm, so I'll bet you have a CGI.pm version older than 2.47. Can you find your system's CGI.pm and grep for "VERSION" in it to determine the version? I checked debian stable. and its perl 5.8.8 has version 3.15, so is not affected, I think.

I have CGI.pm 3.15 too:

$ grep VERSION= /usr/share/perl/5.8.8/CGI.pm
$CGI::VERSION='3.15';

I've just checked in a fix that should work, can you test it? 71f10579c00a8ddc20ada1a1efd33aac25a3da7e --Joey

I've patched attachment.pm module, but the bug still occurs. However I can see a little progress. I changed invoking error() subroutine like you showed me before and now Ikiwiki prints

failed to get filehandle:test.txt ; file:sandbox/test.txt ; is ref:

--Paweł

Well then, your CGI.pm is somehow not behaving as its documentation describes, in two ways: 1. upload() is not returning a reference to the filehandle 2. The filename returned by param("attachment") is not also a file handle. That seems very broken. I can try to work around it some more though. I've checked in a second try at dealing with things, can you try it? --Joey

Do you mean that 66f35e30dcea03c631a293e2341771277543b4ae? If so, then it causes "Internal Server Error" for me:

Can't use string ("test.txt") as a symbol ref while "strict refs" in use at /usr/share/perl5/IkiWiki/Plugin/attachment.pm line 144.

I can rebuild Debian stable source package with CGI for Perl. Maybe it will help me? What do you think? --Paweł

Silly thinko on my part, fixed that in git.. --Joey

Thanks for the fix, Joey! Now CGI doesn't fails, but still no success with attaching file:

failed to open : No such file or directory

Do you have any another idea how to resolve that problem? I can try with rebuilding package perl-modules if it's necessary in that situation. --Paweł

If CGI.pm is not creating a temp file, not providing a filehandle by either of its documented methods, then it's just broken; ikiwiki can't deal with that level of brokennecess. I need to find out if this affects stable in general, or just you/ubuntu. --Joey

Same thing on FreeBSD using CGI.pm 3.15. Looks like $self->{'.tmpfiles'} in CGI.pm is not populated with the information about the uploaded file, causing tmpFileName() to return '' (unloadInfo(), which uses the same lookup method fails in the same manner), but I have yet to find out why this happens. --HenrikBrixAndersen

The same message I can see in the Apache log file. There is also following warning:

Use of uninitialized value in length at /usr/share/perl5/IkiWiki/Plugin/attachment.pm line 36.

This is unrelated, I've fixed the warning message. --Joey

Is it Ikiwiki bug or my attachment plugin is misconfigured? --Paweł

I've reproduced the bug, and it does seem to be a bug with the perl in debian stable/ubuntu hardy. Trying to figure it out --Joey

This was amazingly disgusting, see commit message for the full horror of the details. I think it's done -- at least it works on debian stable now. --Joey

Wow! It's probably the biggest Ikiwiki commit message I've ever seen

Yes, I can confirm that now the plugin works for me and I'm able to add attachments to my wiki. Yupiii! Thanks a lot, Joey! You're really great! --Paweł

Thank you very much for your effort, Joey! --Paweł

On Line #46 of the bzr plugin there's a mistalke. Instead of:

my @cmdline = ("bzr", $config{srcdir}, "update");

It should be:

my @cmdline = ("bzr", "update", $config{srcdir});

The former produces errors such as "bzr: ERROR: unknown command "/home/user/ikiwiki/posts", "'bzr /home/user/ikiwiki/posts update' failed: Inappropriate ioctl for device at /usr/share/perl5/IkiWiki/Rcs/bzr.pm line 48.".

done, thanks --Joey

The img directive allows for specifying an align parameter -- which is of limited usability as the image is embedded as <p><img ...></p>. That's at least what I see on http://www.bddebian.com:8888/~hurd-web/hurd/status/. On the other hand, CSS is supposed to be used instead, I guess. (But how... I forgot almost of my CSS foo again it seems.) --tschwinge

The img tag doesn't create P tags, but if you have surrounded the img directive with newlines, they will result in paragraph tags.

I've edited the URL you provided to demonstrate this -- hope you don't mind! I've also added an inline, right-aligned image to this page. -- Jon

Contrary to all of the above, html does not care about P tags when floating an image to the left or right via align. Proof: http://kitenet.net/~joey/pics/toomanypicturesofjoey/, where the image is in its own paragraph but still floats. Also, I re-modified a local copy of the hurd page to enclose the image in a P, and it still floats.

Tested with Chromium and Firefox. --Joey

Uh, sorry for not confirming what I supposed to be with looking into the relevant standard. It just seemed too obvious to me that the closure of <p>...</p> would confine whatever embedded stuff may be doing. (Meaning, I didn't expect that the img's alignment would propagate to the p's and would thus be visible from the outside.)

I confirm (Firefox, Ubuntu jaunty) that your picture page is being shown correctly -- thus I suppose that there's a buglet in our CSS scripts again...

--tschwinge

It seems, the 'align=right' parameter gets filtered in my installation Are there other plugins, that could throw the parameter away? --jwalzer

Can't think of anything. htmlscrubber doesn't; tidy doesn't. --Joey

I'm getting this error message when I refresh my wiki:

$ hg commit -u me -m "Minor corrections"
refreshing wiki..
scanning htmletc/moco-conf-rooms.mdwn
building htmletc/moco-conf-rooms.mdwn
Use of uninitialized value in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.8.9/Text/Typography.pm line 542.
building sidebar.mdwn, which depends on htmletc/moco-conf-rooms
building contact.mdwn, which depends on sidebar
building 500.mdwn, which depends on sidebar
Use of uninitialized value in concatenation (.) or string at /usr/local/lib/perl5/site_perl/5.8.9/Text/Typography.pm line 542.
building ceramics.mdwn, which depends on sidebar
building glossary.mdwn, which depends on sidebar
syntax error in pagespec "internal(glossary/comment_*)"
warning: post-commit hook exited with status 2

But there is no error if I use ikiwiki --rebuild to regenerate the whole thing.

You neglect to say what version of ikiwiki this is, or give any information to reproduce the bug.

My guess: A version older than 3.20100403, which included 799b93d258bad917262ac160df74136f05d4a451, which could lead to incorrect "syntax error in pagespec" that only happened some of the time.

(The Text::Typography warning seems probably unrelated.) --Joey

I'm sorry, I don't know what I was thinking there. It's ikiwiki 3.20100212, and manually applying the patch you linked to made the bug go away. (Upgrading ikiwiki is a pain on nearlyfreespeech, especially if you don't want to keep the build directory around -- please consider making ikiwiki runnable directly from a git clone.)

The final </div> in recentchanges.tmpl gets wrapped in a <p> tag for some reason, resulting in the following invalid XHTML at the end of the RecentChanges page

<p></div></p>

I'll bet this is fixed if you use the markdown 1.2 prerelease, which has a much less buggy html parser. (Ah, I see below that was the case.) --Joey

Also, there is a problem with the <img> tags generated by the smiley plugin which end up wrapped in a <pre> tag in the inline diff output. <img> tags is not allowed within a <pre> block. Maybe the smiley plugin should be disabled on RecentChanges?

See Smileys in the block code, which is now fixed. --Joey

See the validator output for more details.

---

I'll add this here since it's related. I also noticed that the meta tags for redirected pages need to be closed in order to be valid XHTML:

<meta http-equiv="refresh" content="10; URL=../ikiwiki/pagespec/">

I'm noticing these problems because I'm serving ikiwiki-generated content as application/xhtml+xml (as opposed to text/html) in order to include inline MathML. Any invalid XHTML causes Firefox to halt all processing and throw an error. —Jason Blevins

---

Here is a simple patch for the refresh problem. I haven't figured out what's causing the recentchanges bug yet.

--JasonBlevins

Thanks, applied that patch. --Joey

---

It turns out that the invalid XHTML on the recent changes page is due to a bug in Markdown. I was using the packaged version of markdown in Ubuntu (Gutsy and markdown 1.0.1-6). Everything is fine after installing the most recent version of Text::Markdown from CPAN.

Note that the above patch for the redirect tag is still applicable and the smiley issue remains open. --JasonBlevins

This bug is done, all issues are fixed. --Joey

To make ikiwiki publish world-readable files (usually what you want) regardless of your umask, you override the umask setting to 022 octal (which is 18 in decimal). So far so good.

However, because it's interpreted as a plain number in Perl, the way you set it varies between formats. In IkiWiki::Setup::Standard you can use either

umask => 022

or (less obviously) one of

umask => 18
umask => "18"

but if you use

umask => "022"

you get the less than helpful umask of 026 octal (22 decimal).

Similarly, in IkiWiki::Setup::Yaml (the default for ikiwiki-hosting you have to use one of

umask: 18
umask: "18"

and if you try to say 022 you'll get 22 decimal = 026 octal.

Available in a git repository branch.
Branch: smcv/umask-keywords
Author: smcv

Perhaps the best way to solve this would be to have keywords for the few values of umask that are actually useful?

• private (= 077 octal = 63 decimal)
• group (= 027 octal = 23 decimal)
• public (= 022 octal = 18 decimal)

I don't think g+w is a good idea in any case, because as documented on security, if ikiwiki makes its srcdir group-writeable then any member of the group can "cause trouble" (escalate privileges to those of the wiki user?) via a symlink attack. So I don't think we need keywords for those.

--smcv

I support this change, but your git repository does not seem to have that branch (or anything) in it today. --Joey

git pushes have a restrictive umask, ironically... fixed. --smcv

done --Joey