Bug 25483

Created attachment 104839 [details]
1905 url item view

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)

(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

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?

(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

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.

(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

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 ?

(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.

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.

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.

(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.

(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.

(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.

(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.

(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

> 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

(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

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