This is ikiwiki's bug list. Link bugs to done when done.
Disappearing Pages
I have a problem where pages within the rendered wiki become empty. The headers, footers, and sidepanel are there, but the body is completely missing. If I do a webedit and change anything (adding whitespace is enough) and commiting the change updates the page and the body appears. If I then do a rebuild of the wiki from the command line, I get the blank pages again. I have debug turned up but I don't see anything that makes me suspect anything. When I do a rebuild from the command line I get the following warning.
Use of uninitialized value in substitution (s///) at /usr/share/perl5/IkiWiki/Plugin/inline.pm line 234.
The odd thing is that I have 5 other wikis on this same system and none of them seem to be experiencing the same problems. The only difference seems to be the use of sidebars and google calendar in the affected wiki.
Posted Sat Feb 10 15:27:08 2007Could you post a tarball of the wiki and any setup file you use somewhere so I can try to reproduce your problem? --Joey
The Wiki I think it has something to do with the plugin selection. --?ScottHenson
Ok, I built your wiki, and got no contentless pages here. I also didn't see the uninitialized value warning, which could be connected. However, I that uninitialized value come from an inline directive, and the wiki source doesn't seem to use inlining at all, so I'm confused about that. --Joey
Sorry, thats my fault. The wiki that was having the problem had some information that I couldn't distribute. So I reproduced the bug on another wiki and sent you that. Those warnings don't seem to have any effect on the disappearing content. Sorry for the confusion. --?ScottHenson
That's ok, but since I couldn't reproduce it with the data you sent, I can't really fix it. --Joey
Has bugs updating things if the bestlink of a page changes due to adding/removing a page. For example, if Foo/Bar links to "Baz", which is Foo/Baz, and Foo/Bar/Baz gets added, it will update the links in Foo/Bar to point to it, but will forget to update the linkbacks in Foo/Baz.
And if Foo/Bar/Baz is then removed, it forgets to update Foo/Bar to link back to Foo/Baz.
As of 1.33, this is still true. The buggy code is the %linkchanged calculation in refresh(), which doesn't detect that the link has changed in this case.
Posted Sat Feb 10 15:27:08 2007If a page inlines some other page (such as this page by the bugs page), and the page is removed (such as by this page being linked to bugs/done), the inlining page is not updated to remove it.
This only happens if the page is removed from the inlined pagespec due to a tag changing; the problem is that once the tag is changed, ikiwiki does not know that the page used to match before.
Another example would be a pagespec that allowed only matching new pages:
newer(1 day)
Obviously, the pages that matches are going to change, and again once they do, ikiwiki will no longer know that they matched before, so it won't know to remove them from a page that used that to inline them.
To fix, seems I would need to record the actual list of pages that are currently included on an inline page, and do a comparison to see if any have changed.
At first I thought, why not just add them to the dependencies explicitly, but that failed because the dependencies GlobList failed to match when a negated expression like "!tag(bugs/done)" is matched. It is, however, doable with PageSpecs:
(real deps here) or (list of all currently inlined pages here)
However, it's not really clear to me how to remove inlined pages from the deps when they stop being inlined for whatever reason. So a separate list would be better.
So this is blocked by plugin data storage I suppose.
Posted Sat Feb 10 15:27:08 2007If you're using ikiwiki without installing it, the svn post-commit wrapper will die (in a difficult-to-debug way) when it tries to execute ikiwiki.pl because it can't find IkiWiki.pm.
I'm not sure how to fix this in a secure way. For now I'm just changing use lib '.' in ikiwiki.pl to point to the hard-coded directory where ikiwiki was unpacked.
Posted Sat Feb 10 15:27:08 2007This workaround doesn't work here. "
./ikiwiki.pl --setup ikiwiki.setup
" is ok, but the wrappers fail in action. Using "FindBin
" seems a solution. Here is a (kinda ugly) patch which also allows you to usebasewiki
+templates
in the source directory. The patched version works fine in my homepage. --?Roktas
I'm using the tags plugin with tagbase="tags".
Already existing tags, corresponding to pages like tags/foo.html work just fine.
If I add to a page a tag which is not existing (e.g. with ) the just modified page will have a link which point to tags/newtag. This is in theory correct, but in practice leads to creating a tags/newtag subpage of the page I'm editing, while my tagbase is supposed to be relative to the wiki root.
When used in a wiki which already have some tags this leads to mixing up tags located in tags/ and tags located in whatever/tags/.
Posted Sat Feb 10 15:27:08 2007When a new page is being edited, ikiwiki lets you chose where the page will be created, so you'll get a dropdown list of possible locations for the tag page. You should be able to choose between either tags/foo or page/tags/foo.
The way that ikiwiki decides which location to default to in this box is fairly involved; but in general it will default to creating the page at the same level as the tagged page. So if the tag is on any toplevel page in the wiki, it will default to creating
tags/foo
; if the tag is on a page in a subdirectory, it will default to creating subdir/tags/foo.I personally like this behavior; it allows me to create a subdirectory for a particular thing and use tags that are specific to that thing, which are kept confined to that subdirectory by default. For example, this is used for ikiwiki's own plugins tags, which are all located under plugins/type/* and which apply to pages under plugins/*.
It's clearly not the right default for every situation though. Explcitly setting a tagbase probably lessons the likelyhood that it's the right default for things under that tag base. I'd not be opposed to adding a special case to change the default in this case, or adding a configuration option to change the default globally. On the other hand, it is pretty simple to just check the location and select the right one from the list when creating a new page..
--Joey
Web browsers don't word-wrap lines in submitted text, which makes editing a
page that someone wrote in a web browser annoying (gqip
is vim user's
friend here). Is there any way to improve this?
ikiwiki will generate html formatted error messages to the command line if --cgi is set, even if it's not yet running as a cgi
Posted Sat Feb 10 15:27:08 2007RSS output contains relative links. Ie. http://kitenet.net/~joey/blog/index.rss contains a link to http://kitenet.net/~joey/blog/../blog.html
Posted Sat Feb 10 15:27:08 2007ikiwiki compiles my wiki successfully. But the svn post-commit hook it installs doesn't work at all. Instead of rendering the files, it deletes their rendered versions. The reason is that the src directory, /home/.kelli/glasserc/wikiwc, matches the prune regexp, so no files in the wiki get added to @files.
I think the prune regexp would be more useful if it was only used to check the relative path from the src root to a file in the wiki.
Posted Sat Feb 10 15:27:08 2007I agree with this feature wish. Here is a first cut implementation for this feature.
--?roktas
After 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
Posted Sat Feb 10 15:27:08 2007I'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.
Posted Sat Feb 10 15:27:08 2007XMLin 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
The diff links in RecentChanges go to a viewcvs backtrace if the rev in question is when the page was added. Is this a viewcvs bug, or a behavior ikiwiki needs to work around? - As a special case, there should certianly be no history link for pages generated from the underlaydir as it can never work for them.
Posted Sat Feb 10 15:27:08 2007The header of subpages always links to its "superpage", even if it doesn't exist. I'm not sure if this is a feature or a bug, but I would certainly prefer that superpages weren't mandatory.
For example, if you are in 'example/page.html', the header will be something like 'wiki / example / page'. Now, if 'example.html' doesn't exist, you'll have a dead link for every subpage.
This is a bug, but fixing it is very tricky. Consider what would happen if example.mdwn were created: example/page.html and the rest of example/* would need to be updated to change the parentlink from a bare work to a link to the new page. Now if example.mdwn were removed again, they'd need to be updated again. So example/* depends on example. But it's even more tricky, because if example.mdwn is modified, we don't want to rebuild example/*!
ikiwiki doesn't have a way to represent this dependency and can't get one without a lot of new complex code being added.
For now the best thing to do is to make sure that you always create example if you create example/foo. Which is probably a good idea anyway..
Posted Sat Feb 10 15:27:08 2007If a file in the srcdir is removed, exposing a file in the underlaydir, ikiwiki will not notice the change and rebuild it until the file in the underlaydir gets a mtime newer than the mtime the removed file had.
Posted Sat Feb 10 15:27:08 2007