By default display XSL have : <!DOCTYPE stylesheet [<!ENTITY nbsp " " >]> Since Bug 23290 are replaced with nothing, mangling xsl style sheet output. Worse if nbsp is inside a xslt:text tag some (all?) xml parsers return an error with an empty output. Error: xsltParseTemplateContent: xslt:text content problem compilation error: file /home/koha/webdatas/public/XSLT/OPACResults.xsl element text xsltParseTemplateContent: xslt:text content problem at /home/koha/src/Koha/XSLT_Handler.pm line 343.
How do we recreate the problem? I do see the detail and result page, using the XSLTs. Default result XSLT file is: koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2intranetResults.xsl:<!DOCTYPE stylesheet [<!ENTITY nbsp " " >]>
Created attachment 104353 [details] XSLT patch with entity silently discarded
Created attachment 104354 [details] XSLT patch with parser error
Out of the box XSLT are fine, but upgrading Koha on a site with modified ones aren't, and because ENTITY is defined by default it's often used: Attached patches tested on 2020-05-05 master, Debian strech (it's a koha-testing-docker box) patch bad_output.txt: Online access: ---> Onlineaccess: no_output.txt: xsl parser error if notices have other title fields.
I think that I understand. Koha's XSLTS define <!ENTITY nbsp " " >, but the entity   is *not* actually used by any Koha XSLTs. It seems like Didier uses the   in custom spreadsheets, and that causes the problem. It seems to me that this is not a Koha issue. Rather, Didier should stop using the   entity. I'll open a report to remove the ENTITY declaration in the XSLTs, since it's unusable (and even problematic as Didier highlights) now.
Actually, Didier, what OS are you using and which XML parser? If I recall correctly, the default XML parser in Debian should never have expanded entities even before Bug 23290. I'm guessing you're not using defaults?
(In reply to David Cook from comment #6) > Actually, Didier, what OS are you using and which XML parser? > > If I recall correctly, the default XML parser in Debian should never have > expanded entities even before Bug 23290. I'm guessing you're not using > defaults? As far as I know plain Debian and Ubuntu. Adding unsafe works: <koha_xslt_security> <expand_entities_unsafe>1</expand_entities_unsafe> <koha_xslt_security> Or with 18.11 (prior commit Bug 23290)
Yes but it's not recommended, then you are vulnerable to what is described in bug 23290. The easiest seems to replace nsbp in your xsl files.
(In reply to Jonathan Druart from comment #8) > Yes but it's not recommended, then you are vulnerable to what is described > in bug 23290. The easiest seems to replace nsbp in your xsl files. I agree with Jonathan. I'd recommend not expanding entities as you'll create a security vulnerability in your installation. Just use   directly instead of .
I'd argue that we should mark this as "WON'T FIX".
(In reply to David Cook from comment #9) > (In reply to Jonathan Druart from comment #8) > > Yes but it's not recommended, then you are vulnerable to what is described > > in bug 23290. The easiest seems to replace nsbp in your xsl files. > > I agree with Jonathan. I'd recommend not expanding entities as you'll create > a security vulnerability in your installation. Just use   directly > instead of . Hi, WON'T FIX make sense. Are you going to remove ENTITY in xls or should I make a report? Removing [<!ENTITY nbsp " " >] and using   will do for us, thanks. No authority on XSTL files, libraries change them, moreover in french typography you add a space before many punctuation marks, like colon. Cf. (broken!) Koha french manual translation. https://koha-community.org/manual/18.05/fr/html/systempreferences.html BTW where do we fix this one? It's an eyesore :) Regards Didier
(In reply to didier from comment #11) > Hi, > WON'T FIX make sense. > > Are you going to remove ENTITY in xls or should I make a report? > I've already reported it as Bug 25381. I'm rather busy at the moment, so it would be great if someone else wrote the batch, but if they don't I will eventually. > Removing [<!ENTITY nbsp " " >] and using   will do for us, thanks. > Perfect :) > No authority on XSTL files, libraries change them, moreover in french > typography you add a space before many punctuation marks, like colon. Cf. > (broken!) Koha french manual translation. > https://koha-community.org/manual/18.05/fr/html/systempreferences.html > Ah, that's interesting. It's been many years since I've had to write in French, so I must have forgotten if I ever knew that heh. > BTW where do we fix this one? It's an eyesore :) > Honestly, I'm not 100% sure. I think the git repo can be viewed at http://git.koha-community.org/gitweb/?p=kohadocs.git;a=summary. It looks like this might be the translation file needed to change: http://git.koha-community.org/gitweb/?p=kohadocs.git;a=blob;f=locales/fr/LC_MESSAGES/systempreferences.po;h=90e7d11b50a945a9757c374adb96663054e1dadf;hb=HEAD I think you can use that git repo, and then open a "Documentation" issue on this Bugzilla. I think Caroline Cyr La Rose from inLibro might be the expert on that one these days.