Bug 11741 - < > not displaying correctly in XSLT result list
Summary: < > not displaying correctly in XSLT result list
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal
Assignee: Katrin Fischer
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-11 08:31 UTC by Katrin Fischer
Modified: 2014-12-07 20:07 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 11741: Correct display of < > in XSLT result lists (1.39 KB, patch)
2014-02-11 15:56 UTC, Katrin Fischer
Details | Diff | Splinter Review
Bug 11741: Correct display of < > in XSLT result lists (1.75 KB, patch)
2014-02-25 13:49 UTC, Tomás Cohen Arazi (tcohen)
Details | Diff | Splinter Review
[PASSED QA] Bug 11741: Correct display of < > in XSLT result lists (1.83 KB, patch)
2014-03-11 12:58 UTC, Martin Renvoize (ashimema)
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2014-02-11 08:31:14 UTC
If you have a record, that contains < >, those are incorrectly escaped on the OPAC and staff XSLT result lists. The detail pages display correctly.

Example:
Record: Wer ist wer? <TEST>
Display: Wer ist wer? &lt;TEST&gt
HTML source: &amp;lt;TEST&amp;gt

It looks like a problem with the sequence of escaping characters. First < > are changed to HTML entities, then the apersand itself is changed, leaving us with a mix.

This was reported by one of our librares and seems to have changed between 3.6 and 3.12 as they were recently updated. The problem doesn't seem to appear on master. I couldn't test with 3.14 so far.
Comment 1 Katrin Fischer 2014-02-11 08:49:13 UTC
Hm, thinking more about it - I think it could also be a configuration/indexing problem. Needs more testing.
Comment 2 Katrin Fischer 2014-02-11 14:21:58 UTC
Ok, it's not related to the version actually - it's related to indexing:

rebuild_zebra.pl -x = broken display
rebuild_zebra.pl without -x = display ok

-x is the default on package installations.
Comment 3 Katrin Fischer 2014-02-11 15:56:51 UTC Comment hidden (obsolete)
Comment 4 Katrin Fischer 2014-02-11 15:58:04 UTC
I found a way to fix the display, but I am not totally persuaded this is a good solution - please comment :)
Comment 5 Mark Tompsett 2014-02-25 03:14:12 UTC
I think the patch is good, but I can't duplicate.
I added a record from z39.50, but tweaked the title to have >TEST<
I then did:
./misc/migration_tools/rebuild_zebra.pl -b -a -r -x -v
Then realized OOPS! 3.14.x not master.
git checkout -b bug_11741 origin/3.14.x
And then I tried to browse for the record
https://demo.library.kohasystem.ca/cgi-bin/koha/opac-detail.pl?biblionumber=...
And everything displayed nicely.
I then thought, "Oh wait! XSLT junk!"
So, I changed the OPACXSLTDetailsDisplay and OPACXSLTResultsDisplay to default.
And retried. Still looked okay.
Comment 6 Katrin Fischer 2014-02-25 08:11:27 UTC
I think Tomas tried to dig out the real problem, maybe he has an idea why reproducing the problem proved difficult?
Comment 7 Tomás Cohen Arazi (tcohen) 2014-02-25 13:23:53 UTC
(In reply to M. Tompsett from comment #5)
> I think the patch is good, but I can't duplicate.

You need to be in a GRS-1 setup to reproduce.
Comment 8 Tomás Cohen Arazi (tcohen) 2014-02-25 13:49:37 UTC Comment hidden (obsolete)
Comment 9 Martin Renvoize (ashimema) 2014-03-11 12:58:01 UTC
Created attachment 26106 [details] [review]
[PASSED QA] Bug 11741: Correct display of < > in XSLT result lists

< and > are incorrectly transformed into HTML entities on the
XSLT result list.

Example:
Record: <TEST>
Result list: &lt;TEST&gt
HTML source: &amp;lt;TEST&amp;gt

To test:
- catalog a record that contains > and <
- Reindex, without using the -x option
- Confirm the display is correct
- Reindex again, using the -x option
- Confirm the display is now broken
- Apply patch
- Reindex again with and without -x
- Verify that now the display is always correct

Signed-off-by: Tomas Cohen Arazi <tomascohen@gmail.com>
Note: the problem is only visible in GRS-1 setup. It works as expected.
No behaviour change in DOM.
I belive we shouldn't be (de)escaping data ad-hoc, but it seems that GRS-1
needs it because it doesn't handle HTML entities properly. This fix is OK for
GRS-1, unneeded for DOM and probably any other modern search engine.

Signed-off-by: Martin Renvoize <martin.renvoize@ptfs-europe.com>
Comment 10 Galen Charlton 2014-05-05 17:51:38 UTC
Pushed to master.  Thanks, Katrin!