ikiwiki/ bugs/ done

recently fixed bugs

attachment: failed to get filehandle

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? diff --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 diff? 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! :D Thanks a lot, Joey! You're really great! :) --Paweł

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

Posted Thu Jul 10 05:45:51 2008
git fails to compile

Background: I'm running ikiwiki on OS X leopard, (a laptop), and I have the wiki running locally, as it's mostly for note taking and personal stuff. Anyway.

I'd been using svn, but I'm making the leap to git (finally) and moving the wiki over as well...

The git works great, I am in fact, quite pleased. Here's the problem. When I try and run ikiwiki --setup [setupfile] I get the following message:

Can't exec "git": No such file or directory at /opt/local/lib/perl5/vendor_perl/5.8.8/IkiWiki/Rcs/git.pm line 29.
/Users/tychoish/.ikiwiki/ikiwiki.setup: Cannot exec 'git log --max-count=50 --pretty=raw --raw --abbrev=40 --always -c -r HEAD -- .': No such file or directory
BEGIN failed--compilation aborted at (eval 6) line 139.

/Users/$HOME/.ikiwiki/ikiwiki.setup: 'git log --max-count=50 --pretty=raw --raw --abbrev=40 --always -c -r HEAD -- .' failed: 
BEGIN failed--compilation aborted at (eval 6) line 139.

I can get the wiki to compile if: I take the git stuff out of the setup file, if I put rcs => "" or if I set the the git_master_branch to "".

I think the problem is that ikiwiki can't deal with the onslaught of such a large quantity of history/log information at once, somehow, because the repository came to this moment with a lot of history that the compiler has to crunch through. How to remedy this, is beyond my skill insight...

Thanks.

-- tychoish

It looks like it can't find git; what is $PATH set to when ikiwiki is run, and is git in one of those directories? --bma

Yeah, ikiwiki and git are both installed underneath macports, which is in the path and works just fine most of the time, and I use macports stuff a lot.

The PATH is set at the top of the ikiwiki program; so the system's PATH setting, or one in the environment will be ignored. (This is done for security since ikiwiki can be run setuid.) If you need to use a nonstandard path, you'll need to edit that. --Joey

Posted Wed Jul 9 15:02:25 2008 Tags: done
attachment plugin enabled by default?

At attachment plugin page I can see that it's enabled by default in Ikiwiki. Is it true?

No, typo (done). I don't want to enable it by default because it requires site-specific configuration to be made secure. --Joey

Thanks for your reply! I was guessing it :) --Paweł

I have backported Ikiwiki 2.52 and I need to add that plugin to add_plugins variable in my ikiwiki.setup file (and rebuild my wiki, of course) to see new upload buttons when I edit a page and click "Attachments" link.

FWIW, you don't need to rebuild the whole wiki, --refresh --wrappers is enough.

It's good to know. Thank you for the hint!

Maybe should I enable attachment handling in different way? --Paweł

Posted Wed Jul 9 15:01:58 2008
Links with symbols can't be edited

We just installed 2.52 on debian testing, and all edit links with symbols (including spaces) are coming up with empty text fields because the URL to the mdwn file is wrong.

For example, the existing page:

wiki/bugs/__39__Existing_Subject__39___vs.___39__Browse__39__/

displays the bug "'Existing Subject' vs. 'Browse'". But if we click 'Edit' on that page, we get:

wiki/ikiwiki.cgi?page=bugs%2F'Existing%20Subject'%20vs.%20'Browse'&do=edit

.. which of course opens with a blank edit box. Note that manually typing in the correct URL:

wiki/ikiwiki.cgi?page=bugs%2F__39__Existing_Subject__39___vs.___39__Browse__39__&do=edit

does work.

You need to rebuild your wiki on upgrade to 2.52. The old edit links looked like the first link above, and ikiwiki has changed so that it needs the new link above. To get those links on static pages, you need to rebuild the wiki, like the news says to.

closing as user error --Joey

Posted Wed Jul 9 08:28:17 2008
colon:problem

Joey, please fix the colon in page name of my report. Ikiwiki sets "attachment:_failed_to_get_filehandle/" URL on "Bugs" page and the report is not clickable in my Epiphany browser:

Firefox doesn't know how to open this address, because the protocol
(attachment) isn't associated with any program.

I can only edit it :) Bad handling ':' character by Ikiwiki is probably its another bug. --Paweł

fixed in git (but fix is not live on here as of this writing) --Joey

Posted Tue Jul 8 23:05:54 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 Tue Jul 8 05:52:28 2008
CGI edit and slash in page title

Try clicking the Edit link for http://ikiwiki.info/todo/Add_showdown_GUI_input__47__edit/

The link produces a query string that the edit CGI interprets to mean edit.mdwn in an Add showdown GUI input subpage.

There's something there now, but only because I created it. When I first tried it, it came up blank. I tried several different ways of altering the escaping of the query string to get the real page to come up, but I never succeeded, so I just grabbed the original text from git and pasted it into the new page....

So somehow the generation of Edit links and the CGI for doing the editing need to get in agreement on just how they're going to escape slashes in a page title.

--Chapman Flack

bleh. Fixed --joey

Posted Tue Jul 8 05:52:28 2008
search creates configuration files many times on rebuild

Currently, if ikiwiki is rebuilding then search.pm will (wastefully) create its configuration files every time it indexes a file.

This patch ensures the configuration files are created only once.

--Gabriel

Done (and fixed your url) --Joey

Posted Tue Jul 8 05:52:28 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 Tue Jul 8 05:52:28 2008
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 Tue Jul 8 05:52:28 2008