Prettydate creates strings like this: Last edited in the wee hours of Tuesday night, July 1st, 2009. However, July 1st is a Wednesday, so either date or Weekday should be modified. In the spirit is probably Tuesday night, June 30th. --ulrik

The default prettydate times are fairly idiosyncratic to how Joey thinks about time. Specifically, it's still Tuesday night until he wakes up Wednesday morning -- which could be in the afternoon. But, Joey also realizes that dates change despite his weird time sense, and so July 1st starts at midnight on Tuesday and continues through Tuesday night and part of Wednesday.

(This might not be as idiosyncratic as I make it out to be.. I think that many people would agree that in the wee hours of New Years Eve, when they're staggering home ahead of the burning daylight, the date is already January 1st.)

I think the bug here is that prettydate can't represent all views of time. While the times of day can be configured, and it's possible to configure it to call times after midnight "Wednesday morning, July 1st", it is not possible to configure the date or weekday based on the time of day.

In order to do so, prettydate's timetable would need to be extended to include the "%B %o, %Y" part, and that extended to include "%B-", "%o-", and "%Y-" to refer to the day before.

--Joey

fair enough, I think I can get converted to a warped time perspective. --ulrik

Example (from here):

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

gives:

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

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

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.

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

• If a site has multiple pages that aggregate, and they use the same name, one will win and get the global name, the other will claim it's working, but it's really showing what the other aggregated.
• If an aggregate directive is moved from page A to page B, and the wiki refreshed, aggregate does not realize the feed moved, and so it will keep aggregated pages under A/feed_name/*. To work around this bug, you have to delete A, refresh (maybe with --aggregate?), and then add B.

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?

It may be that I'm simply misunderstanding something, but what is the rationale for having tagged() also match normal wikilinks?

It simply hasn't been implemented yet -- see the answer in tag pagespec function. Tags and wikilinks share the same underlying implementation, although ab reasonable expectation is that they are kept separate. --Ivan Z.

The following situation. I have tagbase => 'tag'. On some pages, scattered over the whole wiki, I use [[!tag open_issue_gdb]] to declare that this page contains information about an open issue with GDB. Then, I have a page /tag/open_issues_gdb.mdwn that essentially contains [[!map pages="tagged(open_issue_gdb)"]]. So far, so good: this page indeed does list all pages that are tagged like this. But now, when I add in /gdb.mdwn a link to this page, like [[Open Issues|tag/open_issue_gdb]], then /gdb.mdwn itself shows up in the map on tag/open_issues_gdb.mdwn. In my understanding this is due to the wikilink being equal to a [[!tag ...]]. What's the rationale on this, or what am I doing wrong, and how to achieve what I want?

--tschwinge

What you are doing "wrong" is putting non-tag pages (i.e. /tag/open_issues_gdb.mdwn) under your tagbase. The rationale for implementing tag as it has been, I think, is one of simplicity and conciseness. -- Jon

No, he has no pages under tagbase that aren't tags. This bug is valid. matching different kinds of links is probably how it will eventually be solved. --Joey

And this is an illustration why a clean work-around (without changing the software) is not possible: while thinking about matching different kinds of links, I thought one could work around the problem by simply explicitly including the kind of the relation into the link target (like the tagbase in tags), and by having a separate page without the "tagbase" to link to when one wants simply to refer to the tag without tagging. But this won't work: one has to at least once refer to the real tag page if one wants to talk about it, and this reference will count as tagging (unwanted). --Ivan Z.

But well, perhaps there is a workaround without introducing different kinds of links. One could modify the tag plugin so that it adds 2 links to a page: for tagging -- tagbase/TAG, and for navigation -- tagdescription/TAG (displayed at the bottom). Then the tagdescription/TAG page would hold whatever list one wishes (with tagged(TAG) in the pagespec), and whenever one wants to merely refer to the tag, one should link to tagdescription/TAG--this link won't count as tagging. So, tagbase/TAG would become completely auxiliary (internal) link targets for ikiwiki, the users would edit or link to only tagdescription/TAG. --Ivan Z.

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

?smth with a pipe|about the \ ?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

I agree, browser handling of this CSS is often not good.

A toggle would be the perfect UI, but the heaviness of needing to include 30 lines of javascript to do it, plus then it only working with javascript enabled, is also not optimal.

Another idea would be to make the "..." a link to the ikiwiki cgi. The cgi could then have a mode that displays all the backlinks of a page in a list.

Yet another idea: Find some more refined CSS for handling a variable size popup.. --Joey

Error received when clicking on the "edit" link:

Error: [CGI::FormBuilder::AUTOLOAD] Fatal: Attempt to address non-existent field 'text' by name at /home/tealart/bin/share/perl/5.8.4/IkiWiki/CGI.pm line 112

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

Error: [CGI::FormBuilder::AUTOLOAD] Fatal: Attempt to address non-existent field 'param' by name at /home/tealart/bin/share/perl/5.8.4/IkiWiki/Plugin/editpage.pm line 122

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:

• Running on shared hosting (dreamhost; but everything compiles, dependencies installed, the site generates perfectly, other CGIs work, the file permissions work).

• It's running perl 5.8.4, but I did upgrade gettext to 0.17

• the server is running gcc v3.3.5 (at this point, this is the main difference between the working system and my box.)

• I've removed the locale declarations from both the config file and the environment variable.

• I've also modified the page template and have my templates in a non standard location. The wiki compiles fine, with the template, but might this be an issue? The CGI script doesn't (seem) to load under the new template, but I'm not sure how to address this issue.

• All of the required/suggested module dependencies are installed (finally) to the latest version including (relevantly) CGI::FormBuilder 3.0501.

• I'm running ikiwiki v3.08. Did I mention that it works perfectly in nearly every other way that I've managed to test thusfar?

---

I suspect that your perl is too old and is incompatible with the version of CGI::FormBuilder you have installed.

Is so, it seems likely that the same error message can be reproduced by running a simple command like this at the command line:

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

--Joey

nope, that command produces no output.

I considered downgrading CGI::FormBuilder but I saw evidence of previous versions being incompatible with ikiwiki so I decided against that.

-- tychoish

Some elements of HTML5 can be safely supported by ikiwiki. There are several differences between HTML4 and HTML5.

• HTML5 branch
• ikiwiki instance with HTML5 templates

HTML5 Validation and t/html.t

validator.nu is the authorative HTML5 validator, however it is almost impossible to sanely introduce as a build dependency because of its insane Java requirements. I test locally via cURL, though Debian packages cannot be built with a network dependency.

In the future, hopefully ikiwiki can test for valid HTML5 using Relax NG schema using a Debian package tool rnv.

HTML5 migration issues

article element

This element is poorly supported by browsers. As a workaround, style.css needs:

article {
    display: block;
}

Internet Explorer will display it as a block, though you can't seem to be further control the style.

Validator complains with no h1-h6 in header

• #509

Time element

The time element ideally needs the datatime= attribute set by a template variable with what HTML5 defines as a valid datetime string.

As a workaround:

au:~% grep timeformat natalian.setup
timeformat => '%Y-%m-%d',

Hi!

How about to replace sparkline-php from Suggests by a better alternative?

I would like to file a RM bug to get it out of archive. Do you have a better alternative for it? PHP has a lot of them..

Thanks

sparline-php is orphaned in Debian. Upstream, is has seen activity as recently as 11 months ago.

I don't know of a better alternative. I looked at the perl sparkline stuff in CPAN and is was bad enough that the pain of using php from this perl program was a better alternative.

Anyway, it works great; maintaining the sparkline-php package in Debian would certianly be much less work than finding some alternative and rewriting the ikiwiki code to use it, and packaging that alternative and maintaining it in Debian. So your suggestion doesn't make a lot of sense; Debian should just find a maintainer for sparkline-php. --Joey

When using the htmltidy plugin (and possibly in other circumstances), ikiwiki sometimes creates more </p> tags than <p> tags, causing unbalanced markup. I've previously noticed unbalanced tags when a [[!map ]] matches no pages. This is part of the reason I developed htmlbalance.

This is particularly noticeable if htmltidy is enabled when building the docwiki: on the 'contrib' plugin pages, the title becomes foo </p> (third-party plugin) (with the angle-brackets escaped - it seems the text gets sanitized but is then escaped anyway).

I believe that this snippet in IkiWiki.pm might be the reason for the imbalance:

    if ($oneline) {
            # hack to get rid of enclosing junk added by markdown
            # and other htmlizers
            $content=~s/^<p>//i;
            $content=~s/<\/p>$//i;
            chomp $content;
    }

The fact that HTML in a [[!meta title]] is added but then escaped might indicate that some other bug is involved.

At the moment, you go through the login shuffle and then are told that cookies are needed, so you lose all your data and login again. It would be much slicker to note by the edit link, or at least on the login page, that cookies are required.

Hmm, it seems to me to be fairly obvious, since the vast majority of websites that have a login require cookies. Such warnings used to be common, but few sites bother with them anymore. --Joey

Very few websites break without cookies. Even fewer lose data. Can ikiwiki avoid being below average by default? --MJR

Can we avoid engaging in hyperbole? (Hint: Your browser probably has a back button. Hint 2: A username/password does not count as "lost data". Hint 3: Now we're arguing, which is pointless.) --Joey

Even better would be to only display the cookie note as a warning if the login page doesn't receive a session cookie.

I considered doing this before, but it would require running the cgi once to attempt to set the cookie and then redirecting to the cgi a second time to check if it took, which is both complicated and probably would look bad.

Might this be possible client-side with javascript? A quick google suggests it is possible: http://www.javascriptkit.com/javatutors/cookiedetect.shtml. MJR, want to try adding that? -- Will

Best of all would be to use URL-based or hidden-field-based session tokens if cookies are not permitted.

This is not very doable since most of the pages the user browses are static pages in a static location.

The pages that lose data without cookies (the edit pages, primarily) don't look static. Are they really? --MJR

As soon as you post an edit page, you are back to a static website.

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.

SVG images can only be included via an <object>, <embed>, or <iframe> tag. Or, perhaps as inline SVG. The htmlscrubber strips all three tags since they can easily be used maliciously. If doing inline SVG, I'd worry that the svg file could be malformed and mess up the html, or even inject javascript. So, the only options seem to be only supporting svgs on wikis that do not sanitize their html, or assuming that svgs are trusted content and embedding them inline. None of which seem particularly palatable.

I suppose the other option would be converting the svg file to a static image (png). The img plugin could probably do that fairly simply. --Joey

I'm working on inline SVG and MathML support in ikiwiki and I've modified my htmlscrubber to sanitize SVG and MathML using the whitelists from html5lib. Here's a patch. I've also made some notes about this here: svg.

I suspect that this bug may have caught the eye of anyone interested in this sort of thing. I'll elaborate a bit on my user page to avoid getting off-topic here. --JasonBlevins, October 21, 2008

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

Yes, these need to be fixed. But note that the localised texts come back into ikiwiki and are used in various places, including plugins. Including, possibly, third-party plugins. So localising the buttons would seem to require converting from the translations back into the C locale when the form is posted. --Joey

Wouldn't it be more easy to change all calls to the corrects ones (including in plugins) ? For instance in the same file (CGI.pm): elsif ($form->submitted eq gettext("Save Page")) {. That way no conversion to the C locale is needed. gettext use should just be publicized in documentation (at least in write). --bbb

It would be easy, but it could break third-party plugins that hardcode the english strings. It's also probably less efficient to run gettext over and over. --Joey

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 ?

No, that's not a sane way to localise the templates. The templates can be translated by making a copy and modifying it, or by using a tool to generate .mo files from the templates, and generate translated templates from .po files. (See l10n for one attempt.) But pushing the localisation of random strings in the templates through the ikiwiki program defeats the purpose of having templates at all. --Joey

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

I have a commit doing

-[[map pages="link(tag/<TMPL_VAR name>) and !papers/*"]]
+[[map pages="link(sourcepage()) and !papers/*"]]

ikiwiki now fails to compile the site, barfing:

Use of uninitialized value in subroutine entry at /usr/share/perl5/IkiWiki.pm line 1288.
ikiwiki.setup: Can't use string ("") as a subroutine ref while "strict refs" in use at /usr/share/perl5/IkiWiki.pm line 1288.
BEGIN failed--compilation aborted at (eval 6) line 200.

after forcefully entering the Perl mode of thinking, I reduced this to line 1285 of IkiWiki.pm (2.53), which apparently returns undef:

my $sub=pagespec_translate($spec);

Why does it even bother parsing the diffs of recentchanges?

I have not recompiled this site in ages, so I am not sure when this problem was introduced, but it wasn't there when I worked on the site last about a year ago in September 2007.

-- madduck

I can't reproduce this problem. When I try, the generated recentchanges/change_$sha1._change file has the diff properly escaped, so that the map is not expanded at all.

I also tried de-escaping that, and still failed to reproduce any crash. The bogus pagespec simply expands to nothing. The line directly after the line you quoted checks for syntax errors in the pagespec translation eval and seems to be working fine:

joey@kodama:~>perl -e 'use IkiWiki; my $sub=IkiWiki::pagespec_translate("link(tag/) and !papers/*"); print "caught failure:".$@' caught failure:syntax error at (eval 14) line 1, near "|| &&"

Based on your line numbers, you are not running a current version of ikiwiki. (Doesn't quite seem to be version 2.53.x either) Try with a current version, and see if you can send me a source tree that can reproduce the problem? --Joey

If I create a page whose title contains an apostrophe, then inlining that page produces nothing. It looks like the inline plugin is failing to do the translation from apostrophe to _39_ that other parts of the system do, so although one can make wikilinks to such pages and have them detected as existing (for instance, by the conditional plugin), inline looks in the wrong place and doesn't see the page.

I can't reproduce that (btw, an apostrophe would be __39__) --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.

Removing 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

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.

I have perl 5.10.0. Ikiwiki 2.44 compiles fine. Compiling 2.45 fails after 'make':

perl -Iblib/lib   ikiwiki.out -libdir . -setup docwiki.setup -refresh
refreshing wiki..
docwiki.setup: Failed to load plugin IkiWiki::Plugin::goodstuff: Failed to load plugin IkiWiki::Plugin::shortcut: Too many arguments for IkiWiki::srcfile at IkiWiki/Plugin/shortcut.pm line 16, near "1)"
Compilation failed in require at (eval 31) line 2.
BEGIN failed--compilation aborted at (eval 31) line 2.
BEGIN failed--compilation aborted at (eval 23) line 2.
BEGIN failed--compilation aborted at (eval 10) line 21.
make: *** [extra_build] Error 255

I can't reproduce this. It looks like your IkiWiki.pm is out of sync with your IkiWiki/Plugin/shortcut.pm. The ones distributed in 2.45 are in sync. Or your perl is failing to use the right version of Ikiwiki.pm, perhaps using a previously installed version. But the -Iblib/lib instructs perl to look in that directory first, and the Makefile puts Ikiwiki.pm there. --Joey

I removed all traces of the previous installation, and now 2.45 compiles. I don't know why it was picking up the old version of Ikiwiki.pm, but now it works. Please close this bug, and thanks for the help.

Where were the files from the old installation? I still don't understand why they would be seen, since -Iblib/lib is passed to perl. --Joey

They were under /usr/local/{bin,lib,share}. I can try to provide more info, or try to reproduce it, if you need me to.

Well, here are some things to try.

perl -Iblib/lib -V

This should have blib/lib first in the listed @INC

joey@kodama:~/src/ikiwiki>strace perl -Iblib/lib -e 'use IkiWiki' 2>&1 |grep IkiWiki.pm
stat64("blib/lib/IkiWiki.pmc", 0xbfa1594c) = -1 ENOENT (No such file or directory)
stat64("blib/lib/IkiWiki.pm", {st_mode=S_IFREG|0444, st_size=31982, ...}) = 0
open("blib/lib/IkiWiki.pm", O_RDONLY|O_LARGEFILE) = 5

This is how perl finds IkiWiki.pm here. Note that I've run "make" first.

OK, this is what I'm getting:

$ perl -Iblib/lib -V
@INC:
blib/lib
/usr/lib/perl5/site_perl/5.10.0
/usr/share/perl5/site_perl/5.10.0
/usr/lib/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib/perl5/core_perl
/usr/share/perl5/core_perl
/usr/lib/perl5/current
/usr/lib/perl5/site_perl/current

I ran the following in my current 2.45 source dir, where the make already succeded. If you need it, I can post the output in the case where make fails.

$ strace perl -Iblib/lib -e 'use IkiWiki' 2>&1 |grep IkiWiki.pm
stat64("blib/lib/IkiWiki.pmc", 0xbfa6167c) = -1 ENOENT (No such file or directory)
stat64("blib/lib/IkiWiki.pm", {st_mode=S_IFREG|0444, st_size=31901, ...}) = 0
open("blib/lib/IkiWiki.pm", O_RDONLY|O_LARGEFILE) = 3

I need to see it in the case where it's failing. --Joey

I finally had some time to look into this again.

I wiped ikiwiki off my system, and then installed version 2.41. I tried installing 2.46 and get the same error as above, so I'll be using 2.46 below. (BTW, the debian page still lists 2.45 as current; I had to fiddle with the download link to get 2.46).

After running ./Makefile.PL I get:

$ perl -Iblib/lib -V
[bunch of lines snipped]
  @INC:
blib/lib
[bunch of paths snipped]

Running the strace:

$ strace perl -Iblib/lib -e 'use IkiWiki' 2>&1 |grep IkiWiki.pm

I get a bunch of ENOENTs and then at the end:

stat64("./IkiWiki.pmc", 0xbfa2fe5c)     = -1 ENOENT (No such file or directory)
stat64("./IkiWiki.pm", {st_mode=S_IFREG|0644, st_size=31987, ...}) = 0
open("./IkiWiki.pm", O_RDONLY|O_LARGEFILE) = 3

After running make (and having it fail as described above):

$ strace perl -Iblib/lib -e 'use IkiWiki' 2>&1 |grep IkiWiki.pm
stat64("blib/lib/IkiWiki.pmc", 0xbfd7999c) = -1 ENOENT (No such file or directory)
stat64("blib/lib/IkiWiki.pm", {st_mode=S_IFREG|0444, st_size=31901, ...}) = 0
open("blib/lib/IkiWiki.pm", O_RDONLY|O_LARGEFILE) = 3

I don't know what is going on, but I'll run any more tests you need me to.

No help.
The only further thing I can think to try is strace -f the entire failing make run (or the ikiwiki command that's failing in it, if you can reproduce the failure at the command line). --Joey

I have 2.46 installed and I can reproduce the bug reported against 2.49. The command that fails is:

$ /usr/bin/perl -Iblib/lib   ikiwiki.out -libdir . -setup docwiki.setup -refresh
docwiki.setup: Failed to load plugin IkiWiki::Plugin::inline: Too many arguments for IkiWiki::htmlize at IkiWiki/Plugin/inline.pm line 359, near "))"
Compilation failed in require at (eval 14) line 2.
BEGIN failed--compilation aborted at (eval 14) line 2.
BEGIN failed--compilation aborted at (eval 10) line 21.

strace -f produces a 112K file. I don't know enough to be comfortable analyzing it. However, lines like:

stat64("/usr/local/share/perl5/site_perl/5.10.0/IkiWiki.pm", {st_mode=S_IFREG|0444, st_size=31982, ...}) = 0

make me think the make process is not completely independent of a previous installation. Joey, should I email you the strace log file?

Email it (joey@ikiwiki.info), or post it to a website somewhere. --Joey

The relevant part of the file is:

execve("/usr/bin/perl", ["/usr/bin/perl", "-Iblib/lib", "ikiwiki.out", "-libdir", ".", "-setup", "docwiki.setup", "-refresh"], [/* 55 vars */]) = 0
[...]
stat64("blib/lib/5.10.0/i686-linux-thread-multi", 0xbfa72240) = -1 ENOENT (No such file or directory)
stat64("blib/lib/5.10.0", 0xbfa72240)   = -1 ENOENT (No such file or directory)
stat64("blib/lib/i686-linux-thread-multi", 0xbfa72240) = -1 ENOENT (No such file or directory)
[...]
stat64("/usr/local/share/perl5/site_perl/5.10.0/IkiWiki.pmc", 0xbfa71e5c) = -1 ENOENT (No such file or directory)
stat64("/usr/local/share/perl5/site_perl/5.10.0/IkiWiki.pm", {st_mode=S_IFREG|0444, st_size=31982, ...}) = 0
open("/usr/local/share/perl5/site_perl/5.10.0/IkiWiki.pm", O_RDONLY|O_LARGEFILE) = 4

So it doesn't look for IkiWiki.pm in blib at all. But it clearly has been asked to look in blib, since it looks for the 3 directories in it. When I run the same thing locally, I get:

execve("/usr/bin/perl", ["/usr/bin/perl", "-Iblib/lib", "ikiwiki.out", "-libdir", ".", "-setup", "docwiki.setup", "-refresh"], [/* 55 vars */]) = 0
[...]
stat64("blib/lib/5.10.0/i486-linux-gnu-thread-multi", 0xbf84f320) = -1 ENOENT (No such file or directory)
stat64("blib/lib/5.10.0", 0xbf84f320) = -1 ENOENT (No such file or directory)
stat64("blib/lib/i486-linux-gnu-thread-multi", 0xbf84f320) = -1 ENOENT (No such file or directory)
[...]
stat64("blib/lib/IkiWiki.pmc", 0xbf84ef4c) = -1 ENOENT (No such file or directory)
stat64("blib/lib/IkiWiki.pm", {st_mode=S_IFREG|0444, st_size=32204, ...}) = 0
open("blib/lib/IkiWiki.pm", O_RDONLY|O_LARGEFILE) = 6

The thing I really don't understand is why, on the system where perl fails to look in blib when straced as above, we've already established it does look for it when perl -Iblib/lib -e 'use IkiWiki' is straced.

The only differences between the two calls to perl seem to be: * One runs perl, and the other /usr/bin/perl -- are these really the same program? Does perl -lblib/lib ikiwiki.out -libdir . -setup docwiki.setup -refresh fail the same way as the /usr/bin/perl variant? * The -libdir ., which causes ikiwiki to modify @INC, adding "." to the front of it.

I'm entirely at a loss as to why I cannot reproduce this with the same versions of perl and ikiwiki as the two people who reported it. There must be something unusual about your systems that we have not figured out yet. --Joey

Joey, thanks for your time and effort looking into this.

I checked with which: perl is indeed /usr/bin/perl. The commands fail similarly when calling perl and /usr/bin/perl.

However, you might be into something with your libdir idea. If I remove it from the command line, the command succeeds. In other words, if I run

perl -Iblib/lib   ikiwiki.out -setup docwiki.setup -refresh

then it works perfectly.

Well, that's just weird, because libdir is handled by code in IkiWiki.pm. So I don't see how setting it could affect its searching for IkiWiki.pm at all, actually. It could only affect its searching for files loaded later. Anyway, can I get a strace of it succeeding this way?

Also, can you show me the first 15 lines of your ikiwiki.out? It's occurred to me you might have an unusual use lib line in it.

By the way, I'm running Arch linux. The perl build script is a bit long, but I see they install a patch to modify @INC: http://repos.archlinux.org/viewvc.cgi/perl/repos/core-i686/perl-5.10.0-archlinux-inc-order.patch?revision=1&view=markup

Would you suggest I try rebuilding perl without this patch? Debian has a huge perl patch (102K!); it's not straightforward for me to see if they do something similar to Arch.

I think Debian has a similar patch.

When you click on a broken link to create a new page, Ikiwiki lower-cases the new page's filename. I wish it wouldn't.

If I click on "Czars in Russia", I'd like Ikiwiki to create "Czars_in_Russia.mdwn", not "czars_in_russia.mdwn". Is this possible? --sabr

There's a simple patch that can do this:

-- a/IkiWiki.pm
+++ b/IkiWiki.pm
@@ -584,7 +584,7 @@ sub htmllink ($$$;@) {
            return "<span class=\"createlink\"><a href=\"".
                cgiurl(
                    do => "create",
-                   page => pagetitle(lc($link), 1),
+                   page => pagetitle($link, 1),
                    from => $lpage
                ).
                "\">?</a>$linktext</span>"

This is fine if you don't mind mixed or randomly cased filenames getting created. Otoh, if the link happened to start a sentence and so had its first letter upper-cased, that might not be desired.

Of course ikiwiki's case insensative, and there are other ways of creating pages that don't lower case them, including using the create a page form on a blog (as was done for this page..).

I'm undecided about making the above change by default though, or about making it a config option. Maybe it would be better to include both capitalisations in the select list that is used to pick the name for the newly created page. Then, which one is the default wouldn't much matter. (The non-lower cased one would probably be the best choice.) --Joey

Either of your proposed solutions (make it the default or include both in the pop-up menu) sounds fine to me. Which one is easier? --sabr

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

Does this patch against proxy.py help?

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

No, still the same failure. I think it's failing parsing the input data, (which perl probably transmitted as an int due to perl internals) not writing out its response. --Joey

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

Like this? (Existing code in aggregate.pm...) --Joey

# 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'll have to debug this, it's not working here... and this is an ikiwiki aggregator scraping another ikiwiki site.

Any news about this? --Joey

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

Ikiwiki calls rcs_add() if the page is new, followed by rcs_commit(). For mercurial, these run respectively hg add and hg commit. If the add or commit fails, it will print a warning to stderr, you might check apache's error.log to see if there's anything there. --Joey

The problem was using accented characters (é, í) on the change comments. I didn't have an UTF-8 locale enabled in my setup file. By coincidence this happened for the first time in a couple of consecutive blog posts, so I was mistaken about the root of the problem. I don't know if you will consider this behavior a bug, since it's strictly speaking a misconfiguration but it still causes ikiwiki's mercurial backend to fail. A quick note in the docs might be a good idea. For my part, please close this bug, and thanks for the help. --?buo

So, in a non-utf8 locale, mercurial fails to commit if the commit message contains utf8? --Joey

(Sorry for the delay, I was AFK for a while.) What I am seeing is this: in a non-utf8 locale, using mercurial "stand-alone" (no ikiwiki involved), mercurial fails to commit if the commit message has characters such as á. If the locale is utf8, mercurial works fine (this is with mercurial 1.0).

However, the part that seems a bit wrong to me, is this: even if my locale is utf8, I have to explicitly set a utf8 locale in the wiki's setup file, or the commit fails. It looks like ikiwiki is not using this machine's default locale, which is utf8. Also, I'm not getting any errors on apache's error log.

Wouldn't it make sense to use the machine's default locale if 'locale' is commented out in the setup file?

Ikiwiki wrappers only allow whitelisted environment variables through, and the locale environment variables are not included currently.

But that's not the whole story, because "machine's default locale" is not very well defined. For example, my laptop is a Debian system. It has a locale setting in /etc/environment (LANG="en_US.UTF-8"). But even if I start apache, making sure that LANG is set and exported in the environment, CGI scripts apache runs do not see LANG in their environment. (I notice that /etc/init.d/apache explocitly forces LANG=C. But CGI scripts don't see the C value either.) Apache simply does not propigate its runtime environment to CGI scripts, and this is probably to comply with the CGI specification (although it doesn't seem to completly rule out CGI's being passed other variables).

If mercurial needs a utf-8 locale, I guess the mercurial plugin needs to check if it's not in one, and do something sane (either fail earlier, or complain, or strip utf-8 out of comments). --Joey

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

Openid's security model does not rely on the openid consumer (ie, ikiwiki) performing any sanity checking of the openid server. All the security authentication goes on between your web browser and the openid server. This may involve ssl, or not.

Note that I'm not an openid expert, and the above may need to be taken with a grain of salt. I also can make no general statements about openid being secure. --Joey

For example, my openid is "http://joey.kitenet.net/". If I log in with this openid, ikiwiki connects to that http url to determine what openid server it uses, and then redirects my browser to the server (https://www.myopenid.com/server), which validates the user and redirects the browser back to ikiwiki with a flag set indicating that the openid was validated. At no point does ikiwiki need to verify that the https url is good. --Joey

Ok, so I guess the worst that could happen when ikiwiki talks to the http address is that it gets intercepted, and ikiwiki gets the wrong address. ikiwiki will then redirect the browser to the wrong address. An attacker could trick ikiwiki to redirect to their site which always validates the user and then redirects back to ikiwiki. The legitimate user may not even notice. That doesn't so seem secure to me...

All the attacker needs is access to the network somewhere between ikiwiki and http://joey.kitenet.net/ or the ability to inject false DNS host names for use by ikiwiki and the rest is simple.

-- Brian May

I guess that the place to add SSL cert checking would be in either LWPx::ParanoidAgent or Net::OpenID::Consumer. Adding it to ikiwiki itself, which is just a user of those libraries, doesn't seem right.

It's not particularly clear to me how a SSL cert can usefully be checked at this level, where there is no way to do anything but succeed, or fail; and where the extent of the check that can be done is that the SSL cert is issued by a trusted party and matches the domain name of the site being connected to. I also don't personally think that SSL certs are the right fix for DNS poisoning issues. --Joey

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 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 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 bug #129528.

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

Please get the patch from the *.mdwn source.

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

When searching in ikiwiki, sometimes discussion pages turn up. However, they are only titled "discussion". In order to know what topic they are discussing, you have to look at the URL. Shouldn't they be titled "foo/discussion" or "discussion of foo" or something? Thanks, --perolofsson

[[!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

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.

I never noticed this bug, since it only happens if the htmlscrubber is disabled. --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.

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

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.

This issue can arise in at least two ways:

1. 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.
2. 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/">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="http://ikiwiki.info/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

---

Has 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

I've now solved a similar bug involving the smiley plugin. The code used there should give some strong hints how to fix this bug, though I haven't tried to apply the method yet. --Joey

bug #487397

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

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

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

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?

See "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

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

---

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.

• Has 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..

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