Some librarians like to add HTML in the 5xx fields to display links, etc. We should allow $raw filters in this case.
Created attachment 91909 [details] [review] Bug 23412: HTML should be allowed in MARC notes. (5xx fields) TEST PLAN 1. Add some HTML to one of the 5xx fields that displays in the OPAC: <a href ="www.koha-community.org">koha</a> 2. Go to the record in the OPAC and look under the 'Title notes' tab. 3. See that the HTML displays literally. 4. Apply patch 5. Look at the 'Title notes' tab again. 6. HTML displays correctly
Created attachment 91936 [details] [review] Bug 23412: HTML should be allowed in MARC notes. (5xx fields) Signed-off-by: Maryse Simard <maryse.simard@inlibro.com>
What about regular use of chars like < and & in a note. Alice & Bob e.g. becomes now Alice $ Bob This might need a bit more thought?
(In reply to Marcel de Rooy from comment #3) > What about regular use of chars like < and & in a note. > Alice & Bob e.g. becomes now Alice $ Bob > > This might need a bit more thought? I've done some testing too, these were my 500$a: <a href ="http://www.koha-community.org">koha</a> http://www.koha-community.org Alice & Bob They all display nicely, with the second already being displayed as a link without the patch(!). So I don't see the breakage Marcel points out. But what breaks is: Berlin <Germany> With the browser hiding the part <Germany>. We often see this in older data as it used to be a common cataloguing practice. There are also other use cases for <> like mathematic formulas that we could break display with this change. Note: this also only changes the OPAC, but not the staff display.
I think we should use html_line_break filter like it used to be : to allow HTML and also present simple multi-lines text. Patch must cover staff and basket on MARCNOTES and notes. I'm on a patch and a nice test plan.
(In reply to Fridolin SOMERS from comment #5) > I think we should use html_line_break filter like it used to be : to allow > HTML and also present simple multi-lines text. > > Patch must cover staff and basket on MARCNOTES and notes. > > I'm on a patch and a nice test plan. Oups this is an old statement. I have no patch nor test plan. We should also fix staff interface no ?
I am still not sure we should bend the standard like that... especially as it will break things like the sample below with the <> as part of the text.
(In reply to Katrin Fischer from comment #7) > I am still not sure we should bend the standard like that... especially as > it will break things like the sample below with the <> as part of the text. I think you are correct and we should not bend the standard like this, marking this as wont fix.
(In reply to Lucas Gass from comment #8) > (In reply to Katrin Fischer from comment #7) > > I am still not sure we should bend the standard like that... especially as > > it will break things like the sample below with the <> as part of the text. > > I think you are correct and we should not bend the standard like this, > marking this as wont fix. I'm not sure I follow. Which standard would be bent by allowing HTML?
On the topic of standards, I think that this is my favourite MARC field: 887 - Non-MARC Information Field (R) https://www.loc.gov/marc/bibliographic/bd887.html I think it was probably intended for XML data outside the MARC schema, but I've seen some wild things in there before...
(In reply to David Cook from comment #10) > On the topic of standards, I think that this is my favourite MARC field: > > 887 - Non-MARC Information Field (R) > https://www.loc.gov/marc/bibliographic/bd887.html > > I think it was probably intended for XML data outside the MARC schema, but > I've seen some wild things in there before... Technically, I would say that XHTML is allowed in the 887 at least.
I think the problem is not the HTML so much as the expectation that it should render... and then it will be used for formatting, which is not a good mix usually - formatting and data.