recently fixed bugs
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 invokingerror()
subroutine like you showed me before and now Ikiwiki printsfailed 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 byparam("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? --JoeyDo 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ł
Posted Thu Jul 10 05:45:51 2008I'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ł
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
Posted Wed Jul 9 15:02:25 2008It 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
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 2008We 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.
Posted Wed Jul 9 08:28:17 2008You 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 Tue Jul 8 23:05:54 2008Joey, 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
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:
- perl is 5.10.0 (built myself on the account, rather than the system perl)
- The host system is Debian Etch
- Kernel is a custom 2.6.16-xen kernel
- Gcc 4.1.2
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...
Posted Tue Jul 8 05:52:28 2008closing as a duplicate of 2.45 Compilation error
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
Posted Tue Jul 8 05:52:28 2008bleh. Fixed --joey
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
Posted Tue Jul 8 05:52:28 2008Done (and fixed your url) --Joey
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 2008I'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ł
Posted Tue Jul 8 05:52:28 2008I 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ł