Created attachment 91946 [details] Example markup Symptom: <span class="results_summary online_resources"> <span class="label">Online resources: </span><a property="url" href="http:///cgi-bin/koha/opac-retrieve-file.pl?id=f445180b2247beac068a3bdef750856b" target="_blank">PDF Views of <span class="term">Acca</span>, Haifa, Mt. Carmel and Other Places</a> | <a property="url" href="http:///cgi-bin/koha/opac-retrieve-file.pl?id=343848fcfdc5123bedf606f5b98110d6" target="_blank">PDF Views of <span class="term">Acca</span>, Haifa, Mt. Carmel and Other Places (Annotated Version)</a> </span> href is malformed: http:///cgi-bin/koha Cause ?? Looks like problem in XSLT (fragment from MARC21slim2OPACDetail.xsl) <xsl:if test="not(contains(marc:subfield[@code='u'],'://'))"> <xsl:choose> <xsl:when test="@ind1=7"> <xsl:value-of select="marc:subfield[@code='2']"/><xsl:text>://</xsl:text> </xsl:when> <xsl:when test="@ind1=1"> <xsl:text>ftp://</xsl:text> </xsl:when> <xsl:otherwise> <xsl:text>http://</xsl:text> </xsl:otherwise> </xsl:choose> Note these same resource links are correct in the opac search view. <span class="results_summary online_resources"> <span class="label">Online access: </span><a target="_blank" href="/cgi-bin/koha/opac-retrieve-file.pl?id=f445180b2247beac068a3bdef750856b">PDF Views of <span class="term">Acca</span>, Haifa, Mt. Carmel and Other Places</a> | <a target="_blank" href="/cgi-bin/koha/opac-retrieve-file.pl?id=343848fcfdc5123bedf606f5b98110d6">PDF Views of <span class="term">Acca</span>, Haifa, Mt. Carmel and Other Places (Annotated Version)</a> </span> If one explicitly adds the full path to the 856u URI these are correctly referenced in the resulting markup. Relative paths are not.
Could you share what your 856 looks like?
Created attachment 91947 [details] The corresponding MARC record and file browse dialog
The issue seems to be that the 856 tag expects a full URL. Does anyone know if the standard requires it?
I just tested on master and the link is broken for me everywhere: - OPAC detail and result pages - Staff detail and result pages I wanted to check the MARC standard... but: Some Library of Congress Websites Will Not Be Available August 9-11 But as it turns out... this is a regression caused by the recently added 21887. I am updating severity as this content is created by the file upload feature that is inbuilt into Koha. So we can expect a lot of those links broken now :(
Hi Steve, did you manually catalog the relativ URLs or were they added with a feature inbuilt to Koha? After some discussion on IRC and studying the MARC standard it looks like you should always use fully qualified URLs - also because MARC is thought for data exchange.
Hi Steve, Could you let me know how you created your 856$u links in the first place? It is my understanding that they really aught to be fully qualified and not relative (MARC is designed for sharing, so a relative URI isn't all that helpful in that case). When I tested the cataloguing tool to upload a file for attaching to a new record it populated the record with a fully qualified link including the opac base url. We still need to think about this use case, but that would certainly help shed some light on whether it's a practice in frequent use or not.
Hi Martin, the links are created with the cataloguing UI so nothing handcrafted. If one adds the OPACBaseURL then the MArc record includes that in the field. To be fair this problem reared its head because I did not originally set the opacbaseurl. If you change the opac base url or rename the host however the self originating links will be all broken. The relative URL's are to be preferred in these cases and to construct correct URI's at runtime.. But then you have the problem of these opac file retrieve URI's hard coded in MArc records which may become unusable at a point in the future. SO a multi pronged problem. How best to store 856u records when they are self-originating records How to then integrate the opacbaseurl into markup renders and marc record generation/export How to distinguish self from non self originating URL's in the 856u$ field. PResumably its not that difficult to update this record when the opac base url record evolves/changes and the URL contains a pattern like opac-retrieve-file. So there are work arounds.
When we first implemented Koha years ago we created 856$u fields with a placeholder of /libimage for the file location. For instance /libimage/some/path/to/the/file.pdf . The image files are located on a different apache instance. There is a redirect in the apache config like this: Redirect /libimage http://anotherapacheserver/imagefolder . This was done to facilitate moving the files to a different location. We can move the whole folder/file structure and just change the redirect in Apache to point to the right place. Since upgrading to 19.05.01 the links on the records no longer work. During the upgrade, I did have a server failure and had to move to another existing linux server where I duplicated all the apache configs. I only mention that because there was more than one thing going on at the time. All other Koha functions seem to be operating as expected. I am suspicious that the feature in this upgrade broke how things work though. Strangely, if you do a search in the OPAC and click on a link in the results, the link redirects correctly and the image is displayed. However if you open the record and click on the same link, you get an error that "libimage's server IP address could not be found". Same with the Staff client, except both the results page links and the in record links result in the error.
Following up, I was able to fix my redirect issue by creating custom xslt files for Staff Client results and details, and OPAC details. In all three of these I just commented out the If statement added by Bug 21887. I looked at the OPAC results xslt file and the code is in there, but doesn't seem to stop my Redirect directive in the Apache config from executing correctly. A workaround for now.
Is this still an issue?
If I understood correctly, the original issue has been fixed by setting correctly OPACBaseURL. Closing then. Please reopen if it's still valid.