ikiwiki/ bugs/ done

recently fixed bugs

Problem with displaying smileys on inline page

I've noticed that my browser doesn't display the smileys on a page where I used inline pluggin. However I can see them when I click the link to the inlined "subpage".

I checked HTML sources and it seems that Ikiwiki always generate the same relative path to image file with a smile (../../../../../smileys/smile.png), regardless of the page location. Are you sure it's a right working?

What about if I have main inline page, for example http://www.domain.com/blog/ page with http://www.domain.com/blog/post/2008/06/27/foo/ subpage with the smile?

Do you have any idea how to fix it? I dont't want to have multiple smileys directory, of course :) --Paweł

I see that I broke this in commit 0b9e849aba38f0695491ad5ca27de11632627ffe, presumably because a) sanitize filters didn't get destpage at the time and b) I didn't think through what that meant. Luckily, in the meantime, I added destpage to santize's parameters, so it was easy to fix. done --Joey

Great! Thank you very much, Joey!

BTW, I love Git (and another distributed SCMs) commit id. It's so human friendly ;) --Paweł

Posted Sun Jun 29 14:09:52 2008
toc in sidebar

Putting a toc in the sidebar used to work, but was broken by commit 9652cdfe2eb16150518e34af33c8858118fe0a09, which, in turn fixed a bug with the toc not appearing during page preview.

So, if toc is a sanitize hook, it can't be used in the sidebar, because the sidebar is only added to the page later. If the toc is a format hook, it shows up in the sidebar, but not at page preview time (because format hooks are not called during preview). Also, calling the toc as a format hook makes any headers that are hardcoded into the page template show up in the toc, which is rarely desirable.

I can't think of a way between these that works in all cases. Maybe call the format hooks when generating a page preview? Maybe add an option to toc to make it embeddable in the sidebar?

Hmm, I think I need to call format during preview. Another case is that inline uses a format hook to insert the inlined content..

--Joey

done

Posted Sat Jun 28 22:52:13 2008
textile plugin dies if input has a non-utf8 character
20:03:56$ ikiwiki --setup *setup --rebuild
successfully generated /home/jon/git/ikiwiki/hooks/post-update
utf8 "\x92" does not map to Unicode at /usr/share/perl5/IkiWiki.pm line 320, <$in> chunk 1.
utf8 "\x92" does not map to Unicode at /usr/share/perl5/IkiWiki.pm line 320, <$in> chunk 1.
ikiwiki.setup: Malformed UTF-8 character (fatal) at /usr/share/perl5/Text/Textile.pm line 775.
BEGIN failed--compilation aborted at (eval 6) line 166.

The first two complaints happen if textile is not loaded, the third fatal one happens if it is.

0x92 is "single quote" in the evil windows default codepage. It would be nice to handle this gracefully and not abort ikiwiki at this point, or alternatively, die fatally but mention which input page caused the error.

Interestingly enough, in my case, the input file has several other bad windows characters (0xFC, u-umlaut) which have not caused ikiwiki to abort. ikiwiki version 2.50. -- JonDowland

Fixed in git. done --Joey

Posted Mon Jun 16 15:43:12 2008
Can't rebuild wiki pages with ikiwiki 2.49

I've just upgraded ikiwiki from version 1.45 to 1.49, using my own Ubuntu Gutsy backport. Now I can't rebuild all my wiki pages. Both methods of rebuilding pages fail:

$ sudo ikiwiki-mass-rebuild 
Processing /home/ptecza/path/to/ikiwiki.setup as user ptecza ...
failed to set egid 1000 4 20 24 25 29 30 44 46 104 109 110 119 1000 (got back 1000 1000 119 110 109 104 46 44 30 29 25 24 20 4) at /usr/sbin/ikiwiki-mass-rebuild line 38, <$list> line 13.
Processing /home/ptecza/path/to/ikiwiki.setup as user ptecza failed with code 65280

$ ikiwiki --setup ikiwiki.setup
pomyślnie utworzono /var/www/path/to/ikiwiki.cgi
pomyślnie utworzono /home/ptecza/path/to/hooks/post-commit.ikiwiki
terminate called after throwing an instance of 'Xapian::InvalidArgumentError'
Aborted

I've installed all needed packages for new search engine and added path to omega binary in my ikiwiki.setup file.

Any ideas how to fix that problem? --Paweł

Well, it's two separate problems. Xapian is crashing in the C code when asked to create a stemmer for pl. This is a Xapain bug, but I've put in a workaround.

For the first problem, looks like I need a more robust grouplist comparor -- fixed in git.

done --Joey

Thanks a lot for the rapid fix, Joey! Now my ikiwiki works good for me :)

BTW, why have you replaced Hyper Estraier by Xapian? It seems that second search engine is faster, but I'm not sure it has the same wide syntax. Also I can't see how to change number of hits per page... --Paweł

Xapian indexes more quickly, and with the perl interface I was able to make updates for changes pages quite efficient. My experience with Hyper Estraier has not been good, with its database often breaking, and it sometimes crashing. Xapian also does a ranked search, and supports searching for specific metadata like "title:foo". --Joey

Thank you very much for the reply! I have never had problems with Hyper Estraier, but I'm not a long-time user of that searching engine. It's good to know about Xapian pros and Hyper Estraier cons. --Paweł

Posted Mon Jun 16 15:30:35 2008
Can't build 2.49?

Solved - see Buo's suggestion below

I'm using ikiwiki on a shell account/hosting site where I can build but have no root privileges. I went to build 2.49 last night, but make fails with the following error:

/home/telemachus/bin/perl -Iblib/lib   ikiwiki.out -libdir . -setup docwiki.setup -refresh
docwiki.setup: Failed to load plugin IkiWiki::Plugin::inline: Too many arguments for IkiWiki::htmlize at IkiWiki/Plugin/inline.pm line 359, near "))"
Compilation failed in require at (eval 14) line 2.
BEGIN failed--compilation aborted at (eval 14) line 2.

BEGIN failed--compilation aborted at (eval 10) line 21.

make: *** [extra_build] Error 255

I looked at that patch of inline.pm, but nothing obvious jumped out at me, and I'm reluctant to tinker with it on my own. Other details that may be useful:

Any thoughts or suggestions are appreciated. Thanks.

See this report: 2.45 Compilation error

I don't know if this is the same problem you're seeing, but it looks similar. The issue is unresolved AFAICT, but I haven't had a chance to try 2.49 yet.

The only workaround I've found is to completely remove any previous ikiwiki installation that might be present on the system. --Buo

Thanks, Buo. I removed the traces of the previous ikiwiki, and I was able to install. No luck getting the new search plugin to work, but we'll leave that for another day. Thanks again.

Quick follow-up: 2.50 compiled and installed without a hitch. Just thought I would mention it...

closing as a duplicate of 2.45 Compilation error

Posted Sun Jun 15 15:34:50 2008
Spaces in link text for ikiwiki links

Versions 2.0 and 2.1 of ikiwiki, and I think earlier versions as well, allowed wiki links to have spaces in the link text. For example, [[ikiwiki logo page|logo]] should create an anchor tag referencing the logo page, and [[ikiwiki logo|logo/ikiwiki.png]] should create an image tag referencing the logo.

As of version 2.2, this no longer works. I think the pattern [[...|...]] should allow spaces before the pipe. I suspect this is the same problem as reported in discussion.

The above examples are ambiguous, only worked due to a bug, and were never documented to work. So I'm not inclined to re-add support for them.

If you look at WikiLink, it is clear that spaces cannot be used in WikiLinks. It also shows how to use underscores in the link text if you want multiple words.

This was a decision I made a long time ago due to the ambiguity between a WikiLink and a PreProcessorDirective. Is "[[foo bar|baz]]" a wikilink to baz with a link text of "foo bar", or an instance of preprocessor directive "foo" with a parameter of "bar|baz"? If it's interpreted as a wikilink today, that could change tomorrow if a new preprocessor directive is added.

Before version 2.2, ikiwiki actually first treated it as a preprocessor directive. If that failed, it output the preprocessor directive back onto the page, and next the wikilink code tried treating it as a wikilink. In 2.2, I fixed several problems with the way an unhandled preprocessor directive was re-output onto the page, by prefixing it with a '\' ... which makes it not be treated as a WikiLink.

If WikiLinks had ever been documented to work with spaces in them, then I'd feel I needed to support the pre 2.2 behavior, but I don't feel that I have to support old behavior that was never documented and happened due to a bug, so I current have no plans to bring the old behavior back. --Joey

I agree that the grammar should be unambiguous. It seems to me that the problem with spaces-in-wikilinks is caused by overloading the wikilink and preprocessor syntax to use the same symbols. If they didn't (and is there much advantage in them using the same symbols? I know in some cases you have something which is a wikilink and a preprocessor directive, but how often?) there'd be no problem with spaces.

If there was ever a future, syntax-breaking major release of ikiwiki (similar to python3000) I'd like to see this fixed as part of that. --JonDowland

You can enable prefix_directives and get the disambiguated behavior and spaces in wikilinks today. It will become the default in 3.0. --Joey

done

Posted Fri Jun 13 12:26:55 2008
taint and -T

By default, tflag is not defined. But ikiwiki.in has -T causing build failure:

perl -Iblib/lib ikiwiki.out -libdir . -setup docwiki.setup -refresh "-T" is on the #! line, it must also be used on the command line at ikiwiki.out line 1.

pm_filter removes the -T from ikiwiki.in when generating ikiwiki.out unless NOTAINT=0 is set. I cannot reproduce your problem. --Joey

Thanks. Now I see. NetBSD and DragonFly and several other systems don't have /usr/bin/perl so that path is replaced in the sh-bang lines of various scripts. So it doesn't match in the pm_filter expression. Can you please consider providing a variable or not matching on that assumed path to perl.

--- pm_filter.orig      2008-04-28 07:59:58 -0700
+++ pm_filter   2008-04-28 08:01:21 -0700
@@ -20,6 +20,6 @@
                $_="use lib '$libdir';\n";
        }
 }
-elsif ($. == 1 && ($ENV{NOTAINT} || ! exists $ENV{NOTAINT}) && m{^(#!/usr/bin/perl) -T$}) {
+elsif ($. == 1 && ($ENV{NOTAINT} || ! exists $ENV{NOTAINT}) && m{^(#!.*) -T$}) {
        $_=qq{$1\n};
 }

--JeremyReed

I could look for "#!.perl -T", if that would work. #!.-T is perhaps over-broad. --Joey

Yes, being more precise should be fine. Note that some may have bin/perl5 or bin/perl5.8.8 for example, so please consider optional number, like ^(#!/./perl[0-9].*) -T$ or something like that.

done

Posted Tue Jun 10 13:45:55 2008
raw html in-page and [[!included]]

I'm trying to add a flickr stream thing to my (static) ikiwiki. I've disabled htmlscrubber and enabled rawhtml, and I get many strange errors.

putting the html right into the markdown index.mdwn

This should work, but html code (listing 1) shows up with a hash replaced for the actual content (listing 2)

I have to suspect that replacing html with some hash is a bug.

Congrats, you're another person to fall afoul of markdown bug #380212. The fix is to use Text::Markdown, or markdown 1.0.2 instead of buggy old markdown 1.0.1. --Joey

inlining raw html

This would be my prefered solution. in index.mdwn:

[[!inline pages="flickr.html" rss="no"]]

but this refuses to show any content. Trying to RTFM and adding raw="yes" results in this error:

uppdaterar wiki..
söker av index.mdwn
ritar upp index.mdwn
private//ikiwiki.setup: Can't call method "param" on an undefined value at /usr/share/perl5/IkiWiki/Plugin/inline.pm line 253.
BEGIN failed--compilation aborted at (eval 10) line 63.

current workaround: iframe

I'm no html guru so I put the stuff in an iframe, but that doesn't work, since the links are script-generated and need a target="" attribute in them to load in the right place (replacing ikiwiki page).

Ikiwiki version: 2.44

plugin configuration:

disable_plugins => [qw{htmlscrubber}],
add_plugins => [qw{img map rawhtml toggle template prettydate haiku meta}],

best regards
ulrik

listing 1

<!-- Start of Flickr Badge -->
<style type="text/css">
#flickr_badge_source_txt {padding:0; font: 11px Arial, Helvetica, Sans serif; color:#666666;}
#flickr_badge_icon {display:block !important; margin:0 !important; border: 1px solid rgb(0, 0, 0) !important;}
#flickr_icon_td {padding:0 5px 0 0 !important;}
.flickr_badge_image {text-align:center !important;}
.flickr_badge_image img {border: 1px solid black !important;}
#flickr_www {display:none; text-align:left; padding:0 10px 0 10px !important; font: 11px Arial, Helvetica, Sans serif !important; color:#3993ff !important;}
#flickr_badge_uber_wrapper a:hover,
#flickr_badge_uber_wrapper a:link,
#flickr_badge_uber_wrapper a:active,
#flickr_badge_uber_wrapper a:visited {text-decoration:none !important; background:inherit !important;color:#6600CC;}
#flickr_badge_wrapper {}
#flickr_badge_source {padding:0 !important; font: 11px Arial, Helvetica, Sans serif !important; color:#666666 !important;}
</style>
<table id="flickr_badge_uber_wrapper" cellpadding="0" cellspacing="10" border="0">
<tr>
<td><a href="http://www.flickr.com" id="flickr_www">www.<strong style="color:#3993ff">flick<span style="color:#ff1c92">r</span></strong>.com</a><table cellpadding="0" cellspacing="2" border="0" id="flickr_badge_wrapper">
<tr>
<script type="text/javascript" src="http://www.flickr.com/badge_code_v2.gne?show_name=1&count=5&display=latest&size=s&layout=h&source=user&user=23579158%40N05"></script>
<td id="flickr_badge_source" valign="center" align="center">
<table cellpadding="0" cellspacing="0" border="0"><tr>
<td width="10" id="flickr_icon_td"><a href="http://www.flickr.com/photos/23579158@N05/"><img id="flickr_badge_icon" alt="englabenny's items" src="http://farm3.static.flickr.com/2338/buddyicons/23579158@N05.jpg?1211285412#23579158@N05" align="left" width="48" height="48"></a></td>
<td id="flickr_badge_source_txt"><nobr>Go to</nobr> <a href="http://www.flickr.com/photos/23579158@N05/">englabenny's photostream</a></td>
</tr></table>
</td>
</tr>
</table>
</td></tr></table>
<!-- End of Flickr Badge -->

listing 2

<!-- Start of Flickr Badge -->
<style type="text/css">
#flickr_badge_source_txt {padding:0; font: 11px Arial, Helvetica, Sans serif; color:#666666;}
#flickr_badge_icon {display:block !important; margin:0 !important; border: 1px solid rgb(0, 0, 0) !important;}
#flickr_icon_td {padding:0 5px 0 0 !important;}
.flickr_badge_image {text-align:center !important;}
.flickr_badge_image img {border: 1px solid black !important;}
#flickr_www {display:none; text-align:left; padding:0 10px 0 10px !important; font: 11px Arial, Helvetica, Sans serif !important; color:#3993ff !important;}
#flickr_badge_uber_wrapper a:hover,
#flickr_badge_uber_wrapper a:link,
#flickr_badge_uber_wrapper a:active,
#flickr_badge_uber_wrapper a:visited {text-decoration:none !important; background:inherit !important;color:#6600CC;}
#flickr_badge_wrapper {}
#flickr_badge_source {padding:0 !important; font: 11px Arial, Helvetica, Sans serif !important; color:#666666 !important;}
</style>


7383eb73071488c9ef46d617acf3e402


</td></tr></table>
<!-- End of Flickr Badge -->
Posted Tue Jun 10 13:45:55 2008 Tags: done
<br> tags are removed from markdown inline HTML

I am trying to add a post address to a document:

First line
Second line

As you can see, the <br/> is being removed. I disabled htmlscrubber, but that was not it. The markdown Dingus on its homepage processes the inline HTML just fine.

I tried searching the web and wiki but could not find any information on why
would be removed.

It does work if you use <br />:

First line
Second line

Or, as we've just been told in #ikiwiki: put two spaces at the end of the first line.

First line
Second line

--tschwinge

<br/> is also valid, so this is a bug still. --madduck

It is the htmlscrubber that removes that. It's due to bug #365971, basically the [[cspan HTML::Scrubber]] doesn't understand xhtml tags of this sort at all, I hacked it to support <br /> by tellig it to treak the "/" as an attribute, but if there's no space, it doesn't see it as an attribute. Hmm, I could also add br as a tag name, that would catch both cases. Ok, done --Joey

Posted Tue Jun 10 13:45:55 2008
recentchangesdiff crashes on commits which remove a lot of files

recentchangesdiff causes rendering to segfault if a commit removes a lot of contents. I removed close to 400 files, total size of about 950Kb in a single commit and now ikiwiki segfaults on refresh and rebuild:

[...]
rendering recentchanges.mdwn
[1]    5541 segmentation fault  ikiwiki --verbose --setup ikiwiki.setup --refresh

If I disable the plugin, the segfault does not happen, but I have to remove wc/recentchanges/* or else it will crash just as well.

This is reproducible, but I cannot provide the source code.

Can you provide a sanitised version of the source code? I've tried ikiwiki on some files that are just large, and cannot reproduce any problems, so it must be something in the specific file. (A perl bug is also clearly involved here.) --Joey

The tarball is at http://scratch.madduck.net/tmprecentchanges-segfault.tgz - unpack it in /tmp and chdir() to /tmp/cdt.taF18912, then run

ikiwiki --setup ikiwiki.setup
# segfaults
git checkout HEAD^
ikiwiki --setup ikiwiki.setup
# segfaults
rm -rf wc/recentchanges
ikiwiki --setup ikiwiki.setup
# works

I can reproduce it fine with that, thanks, and it's really looking like a pure perl bug, that is triggered by markdown. Here's a simpler test case:

joey@kodama:/tmp>markdown < f
zsh: segmentation fault  markdown < f

Where f is a 6.3 mb file that I extracted from ikiwiki's rendering pipeline.

It seems to be crashing at markdown line 345, which is a big nasty s/// statement.

The good news: markdown version 1.0.2~b8-2 does not trigger this perl bug. I only see it with 1.0.1. (Bad news: Newer versions of markdown are slooooooow, especially on such large files.)

I'm calling this done since I've filed bug #470676 on perl, and also have modified recentchangesdiff to only show the first 200 lines of diff, which should be enough without bloating the recentchanges into perl-crashing territory. --Joey

Posted Tue Jun 10 13:45:55 2008