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

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

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

The following error is displayed when trying to include a jpg image:

[[!img Error: failed to read filename.jpg: Exception 435: unable to open image 'jpeg:/path/to/source/folder/filename.jpg[0]': No such file or directory @ error/blob.c/OpenBlob/3569]]

I routinely include JPEGs via img. Can you share a) exactly the directive you've tried to use to generate that error and b), if possible, the source image? — Jon, 2023-12-05

marking done (invalid) for now, I think this is some kind of user-error. feel free to untag done if you return to this and answer my Q above. Thanks! — Jon, 2024-02-26

The pubdate attribute is not valid for modern HTML(5).

The h-entry microformat describes an alternative way to achieve the same thing: a dt-published class name.

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

—Jon, 2020-10-06

LGTM. In charset attribute on the script element is obsolete, I found that itemprop="datePublished" was another way to do this, but it seems like there is no real standard way to do this anymore, so I'm happy with anything that doesn't break validators. --anarcat, 2022-09-06

done. Thanks for the ACK — Jon, 2024-02-22

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