Available in a git repository branch.
Branch: schmonz/portability
Author: schmonz

Whoops, somehow missed a spot on the last incarnation of this branch. find -not doesn't work on NetBSD and find ! runs equivalently for me. Fixed in 9659272e25fac37f896991dab01a05b4f4c85ccb.

When an ikiwiki instance is holding a lock, a web user clicking on "add comment" (for example) will have to wait for the lock to be released. However, all they are then presented with is a web form. Perhaps CGI requests that are read-only (such as generating a comment form, or perhaps certain types of edits) should ignore locks? Of course, I'd understand that the submission would need to wait for a lock. — Jon

This is possibly/probably due to my weird setup, which is that I have apache behind nginx, with the result that apache sees the client's IPv4 address as having been mapped to IPv6. i.e. ::ffff:10.11.12.13. That being the case, I currently need to specify that (with the ::ffff: prepended) if I want to whitelist (or more importantly blacklist) and IPv4 address.

It strikes me that this is liable to become more of a problem as people finally start using IPv6, so it might be worth ensuring that the code that compares IP addresses be able to treat the two formats (with and without the ffff's) as equivalent. --fil

My setup matches w3mmode ikiwiki.setup exactly. My doc/index.mdwn just has a line or two of plain text. When I try to edit that page in w3m, it works fine until I push [Save Page]. Then I just get a page that only contains "403".

ikiwiki version is 3.20110715ubuntu1. w3m is 0.5.3.

-- terry

I made it work, though probably not completely, by renaming ~/.ikiwiki/wrappers/ikiwiki.cgi to ikiwiki2.cgi and replacing it with:

#!/bin/bash
/home/tjgolubi/.ikiwiki/wrappers/ikiwiki2.cgi $* | sed -e 's,http://localhost,file://,g'

I'm afraid that this hack may have bad side-effects, but I hope it points you to the cause/solution. Of course, the next time I rerun ikiwiki --setup, it will overwrite my wrapper-wrapper.

-- terry

I made a logfile of all the args, env, and stdin/stdout to/from my wrapper. If you're interested, I'll email it to you. I wasn't able to attach it here.

-- terry

Can't appear to get 'wiki' functions (i.e. editing) running when ikiwiki is running on a port other than the default (port 80). Somewhere in the processing it considers the base URL to exclude the port number and the websever throws back an error finding the page.

For example if you run on 'http://my.gear.xxx:8080/' then after clicking login (using default password auth) it will process and try to redirect you to 'http://my.gear.xxx/cgi-bin/ikiwiki.cgi'. I'm assuming that somewhere we've used the 'path' and the 'host' and dropped the remainder. I can figure out where this is yet but I'll post back if I get lucky.

-- fergus

NB: both the 'url' and the 'cgiurl' include the port and removing the port element provides the expected functionality.

SERVER_PORT=8181  
HTTP_HOST=zippy0.ie0.cobbled.net  

[ ... ]

my $vh = $self->http('x_forwarded_host') || $self->http('host');
my $protocol = $self->protocol;
if ($vh) {
   return ($vh =~ /:(\d+)$/)[0] || ($protocol eq 'https' ? 443 : 80);

[ ... ]

Patch for thttpd-2.25b for posterity and completeness

diff --git a/libhttpd.c b/libhttpd.c
index 73689be..039b7e3 100644
--- a/libhttpd.c
+++ b/libhttpd.c
@@ -2074,9 +2074,6 @@ httpd_parse_request( httpd_conn* hc )
        cp = &buf[5];
        cp += strspn( cp, " \t" );
        hc->hdrhost = cp;
-      cp = strchr( hc->hdrhost, ':' );
-      if ( cp != (char*) 0 )
-          *cp = '\0';
        if ( strchr( hc->hdrhost, '/' ) != (char*) 0 || hc->hdrhost[0] == '.' )
            {
            httpd_send_err( hc, 400, httpd_err400title, "", httpd_err400form, "" );

-- fergus

I've gone ahead and filed a bug on CGI.pm too: https://rt.cpan.org/Ticket/Display.html?id=72678 --Joey

That'll be an interesting discussion as I'd suggest that HTTP headers are defined in the CGI specification as client headers and thus what thttpd is doing is wrong (i.e. mangling the client's own representation). Whether a CGI client should trust HTTP header over the server is probably already settled by convention.

-- fergus

I originally set up ikiwiki by using the debian package, but had some odd issues, so i figured i'd try installing from git. To do that i uninstalled the debian package and then did the Makefile dance from the git dir. In that process the original dirs configured in templatedir underlaydir in my wiki were deleted; HOWEVER when rebuilding the script just went ahead and did not even note the lack of those dirs. It would be nice if it threw errors if the dirs were configured, but non-existant.

I just tried to clone the git repo onto a windows machine to test things out a bit and it turns out i cannot even successfully checkout the code because of those colons. Would a patch changing those to underscores be accepted? --Mithaldu

I'm using the most recent release of ikiwiki (3.20110905), the Perl shipped with SuSE 11.4 (v5.12.3), and built and installed xapian 1.2.7 from source, as it seems the current stable version that's encouraged for use by xapian.

After enabling the search plugin and pointing ikiwiki to the omega program, rerunning ikiwiki --setup, and attempting a search, all searches return 0 results. No errors are reported by omindex or ikiwiki while producing the indexes in .ikiwiki/xapian/*, and the files appear to contain the indexed data. I don't think it's a problem in indexing.

When running omega by hand in the .ikiwiki/xapian directory, providing queries on the command-line, runs correctly but again provides no results.

I found that Debian stable is currently shipping 1.2.3, and on a hunch, I built that version, and searching now works fine. This looks like the usage of xapian's query template has changed somewhere between 1.2.3 and 1.2.7. Someone more familiar with xapian's query template language should be able to figure out what needs to be changed more specifically.

When I create a new page and upload an attachment all is fine.

If I try to upload a second attachment (or remove the previously uploaded attachment), no upload happens. Instead the page gets created. No matter what I typed in, I just get a map to show the attachment. Now I can edit this page and everything is fine again.

Another workaround is to first save the text and then edit and upload the rest.

Is this a problem on my site or does anyone else see this?

(If it's my fault feel free to move this to forum.)

When the aggregate plugin was used for a feed and this is removed (or the same feed name given a different rss feed), the old entries don't automatically vanish.

I think that if it was just removed, they are never GC'd, because the expiry code works on the basis of existing feeds. And if it was replaced, old items won't go away until expirecount or expireage is met.

To fix it probably needs an explicit check for items aggregated by feeds that no longer provide them, Catching old items for feeds that were changed to a different url may be harder yet. --Joey

Wikis are great tools for collaborative content of all types, but the choice for website creators who want a level of collaboration seem to have to choose between a static website, a wiki that anyone (or all members) can edit, or an overkill customized web app.

A simple innovation that needs to propagate through wiki software is adding the ability to suggest edits and accept those edits. Perhaps you want a wiki that anyone can suggest and edit, but only registered users can edit freely or accept edits. Or you want anyone, including members, to only be able to suggest edits, and only have moderators able to approve edits and edit freely. Etc, etc.

Two examples of encoding breakage observed in the wild. In both cases the ampersand needs to be escaped. --Joey

<link href="http://www.youtube.com/watch?v=Z9hP9lhBDsI&feature=youtube_gdata"/>

<category term="vicky&alice" />

in ikiwiki instances that don't reside in the git root directory (the only ones i know of are ikiwiki itself), reverts show the wrong link in the recentchanges (for example, in the ikiwiki main repository's 4530430 and its revert, the main index page was edited, but the revert shows doc/index as a link).

the expected behavior is to compensate for the modified root directory (i.e., show index instead of doc/index).

Hi, I created [[sandbox/subpage]] then I deleted it with the "remove" button. After confirmation there was a message about a xapian error (My bad, I did not write down the exact error message). Now, accessing ?sandbox/subpage leads my browser complains about a redirect loop. JeanPrivat

Apache will return 403 (Forbidden) instead of 404 (Not Found) if the Indexes option is turned off. This is because with Indexes turned on, it considers it something it might be able to serve in the future. With Indexes off, it will never serve that page in the future (unless Indexes is turned back on).

The 404 plugin code only checks for 404, not 403. It should check for both.

See Also:

The opendiscussion plugin allows pages named according to the discussionpage setting to be edited anonymously, even if discussion => 0 is set.

(If it respected the discussion option, the combination of opendiscussion and moderatedcomments might be good for blogs.)

The table plugin seems to be unable to read a CSV file that uses \r\n for line delimiters. The same file with \r works fine. The error message is "Empty data". --liw

I was seeing this as well on an Ubuntu 11.04 system with Ubuntu 11.04, Perl 5.10.1, IkiWiki 3.20110124ubuntu1, and libtext-csv-perl 1.21-1, all installed from APT. However, when I removed libtext-csv-perl from APT and installed it from CPAN, the problem went away. FWIW, what CPAN grabbed was MAKAMAKA/Text-CSV-1.21.tar.gz. --micahrl

When I add a comment to a page, its title should be a hyperlink. This would make re-opening it to re-read parts of it, either.

I.e. when adding a comment to this page, the last part should be a hyperlink, as well:

ikiwiki/ bugs/ creating Site title not clickable while adding a comment

Richard

mkdir -p ikiwiki-tag-test/raw/a_dir/ ikiwiki-tag-test/rendered/
echo '<span class="createlink"><a href="/ikiwiki.cgi?page=a_tag&amp;from=bugs%2Ftransient_autocreated_tagbase_is_not_transient_autoindexed&amp;do=create" rel="nofollow">?</a>a tag</span>' > ikiwiki-tag-test/raw/a_dir/a_page.mdwn
ikiwiki --verbose --plugin tag --plugin autoindex --plugin mdwn --set autoindex_commit=0 --set tagbase=tag --set tag_autocreate=1 --set tag_autocreate_commit=0 ikiwiki-tag-test/raw/ ikiwiki-tag-test/rendered/
ls -al ikiwiki-tag-test/raw/.ikiwiki/transient/
ls -al ikiwiki-tag-test/rendered/tag/

Shouldn't ikiwiki-tag-test/raw/.ikiwiki/transient/tag.mdwn and ikiwiki-tag-test/rendered/tag/index.html exist?

I noticed this a few times in Google Chrome 12 (dev channel) a few times, already:

I added a comment to

http://git-annex.branchable.com/forum/performance_improvement:_git_on_ssd__44___annex_on_spindle_disk/

and left the page. Later, I revisited

http://git-annex.branchable.com/forum/

and clicked on

http://git-annex.branchable.com/forum/performance_improvement:_git_on_ssd__44___annex_on_spindle_disk/

My own comment did not appear. I pressed F5 and eh presto.

My assumption is that ikiwiki does not tell Chrome to reload the page as the cache is stale.

Richard

Similarly to po: apache config serves index.rss for index, the po apache config has another bug.

The use of "DirectoryIndex index", when combined with multiviews, is intended to serve up a localized version of the index.??.html file.

But, if the site's toplevel index page has a discussion page, that is "/index/discussion/index.html". Or, if the img plugin is used to scale an image on the index page, that will be "/index/foo.jpg". In either case, the "index" directory exists, and so apache happily displays that directory, rather than the site's index page!

--Joey

For security reasons, one of the sites I'm in charge of uses a Reverse Proxy to grab the content from another machine behind our firewall. Let's call the out-facing machine Alfred and the one behind the firewall Betty.

For the static pages, everything is fine. However, when trying to use the search, all the links break. This is because, when Alfred passes the search query on to Betty, the search result has a "base" tag which points to Betty, and all the links to the "found" pages are relative. So we have

<base href="Betty.example.com"/>
...
<a href="./path/to/found/page/">path/to/found/page</a>

This breaks things for anyone on Alfred, because Betty is behind a firewall and they can't get there.

What would be better is if it were possible to have a "base" which didn't reference the hostname, and for the "found" links not to be relative. Something like this:

<base href="/"/>
...
<a href="/path/to/found/page/">path/to/found/page</a>

The workaround I've come up with is this.

Here's a patch:

diff --git a/IkiWiki/Plugin/search.pm b/IkiWiki/Plugin/search.pm
index 3f0b7c9..26c4d46 100644
--- a/IkiWiki/Plugin/search.pm
+++ b/IkiWiki/Plugin/search.pm
@@ -113,7 +113,7 @@ sub indexhtml (@) {
        }
        $sample=~s/\n/ /g;

-       my $url=urlto($params{destpage}, "");
+       my $url=urlto($params{destpage}, undef);
        if (defined $pagestate{$params{page}}{meta}{permalink}) {
                $url=$pagestate{$params{page}}{meta}{permalink}
        }

It works for me, but it has the odd side-effect of prefixing links with a space. Fortunately that doesn't seem to break browsers. And I'm sure someone else could come up with something better and more general.

--KathrynAndersen

I think this should be a concern of ikiwiki's official FreeBSD port.

At any rate, even if it is decided that ikiwiki should be fixed, then it is probably better to use $installbin/perl from -MConfig and not the env hack.

The remove plugin cannot remove transient pages.

This is particularly a problem for tag pages, and autoindex created pages. So both plugins default to not creating transient pages, until this is fixed. --Joey

The inline and comments plugins both generate feed links.

In both cases, the generated markup include an element with id="feedlink".

XHTML 1.0 Strict (Ikiwiki's default output type) forbids multiple elements with the same ID:

As does W3C's HTML5.

Any page with both a comments feed and an inline feed will be invalid XHTML 1.0 Strict or HTML 5.

-- Jon

At least my setup on kapsi.fi always prints 404 Not Found after adding a page with non-ascii characters in name. But the page exists and is visible after the 404 with url encoding and the blog page is inlined correctly on the feed page.

Apparently ikiwiki.info does not complain with 404. Should the character encoding be set in wiki config?

Happens also after editing the page. Here's an example:

Difference is in the word Iso-Syöte. Pehaps also the browsers is part of the game, I use Iceweasel from Debian unstable with default settings.

Server runs Debian 5.0.8 but I don't have access to the Apache configs. Here's the tcp stream from wireshark without cookie data, page name is testiä.html. I guess page name is in utf-8 but in redirect after post it is given to browser with 8859-1.

POST /ikiwiki.cgi HTTP/1.1
Host: mcfrisk.kapsi.fi
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://mcfrisk.kapsi.fi/ikiwiki.cgi
Cookie: XXXX
Content-Type: multipart/form-data; boundary=---------------------------138059850619952014921977844406
Content-Length: 1456

-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="_submitted"

2
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="do"

edit
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="sid"

93c956725705aa0bbdff98e57efb28f4
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="from"


-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="rcsinfo"

5419fbf402e685643ca965d577dff3dafdd0fde9
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="page"

testi..
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="type"

mdwn
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="editcontent"

test
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="editmessage"


-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="_submit"

Save Page
-----------------------------138059850619952014921977844406
Content-Disposition: form-data; name="attachment"; filename=""
Content-Type: application/octet-stream


-----------------------------138059850619952014921977844406--
HTTP/1.1 302 Found
Date: Wed, 02 Feb 2011 19:45:49 GMT
Server: Apache/2.2
Location: /testi%E4.html?updated
Content-Length: 0
Keep-Alive: timeout=5, max=500
Connection: Keep-Alive
Content-Type: text/plain

GET /testi%E4.html?updated HTTP/1.1
Host: mcfrisk.kapsi.fi
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://mcfrisk.kapsi.fi/ikiwiki.cgi
Cookie: XXXX

HTTP/1.1 404 Not Found
Date: Wed, 02 Feb 2011 19:45:55 GMT
Server: Apache/2.2
Content-Length: 279
Keep-Alive: timeout=5, max=499
Connection: Keep-Alive
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /testi..html was not found on this server.</p>
<hr>
<address>Apache/2.2 Server at mcfrisk.kapsi.fi Port 80</address>
</body></html>

Getting the pages has worked every time:

GET /testi%C3%A4.html HTTP/1.1
Host: mcfrisk.kapsi.fi
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20110107 Iceweasel/3.5.16 (like Firefox/3.5.16)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: XXXX
If-Modified-Since: Wed, 02 Feb 2011 19:45:54 GMT
If-None-Match: "1b518d-7c0-49b51e5a55c5f"
Cache-Control: max-age=0

HTTP/1.1 304 Not Modified
Date: Wed, 02 Feb 2011 20:01:43 GMT
Server: Apache/2.2
Connection: Keep-Alive
Keep-Alive: timeout=5, max=500
ETag: "1b518d-7c0-49b51e5a55c5f"

It looks like there is no way to logout of ikiwiki at present, meaning that if you edit the ikiwiki in, say, a cybercafe, the cookie remains... is there some other security mechanism in place that can check for authorization, or should I hack in a logout routine into ikiwiki.cgi?

I was referred to this page from posting to the forum. I am also interested in being able to use user class and status to modify the page. I will try to put together a plugin. From what I can see there needs to be a few items in it.

Then there would need to be a little javascript to use these links appropriately. I have little javascript experience but I know that can be done. I am less sure if it is possible to add this functionality to a plugin so I'll start with that. If no one objects I will continue to post here if I make progress. If anyone has any suggestions on how to modify my approach to code it in an easier way I'd appreciate the input. justint

I'd like the more plugin and RSS to play better together. In the case of the html generation of the main page of a blog, I'd like to get the first paragraph out, but keep RSS as a full feed.

Maybe there is a different plugin (I also tried toggle)?

I also note, that at least currently, more seems to break on a few pages, not being parsed at all when aggregated into the front page.

see also: rss feeds do not use recommended encoding of entities for some fields

Wide characters should probably be supported, or, at the very least, warned about.

Test case:

mkdir -p ikiwiki-utf-test/raw ikiwiki-utf-test/rendered
for page in txt mdwn; do
  echo hello > ikiwiki-utf-test/raw/$page.$page
  for text in 8 16 16BE 16LE 32 32BE 32LE; do
    iconv -t UTF$text ikiwiki-utf-test/raw/$page.$page > ikiwiki-utf-test/raw/$page-utf$text.$page;
  done
done
ikiwiki --verbose --plugin txt --plugin mdwn ikiwiki-utf-test/raw/ ikiwiki-utf-test/rendered/
www-browser ikiwiki-utf-test/rendered/ || x-www-browser ikiwiki-utf-test/rendered/
# rm -r ikiwiki-utf-test/ # some browsers rather stupidly daemonize themselves, so this operation can't easily be safely automated

BOMless LE and BE input is probably a lost cause.

Optimally, UTF-16 (which is ubiquitous in the Windows world) and UTF-32 should be fully supported, probably by converting to mostly-UTF-8 and using &#xXXXX; or &#DDDDD; XML escapes where necessary.

Suboptimally, UTF-16 and UTF-32 should be converted to UTF-8 where cleanly possible and a warning printed where impossible.

Reading the wikipedia pages about UTF-8 and UTF-16, all valid Unicode characters are representable in UTF-8, UTF-16 and UTF-32, and the only errors possible with UTF-16/32 -> UTF-8 translation are when there are encoding errors in the original document.

Of course, it's entirely possible that not all browsers support utf-8 correctly, and we might need to support the option of encoding into CESU-8 instead, which has the side-effect of allowing the transcription of UTF-16 or UTF-32 encoding errors into the output byte-stream, rather than pedantically removing those bytes.

An interesting question would be how to determine the character set of an arbitrary new file added to the repository, unless the repository itself handles character-encoding, in which case, we can just ask the repository to hand us a UTF-8 encoded version of the file.

-- Martin Rudat

Consider this:

$ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.tar.bz2
$ wget http://schwinge.homeip.net/~thomas/tmp/cutpaste_filter.patch

$ tar -xj < cutpaste_filter.tar.bz2
$ cd cutpaste_filter/
$ ./render_locally
$ find "$PWD".rendered/ -type f -print0 | xargs -0 grep -H -E 'FOO|BAR'
[notice one FOO in there]
$ rm -rf .ikiwiki "$PWD".rendered

$ cp /usr/share/perl5/IkiWiki/Plugin/cutpaste.pm .library/IkiWiki/Plugin/
$ patch -p0 < ../cutpaste_filter.patch
$ ./render_locally
$ find "$PWD".rendered/ -type f -print0 | xargs -0 grep -H -E 'FOO|BAR'
[correct; notice no more FOO]

I guess this needs a general audit -- there are other places where preprocess is being doing without filtering first, for example in the same file, copy function.

--tschwinge

If comments_allowdirectives is set, previewing a comment can run directives that create files. (Eg, img.) Unlike editpage, it does not keep track of those files and expire them. So the files will linger in destdir forever.

Probably when the user then tries to save the comment, ikiwiki will refuse to overwrite the unknown file, and will crash. --Joey

I'd like a way to always ask the RCS (Git) to update a file's mtime in refresh mode. This is currently only done on the first build, and later for --gettime --rebuild. But always rebuilding is too heavy-weight for this use-case. My options are to either manually set the mtime before refreshing, or to have ikiwiki do it at command. I used to do the former, but would now like the latter, as ikiwiki now generally does this timestamp handling.

From a quick look, the code in IkiWiki/Render.pm:find_new_files is relevant: if (! $pagemtime{$page}) { [...].

How would you like to tackle this?

--tschwinge

I'm attempting a merge with the SVN plugin via the web interface with ikiwiki-3.20100403 and subversion 1.6.11.

The web interface says

Your changes conflict with other changes made to the page.

Conflict markers have been inserted into the page content. Reconcile the conflict and commit again to save your changes.

However there are no merge conflict markers in the page. My apache error log says:

[Fri Apr 30 16:43:57 2010] [error] [client 10.64.64.42] svn: Commit failed (details follow):, referer: https://unixwiki.ncl.ac.uk/ikiwiki.cgi
[Fri Apr 30 16:43:57 2010] [error] [client 10.64.64.42] svn: Authorization failed, referer: https://unixwiki.ncl.ac.uk/ikiwiki.cgi

-- Jon

Lighttpd apparently sets REDIRECT_STATUS=200 for the server.error-handler-404 page. This breaks the 404 plugin which checks this variable for 404 before processing the URI. It also doesn't seem to set REDIRECT_URL.

#!/bin/sh
REDIRECT_STATUS=404; export REDIRECT_STATUS
REDIRECT_URL="$SERVER_NAME$REQUEST_URI"; export REDIRECT_URL
exec /path/to/your/ikiwiki.cgi "$@"

I was able to fix my server to check the REQUEST_URI for ikiwiki.cgi and to continue processing if it was not found, passing $ENV{SEVER_NAME} . $ENV{REQUEST_URI} as the first parameter to cgi_page_from_404. However, my perl is terrible and I just made it work rather than figuring out exactly what to do to get it to work on both lighttpd and apache.

This is with lighttpd 1.4.19 on Debian.

sub cgi ($) {
        my $cgi=shift;
        if ($ENV{REQUEST_URI} !~ /ikiwiki\.cgi/) {
                my $page = cgi_page_from_404(
                        Encode::decode_utf8($ENV{SERVER_NAME} . $ENV{REQUEST_URI}),
                        $config{url}, $config{usedirs});
                IkiWiki::Plugin::goto::cgi_goto($cgi, $page);
        }

#       if (exists $ENV{REDIRECT_STATUS} &&
#           $ENV{REDIRECT_STATUS} eq '404') {
#               my $page = cgi_page_from_404(
#                       Encode::decode_utf8($ENV{REDIRECT_URL}),
#                       $config{url}, $config{usedirs});
#               IkiWiki::Plugin::goto::cgi_goto($cgi, $page);
#       }
}

It seems that rebuild a wiki (ikiwiki --rebuild) after changing the underlaydir config option doesn't remove the pages coming from the previous underlaydir.

I've noticed this with the debian package version 3.20100102.3~bpo50+1.

Perhaps it is possible to improve this or mention it in the manual page?

--prosper

I have a page with the name "umläute". When I try to remove it, ikiwiki says:

Error: ?umläute does not exist

I wrote the following patch, which seems to work on my machine. I'm running on FreeBSD 6.3-RELEASE with ikiwiki-3.20100102.3 and perl-5.8.9_3.

--- remove.pm.orig      2009-12-14 23:26:20.000000000 +0100
+++ remove.pm   2010-01-18 17:49:39.000000000 +0100
@@ -193,6 +193,7 @@
                        # and that the user is allowed to edit(/remove) it.
                        my @files;
                        foreach my $page (@pages) {
+                               $page = Encode::decode_utf8($page);
                                check_canremove($page, $q, $session);

                                # This untaint is safe because of the

To reproduce:

bestlink() checks %links (and %pagecase) to confirm the existance of the page. However, find_del_files() does not remove the deleted page from %links (and %pagecase).

Since find_del_files removes the deleted page from %pagesources and %destsources, won't it make sense for bestlink() to check %pagesources first? --harishcm

#!/usr/bin/perl
# Plugin to reproduce bestlink returning deleted pages. 
# Run with ikiwiki in verbose mode.

package IkiWiki::Plugin::bestlinkbug;

use warnings;
use strict;
use IkiWiki 3.00;

sub import {
    hook(type => "getsetup", id => "bestlinkbug", call => \&getsetup);
    hook(type => "needsbuild", id => "bestlinkbug", call => \&needsbuild);
}

sub getsetup () {
    return
        plugin => {
            safe => 1,
            rebuild => 0,
        },
}

sub needsbuild (@) {
    my $needsbuild=shift;

    foreach my $page (keys %pagestate) {
        my $testpage=bestlink($page, "test") || next;

        debug("$page");
    }
}   

1

The map directive sort by pagename. That looks kind of odd, when used together with show=title. I would expect it to sort by title then.

[[!inline ]] is rendered with a space in front of the first closing bracket. --tschwinge

I'm trying to make a pretty theme for ikiwiki and I'm making progress (or at least I think I am :-). However I've noticed an issue when it comes to theming. On the front page the wiki name is put inside the "title" span and on all the other pages, it's put in the "parentlinks" span. See here:

From my dev home page:

<div class="header">
<span>
<span class="parentlinks">

</span>
<span class="title">
adam.shand.net/iki-dev
</span>
</span><!--.header-->

</div>


From a sub-page of my dev home page:

<div class="header">
<span>
<span class="parentlinks">

<a href="../">adam.shand.net/iki-dev/

</span>
<span class="title">
recipes </span>
</span><!--.header-->

</div>


I understand the logic behind doing this (on the front page it is the title as well as the name of the wiki) however if you want to do something different with the title of a page vs. the name of the wiki it makes things pretty tricky.

I'll just modify the templates for my own site but I thought I'd report it as a bug in the hopes that it will be useful to others.

Cheers,
AdamShand.

Example:

[[`\[[!taglink TAG\]\]`|plugins/tag]]

gives:

[[\[[!taglink TAG\]\]|plugins/tag]]

Expected: there is a wikilink with the complex text as the displayed text. --Ivan Z.

aggregate takes a name parameter that specifies a global name for a feed. This causes some problems:

Need to find a way to not make the name be global. Perhaps it needs to include the name of the page that contains the directive?

Escaping pipe-symbol in ?taglink targets doesn't work as I wanted:

?smth with a pipe|about the </span> ?smth with a pipe|about the

as opposed to simple wikilinks:

?a link to smth with a pipe ?a link to smth with a pipe

And it seems to work in pagespecs:

tagged:

link:

The remove plugin does not report an error if git rm fails. (It probably doesn't if other VCS backends fail too). This can happen for example if a page in your source directory is not a tracked file for whatever reason (in my case, due to renaming the files and forgetting to commit that change).

-- Jon

I was just hovering over the '...' next to the backlinks on a page on http://ikiwiki.info/. In terms of the size of my browser window, this was towards the bottom-right of the screen.

When I hovered over the '...', the additional backlinks float appeared. This caused the page length to grow down, meaning a horizontal scrollbar was added to the page. This meant the text reflowed, and the '...' moved outside of my mouse pointer region.

This caused an infinite loop of box appears... text moves, box disappears... box re-appears.. which was not very visually pleasant.

In general I think that the onhover float is a bit of bad UI. Even a truncated list of backlinks looks cluttered due to there being no delimiters. I moved to having an always-complete list of backlinks and having them as LI elements inside a UL to make it look neater, although I appreciate that would make some pages very long indeed.

How about doing something a little like toggle for the excess items instead?

-- Jon

An additional, related issue: if the box expands beyond the bottom of the page, you might move your mouse pointer to the scrollbar in order to move further down the list, but of course then you are outside the hover region.

-- Jon

Error received when clicking on the "edit" link:

Error received when following a "Create New Page" (eg. ?) link:

I could probably find several other flavors of this error if I went looking, but I trust you get the idea.

The CGI starts to render (this isn't the "you forgot to set the permissions/turn on the CGI" error) and then fails.

Further details:

perl -e 'use warnings; use strict; use CGI::FormBuilder; my $form=CGI::FormBuilder->new; $form->text("boo")'

In ikiwiki 2.66, SVG images are not recognized as images. In ikiwiki.pm, the hardcoded list of image file extensions does not include ".svg", which it probably should unless there's some other issue about rendering SVGs?

The 'img' plugin also seems to not support SVGs.

A lot of strings in ikiwiki are hardcoded and not taken for locales resources through gettext. This is bad because ikiwiki is thus difficult to spread for non-english users.

I mean that, for instance in CGI.pm, line like:

my @buttons=("Save Page", "Preview", "Cancel");

should be written as

my @buttons=(gettext("Save Page"), gettext("Preview"), gettext("Cancel"));

In standards templates things seems wrongly written too. For instance in page.tmpl line like:

<li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li>

should be written as

<li><a href="<TMPL_VAR EDITURL>" rel="nofollow"><TMPL_VAR EDITURL_TEXT</a></li>

with EDITURL_TEXT variable initialized in Render.pm through a gettext call.

Am I wrong ?

If not I can spend some time preparing patches for such corrections if it can help.

-- bbb

A ?PageSpec that is entirely negated terminals, such as "!foo and !bar" matches all other pages, including all internal pages. This can lead to unexpected results, since it will match a bunch of recentchanges pages, etc.

Recall that internal-use pages are not matched by a glob. So "*" doesn't match them. So if the pagespec is "* and !foo and !bar", it won't match them. This is the much more common style.

There's an odd inconsistency with entirely negated pagespecs. If "!foo" matches page bar, shouldn't "" also match bar? But, the empty pagespec is actually special-cased to not match anything.

Indeed, it seems what would be best would be for "!foo" to not match any pages, unless it's combined with a terminal that positively matches pages ("* and !foo"). Although this would be a behavior change, with transition issues.

Another approach would be to try to detect the case of an entirely negated pagespec, and implicitly add "and !internal()" to it.

Either approach would require fully parsing the pagespec. And consider cases like "!(foo and !bar)". Doesn't seem at all easy to solve. --Joey

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.

When committing a page like this one, with an escaped toc directive in it:

[[!toc  ]]

The recentchangesdiff comes back with it unescaped. Which can be confusing.

If you create a foo.rst containing only a number, such as "11", rendering results in the following error being thrown. (Now that I've fixed the error throwing code..):

exceptions.TypeError:coercing to Unicode: need string or buffer, int found

--Joey

index 5136b3c..545e226 100755
--- a/plugins/proxy.py
+++ b/plugins/proxy.py
@@ -88,7 +101,7 @@ class _IkiWikiExtPluginXMLRPCHandler(object):

    @staticmethod
    def _write(out_fd, data):
-        out_fd.write(data)
+        out_fd.write(str(data))
        out_fd.flush()

    @staticmethod

It would be nice if the aggregate plugin would try to extract the m/ctime out of each post and touch the files on the filesystem appropriately, so that ikiwiki reflects the actual time of the post via the inline plugin, rather than the time when the aggregation ran to pull the post in. --madduck

# Set the mtime, this lets the build process get the right creation
# time on record for the new page.
utime $mtime, $mtime, pagefile($guid->{page})
    if defined $mtime && $mtime <= time;

I am using mercurial as RCS backend and ikiwiki 2.40.

It seems that, when adding a blog post, it is not immediately commited to the mercurial repo. I have a page with this directive:

[[!inline  pages="journal/blog2008/* and !*/Discussion" show="0" feeds="no" actions="yes" rootpage="journal/blog2008"]]

When I add a blog post, I see it on the wiki but it doesn't appear on History or RecentChanges. If I run hg status on the wiki source dir, I see the new file has been marked as A (ie, a new file that has not been commited).

If I then edit the blog post, then the file gets commited and I can see the edit on History and RecentChanges. The creation of the file remains unrecorded. --?buo

As far as I can tell, ikiwiki is not checking the SSL certificate of the remote host when using openid authentication. If so, this would allow for man-in-the-middle type attacks. Alternatively, maybe I am getting myself confused.

Test #1: Enter URL as openid server that cannot be verified (either because the certificate is self signed or signed by an unknown CA). I get no SSL errors.

Test #2: Download net_ssl_test from dodgy source (it uses the same SSL perl library, and test again. It seems to complain (on same site ikiwiki worked with) when it can't verify the signature. Although there is other breakage with the version I managed to download (eg. argument parsing is broken; also if I try to connect to a proxy server, it instructs the proxy server to connect to itself for some weird reason).

For now, I want to try and resolve the issues with net_ssl_test, and run more tests. However, in the meantime, I thought I would document the issue here.

-- Brian May

I was a bit vague myself on the details on openid. So I looked up the standard. I was surprised to note that they have already considered these issues, in section 15.1.2, http://openid.net/specs/openid-authentication-2_0.html#anchor41.

It says:

"Using SSL with certificates signed by a trusted authority prevents these kinds of attacks by verifying the results of the DNS look-up against the certificate. Once the validity of the certificate has been established, tampering is not possible. Impersonating an SSL server requires forging or stealing a certificate, which is significantly harder than the network based attacks."

With regards to implementation, I am surprised that the libraries don't seem to do this checking, already, and by default. Unfortunately, I am not sure how to test this adequately, see Debian bug #466055. -- Brian May

I think Crypt::SSLeay already supports checking the certificate. The trick is to get LWP::UserAgent, which is used by LWPx::ParanoidAgent to enable this checking.

I think the trick is to set one of the the following environment variables before retrieving the data:

$ENV{HTTPS_CA_DIR} = "/etc/ssl/certs/";
$ENV{HTTPS_CA_FILE} = "/etc/ssl/certs/file.pem";

Unfortunately I get weird results if the certificate verification fails, see Debian bug #503440. It still seems to work though, regardless.

-- Brian May

If I try to authenticate using openid to my site, it tries to create a http or https connection to the openid server. This doesn't work, because the direct connection is blocked by the firewall.

It would be good if ikiwiki supported setting up a proxy server to solve this.

I have found if I add:

newenviron[i++]="HTTPS_PROXY=http://host.domain.com:3128";

to IkiWiki/Wrapper.pm it solves the problem for https requests, however it obviously would be preferred if the proxy name is not hard coded.

Also, the ability to set HTTPS_CA_FILE and HTTPS_CA_DIR might benefit some people. Then again, it I can't see any evidence that the SSL certificate of the server is being checked. See the bug report I filed on this separate issue.

Unfortunately, HTTP_PROXY doesn't work for http:// requests, it looks like that library is different.

Update 2008-10-26:

Better solution, one that works for both http and https, and uses config options. It appears to work...

Note that using $ua->proxy(['https'], ...); won't work, you get a "Not Implemented" error, see http://community.activestate.com/forum-topic/lwp-https-requests-proxy. Also see Debian bug #129528.

Also note that the proxy won't work with liblwpx-paranoidagent-perl, I had to remove liblwpx-paranoidagent-perl first.

louie:/usr/share/perl5/IkiWiki/Plugin# diff -u openid.pm.old openid.pm
--- openid.pm.old   2008-10-26 12:18:58.094489360 +1100
+++ openid.pm   2008-10-26 12:40:05.763429880 +1100
@@ -165,6 +165,14 @@
            $ua=LWP::UserAgent->new;
    }
 
+   if (defined($config{"http_proxy"})) {
+       $ua->proxy(['http'], $config{"http_proxy"});
+   }
+
+   if (defined($config{"https_proxy"})) {
+       $ENV{HTTPS_PROXY} = $config{"https_proxy"};
+   }
+
    # Store the secret in the session.
    my $secret=$session->param("openid_secret");
    if (! defined $secret) {

Brian May

Available in a git repository branch.
Branch: schmonz/proxies
Author: schmonz

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.

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.

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.

This bug is described here:

http://kitenet.net/~joey/blog/entry/OpenID/discussion/

If 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

# 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);

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/">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:

<span class="createlink"><a href="/ikiwiki.cgi?page=this&amp;from=bugs%2Fwiki_links_still_processed_inside_code_blocks&amp;do=create" rel="nofollow">?</a>this</span>

and have it render like:

[[this]]

--?cworth

Debian bug #487397

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 word 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. --Joey

http://www.gnu.org/software/hurd/hurd/translator/writing.html does not exist. Then, on http://www.gnu.org/software/hurd/hurd/translator/writing/example.html, in the parentlinks line, writing links to the top-level index file. It should rather not link anywhere at all. --tschwinge

<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/

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

If a file in the srcdir is removed, exposing a file in the underlaydir, ikiwiki will not notice the removal, and the page from the underlay will not be built. (However, it will be if the wiki gets rebuilt.)

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?