po4a version 0.70 and newer appear to have changed the API enough that the IkiWiki po plugin is broken.

This was reported as a FTBFS bug in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072760

I think this patch is sufficient: https://salsa.debian.org/jmtd/ikiwiki/-/commit/65f13f08901806a3b458cd625369e27bf19722e0

— Jon, 2024-06-11

I've pushed a Debian package update with a slightly more involved patch:

https://salsa.debian.org/debian/ikiwiki/-/blob/debian/master/debian/patches/0001-Adjustments-for-po4a-0.7.0.patch?ref_type=heads

I'm unavailable for a couple of weeks so I'll let it "soak" in Debian before committing it here. — Jon, 2024-06-12

done.

I suffer from the occasional markdown glitches using branchable.

I've found that switching my own non-ikiwiki projects to https://github.com/jgm/CommonMark has helped sort them out for the most part.

ikiwiki does not implement Markdown on its own: it uses one of several third-party libraries, with the current recommendation being Discount. Out-of-process implementations like pandoc are not suitable to be the default for performance reasons.

There seems to be a Perl binding for libcmark at https://github.com/nwellnhof/perl-commonmark, but unfortunately its README points out that the libcmark API is not stable, which means libcmark and perl-commonmark would have to be upgraded in lockstep: this makes them awkward to deal with in Linux distributions. As a result I'm not going to look into this myself until there is a stable API for Commonmark available in Debian.

However, if you want to add optional Commonmark support to the mdwn plugin, I'd review a patch. --smcv

A very initial patch is here. There might be ikiwiki-to-commonmark option translation to do.

Patch: https://github.com/jmtd/ikiwiki/commit/c76eeac8152604ce3d7d1672fe404c8ee8ef2dd8

I'm starting to review outstanding IkiWiki patches, and this one was an early candidate because it's so trivial, but I have some questions to resolve.

1. In order of preference, I've inserted this after multimarkdown and Discount, but those are only enabled if they are explicitly selected; Commonmark is ahead of the remaining implementations that are checked for (Text::Markdown, Markdown, /usr/bin/markdown), and so if available, would take precedence. Is this reasonable?
2. Should one be able to explicitly force Commonmark, like one can with multimarkdown and Discount?
3. I'd not use gettext in the debug print now.
4. I need to double check why I've used -> instead of :: (thanks anarcat)
5. Per smcv's comment above, what's the status of the Commonmark library in Debian now?

— Jon, 2024-02-22

I'd say:

1. yes, new implementations should be deprioritised unless a strong rationale is given.
2. That would be great, but I wouldn't make that a blocker.
3. no opinion
4. nod
5. as far as I can tell from my magic script, neither libcmark or libperl-commonmark are packaged. There isn't even a WNPP bug. I do wonder if that's a criteria for inclusion though; I wouldn't keep code away merely because it's not in Debian. (What is our criterion, actually? I'd say "unit tests and integration in CI", but, while we have the former, we don't have the latter, and not having Debian package might make testing this harder.... )

-- anarcat

I tried this patch on Fedora 39 (which has perl-commonmark 0.290000 and libcmark 0.30.3 packaged), but immediately encountered a problem where all wikilinks and directives stopped working. [[foo]] in the source page becomes simply foo in the generated HTML, as if CommonMark ate the double brackets.

I don't have a different system to compare if it's specific to the Fedora packages. Did you face this problem?

-- j@ustink.org 2024-06-29

Embarrassingly, yes. I've just (re-)confirmed this with libcmark0.30.2 and libcommonmark-perl 0.310100-1. I should have a fix pushed tonight or Tomorrow. — Jon, 2025-09-12

done.

Building current master on debian stable:

   Failed test at t/po.t line 538.
#                   '<p>Tails takes <BD> hour to install</p>
# '
#     doesn't match '(?^usx:
#       .*
#       L'installation\sde\sTails\sdure\s<BD>\sheure
#       .*
# )'
# Looks like you failed 1 test of 126.
t/po.t .........................
Dubious, test returned 1 (wstat 256, 0x100)

The failing code comes from "t/po.t: add test for UTF-8 vs. po4a 0.58+"

It builds ok on debian unstable. --Joey

confirmed, specifically broken with po4a=0.69-1, works with po4a=0.73-2. I'll see if I can adjust the test so it works in both cases. — Jon, 2025-04-18

I've written a patch to resolve this. I've asked intrigeri if they can review it. — Jon, 2025-04-20

done. Thanks intrigeri for the review. I experimented with Debian's Salsa CI a little, and make test passes for current git master on both bookworm and sid runners. I plan to cut a new release before the Debian hard freeze. — Jon, 2025-04-28

I was just trying to get footnotes working on a blog post (strange usecase I suppose) and no matter what I did I wasn't able to get them to work. I tried both Discount and MultiMarkdown, looked at the code in the mdwn.pm file, etc. I finally narrowed it down to the issue being that I was trying to have the footnote definition and reference both inside the text=""" """ block of the !more directive. I haven't looked through the code for the more.pm yet to see why that is happening, but will do so and see if I can figure out a fix.

EDIT: this was my user error, turns out the footnote comment requires the : following the [^1] in order to work. i'll leave this here in case it helps someone in the future struggling with footnotes. - ?mare Jan 12 2025 18:15PDT

done — Jon, 2025-01-13

i was wondering, is there support for multiple references to the same footnote on a page? e.g., if i have text[^1] more text[^2] some more text[^1] and

[^1] ref 1

[^2] ref 2

the [^1] on some more text never gets turned into a link to the footnote, nor does a second section link get added to the end of the respective footnote. this is counter to the behavior in my markdown editor (not the most useful benchmark, i know). thanks - ?mare Jan 13 2025

This is all pretty transparent to IkiWiki; it depends on the back-end. Unfortunately neither Discount nor Multimarkdown seem to support this.

Someone could/should write an IkiWiki plugin to implement footnotes, independent of of the markdown backend (or even syntax plugin).

— Jon, 2025-01-16

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

The HTML5 "Details" tag would be perfect: https://www.w3schools.com/TAGS/tag_details.asp

example

here's an example

The above works for me on ikiwiki.info which does not have html5:1 so far as I can tell — Jon, 2020-04-21

Patch in my repo, branch more-backlinks-details-tag. (I must say this looks much nicer, IMHO) —Jon, 2020-10-07

I've refreshed that branch after exploring this a little more. The main problem I had with my previous solution (simply substituting the floating box for a details tag) was how to integrate the overflow links nicely with the normal ones. Since details is a block-level tag, by default it would begin on a line after the existing links, and I couldn't settle on something which looked particularly integrated. E.g.:

Links: Foo Bar Baz…

Continued:

Baz Bar Foo

I decided that, in the event the backlinks list overflowed, it made more sense to replace the whole list with a details tag, and keep all the links together. E.g.

Links:

Foo Bar Baz Baz Bar Foo

So that's what I've settled on. done. — Jon, 2024-11-19

Originally reported to Debian in 2009 at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=523701

IkiWiki generates form elements with charset attributes in a few places. The Debian bug pointed at the "add comment" form, but there are other instances.

charset is not a valid attribute for the form element in HTML(5). We probably want accept-charset, instead: https://html.spec.whatwg.org/multipage/forms.html#attr-form-accept-charset

The WHATWG spec page above suggests the only valid value for the attribute is UTF-8. Is it superfluous? Or does the presence of the attribute change browser behaviour?

— Jon, 2024-04-05

I don't think we should keep the attribute at all. According to MDN, it defaults to the page encoding, which seems fine to me, and much more reasonable than having to specify a (possibly different?!) charset everywhere... So I would just remove this. -- anarcat

Thanks for the info! I've removed it in the linked branch. — Jon, 2024-04-05

I've tested this out a little now and I think it's good to go. done. — Jon, 2024-04-06

Reported to Debian:

The latest upload of highlight effectively breaks any ikiwiki install using the highlight plugin, since the plugin crashes trying to run the searchDataDir() method.

The attached patch switches to calling initSearchDirectories, per upstream's migration guide. It seems to work on my site.

patch:

From: David Bremner <bremner@debian.org>
Date: Wed, 23 Aug 2023 14:54:34 -0300
Subject: Migrate highlight plugin to highlight 4.0

Highlight upstream has changed the API as of highlight 4.0
---
 IkiWiki/Plugin/highlight.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IkiWiki/Plugin/highlight.pm b/IkiWiki/Plugin/highlight.pm
index 04c554a..e70817b 100644
--- a/IkiWiki/Plugin/highlight.pm
+++ b/IkiWiki/Plugin/highlight.pm
@@ -54,7 +54,7 @@ sub checkconfig () {
    eval q{use highlight};
    if (highlight::DataDir->can('new')) {
        $data_dir=new highlight::DataDir();
-       $data_dir->searchDataDir("");
+       $data_dir->initSearchDirectories("");
    } else {
        $data_dir=undef;
    }

This patch is safe for (at least) version 3.41 in Debian stable, (dating from 2017-12-09) which has both symbols. I think it's safe for inclusion in IkiWiki. — Jon, 2024-03-04

Ah wait, it's fixed in master, with 9ea3f9dfe7c0341f4e002b48728b8139293e19d0 which branches on the API major version, so should be safer for even older highlight versions. done. — Jon, 2024-03-04

With po4a 0.58+, the po plugin incorrectly extracts UTF-8 strings from source pages.

I've prepared a branch to fix this: https://gitlab.tails.boum.org/tails/ikiwiki/-/tree/po-fix-utf8

This branch adds a test case that fails on current master. That test case passes from my branch on Debian sid with po4a 0.55 (Buster), 0.62 (Bullseye), and 0.66 (sid).

Testing these patches on current master with po4a 0.69 and the second new test fails for me

not ok 126
#   Failed test at t/po.t line 533.
#                   '<p>Tails takes  hour to install</p>
# '
#     doesn't match '(?^usx:
#   .*
#   L'installation\sde\sTails\sdure\s\sheure
#   .*
# )'
1..126

I'm going to look at this a little closer as I'd like to merge it, perhaps I can resolve this problem. (existing test 119 fails for me on master, too) — Jon, 2024-03-06

Ah, wrong PERL5LIB. I've verified your new tests fail in master; pass in your branch rebased on current master and also pass on top of Buster's ikiwiki/po4a version. Since that's now oldoldstable, if this is the lower boundary of "works", I'm OK with that. Applied, thank you! done. — Jon, 2024-03-06

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

When the search plugin is enabled, with the options:

# search plugin
# path to the omega cgi program
omega_cgi: /usr/lib/cgi-bin/omega/omega
# use google site search rather than internal xapian index?
google_search: 0

Then we see the following error when editing a page from the web browser UI or running ikiwiki --rebuild:

Error: Exception: Db block overwritten - are there multiple writers?

The issue goes away when we disable the 'search' plugin.

We're running ikiwiki version 3.20180228-1.

Every time? I used to see an error (this one, I think) intermittently on OS X, on incremental rebuilds only. Haven't seen it in a while, though. Maybe something got fixed upstream. What OS, and what version of Xapian and Omega? (1.4.11 for me.) Maybe worth blowing away .ikiwiki/xapian/, as described in inside dot ikiwiki?

--schmonz

We've removed the .ikiwiki/xapian directory before performing a rebuild, including actually rebooting the host OS. The search appears to work for a while, but once the wiki has been live for a while (and subject to edits on the web interface), the issue reappears.

• OS: Ubuntu 18.04.2 LTS (GNU/Linux 4.15.0-47-generic x86_64)
• xapian-tools/bionic-updates,bionic-security,now 1.4.5-1ubuntu0.1 amd64
• xapian-omega/bionic,now 1.4.5-1 amd64

I've upgraded our installations of both Xapian components and will let you know if that fixes it. -- jsewell

Updating appeared to fix it. Sorry for not trying that sooner. Thanks for the help. -- jsewell

done. — Jon, 2024-03-25