If a page has a discussion page, which is then removed, ikiwiki seems not to notice that the discussion page has gone away, and does not update the link to it in the action bar.

Reprocued with 2.5 --Joey

Looks to me like loadindex is populating %destsources with information that the old discussion page exists, which isn't invalidated when ikiwiki discovers that the page is gone. This leaves dangling links whenever any page is deleted, not just a discussion page. --Ethan

Here's a patch that trawls through %destsources deleting pages when they are found to be deleted. It's a little inelegant, but it's simple and it works. --Ethan

Thankyou for the patch! Done. --Joey

Hi there, I'm trying to remove the render blocking Javascript from the ikiwiki/branchable site https://developers.google.com/speed/pagespeed/insights/?url=http%3A%2F%2Fwebconverger.org%2F

I've tried disabling relativedate, toggle & even goodstuff, but STILL there is being JS embedded in my test site http://sg.webconverger.com/:

I am a bit at a loss now. Any ideas?

Can't help with the specific question but you won't get higher rating than 85 due to the local.css link.img.kalleswork.net pagespeed results -kjs

I'm fairly certain this was addressed by d16e34c736676256b7cd3ea12797313dc1332fc3. done. — Jon, 2024-03-25

recentchangesdiff causes rendering to segfault if a commit removes a lot of contents. I removed close to 400 files, total size of about 950Kb in a single commit and now ikiwiki segfaults on refresh and rebuild:

[...]
rendering recentchanges.mdwn
[1]    5541 segmentation fault  ikiwiki --verbose --setup ikiwiki.setup --refresh

If I disable the plugin, the segfault does not happen, but I have to remove wc/recentchanges/* or else it will crash just as well.

This is reproducible, but I cannot provide the source code.

Can you provide a sanitised version of the source code? I've tried ikiwiki on some files that are just large, and cannot reproduce any problems, so it must be something in the specific file. (A perl bug is also clearly involved here.) --Joey

The tarball is at http://scratch.madduck.net/tmprecentchanges-segfault.tgz - unpack it in /tmp and chdir() to /tmp/cdt.taF18912, then run

ikiwiki --setup ikiwiki.setup
# segfaults
git checkout HEAD^
ikiwiki --setup ikiwiki.setup
# segfaults
rm -rf wc/recentchanges
ikiwiki --setup ikiwiki.setup
# works

I can reproduce it fine with that, thanks, and it's really looking like a pure perl bug, that is triggered by markdown. Here's a simpler test case:

joey@kodama:/tmp>markdown < f
zsh: segmentation fault  markdown < f

Where f is a 6.3 mb file that I extracted from ikiwiki's rendering pipeline.

It seems to be crashing at markdown line 345, which is a big nasty s/// statement.

The good news: markdown version 1.0.2~b8-2 does not trigger this perl bug. I only see it with 1.0.1. (Bad news: Newer versions of markdown are slooooooow, especially on such large files.)

I'm calling this done since I've filed Debian bug #470676 on perl, and also have modified recentchangesdiff to only show the first 200 lines of diff, which should be enough without bloating the recentchanges into perl-crashing territory. --Joey

The ability to post comments depends on several factors:

• comments_pagespec controls whether comments on a particular page will be displayed
• comments_closed_pagespec controls whether comments on a particular page are allowed
• the check_canedit call controls whether comments are allowed for a particular combination of page and user

If check_canedit says that a user can post a comment (in particular, if opendiscussion is enabled or lockedit is disabled or permissive), and comments_closed_pagespec does not contradict it, then users who construct a do=comment CGI URL manually can post comments that will not be displayed. I don't think this is a security flaw as such, which is why I'm not reporting it privately, but it violates least-astonishment.

My ready/comments branch fixes this, by changing the test at submission time from (pseudocode)

!comments_closed_pagespec && check_canedit

to

comments_pagespec && !comments_closed_pagespec && check_canedit

--smcv

merged --smcv

I've just noticed that attachment plugin escapes the underscore characters in attached filenames. For example, when I wanted to add foo_bar_baz.txt file, then Ikiwiki added file foo__95__bar__95__baz.txt to my Subversion repo. I hope that the filename is terribly ugly not only for me

Is it a bug or security feature? --Paweł

Update: It's not only problem with attached filenames. I have mysql/myisam_vs_ndb.mdwn page in my wiki and attached two images (myisam_vs_ndb_sql.png and myisam_vs_ndb_cpu.png) and one OpenDocument file (myisam_vs_ndb.ods). Ikiwiki placed them into myisam__95__vs__95__ndb subdirectory as myisam__95__vs__95__ndb__95__sql.png, myisam__95__vs__95__ndb__95__cpu.png and myisam__95__vs__95__ndb.ods files. When I click "Attachments" link, I can't see my uploaded files, because there are in another subdirectory (myisam__95__vs__95__ndb instead of myisam_vs_ndb). --Paweł

done, uses linkpage now.

It's seems that now Ikiwiki doesn't escape the filenames with underscore(s). Thank you very much for the fast fix! --Paweł

Versions 2.0 and 2.1 of ikiwiki, and I think earlier versions as well, allowed wiki links to have spaces in the link text. For example, [[!ikiwiki logo page|logo]] should create an anchor tag referencing the logo page, and [[!ikiwiki logo|logo/ikiwiki.png]] should create an image tag referencing the logo.

As of version 2.2, this no longer works. I think the pattern [[...|...]] should allow spaces before the pipe. I suspect this is the same problem as reported in discussion.

The above examples are ambiguous, only worked due to a bug, and were never documented to work. So I'm not inclined to re-add support for them.

If you look at WikiLink, it is clear that spaces cannot be used in WikiLinks. It also shows how to use underscores in the link text if you want multiple words.

This was a decision I made a long time ago due to the ambiguity between a WikiLink and a Directive. Is "[[foo bar|baz]]" a wikilink to baz with a link text of "foo bar", or an instance of preprocessor directive "foo" with a parameter of "bar|baz"? If it's interpreted as a wikilink today, that could change tomorrow if a new preprocessor directive is added.

Before version 2.2, ikiwiki actually first treated it as a preprocessor directive. If that failed, it output the preprocessor directive back onto the page, and next the wikilink code tried treating it as a wikilink. In 2.2, I fixed several problems with the way an unhandled preprocessor directive was re-output onto the page, by prefixing it with a '\' ... which makes it not be treated as a WikiLink.

If WikiLinks had ever been documented to work with spaces in them, then I'd feel I needed to support the pre 2.2 behavior, but I don't feel that I have to support old behavior that was never documented and happened due to a bug, so I current have no plans to bring the old behavior back. --Joey

I agree that the grammar should be unambiguous. It seems to me that the problem with spaces-in-wikilinks is caused by overloading the wikilink and preprocessor syntax to use the same symbols. If they didn't (and is there much advantage in them using the same symbols? I know in some cases you have something which is a wikilink and a preprocessor directive, but how often?) there'd be no problem with spaces.

If there was ever a future, syntax-breaking major release of ikiwiki (similar to python3000) I'd like to see this fixed as part of that. --Jon

You can enable prefix_directives and get the disambiguated behavior and spaces in wikilinks today. It will become the default in 3.0. --Joey

done

The po plugin systematically overrides the title of the homepage with the wikiname. This prevents explicitly changing it with a meta directive. It should rather check whether it was overridden before setting it back.

Here is a simple patch for that:

diff --git a/Plugin/po.pm b/Plugin/po.pm
index 6395ebd..a048c6a 100644
--- a/Plugin/po.pm
+++ b/Plugin/po.pm
@@ -333,7 +333,7 @@ sub pagetemplate (@) {
            && $masterpage eq "index") {
                $template->param('parentlinks' => []);
        }
-       if (ishomepage($page) && $template->query(name => "title")) {
+       if (ishomepage($page) && $template->query(name => "title") && !$template->query(name => "title_overridden")) {
                $template->param(title => $config{wikiname});
        }
 }

Thanks.

I fixed this patch a bit and applied it to my po branch, thanks (commit 406485917).

But... a bug (probably in HTML::Template) prevents this theoretically correct solution to actually work. Setting a parameter that does not appear in the template, such as title_overridden, is not working on my install: the value does not seem to be stored anywhere, and when accessing it later using $template->param('title_overridden') it is always undef. Adding <TMPL_IF TMPL_VAR TITLE_OVERRIDDEN></TMPL_IF> in page.tmpl is a working, but ugly workaround.

I am nevertheless in favour of merging the fix into ikiwiki. We'll then need to find how to find the remaining (smaller) bug so that this code can actually work.

I'd like others to test my po branch and see if they can reproduce the bug I am talking of.

--intrigeri

Commit 406485917 looks fine to me, FWIW --smcv

I tracked the HTML::Template bug (or missing documentation?) a bit more. This lead to commit b2a2246ba in my po branch, that enables HTML::Template's parent_global_vars option which makes title_overridden work.

OTOH I feel this workaround is a bit ugly as this option is not documented. IMHO being forced to use it reveals a bug in HTML::Template. I reported this: https://rt.cpan.org/Public/Bug/Display.html?id=64158.

But still, I think we need to apply the workaround as HTML::Template's author has not updated any dist on CPAN for more than one year. --intrigeri

All merged, done. --Joey

During ikiwiki make phase the rst process hangs:
ps output
gdb backtrace 1
gdb backtrace 1

working with python 2.7
http://dpaste.com/0985A91
not working with python3.3~3.4
http://dpaste.com/0ACNK3W

Retitled this bug report since it seems to be specific to Python 3.

The rst plugin is probably more commonly used with Python 2. It seems likely that there is some Python-3-specific bug in proxy.py, perhaps introduced by commit 154c4ea "properly encode and decode from/to utf8 when sending rpc to ikiwiki".

I can reproduce this on Debian by installing python3-docutils and changing the first line of plugins/proxy.py, the first line of plugins/pythondemo, the first line of plugins/rst and the system() call in t/rst.t to use python3 instead of python. --smcv

looks like the problem is in proxy.py
ml = IkiWikiExtPluginXMLRPCHandler.read(in_fd).decode('utf8')

without decode('utf8') is working

That call was introduced to fix a bug under Python 2 so it cannot just be removed, but I've put a proposed branch on this related bug. --smcv

tested and fixed with patch http://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/38bd51bc1bab0cabd97dfe3cb598220a2c02550a and patch http://git.pseudorandom.co.uk/smcv/ikiwiki.git/commitdiff/81506fae8a6d5360f6d830b0e07190e60a7efd1c

done, pending release --smcv

If the timeformat option is '%c', every time websetup rewrites the setup file, it changes to a ddate-style time format (but if ddate is not actually enabled, some of the format codes aren't understood by strftime, so they get passed through).

Presumably this is because websetup loads all plugins, so IkiWiki::plugin::ddate::checkconfig is run...

(This bug seems oddly appropriate. Hail Eris)

done fnord

the recently introduced fixes for crashes in the python proxy even if disabled caused the typical python2 implicit conversion failures ("'ascii' codec can't...") on my debian sid system -- to fix it, i had to revert commit 154c4ea9e.

i did not dig down all the way to the xml / xmlrpc modules, but my impression is that some module changed its behavior between stable and sid and now generates unicode strings instead of str.

a patch to allow both versions by inspecting the types and en-/decoding on demand should work both for anarcat's and my case. i did not test the python3 version, but i'm pretty sure it was already broken after the abovementioned patch.

-- chrysn

update 2014-06-29: the problem persists, but i found it is not trivial to reproduce. to demonstrate, use this test plugin:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

from proxy import IkiWikiProcedureProxy

def preprocess(self, proxy, *args):
    return repr(self.rpc('pagetype', 'schön'))

proxy = IkiWikiProcedureProxy(__name__)
proxy.hook('preprocess', preprocess, id='testdirective')
proxy.run()

note that when the 'schön' is stored in a variable, the exception changes -- it seems to me that the issue is related to the way exceptions are encoded.

the suggested patch still applies and solves the issue. --chrysn

In this patch band:

-        xml = _IkiWikiExtPluginXMLRPCHandler._read(in_fd).decode('utf8')
+        response = _IkiWikiExtPluginXMLRPCHandler._read(in_fd)
+        if isinstance(response, unicode):
+            xml = response.encode('utf8')

I think you mean response.decode, not response.encode.

Other than that it looks good to me. I like the use of repr in debug messages. --smcv

afaict, encode is fine there -- the relevant methods in python2 are unicode.encode which gives a str, and str.decode which usually gives a unicode. (i'd happily ditch python2 and port all plugins to python3, where this is all easier, but my vCard rendering still uses an ancient module.) --chrysn

You were right about this, encode is appropriate to go from unicode to str under Python 2. However, Python 3 is still broken.

My ready/more-proxy-utf8-fail branch, based on yours, fixes the rst test when run under Python 3 and hopefully also fixes this one. Please check that it still fixes your test-case too.

Joey, I think this is ready for merge even if it doesn't fix chrysn's bug - it does fix Python 3 support in general. --smcv

merged --smcv