Bug 7535

Summary: OPAC displays ampersands incorrectly.
Product: Koha Reporter: D Ruth Holloway <ruth>
Component: OPACAssignee: D Ruth Holloway <ruth>
Status: CLOSED FIXED QA Contact: Ian Walls <koha.sekjal>
Severity: minor    
Priority: P5 - low CC: paul.poulain, wizzyrea
Version: 3.8   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3326
Change sponsored?: --- Patch complexity: ---
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Proposed patch
[Signed Off] Bug 7535: ampersands not showing properly in non-XSLT OPAC

Description D Ruth Holloway 2012-02-13 15:24:08 UTC
In Bug 3326, Jared resolved the odd display of ampersands caused by Zebra's odd encoding of them for the OPAC, and XSLT display was fixed for the opac, but non-XSLT display still shows the oddity.  

Two-line patch coming momentarily, for both Master and 3.6.x, which both exhibit this behavior.
Comment 1 D Ruth Holloway 2012-02-13 15:28:02 UTC Comment hidden (obsolete)
Comment 2 D Ruth Holloway 2012-02-13 15:30:02 UTC
In my first note, I typed, still sleepily, "Jared resolved the odd display of ampersands caused by Zebra's odd encoding of them for the OPAC"

...that should be for the *staff client*, of course.
Comment 3 Liz Rea 2012-02-16 23:51:11 UTC
Created attachment 7706 [details] [review]
[Signed Off] Bug 7535: ampersands not showing properly in non-XSLT OPAC

Jared's fix for Bug 3326 fixed this in the staff client, but not the OPAC; moving this one line fixes it
both places.

Signed-off-by: Liz Rea <wizzyrea@gmail.com>
This can be replicated by indexing with -x
OPACXSLTResults must be set to "normally"
Reproduced original bug with rebuild-zebra.pl -x -b -w -r -v -v
Patch corrects the issue, does not change intranet behavior.
Comment 4 Paul Poulain 2012-02-21 15:45:30 UTC
QA comment: tiny patch, passed QA

Note that 
+    $data =~ s/\&amp\;amp\; /\&amp\; /g;
is not made in output_with_http_headers

It means that, if we don't output something *not* html, and the string replaced is present, it will be replaced, and that could be not what we're expecting.
Howver, the risk is less than tiny, so I accept this patch.
Comment 5 Jared Camins-Esakov 2012-12-31 00:39:36 UTC
There have been no further reports of problems so I am marking this bug resolved.