Bug 25483 - Url item field no longer accepts html tag
Summary: Url item field no longer accepts html tag
Status: RESOLVED DUPLICATE of bug 15352
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: 19.05
Hardware: All All
: P5 - low normal (vote)
Assignee: Owen Leonard
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-13 11:37 UTC by Marjorie Barry-Vila
Modified: 2020-05-20 12:50 UTC (History)
3 users (show)

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


Attachments
1805 url item opac view (138.10 KB, image/png)
2020-05-13 11:37 UTC, Marjorie Barry-Vila
Details
1905 url item view (220.87 KB, image/png)
2020-05-13 11:38 UTC, Marjorie Barry-Vila
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marjorie Barry-Vila 2020-05-13 11:37:43 UTC
Created attachment 104838 [details]
1805 url item opac view

Hi,

In 19.05.04, url item field no longer accepts html tag.

Currently, this is not displaying correctly.

Like bug #23194?

Tested on 18.05 and it was correct.


Normal behavior of 19.05 ?

Regards,
Marjorie
Comment 1 Marjorie Barry-Vila 2020-05-13 11:38:13 UTC
Created attachment 104839 [details]
1905 url item view
Comment 2 Katrin Fischer 2020-05-13 11:58:42 UTC
Hi Marjorie, what did you enter/expect?
This field expects only a link and no HTML and will display as a link in OPAC automatically (so I think entering as HTML directly would probably create issues)
Comment 3 Marjorie Barry-Vila 2020-05-13 12:44:26 UTC
(In reply to Katrin Fischer from comment #2)
> Hi Marjorie, what did you enter/expect?
> This field expects only a link and no HTML and will display as a link in
> OPAC automatically (so I think entering as HTML directly would probably
> create issues)

Hi Katrin,

Here is a sample code
  <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a>

  I do not understand why it no longer works in version 19.05.

Marjorie
Comment 4 Jonathan Druart 2020-05-14 09:48:49 UTC
We expect $u to be the link of the resource, a link is made around the resource.

If you put your link directly in $u, you will have a link built automatically. Is not it what you want?
Comment 5 Marjorie Barry-Vila 2020-05-14 10:15:12 UTC
(In reply to Jonathan Druart from comment #4)
> We expect $u to be the link of the resource, a link is made around the
> resource.
> 
> If you put your link directly in $u, you will have a link built
> automatically. Is not it what you want?

Hi Jonathan,

Sometimes the url is very long and being able to register html tags allows you to see only a short text replacing the url.


Is there an existing parameter not to see the complete url in the url item field? As for the marc field 856$u and 856$y?

Marjorie
Comment 6 Jonathan Druart 2020-05-14 10:31:52 UTC
Salut Marjorie,

If you turn URLLinkText off, the "Link to resource" link will be displayed instead of the URL. I think it's what you are searching for.
Comment 7 Marjorie Barry-Vila 2020-05-14 10:52:17 UTC
(In reply to Jonathan Druart from comment #6)
> Salut Marjorie,
> 
> If you turn URLLinkText off, the "Link to resource" link will be displayed
> instead of the URL. I think it's what you are searching for.

URLLinkText is just for field 856 in biblio notice.

Description
If the 856 field does not have a subfield 3 or y defined, the OPAC will say ‘Click here to access online.^ If you would like the field to say something else enter that in this field.


My problem is for field 952$u (marc21).

This code put in 952$u works in 18.05 not in 19.05.

  <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a>

I do not understand why it no longer works.


Regards
Marjorie
Comment 8 Katrin Fischer 2020-05-14 20:46:18 UTC
I've tested in 17.11 and it works, but only 'by accident' because the browser ignores the very invalid HTML it creates:

<a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a>">  <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the resource</a></a>

The change on master is:

<a href="%3Ca%20href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'%3ELink%20to%20the%20resource%3C/a%3E">Link to resource</a>

We are now escaping the content entered in $u.

I feel we need a better, different way than adding HTML to this field to be able to specify a link text. Is there a separator we could use?

url | linktext ?
Comment 9 Marcel de Rooy 2020-05-15 06:05:47 UTC
(In reply to Katrin Fischer from comment #8)
> I've tested in 17.11 and it works, but only 'by accident' because the
> browser ignores the very invalid HTML it creates:
> 
> <a href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to
> the resource</a>">  <a
> href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/33191'>Link to the
> resource</a></a>
> 
> The change on master is:
> 
> <a
> href="%3Ca%20href='https://cve-grics-ca.proxy.collanaud.qc.ca/fr/1133/
> 33191'%3ELink%20to%20the%20resource%3C/a%3E">Link to resource</a>
> 
> We are now escaping the content entered in $u.
> 
> I feel we need a better, different way than adding HTML to this field to be
> able to specify a link text. Is there a separator we could use?
> 
> url | linktext ?

The one character you should absolutely NOT use is the pipe !
In item fields the pipe is the split character for repeatable subfields and this field is repeatable too.
Comment 10 Marcel de Rooy 2020-05-15 06:11:36 UTC
Apart from that, I think we should not allow html in a field called uri. A uri is what it is. And it is not html. We can render it as an html link and that would fail if we put html in this field.

So the question should probably be: Where do you expect this uri to be presented as a link while it does not?

The reference to bug 23194 is about public notes, a field with completely different content.
Comment 11 Katrin Fischer 2020-05-15 06:19:45 UTC
I think the other bug is relevant in that the 'fix' here would be to remove the filter again, but we'd still end up with wrong HTML and that is not a good solution, especially since not all browsers might be so lenient in parsing it. It was not intended to carry HTML.

Good point about the |. My general feeling is that markup should be avoided whenever possible in favor of structured data entry. Make entry easy as possible and use the software to do the formatting.

I think the issue here is not that you don't want it to appear as link some cases or that it doesn't, but that we have no way to configure a link text (see comment#5) or shorten very long URLs.
Comment 12 Marcel de Rooy 2020-05-15 06:49:15 UTC
(In reply to Katrin Fischer from comment #11)
> I think the issue here is not that you don't want it to appear as link some
> cases or that it doesn't, but that we have no way to configure a link text
> (see comment#5) or shorten very long URLs.

Which you could say, is actually a limitation of the MARC standard. Since our 952$u comes from 852$u. MARC does not allow you to define link text here.

The solution too provide a generic text (as in 856$u) is imo rather poor. Especially when we add multiple URIs in one field.

What you could do, is: add an item field urllinktext and provide a way to enter that field in the item editor somehow. It would live in items and not in MARC. But it could be used whenever we want to render an item URI.
Comment 13 Katrin Fischer 2020-05-15 09:07:28 UTC
(In reply to Marcel de Rooy from comment #12)
> (In reply to Katrin Fischer from comment #11)
> > I think the issue here is not that you don't want it to appear as link some
> > cases or that it doesn't, but that we have no way to configure a link text
> > (see comment#5) or shorten very long URLs.
> 
> Which you could say, is actually a limitation of the MARC standard. Since
> our 952$u comes from 852$u. MARC does not allow you to define link text here.
> 
> The solution too provide a generic text (as in 856$u) is imo rather poor.
> Especially when we add multiple URIs in one field.
> 
> What you could do, is: add an item field urllinktext and provide a way to
> enter that field in the item editor somehow. It would live in items and not
> in MARC. But it could be used whenever we want to render an item URI.

I think we go way beyond 852 in a lot of areas - which is also the problem: There are no more free subfields in Koha to use for this. And if you have repated $u you also get the issue of sequence. Btw - if we used MFHD (MARC for Holdings Data, we could have a full 856 there, so it's not really a limitation of the standard).

The item editor is not made to resort the item subfields and I also feel like that would not be a good solution and more error prone / harder to handle for catalogers.
Comment 14 David Cook 2020-05-17 23:40:38 UTC
(In reply to Katrin Fischer from comment #13)
> I think we go way beyond 852 in a lot of areas - which is also the problem:
> There are no more free subfields in Koha to use for this. And if you have
> repated $u you also get the issue of sequence. Btw - if we used MFHD (MARC
> for Holdings Data, we could have a full 856 there, so it's not really a
> limitation of the standard).
> 
> The item editor is not made to resort the item subfields and I also feel
> like that would not be a good solution and more error prone / harder to
> handle for catalogers.

Of course, I think the only reason we use the 952 for item/holdings data is because we forced Zebra (and to a lesser degree Elasticsearch) to use MARC.

Neither Zebra nor Elasticsearch actually require MARCXML, so another way forward is to have Koha Item Metadata that we create and use however we want. (We'd just need a MARC export for it for metadata exchange with other systems, and in that case we could leave off things like link text.)

A complicated avenue for sure, but it's an option.
Comment 15 David Cook 2020-05-17 23:42:17 UTC
(In reply to Jonathan Druart from comment #6)
> Salut Marjorie,
> 
> If you turn URLLinkText off, the "Link to resource" link will be displayed
> instead of the URL. I think it's what you are searching for.

Honestly, I think this is the answer though. I'd be inclined to mark this as resolved.
Comment 16 Marjorie Barry-Vila 2020-05-19 10:41:11 UTC
(In reply to David Cook from comment #15)
> (In reply to Jonathan Druart from comment #6)
> > Salut Marjorie,
> > 
> > If you turn URLLinkText off, the "Link to resource" link will be displayed
> > instead of the URL. I think it's what you are searching for.
> 
> Honestly, I think this is the answer though. I'd be inclined to mark this as
> resolved.

Hi David,

Leaving blank in  UrlLinkText system preference does not solve the problem for the 952 $u.
Unless I misunderstand when you say "If you turn URLLinkText off"

If the system preference worked for the 952 $u, that would be perfect, the links would not be visible either in the item, but only the text of the system preference and we could remove the html tags.


Marjorie
Comment 17 Katrin Fischer 2020-05-19 10:53:53 UTC
> If the system preference worked for the 952 $u, that would be perfect, the
> links would not be visible either in the item, but only the text of the
> system preference and we could remove the html tags.
> 
> 
> Marjorie

It will work with 20.05 - bug 15352
Comment 18 Marjorie Barry-Vila 2020-05-19 18:23:04 UTC
(In reply to Katrin Fischer from comment #17)
> > If the system preference worked for the 952 $u, that would be perfect, the
> > links would not be visible either in the item, but only the text of the
> > system preference and we could remove the html tags.
> > 
> > 
> > Marjorie
> 
> It will work with 20.05 - bug 15352

ok great! It's enough for me.

I think that the html tags should never have been in the 952$u  but our customers do not always do what they are told ...

I just wanted to understand the change in behavior between 18.05 and 19.05.

Now I understand (thanks to comment 8)

The bug can be marked as resolved for me

Marjorie
Comment 19 Jonathan Druart 2020-05-20 12:50:35 UTC

*** This bug has been marked as a duplicate of bug 15352 ***