Created attachment 82674 [details] Sample MARC record İf you dont add http:// or ftp:// in front of link pages in 856$u field, intranet webpage search result and detail page yields to connect localhost.
Created attachment 82675 [details] [review] Bug 21887: 856 link problem in XSLT result lists and detail page
Created attachment 82676 [details] [review] Bug 21887: 856 link problem in XSLT result lists and detail page Test plan; 1) Add web page link without http:// or ftp:// prefix in 856$u or use Sample Marc record 2) Search record from intranet web page and examine that link in online resources section shows localhost. 3) Apply this patch 4) Search similar record and test link is working correctly Signed-off-by: Devinim <kohadevinim@devinim.com.tr>
From LOC: $u - Uniform Resource Identifier Uniform Resource Identifier (URI), which provides standard syntax for locating an object using existing Internet protocols. Field 856 is structured to allow for the creation of a URL from the concatenation of other separate 856 subfields. Subfield $u may be used instead of those separate subfields or in addition to them. I am not sure if we fully comply with that currently (probably not). This does not either. But still looks good to me..
Created attachment 82677 [details] [review] Bug 21887: (For OPAC) 856 link problem in XSLT result lists and detail page Test plan (for OPAC); 1) Add web page link without http:// or ftp:// prefix in 856$u or use Sample Marc record 2) Search record from OPAC web page and examine that link in online resources section shows localhost. 3) Apply this patch 4) Search similar record and test link is working correctly
Comment on attachment 82677 [details] [review] Bug 21887: (For OPAC) 856 link problem in XSLT result lists and detail page Review of attachment 82677 [details] [review]: ----------------------------------------------------------------- ::: koha-tmpl/opac-tmpl/bootstrap/en/xslt/MARC21slim2OPACResults.xsl @@ +1078,5 @@ > <xsl:attribute name="href">/cgi-bin/koha/tracklinks.pl?uri=<xsl:value-of select="str:encode-uri(marc:subfield[@code='u'], true())"/>&biblionumber=<xsl:value-of select="$biblionumber"/></xsl:attribute> > </xsl:when> > <xsl:otherwise> > + <xsl:attribute name="href"> > + <xsl:if test="not(contains(marc:subfield[@code='u'],'://'))"> I could imagine malformed (yet functional) URLs could cause some problems here. Maybe you'd like to try out http://exslt.org/regexp/index.html to be more precise?
I think you could use starts-with instead as well: https://developer.mozilla.org/en-US/docs/Web/XPath/Functions/starts-with Although I suppose leading whitespace could cause a problem
Hi David, Can you share a sample for malformed but functional URL? Thanks.
(In reply to Devinim from comment #7) > Hi David, > Can you share a sample for malformed but functional URL? > Thanks. Sure, I was thinking something like "koha-community.org?redirect=http://other-site.org" That string would not be caught by this test: <xsl:if test="not(contains(marc:subfield[@code='u'],'://'))"> Apologies for my wording of "malformed but functional URL". What I meant was a a URL missing a scheme but containing an unencoded URL in the query string. Technically, the value of redirect should be encoded, but browsers will typically work with it anyway. If I put "koha-community.org?redirect=http://other-site.org" into a Chrome browser, it'll work. But according to your use case, it will try to connect to localhost.
(In reply to David Cook from comment #6) > I think you could use starts-with instead as well: > > https://developer.mozilla.org/en-US/docs/Web/XPath/Functions/starts-with > > Although I suppose leading whitespace could cause a problem starts-with cannot work the version of xslt we use in koha, am I correct?
Created attachment 90041 [details] [review] Bug 21887: 856 link problem in XSLT result lists and detail page Signed-off-by: Nazlı Çetin <nazli@devinim.com.tr> Signed-off-by: Liz Rea <wizzyrea@gmail.com> I don't think we need to worry about David's edge case. This improves the behaviour significantly.
Created attachment 90042 [details] [review] Bug 21887: (For OPAC) 856 link problem in XSLT result lists and detail page Signed-off-by: Liz Rea <wizzyrea@gmail.com>
Created attachment 90097 [details] [review] Bug 21887: 856 link problem in XSLT result lists and detail page Signed-off-by: Nazlı Çetin <nazli@devinim.com.tr> Signed-off-by: Liz Rea <wizzyrea@gmail.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
Created attachment 90098 [details] [review] Bug 21887: (For OPAC) 856 link problem in XSLT result lists and detail page Signed-off-by: Liz Rea <wizzyrea@gmail.com> Signed-off-by: Chris Cormack <chrisc@catalyst.net.nz>
(In reply to Devinim from comment #9) > > starts-with cannot work the version of xslt we use in koha, am I correct? starts-with should be part of XSLT 1.0, so it should be part of libxml used by Koha.
(In reply to Liz Rea from comment #10) > I don't think we need to worry about David's edge case. This improves the > behaviour significantly. No argument here. In the case I mentioned, I prefer to update the URL data in the database anyway.
I'd love to see a selenium test to cover this to repent future regressions... and do we need to submit corresponding bugs for Unimarc?
Nice work! Pushed to master for 19.11.00
Pushed to 19.05.x for 19.05.01
backported to 18.11.x for 18.11.07
Unfortunately this causes a regression with any relative links added by the opload feature no longer working: bug 23423