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

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

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

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

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

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

<p></div></p>

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

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

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

See the validator output for more details.

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

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

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

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

--JasonBlevins

Thanks, applied that patch. --Joey

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

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

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

After deleting a page with the "remove" button, it seems that the page deletion cannot be reverted using the "revert" icon in RecentChanges. It ironically says that "Error: ?$pagename does not exist". See http://ikiwiki.info/ikiwiki.cgi?rev=860c2c84d98ea0a38a4f91dacef6d4e09f6e6c2e&do=revert. JeanPrivat

And it only gets that far if the remove plugin is enabled. Otherwise it complains that you cannot change $pagename.

The root bug is that git's rcs_preprevert creates a structure that shows the change that was made (which includes a file deletion), not the change that would be made if it was reverted (which includes a file addition). Fixed. --Joey