recently fixed bugs

  1. We have a $srcdir/writable/page.mdwn source file in Git.
  2. ikiwiki is configured to allow edits via the CGI in writable/*, but nowhere else.
  3. Modify $srcdir/writable/page.mdwn, commit ⇒ commit $id.
  4. git mv $srcdir/writable/page.mdwn $srcdir/read-only/page.mdwn

⇒ The web interface allows reverting commit $id (presumably because it changes files only in $srcdir/writable). This operation effectively modifies $srcdir/read-only/page.mdwn, which feels wrong. My guess is that check_canchange does not take into account that Git will automatically detect that the file affected by the to-be-reverted commit has moved, and modify the file in its new location when reverting.

Working on it. In future please report non-public security vulnerabilities (such as authorization bypass) by private email to the maintainers, so that they are not visible to the general public until we have had a chance to fix the bug. --smcv

Sorry about that, I should clearly know better :/ --intrigeri

Fixed by using git revert --strategy=recursive --strategy-option=no-renames. I tried to do something more clever (doing the revert, and checking whether it made changes that aren't allowed) but couldn't get it to work in a reasonable time, so I'm going with the simpler fix. Fix committed, a release will follow later today.

CVE-2016-10026 has been assigned to this vulnerability. --smcv

You rock, thanks a lot! --intrigeri

Posted Sat 17 Dec 2016 07:12:01 JEST

This may, strictly speaking, be a bug in the pandoc plugin, but I think it would be better to fix it in ikiwiki because of its kind (and maybe because I believe/hope pandoc will become the markdown dialect standard). For all I know it might not only affect pandoc tables.

When creating a simple table in pandoc-flavoured markdown,

1    2
---  ---
3    4

pandoc converts this to the html code

<table>
<thead>
<tr class="header">
<th align="left">1</th>
<th align="left">2</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left">3</td>
<td align="left">4</td>
</tr>
</tbody>
</table>

<tr class="header"> causes it to be affected by style.css's

.header {
    margin: 0;
    font-size: 140%;
    font-weight: bold;
    line-height: 1em;
    display: block;
}

(more specifically by display: block;), which results in all header cells to cramp together in the first column.

The fix is easy: In style.css change .header { to .header tr:not(.header) {.

Alternatively, add the following code.

tr.header {
    display: table-row;
    }

I've added that last code snippet to my custom.css file. I admit .header tr:not(.header) is not especially elegant, but then again, I have almost no knowledge of CSS. There might be better solutions. (I don't even know why display: block; breaks the tables or why changing it to display: table-header; doesn't fix it but display: table-row; does :D )

This is essentially a conflict between ikiwiki's expectations for the definitions of CSS classes, and pandoc's expectations. The ikiwiki templates use class="header" to mean essentially the same thing as a HTML5 <header>, while Pandoc assumes a different meaning.

I think div.header, header.header { is probably a cleaner fix, and I have done that.

FYI, display: block breaks the tables because it makes the <tr> not be treated as a table row by the browser's layout engine. table-header is not a valid value for the CSS display attribute so that won't work.

--smcv

Posted Fri 30 Sep 2016 04:10:10 JEST

In commits by Simon McVittie on Oct 5, 2014, the following was added to cgitemplate():

b0a35c81 (Simon McVittie   2014-10-05  61)  my $topurl = $config{url};
3b8da667 (Simon McVittie   2014-10-05  62)  if (defined $cgi && ! $config{w3mmode} && ! $config{reverse_proxy}) {
b0a35c81 (Simon McVittie   2014-10-05  63)      $topurl = $cgi->url;
b0a35c81 (Simon McVittie   2014-10-05  64)  }

I am trying to determine what was intended by this change. The variable $topurl is not used again in this function, so this is essentially dead code. --blipvert

If you look at git log -p IkiWiki/CGI.pm you'll see that at the time, $topurl was used further down the function. Later in the branch, commit 33f6026 "In html5 mode, generate a host- or protocol-relative for the CGI" made this conditional on ! $config{html5}.

Somewhat later, commit 490a1ec "Always produce HTML5 doctype and new attributes, but not new elements" repurposed $config{html5} from "use HTML5" to "use new HTML5 elements" - which meant that commit a052771 "Now that we're always using HTML5, can be relative" could remove the only code that used $topurl.

You are correct to say that computing $topurl is now dead code, and I have removed it. done --smcv

Posted Wed 14 Dec 2016 19:04:04 JEST

When using inline with postform=yes, the user can click on the edit button without providing a title, and are allowed to save the page. This results in a file with a name like ".mdwn", which ikiwiki won't render. --Joey

done; made it error out in this case.

Posted Wed 21 Sep 2016 13:52:03 JEST

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

This seems to work OK now - commit 84c4ca33 and its reversion both appear correctly in recentchanges. Looking at git history, Joey fixed this in commit 1b6c1895 before 3.20120203. --smcv

Posted Fri 24 Jun 2011 09:43:33 JEST

The git commit (in my openid branch) says it all:

Update IkiWiki::openiduser to work with Net::OpenID 2.x

openiduser previously used a constructor that no longer works in 2.x.
However, all we actually want is the (undocumented) DisplayOfURL function
that is invoked by the display method, so try to use that.

This bug affects ikiwiki.info (my commits show up in RecentChanges as http://smcv.pseudorandom.co.uk/ rather than smcv [pseudorandom.co.uk]).

Cherry picked, thanks. --Joey

Relatedly, the other commit on the same branch would be nice to have (edited to add: I've now moved it, and its discussion, to pretty-print OpenIDs even if not enabled). --smcv

Posted Mon 22 Jun 2009 06:57:00 JEST Tags: done

I created ?revert me and then tried the revert button on recentchanges, but I was not allowed to revert it. The specific error was

Error: you are not allowed to change sandbox/revert_me.mdwn

I've just tried reading through the revert code, and I haven't figured out what permission I am lacking. Perhaps the error message could be a little clearer on that. The error might have been thrown by git_parse_changes in git.pm or check_canchange in IkiWiki.pm, via IkiWiki::Receive. -- Jon

fixed --Joey

Brilliant, many thanks. -- Jon

Posted Sat 23 Oct 2010 15:02:58 JEST

I'm using firefox-3.0.8-alt0.M41.1 (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4pre) Gecko/2008100921 Firefox/3.0). I have noticed that quite often it shows an old state of a page at http://ikiwiki.info, e.g., recentchanges without my last edits, or the last page I edited (say, 50 min ago) in the state it was before I edited it.

Only explicitly pressing "reload" helps.

Is it a bug? I haven't been noticing such problems usually on other sites. --Ivan Z.

This remains to be true now, with Epiphany 2.26.3 (Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.1.4pre) Gecko/20080528 Epiphany/2.22 Firefox/3.5). --Ivan Z.

In the most recent ikiwiki release, I added a Cache-Control hack explicitly to work around firefox's broken over-caching.

(When I tested epiphany and chromium, neither had firefox's problem.)

Posted Tue 26 May 2009 09:19:02 JEST Tags: done

RecentChanges should not link to pages that are being deleted. For as example, see the change with the title 'add news item for ikiwiki 2.60' which includes the deletion of "news/version 2.52". Maybe it should be made clear in RecentChanges that the change to the file is it being deleted.

It needs to link to the deleted page so that you can recreate the page if desired.

The link is not of the normal form used for a link to a nonexistant page, instead it redirects through a CGI. This is done because updating the links would require rebuilding all change pages each time, which would be 100x as slow as the current method.

I don't feel that being 100 times faster at the expense of a marginally inconsistent, but still usable interface is a bug. --Joey done

Posted Tue 12 Aug 2008 17:49:41 JEST

The final </div> in recentchanges.tmpl gets wrapped in a <p> tag for some reason, resulting in the following invalid XHTML at the end of the RecentChanges page

<p></div></p>

I'll bet this is fixed if you use the markdown 1.2 prerelease, which has a much less buggy html parser. (Ah, I see below that was the case.) --Joey

Also, there is a problem with the <img> tags generated by the smiley plugin which end up wrapped in a <pre> tag in the inline diff output. <img> tags is not allowed within a <pre> block. Maybe the smiley plugin should be disabled on RecentChanges?

See Smileys in the block code, which is now fixed. --Joey

See the validator output for more details.


I'll add this here since it's related. I also noticed that the meta tags for redirected pages need to be closed in order to be valid XHTML:

<meta http-equiv="refresh" content="10; URL=../ikiwiki/pagespec/">

I'm noticing these problems because I'm serving ikiwiki-generated content as application/xhtml+xml (as opposed to text/html) in order to include inline MathML. Any invalid XHTML causes Firefox to halt all processing and throw an error. —Jason Blevins


Here is a simple patch for the refresh problem. I haven't figured out what's causing the recentchanges bug yet.

--JasonBlevins

Thanks, applied that patch. --Joey


It turns out that the invalid XHTML on the recent changes page is due to a bug in Markdown. I was using the packaged version of markdown in Ubuntu (Gutsy and markdown 1.0.1-6). Everything is fine after installing the most recent version of Text::Markdown from CPAN.

Note that the above patch for the redirect tag is still applicable and the smiley issue remains open. --JasonBlevins

This bug is done, all issues are fixed. --Joey

Posted Sun 16 Mar 2008 12:27:58 JEST Tags: