ikiwiki/ bugs

This is ikiwiki's bug list. Link bugs to done when done.

Disappearing Pages

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.

Could 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

Can you not reproduce the warning or not reproduce the disappearing pages? The warning does not seem to have anything to do with the error of the disappearing pages. --?ScottHenson

I can't reproduce any disappearing text. --Joey

Posted Sat Nov 25 22:21:30 2006
bestlink change update issue

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 Wed Nov 8 21:03:13 2006
svn post-commit wrapper can't find IkiWiki.pm if not installed

If 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.

This 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 use basewiki + templates in the source directory. The patched version works fine in my homepage. --?Roktas

Posted Fri Oct 6 06:31:18 2006
pruning is too strict

ikiwiki 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.

I agree with this feature wish. Here is a first cut implementation for this feature.

--?roktas

Posted Sat Sep 30 21:31:42 2006
tags base dir not used when creating new tags

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/.

When 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

Posted Thu Sep 21 20:45:22 2006 Tags: ?newtag
broken parentlinks

The 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 Tue Aug 22 17:46:00 2006
inline page not updated on removal

If 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 Wed Aug 2 05:31:02 2006
html errors

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 Fri Jun 23 00:40:03 2006
underlaydir file expose

If 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 Fri Jun 23 00:39:41 2006
rss output relative links

RSS output contains relative links. Ie. http://kitenet.net/~joey/blog/index.rss contains a link to http://kitenet.net/~joey/blog/../blog.html

Posted Fri Jun 23 00:39:13 2006
diff links to backtrace

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 Fri Jun 23 00:38:13 2006
word wrap

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?

Posted Fri Jun 23 00:37:33 2006