recently fixed bugs
I'd like to run ikiwiki under cygwin. I'm new to ikiwiki and have tried to follow the setup tutorial as best I could. I got all the way up to step 7, but I can't get the CGI to run successfully (step 8).
Moved the formbuilder bug to formbuilder 3.0401 broken --Joey
A different problem has reared its ugly head. When I click on "RecentChanges", the CGI complains about an undefined subroutine:
==> apache2/error_log <== [Thu Oct 12 16:20:52 2006] [error] [client 192.168.0.125] Undefined subroutine &IkiWiki::XMLin called at /usr/lib/perl5/site_perl/5.8/IkiWiki/Rcs/svn.pm line 143., referer: http://imrisws36/wiki/index.html?updated [Thu Oct 12 16:20:52 2006] [error] [client 192.168.0.125] Premature end of script headers: ikiwiki.cgi, referer: http://imrisws36/wiki/index.html?updated
Indeed there is no such routine IkiWiki::XMLin(). I don't understand how this can possibly work -- as it manifestly does on linux.
XMLin is supposed to be exported by XML::Simple. My guess is that, due to a missing error check, XML::Simple is failing to load, and it's not aborting then. You probably need to install that module; in the meantime, I've fixed the missing error check in svn. --Joey
done
Posted Sat Dec 2 00:17:08 2006After editing ikiwiki.setup, and running "ikiwiki --setup", the CGI script is successfully created. However, if I then click on "Edit Page" link, I see nothing in the browser and the following in the logs:
==> /var/log/apache2/access_log <== 192.168.0.125 - - [06/Oct/2006:15:12:05 -0500] "GET /cgi-bin/ikiwiki.cgi?page=index&do=edit HTTP/1.1" 500 666 ==> /var/log/apache2/error_log <== [Fri Oct 06 15:12:07 2006] [error] [client 192.168.0.125] HTML::Template::param() : attempt to set parameter 'form-submit' with an array ref - parameter is not a TMPL_LOOP! at /usr/lib/perl5/site_perl/5.8/CGI/FormBuilder.pm line 1415, referer: http://imrisws36/wiki/ [Fri Oct 06 15:12:07 2006] [error] [client 192.168.0.125] Premature end of script headers: ikiwiki.cgi, referer: http://imrisws36/wiki/
Can anyone decipher this for me? I spent some time with cpan earlier today downloading the latest version I could find of prerequisite modules such as HTML::Template and CGI::FormBuilder.
It would help to know what version of CGI::FormBuilder you have. Mine (3.03.01) does not seem to contain this error message. --Joey
I have version 3.0401 of CGI::FormBuilder -- the latest from CPAN. If you are wondering about any other modules, the answer is likely the same: the latest from CPAN. And you're right: the error string in question does not appear in CGI::FormBuilder. I found it in HTML::Template (version 2.8).
OK, so downgrading CGI::FormBuilder to 3.0302 makes the problem go away. I'll leave it to you to figure out whether the bug is in CGI::FormBuilder or in IkiWiki. --Steve
Maybee this bug should be renamed as "doesn't work with CGI::FormBuilder (3.04)." I get same error on FreeBSD.
HTML::Template::param() : attempt to set parameter 'form-submit' with an array
ref - parameter is not a TMPL_LOOP!
at /usr/local/lib/perl5/site_perl/5.8.7/CGI/FormBuilder.pm line 1415
version info:
root@freedom# pkg_info | grep p5-CGI
p5-CGI-FastTemplate-1.09 Perl module for manage templates and parses templates
p5-CGI-FormBuilder-3.0401 FormBuilder for CGI
p5-CGI-Session-4.14 Perl extension for persistent session management
--Mark
For the curious, this new version of CGI::FormBuilder changes how it passes some values to the HTML::Template template. In particular, FORM-SUBMIT used to be just a string containing the buttons used to submit the form. With the new version, it's an array of strings, one per button, and the template needs to be written differently to deal with this. Oddly, the docs have not been updated about this. In fact, from all I can tell, it's a bug, since the array is not in the form that HTML::Template expects to receive it. Here's a simple test case:
#!/usr/bin/perl
my @fields=qw(editcontent);
my @buttons=("Save", "Preview", "Cancel");
use CGI::FormBuilder;
my $form = CGI::FormBuilder->new(
fields => \@fields,
template => "foo.tmpl",
);
print $form->render(submit => \@buttons);
With this test case, it does not seem to be possible to write a foo.tmpl that outputs the buttons using the FORM-SUBMIT template variable.
I was able to work around this bug by just not using FORM-SUBMIT in the template, and hardcoding the buttons (since they never change anyway). Nasty, but it should work. I haven't fully installed the new version of CGI::FormBuilder to test it, and it's quite possible that other changes in the new version cause other breakage. If you want to test the fix, it's in svn now. --Joey
Now that the new version of formbuilder is in debian unstable, I'm using ikiwiki with it, and, after fixing a bug or two more, I think it's all working, so I'll call this bug done. --Joey
Posted Sat Dec 2 00:16:41 2006If a page stops inlining anthing, its rss feed file will linger around and not be deleted.
(The linkmap plugin has the same problem with the png files it creates.)
done
Posted Sun Oct 8 21:21:58 2006If the Markdown module is installed via CPAN rather than apt then the module is actually Text::Markdown.
I had to edit the source to change this on my old server. I have filed a bug against the Debian markdown, which I guess you can consider a blocking bug of this.
I tried to come up with the magical invocation to allow either location to be used by ikiwiki, but I couldn't do it.
-- ?JamesWestby
Fixed, I think --Joey
Fraid not. The import works ok, but I get
Undefined subroutine &Markdown::Markdown called at IkiWiki/Plugin/mdwn.pm line 41.
This is what stumped me, I was trying to import as an alias, but couldn't work out how to do it. A flag if you use the second import would be an ugly solution. -- ?JamesWestby
Ok, the markdown in CPAN must be an entirely different version then if it doesn't has a Markdown::Markdown. Interesting, I'll have a look at it. --Joey
It works if you use Text::Markdown::Markdown, sorry, I forgot to mention that. --JamesWestby
I think what I've committed now will work in all cases. Well, unless there are even more forks of markdown out there (the CPAN module is a fork apparently...)
done --Joey
Posted Sat Sep 16 02:40:34 2006It now compiles here, thanks. --JamesWestby
If you
- Add a link to a non-existant page and save. (e.g. ?somewhere-over-the-rainbow)
- Click the question mark to create the page.
- Click the cancel button.
You get a 404 as the page doesn't exist. This patch redirects to the from location if it is known.
=== modified file 'IkiWiki/CGI.pm'
--- IkiWiki/CGI.pm
+++ IkiWiki/CGI.pm
@@ -427,7 +427,11 @@
}
if ($form->submitted eq "Cancel") {
- redirect($q, "$config{url}/".htmlpage($page));
+ if ( $newpage && defined $from ) {
+ redirect($q, "$config{url}/".htmlpage($from));
+ } else {
+ redirect($q, "$config{url}/".htmlpage($page));
+ }
return;
}
elsif ($form->submitted eq "Preview") {
I think you mean to use
$newfile
? I've applied a modieid version that also deal with creating a new page with no defined $from location. done --JoeyYes of course, that's what I get for submitting an untested patch! I must stop doing that.
[P.S. just above that is
$type=$form->param('type');
if (defined $type && length $type && $hooks{htmlize}{$type}) {
$type=possibly_foolish_untaint($type);
}
....
$file=$page.".".$type;
I'm a little worried by the possibly_foolish_untaint
(good name for it by the way,
makes it stick out). I don't think much can be done to exploit this (if anything),
but it seems like you could have a very strict regex there rather than the untaint,
is there aren't going to be many possible extensions. Something like /(.\w+)+/
(groups of dot separated alpha-num chars if my perl-foo isn't failing me). You could
at least exclude /
and ..
. I'm happy to turn this in to a patch if you agree.]
Posted Sat Sep 16 01:46:17 2006The reason it's safe to use
possibly_foolish_untaint
here is because of the check for $hooks{htmlize}{$type}. This limits it to types that have a registered htmlize hook (mdwn, etc), and not whatever random garbage an attacker might try to put in. If it wasn't for that check, usingpossibly_foolish_untaint
there would be very foolish indeed.. --JoeyNice, sorry I missed it. I must say thankyou for creating ikiwiki. The more I look at it, the more I admire what you are doing with it and how you are going about it
I built ikiwiki using
% perl Makefile.PL PREFIX=/home/ed % make % make install
This installs the files under /home/ed, for example one of the lines it prints is
cp -a basewiki/* /home/ed/share/ikiwiki/basewiki
However when I try to run ikiwiki I get an error as follows:
% ikiwiki --verbose ~/wikiwc/ ~/publichtml/wiki/ --url=http://membled.com/wiki/ Can't stat /usr/share/ikiwiki/basewiki: No such file or directory at /home/ed/lib/perl5/siteperl/5.8.7/IkiWiki/Render.pm line 349
The PREFIX specified at build time should also affect the share directory - it shouldn't try to use /usr/share here.
Actually, the PREFIX, no matter where you specify it, is only intended to control where files are installed, not where they're looked for at runtime.
There's a good reason not to make PREFIX be used to actually change the program's behavior: Most packaging systems use PREFIX when building the package, to make it install into a temporary directory which gets packaged up.
This is not the case. That is the difference between PREFIX and DESTDIR.
DESTDIR does what you describe; it causes the files to be installed into some directory you specify, which may not be the same place you'd eventually run it from.
PREFIX means build the software to run under the location given. Normally it will also affect the location files are copied to, so that 'make install' installs a working system.
At least, that's the way I've always understood it; the MakeMaker documentation isn't entirely clear (perhaps because ordinary Perl modules do not need to be configured at build time depending on the installation directory). It does mention that DESTDIR is the thing used by packaging tools.
Posted Mon Sep 4 03:38:35 2006Thanks for clarifying that. done --Joey
If I try to do a web commit, to a svn+ssh repo, it fails with "Host key verification failed." I think that the setuid isn't fully taking; it should be running as me, but commit log shows www-data. So maybe it has the wrong username? Or EUID/Real UID screwage. done
Posted Mon Sep 4 03:28:32 2006The meta plugin doesn't affect a page if it's being inlined. Probably setting the title with it should override the title of the blog post.
done
Posted Sun Jul 30 23:22:08 2006HTML::Template does not read files as utf-8, so modifying ikiwiki's template files to contain utf-8 won't currently work.
It seems that the best way to fix this would be to make HTML::Template support utf-8.
A workaround is to change all the template reading code like this:
- my $template=HTML::Template->new(blind_cache => 1,
- filename => "$config{templatedir}/page.tmpl");
+ open(TMPL, "<:utf8", "$config{templatedir}/page.tmpl");
+ my $template=HTML::Template->new(filehandle => *TMPL);
+ close(TMPL);
However, this will make ikiwiki slower when rebuilding a wiki, since it won't cache templates.
Could be approached by using HTML::Template's support for filters. Just make it use a filter that turns on utf-8
Or by subclassing it and overriding the _init_template method, though that's a bit uglier
done
Posted Sun Jul 2 19:05:54 2006If you are editing a page using your www browser and hit the "Preview" button, the link to "HelpOnFormatting" on the bottom of the page disappears. This may be expected, or not.
done
Posted Sun Jul 2 17:43:54 2006