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

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

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

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

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

The git commit (in my openid branch) says it all:

Update IkiWiki::openiduser to work with Net::OpenID 2.x

openiduser previously used a constructor that no longer works in 2.x.
However, all we actually want is the (undocumented) DisplayOfURL function
that is invoked by the display method, so try to use that.

This bug affects ikiwiki.info (my commits show up in RecentChanges as http://smcv.pseudorandom.co.uk/ rather than smcv [pseudorandom.co.uk]).

Cherry picked, thanks. --Joey

Relatedly, the other commit on the same branch would be nice to have (edited to add: I've now moved it, and its discussion, to pretty-print OpenIDs even if not enabled). --smcv

RecentChanges should not link to pages that are being deleted. For as example, see the change with the title 'add news item for ikiwiki 2.60' which includes the deletion of "news/version 2.52". Maybe it should be made clear in RecentChanges that the change to the file is it being deleted.

It needs to link to the deleted page so that you can recreate the page if desired.

The link is not of the normal form used for a link to a nonexistant page, instead it redirects through a CGI. This is done because updating the links would require rebuilding all change pages each time, which would be 100x as slow as the current method.

I don't feel that being 100 times faster at the expense of a marginally inconsistent, but still usable interface is a bug. --Joey done

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