If you've found a bug in ikiwiki, post about it here. TODO items go elsewhere. Link items to done when done.
Also see the Debian bugs.
The brokenlinks plugin falsely complains that formatting has a broken link to smileys, if the smiley plgin is disabled. While the page links to it inside a conditional, and so doesn't show the link in this case, ikiwiki scans for links w/o looking at conditionals and so still thinks the page contains the link.
Posted Sun Feb 10 23:46:47 2008Going from RecentChanges, when viewing the diffs of newly created pages (like http://tinyurl.com/35f5q3 for the Allow web edit form comment field to be mandatory page, then there should -- in my opinion -- the diff for the newly added page be shown.
Posted Sun Feb 10 23:46:47 2008I don't see any way to make gitweb do that. You can click on the filename after the "diff -cc" to see the whole file output, but gitweb won't show a diff for a newly added file. --Joey
After installing IkiWiki 2.16 on Mac OS X 10.4 server I attempted to use "/Library/Application\ Support/IkiWiki/Working\ Copies" as the parent of my $SRCPATH and get "skipping bad filename" errors for any .mdwn file in that directory:
skipping bad filename /Library/Application Support/IkiWiki/Working Copies/ikiwikinewt/index.mdwn
Tthe .ikiwiki directory is correctly created in that directory. I switched to using a path with no spaces and it works correctly.
Posted Sun Feb 10 23:46:47 2008The img plugin causes a taint failure if one tries to link a scaled image, e.g.
[[img foo.png size=64x64]]
.ikiwiki.setup: Insecure dependency in mkdir while running with -T switch at /usr/lib/perl5/vendor_perl/5.8.8/IkiWiki.pm line 360.
BEGIN failed--compilation aborted at (eval 5) line 109.
If one omits the size argument it works. And if it worked once the taint failure will not happen again unless one rm -r's the destdir.
Seen with ikiwiki 2.30
Posted Sun Feb 10 23:46:47 2008And what version of perl? See Insecure dependency in mkdir et al. Also, the debian build of ikiwiki has taint checking disabled to avoid this perl bug. Did you build your own? Set NOTAINT=1 when building.. --Joey
Please have a look at
http://www.bddebian.com/~wiki/hurd/running/debian/faq/.
There is (on a sufficiently small display) a large free spacing between the
vmstat line and the first Posted line.
Even without any local.css
.
This is because of clear: both
in ikiwiki's style.css
, line 109,
for .pagedate, .pagelicense, .pagecopyright
.
I can override this in local.css
, but what was the original reason for
adding this clear: both
?
Posted Sun Feb 10 23:46:47 2008Without investigating in detail, I think it was probably because any of the items can be enabled or disabled. So any of them might be the first item after the horizontal rule, and any might be the last item before the modification date. So all of them have to clear both above and below. I'm sure there are better ways for the CSS to handle that. --Joey
The Monotone module still lacks support for setting up a post-commit hook, so commits made via monotone will not automatically update the wiki.
Here for future reference is the most recent version of support for that I've been sent. It's not yet working; there are path issues. --Joey
diff --git a/IkiWiki/Rcs/monotone.pm b/IkiWiki/Rcs/monotone.pm index cde6029..34f8f96 100644 --- a/IkiWiki/Rcs/monotone.pm +++ b/IkiWiki/Rcs/monotone.pm @@ -186,8 +186,9 @@ sub rcs_update () { #{{{ check_config(); if (defined($config{mtnsync}) && $config{mtnsync}) { + check_mergerc(); if (system("mtn", "--root=$config{mtnrootdir}", "sync", - "--quiet", "--ticker=none", + "--quiet", "--ticker=none", "--rcfile", $config{mtnmergerc}, "--key", $config{mtnkey}) != 0) { debug("monotone sync failed before update"); } @@ -604,4 +605,9 @@ __DATA__ return true end } + function note_netsync_revision_received(new_id, revision, certs, session_id) + if (program_exists_in_path("ikiwiki-netsync-hook")) then + execute("ikiwiki-netsync-hook", new_id) + end + end EOF diff --git a/IkiWiki/Wrapper.pm b/IkiWiki/Wrapper.pm index 2103ea5..cff718c 100644 diff --git a/doc/ikiwiki.setup b/doc/ikiwiki.setup index 1377315..0cbe27e 100644 --- a/doc/ikiwiki.setup +++ b/doc/ikiwiki.setup @@ -88,6 +88,16 @@ use IkiWiki::Setup::Standard { # # Enable mail notifications of commits. # notify => 1, #}, + #{ + # # The monotone netsync revision received wrapper. + # # Note that you also need to install a lua + # # hook into monotone to make this work + # # see: http://ikiwiki.info/rcs/monotone/ + # wrapper => "/usr/local/bin/ikiwiki-netsync-hook", + # wrappermode => "04755", + # # Enable mail notifications of commits. + # notify => 1, + #}, ], # Generate rss feeds for blogs?Posted Sun Feb 10 23:46:47 2008
The Atom and RSS templates use ESCAPE=HTML
in the title elements. However, HTML-escaped characters aren't valid according to http://feedvalidator.org/.
Removing ESCAPE=HTML
works fine, but I haven't checked to see if there are any characters it won't work for.
For Atom, at least, I believe adding type="xhtml"
to the title element will work. I don't think there's an equivalent for RSS.
Posted Sun Feb 10 23:46:47 2008Removing the ESCAPE=HTML will not work, feed validator hates that just as much. It wants rss feeds to use a specific style of escaping that happens to work in some large percentage of all rss consumers. (Most of which are broken). http://www.rssboard.org/rss-profile#data-types-characterdata There's also no actual spec about how this should work.
This will be a total beast to fix. The current design is very clean in that all (well, nearly all) xml/html escaping is pushed back to the templates. This allows plugins to substitute fields in the templates without worrying about getting escaping right in the plugins -- and a plugin doesn't even know what kind of template is being filled out when it changes a field's value, so it can't do different types of escaping for different templates.
The only reasonable approach seems to be extending HTML::Template with an ESCAPE=RSS and using that. Unfortunately its design does not allow doing so without hacking its code in several places. I've contacted its author to see if he'd accept such a patch.
(A secondary bug is that using meta title currently results in unnecessry escaping of the title value before it reaches the template. This makes the escaping issues show up much more than they need to, since lots more characters are currently being double-escaped in the rss.)
--Joey
Update: Ok, I've fixed this for titles, as a special case, but the underlying problem remains for other fields in rss feeds (such as author), so I'm leaving this bug report open. --Joey
I have set
templatedir => "/srv/apache2/madduck.net/templates",
in ikiwiki.setup and put a custom page.tmpl
in there, then called ikiwiki --setup
and verified that it works. It even works when I push to the Git repo and let the receive-hook update the wiki.
However, when I make a change via the CGI (which has been created by the last setup run), it applies the default page.tmpl
file to all pages it updates.
Posted Sun Feb 10 23:46:47 2008This issue can arise in at least two ways:
- A permissions problem with the templatedir that prevents ikiwiki from accessing it. If it can't access it, it silently falls back to using templates from the default directory.
- A templatedir that doesn't have an absolute path. In this case ikiwiki will look relative to somewhere, which will sometimes work and sometimes not. Clearly not a good idea.
So far that's the only ways that I can see that this could happen. It would be possible to make ikiwiki try to detect these sorts of problems; it could check if the templatedir exists, and check that it's readable. This would add some extra system calls to every ikiwiki run, and I'm not convinced it's worth it. --Joey
In markdown syntax, none of the other special characters get processed
inside a code block. However, in ikiwiki, wiki links and
preprocessor directives still get processed
inside a code block, requiring additional escaping. For example, [links
don't work](#here)
, but a <a href="ikiwiki/wikilink.html">wikilink</a> becomes HTML
. --JoshTriplett
Indented lines provide a good way to escape a block of text containing markdown syntax, but ikiwiki links like this are still interpreted within such a block. I think that intepretation should not be happening. That is I should be able to write:
this
and have it render like:
this
--cworth
Posted Sun Feb 10 23:46:47 2008Has there been any progress or ideas on this bug recently? I use an expanded CamelCase regexp, and without much escaping in freelink text, or url links, or in codeblocks I get IkiWiki's attempt at creating a "link within a link".
I have no ideas other than perhaps once IkiWiki encounters [[ or the position is reset with a backreference from a CamelCased word, further processing of wikilinks is disabled until the position is reset and a "no not makelinks" flag or variable is cleared.
I've come up with some really ugly workarounds to handle case specific stuff like codeblocks but the problem creeps up again and again in unexpected places. I'd be happy to come up with a patch if anyone has a bright idea on a nice clean way (in theroy) to fix this. I'm out of ideas.
--CharlesMauch
I've moved the above comment here because it seems to be talking about this bug, not the similar Smileys bug.
In the case of either bug, no, I don't have an idea of a solution yet. --Joey
Following a diff link from RecentChanges, the log message shown will not be the one of the actual commit, but the one of some previous commit, in most cases of the one which was installed directly before the current commit.
Posted Sun Feb 10 23:46:47 2008Is there some way to make gitweb show a diff with the right message? I don't see one, except for diffs that show all changes in the commit, rather than only changes to a single file. This feels like a bug in gitweb. --Joey
(Note: feel free to say "not a bug" or offer a workaround rather than changing ikiwiki.)
As reported by a Windows user trying ikiwiki: because Windows doesn't support filenames with colons, he couldn't check out the ikiwiki svn repository. More generally, ikiwiki doesn't encode colons in filenames for wiki pages, but to support Windows users perhaps it should.
Windows does not support filenames containing any of these characters: / \ * : ? " < > |
Posted Sun Feb 10 23:46:47 2008I take it this is a problem when checking out a wiki in windows, not when browsing to urls that have colons in them from windows? --Joey
Correct. You can't directly check out a wiki's repository from Windows if it includes filenames with those characters; you will get errors on those filenames.
Pages under templates/ are invalid (in fact, not only invalid, but also not well-formed) xhtml pages.
This problem is especially serious when you change extension from .html to .xhtml in ikiwiki.setup and use Firefox. Since Firefox will display a error message only for not well-formed application/xhtml+xml pages.
It seems that HTML::Template also support <!--Variable-->
syntax instead
of <Variable>
. Chaning to this syntax will solve this problem, I guess.
Even if changed to <!-- TMPL_VAR -->
style, the problem may still exist if the template contains if else block.
Maybe just encode all < and > when compling pages within the templates folder will solve this problem.
Posted Sun Feb 10 23:46:47 2008I never noticed this bug, since it only happens if the htmlscrubber is disabled. --Joey
When rendering an rst page with utf-8 characters in (specifically but not solely "£"), ikiwiki seems to hang.
Killing with Control-C gives the following traceback:
Traceback (most recent call last):
File "/usr/lib/ikiwiki/plugins/rst", line 97, in ?
handler.handle_request()
File "/usr/lib/ikiwiki/plugins/rst", line 74, in handle_request
ret = rpc_read(processor)
File "/usr/lib/ikiwiki/plugins/rst", line 42, in rpc_read
line = sys.stdin.readline()
KeyboardInterrupt
rst2html on the same file has no problem rendering the file as expected. The markdown plugin also has no problems rendering the same file, so I'm guessing it's a problem with the XML-RPC interface.
Posted Sun Feb 10 23:46:47 2008[[debbug 123456]]
expands to "bug #123456", which is hyperlinked. Could you please drop the leading "bug", for two reasons?
First, #123456 is not a bug, it's a bug report. And second, #123456 suffices, doesn't it? By hardcoding the "bug" in there, you make it impossible to start a sentence with a bug number, e.g.:
There are problems with code. #123456 is a good example of...
instead of
There are problems with code. bug #123456 is a good example of...
Thanks, --madduck
Posted Sun Feb 10 23:46:47 2008If sandbox/page.mdwn has been generated and sandbox/sidebar.mdwn is created, the sidebar is only added to sandbox and none of the subpages. --TaylorKillian
Yes, a known bug. As noted in the code: --Joey
# FIXME: This isn't quite right; it won't take into account
# adding a new sidebar page. So adding such a page
# currently requires a wiki rebuild.
add_depends($page, $sidebar_page);
Posted Sun Feb 10 23:46:47 2008
My backported ikiwiki 1.48 converts smileys in the block code incorrectly. I can see the HTML code of smileys image, instead of smileys image.
For example, I'd like to save interesting for me thread of courier-users mailing list. Please looks below to see what ikiwiki does with that smileys:
From: Bernd Wurst <bernd@bw...>
Subject: Re: [courier-users] Uploaded my SRS implementation for courier to
the web
To: courier-users@li...
Date: Sat, 17 Mar 2007 19:02:10 +0100
Hi.
Am Samstag, 17. Mrz 2007 schrieb Matthias Wimmer:
> See the graphic on http://www.openspf.org/SRS at the bottom on the left
> side. You will find an example there how rewriting an already rewritten
> address works.
Ah, ok, didn't know that. <img src="smileys/smile.png" alt=":)" />
Thanks for the pointer!
cu, Bernd
BTW, maybe converting smileys in the block code should be disabled at all?
--Paweł
Posted Sun Feb 10 23:46:47 2008Looks similar to wiki links still processed inside code blocks; in both cases, substitution happens in a code block, which it shouldn't. --JoshTriplett
Just saw a bug with the git backend and utf8. I was committing to ikiwiki and the post-commit hook emitted a warning message about some text from git not being encoded as proper utf-8. I've lost the message, but it was from line 36 of git.pm. After a couple other commits, the message stopped appearing.
Probably git's output needs to be force encoded to utf-8. --Joey
Posted Sun Feb 10 23:46:47 2008This bug is described here:
http://kitenet.net/~joey/blog/entry/OpenID/discussion/
Posted Sun Feb 10 23:46:47 2008The 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..
Note that this bug does not exist if the wiki is built with the "usedirs" option, since in that case, the parent link will link to a subdirectory, that will just be missing the index.html file, but still nicely usable.
Posted Sun Feb 10 23:46:47 2008If 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.
Relatedly, if there are two files with different extensions that build a page with the same name, in a directory, ikiwiki will update the page whenever either changes, using the changed one as the source. But if that most recently changed one is removed, it won't rebuild the page using the older one as the source.
Posted Sun Feb 10 23:46:47 2008Has 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.
Still true in 1.43 although the code is much different now..
Posted Sun Feb 10 23:46:47 2008Web 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 Sun Feb 10 23:46:47 2008See "using the web interface with a real text editor" on the tips page. --JoshTriplett
Would it be useful to allow a "max width" plugin, which would force on commit the split of long lines ?
Please, no. That would wreak havoc on code blocks and arguments to preprocessor directives, and it would make bulleted lists and quoted blocks look bogus (because the subsequent lines would not match), among other problems. On the other hand, if you want to propose a piece of client-side JavaScript that looks at the active selection in a text area and word-wraps it, and have a plugin that adds a "Word-Wrap Selection" button to the editor, that seems fine. --JoshTriplett
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 20: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
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 20: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 20:27:08 2007