recently fixed bugs
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 inmaster
; pass in your branch rebased on current master and also pass on top of Buster's ikiwiki/po4a version. Since that's nowoldoldstable
, if this is the lower boundary of "works", I'm OK with that. Applied, thank you! done. — Jon, 2024-03-06
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.
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
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.
This remains to be true now, with Epiphany 2.26.3 (Mozilla/5.0 (X11; U; Linux i686; en; rv:1.9.1.4pre) Gecko/20080528 Epiphany/2.22 Firefox/3.5). --Ivan Z.
In the most recent ikiwiki release, I added a Cache-Control hack explicitly to work around firefox's broken over-caching.
(When I tested epiphany and chromium, neither had firefox's problem.)
in ikiwiki instances that don't reside in the git root directory (the only ones i know of are ikiwiki itself), reverts show the wrong link in the recentchanges (for example, in the ikiwiki main repository's 4530430 and its revert, the main index page was edited, but the revert shows doc/index as a link).
the expected behavior is to compensate for the modified root directory (i.e., show index instead of doc/index).
This seems to work OK now - commit 84c4ca33 and its reversion both appear correctly in recentchanges. Looking at git history, Joey fixed this in commit 1b6c1895 before 3.20120203. --smcv
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.
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
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 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
The RecentChanges page is broken (doesn't show any history at all) when used with an empty svnpath in the ikiwiki.setup file.
Say you have the following configuration:
rcs => "svn",
svnrepo => "ssh+svn://foo.bar.com/wiki",
svnpath => "",
In the above, $svnpath need to be either empty or "/" - both trigger the 'next unless' check in IkiWiki/Rcs/svn.pm:rcs_recentchanges() as shown in the patch below, thus causing all files to be ignored for RecentChanges.
I can not see why this check is needed in the first place, so here's a patch for removing it
diff -upr ikiwiki-1.49.orig/IkiWiki/Rcs/svn.pm ikiwiki-1.49/IkiWiki/Rcs/svn.pm
--- ikiwiki-1.49.orig/IkiWiki/Rcs/svn.pm Mon Apr 16 15:15:09 2007
+++ ikiwiki-1.49/IkiWiki/Rcs/svn.pm Mon Apr 16 15:15:47 2007
@@ -176,7 +176,6 @@ sub rcs_recentchanges ($) {
}
foreach (keys %{$logentry->{paths}}) {
- next unless /^\/\Q$config{svnpath}\E\/([^ ]+)(?:$|\s)/;
my $file=$1;
my $diffurl=$config{diffurl};
$diffurl=~s/\[\[file\]\]/$file/g;
It's necessary for wikis, such as this one, that keep other things in the same svn repository. Bug fixed. --Joey