recently fixed bugs
svn log messages containing utf-8 (such as r773) don't get displayed right in RecentChanges. The problem is ikiwiki runs svn log in locale C, which makes it spit out eacaped charcters for utf-8 chars. If it's run in locale en_US.UTF-8, it would be ok, but that would require the system have that locale.
Seems that the right fix for this is to use svn log --xml, which is always utf-8 and come up with a parser for that. Also fixes the spoofing issue in security.
done
Posted Sat Feb 10 15:27:08 2007If 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 Feb 10 15:27:08 2007The 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
HTML::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 Sat Feb 10 15:27:08 2007If 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 Sat Feb 10 15:27:08 2007If 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 Sat Feb 10 15:27:08 2007I 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 Sat Feb 10 15:27:08 2007Thanks for clarifying that. done --Joey
If 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 Sat Feb 10 15:27:08 2007The 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 Sat Feb 10 15:27:08 2007If 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 Feb 10 15:27:08 2007It now compiles here, thanks. --JamesWestby