Bug 30568

Summary: Make patron name fields more flexible
Product: Koha Reporter: Martin Renvoize (ashimema) <martin.renvoize>
Component: PatronsAssignee: Nick Clemens (kidclamp) <nick>
Status: Pushed to main --- QA Contact: Martin Renvoize (ashimema) <martin.renvoize>
Severity: enhancement    
Priority: P5 - low CC: andrew, anni.maki-mantila, blawlor, gmcharlt, hattara, hebah, holly, jonathan.druart, kyle, lucas, mteal, nick, sally.healey, sbcornell
Version: Main   
Hardware: All   
OS: All   
See Also: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28633
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26146
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21978
GIT URL: Initiative type: ---
Sponsorship status: --- Crowdfunding goal: 0
Patch complexity: --- Documentation contact:
Documentation submission: Text to go in the release notes:
Version(s) released in:
25.11.00
Circulation function:
Bug Depends on: 30617    
Bug Blocks: 7680    
Attachments: Bug 30568: Add classes to patron title components
Bug 30568: Add classes to name components in OPAC
Bug 30568: Add classes to component name parts in intranet
Bug 30568: Add classes to name components in OPAC
Bug 30568: Add classes to component name parts in intranet
Bug 30568: Add classes to name components in OPAC
Bug 30568: Add classes to component name parts in intranet
Bug 30568: Add classes to component name parts in intranet
Bug 30568: Add classes to name components in OPAC
Bug 30568: Add classes to component name parts in intranet
Bug 30568: Add classes to name components in OPAC
Bug 30568: Add maybe_span to opac patron-title
Bug 30568: Add maybe_span to opac patron-title
Bug 30568: Correct reference to patron_title in patron-title.inc
Bug 30568: Add classes to component name parts in intranet
Bug 30568: Add classes to name components in OPAC
Bug 30568: Add maybe_span to opac patron-title
Bug 30568: Correct reference to patron_title in patron-title.inc
Bug 30568: Add classes to component name parts in intranet
Bug 30568: Add classes to name components in OPAC
Bug 30568: Add maybe_span to opac patron-title
Bug 30568: Correct reference to patron_title in patron-title.inc
Bug 30568: (QA follow-up) Don't double filter content in wrapper

Description Martin Renvoize (ashimema) 2022-04-20 08:47:42 UTC
We've had a number of bugs around patron name fields..

* Requests for additional fields
* Requests for changes in display order
* Requests for improved duplicate finding
* Requests for improved table sorting

I intend to collect opinions here and try to come up with a solution that suits more options.
Comment 1 Martin Renvoize (ashimema) 2022-04-20 09:01:25 UTC
In bug 21978 comment 9 Christopher Brannon suggests

>What if we could just get away from the name structures, and have 5 or 6 generic >name fields (i.e. Name1, Name2, Name3 etc.), and we can label them in the editor >for whatever purpose we need, and on screens they appear in the order that they >are used.  For example, Name1 is used as Surname, Name2 is First Name, Name3 is >Middle Name, and so on.  Sort will always sort in order of the fields (Name1 >first, Name2 next, and so on), and would display similar to how they appear now:
>
>In results:
>Name1, Name2 [Name3] [Name4] [Name5] [Name6]
>
>On patron account:
>Name2 [Name3] [Name4] [Name5] [Name6] Name1
>

I think this approach could work well, but it needs a little thought as to how it would work with de-duplicating and sorting and we may still need to implement display templating on top as currently you can call the patron-title include with various options for different displays in different places.

I wonder if we could refine our display to a couple of more formal options.. 'short' and 'long' form perhaps.. right now we have various combinations of options in the template.. like including title or not, othernames, inverse ordering, cardnumber, linking.. etc etc
Comment 2 Martin Renvoize (ashimema) 2022-04-20 09:26:30 UTC
patron-title.inc currently allows for the following output formats

* surname (othernames)
* <span class="patron-title">title</span> surname, firstname (othernames) 
* <span class="patron-title">title</span> firtname (othernames) surname
* title surname, firstname (othernames)
* title firstname (othernames) surname
* surname (othernames) (cardnumber)
* <span class="patron-title">title</span> surname, firstname (othernames) (cardnumber)
* <span class="patron-title">title</span> firtname (othernames) surname (cardnumber)
* title surname, firstname (othernames) (cardnumber)
* title firstname (othernames) surname (cardnumber)
* cardnumber
* <span>A patron from library [% Branches.GetName( patron.branchcode ) | html -%]</span>
Comment 3 Martin Renvoize (ashimema) 2022-04-27 06:56:03 UTC
*** Bug 24710 has been marked as a duplicate of this bug. ***
Comment 4 Martin Renvoize (ashimema) 2022-04-27 06:59:04 UTC
There was a try at doing this by surrounding name fields by spans, bug 24710, in the template includes, but it became clear that wasn't an option as the no_html option on the includes, used for title elements, precludes us from using said spans.
Comment 5 Katrin Fischer 2022-11-17 12:54:01 UTC
(In reply to Martin Renvoize from comment #2)
> patron-title.inc currently allows for the following output formats
> 
> * surname (othernames)
> * <span class="patron-title">title</span> surname, firstname (othernames) 
> * <span class="patron-title">title</span> firtname (othernames) surname
> * title surname, firstname (othernames)
> * title firstname (othernames) surname
> * surname (othernames) (cardnumber)
> * <span class="patron-title">title</span> surname, firstname (othernames)
> (cardnumber)
> * <span class="patron-title">title</span> firtname (othernames) surname
> (cardnumber)
> * title surname, firstname (othernames) (cardnumber)
> * title firstname (othernames) surname (cardnumber)
> * cardnumber
> * <span>A patron from library [% Branches.GetName( patron.branchcode ) |
> html -%]</span>

I like the idea of having clearer definitions on when to use what. 

Long, short, anonymous? 

The versions with span and without are for use in the title tag. 
And you'd probably still want title/no title. 

Probably would be nice to see how often each is used to see if we could replace one or another or if there is a good reason for them to be needed.
Comment 6 Sarah Cornell 2022-11-19 15:53:35 UTC
Here are some formats that would be appropriate for us:

firstname surname 

firstname (other names) surname

firstname (othernames) surname (cardnumber)


As I look at it now, we really just want to be able to output names in a variety of formats without the title.  (e.g. including "title" in the item status field in item detail.pl. is too much.)

We are also an outlier in that we have repurposed the title field for pronouns.  So this would also be desirable for us:

firstname surname (title)

I hope I'm answering the right question here.  ;)
Comment 7 Katrin Fischer 2022-11-19 18:07:52 UTC
Hi Sarah, thx for weighing in. Just a note: 22.11 will have 2 new fields: pronouns and middle name.  So you will be able to move from title to pronouns if you'd like.
Comment 8 holly 2024-08-26 21:44:03 UTC
Patron account display: 
It would be great if there were a way to hide particular name fields from patron account display pages. 
Example: A library uses "other name" for legal name when a patron goes by a different first name but the library needs to record the legal name as well. Currently, this displays as First (Other) Last. 
Staff only need to see first name and last name, out of respect for patron privacy and avoiding confusion. The library wants to hide the "other name" from all places where a patron name displays except for the account creation/editing screen. 
This could potentially be controlled with a system preference, something like "If using the Other Name field in patron records, show/hide Other Name."
Comment 9 Andrew Fuerste-Henry 2024-12-09 22:01:19 UTC
Created attachment 175338 [details] [review]
Bug 30568: Add classes to patron title components

to test:
1 - have a patron with data in firstname, surname, middle name, othernames, and preferred name
2 - view patron name in patron record and other places where patron.title is used, confirm lack of HTML markup
3 - apply patch, restart services
4 - reload patron record and other pages around Koha, confirm name display hasn't changed but the composite parts of the name are now marked with classes
Comment 10 Andrew Fuerste-Henry 2024-12-09 22:02:45 UTC
(In reply to Andrew Fuerste-Henry from comment #9)
> Created attachment 175338 [details] [review] [review]
> Bug 30568: Add classes to patron title components
> 
> to test:
> 1 - have a patron with data in firstname, surname, middle name, othernames,
> and preferred name
> 2 - view patron name in patron record and other places where patron.title is
> used, confirm lack of HTML markup
> 3 - apply patch, restart services
> 4 - reload patron record and other pages around Koha, confirm name display
> hasn't changed but the composite parts of the name are now marked with
> classes

I've only done the staff side here, though it shouldn't be hard to do the same on the OPAC. I've gone very minimal here, just inserting spans and classes around the different parts of the name. That should allow the local use of jQuery to further customize and reorder them all.
Comment 11 Andrew Fuerste-Henry 2024-12-10 14:03:28 UTC
Created attachment 175351 [details] [review]
Bug 30568: Add classes to name components in OPAC

To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected
Comment 12 Lucas Gass (lukeg) 2024-12-10 14:56:26 UTC
This breaks some strings where the no_html flag is passed. For example, go to the hold history for a patron with this applied and view the title element:

<title>Holds history for &lt;span class='preferred_name'&gt;Ronnie&lt;/span&gt; &lt;span class='surname'&gt;Ballard&lt;/span&gt; &lt;span class='cardnumber'&gt;(23529000139858)&lt;/span&gt; › Patrons › Koha</title>

It's attempting to pass in HTML when it shouldn't.
Comment 13 Andrew Fuerste-Henry 2024-12-10 18:30:42 UTC
Created attachment 175365 [details] [review]
Bug 30568: Add classes to component name parts in intranet

to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title
Comment 14 Andrew Fuerste-Henry 2024-12-10 18:32:25 UTC
(In reply to Lucas Gass (lukeg) from comment #12)
> This breaks some strings where the no_html flag is passed. For example, go
> to the hold history for a patron with this applied and view the title
> element:
> 
> <title>Holds history for &lt;span
> class='preferred_name'&gt;Ronnie&lt;/span&gt; &lt;span
> class='surname'&gt;Ballard&lt;/span&gt; &lt;span
> class='cardnumber'&gt;(23529000139858)&lt;/span&gt; › Patrons › Koha</title>
> 
> It's attempting to pass in HTML when it shouldn't.

Updated the intranet patch to account for no_html. It doesn't look like a comparable flag exists on the OPAC.

Here's the title of a hold history page without my patches:
<title>Holds history for Jim Andrew (Ace) Acevedo (23529000035676) &rsaquo; Patrons &rsaquo; Koha</title>

"&rsaquo; Patrons &rsaquo; Koha" seems to be there before my code.
Comment 15 Lucas Gass (lukeg) 2024-12-23 14:56:25 UTC
Created attachment 175910 [details] [review]
Bug 30568: Add classes to name components in OPAC

To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 16 Lucas Gass (lukeg) 2024-12-23 14:56:28 UTC
Created attachment 175911 [details] [review]
Bug 30568: Add classes to component name parts in intranet

to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 17 Lucas Gass (lukeg) 2025-09-16 17:58:27 UTC
Created attachment 186504 [details] [review]
Bug 30568: Add classes to name components in OPAC

To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 18 Lucas Gass (lukeg) 2025-09-16 17:58:30 UTC
Created attachment 186505 [details] [review]
Bug 30568: Add classes to component name parts in intranet

to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 19 Lucas Gass (lukeg) 2025-09-16 17:58:53 UTC
Rebased for current main
Comment 20 Brendan Lawlor 2025-09-29 19:18:29 UTC
As is this breaks links in the staff interface in the patron column of tables where patron-title.inc is included like the holds tab of a bib and the holds queue.

It looks like it's caused by a recent change in bug 38714 and the rebase.

Specifically starting at line 62:
[%- IF hide_patron_infos_if_needed AND ( display_patron_name OR display_cardnumber ) -%]
    [%- IF link_to == 'circulation_reserves' -%]
        <a href="/cgi-bin/koha/circ/circulation.pl?borrowernumber=[%- data.borrowernumber | uri -%]#reserves"> </a>
    [%- ELSIF link_to == 'circulation_recalls' -%]
        <a href="/cgi-bin/koha/circ/circulation.pl?borrowernumber=[%- data.borrowernumber | uri -%]#recalls"> </a>
    [%- ELSIF link_to == 'members_pay' -%]
        <a href="/cgi-bin/koha/members/pay.pl?borrowernumber=[%- patron.borrowernumber | uri -%]"> </a>
    [%- ELSE -%]
        <a href="/cgi-bin/koha/members/moremember.pl?borrowernumber=[%- data.borrowernumber | uri -%]"> </a>
    [%- END -%]
[%- END -%]

These are rendered as empty links now. Prior to bug 38714 these anchor tags were left open and at then closed at the end of patron-title.inc lke this:

    [%- IF hide_patron_infos_if_needed AND ( display_patron_name OR display_cardnumber ) -%]
        </a>
    [%- END -%]

I think it would be clearest now if that logic to wrap the display name in an anchor tag is brought inside [%- BLOCK display_patron_name -%]
Comment 21 Nick Clemens (kidclamp) 2025-10-03 18:14:08 UTC
Created attachment 187420 [details] [review]
Bug 30568: Add classes to component name parts in intranet

This patch adds a wrapper function in patron-title.inc that can be used to either span, or not if no html requested
It replaces the same concept that was used for patron title

to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title
5 - Check page titles, patron search, placing a hold, patron search and confirm different links and views work as before
Comment 22 Nick Clemens (kidclamp) 2025-10-03 18:14:12 UTC
Created attachment 187421 [details] [review]
Bug 30568: Add classes to name components in OPAC

To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Comment 23 Andrew Fuerste-Henry 2025-10-03 19:21:04 UTC
For all your ROYGBV testing needs:
.patron_title {
  color: red;
}
.preferred_name {
  color: orange;
}
.middle_name {
  color: yellow;
}
.othernames {
  color: green;
}
.surname {
  color: blue;
}
.patronpronouns {
  color: purple;
}
Comment 24 Brendan Lawlor 2025-10-03 20:11:26 UTC
Thanks for the patch Nick and testing CSS Andrew. This looks good to me.
Comment 25 Andrew Fuerste-Henry 2025-10-06 19:22:14 UTC
Created attachment 187494 [details] [review]
Bug 30568: Add classes to component name parts in intranet

This patch adds a wrapper function in patron-title.inc that can be used to either span, or not if no html requested
It replaces the same concept that was used for patron title

to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title
5 - Check page titles, patron search, placing a hold, patron search and confirm different links and views work as before

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Comment 26 Andrew Fuerste-Henry 2025-10-06 19:22:17 UTC
Created attachment 187495 [details] [review]
Bug 30568: Add classes to name components in OPAC

To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Comment 27 Jonathan Druart 2025-10-07 10:00:10 UTC
The second patch is adding HTML tags, it should depend on the "no_html" flag.

We need to use maybe_span for the OPAC as well.
Comment 28 Nick Clemens (kidclamp) 2025-10-09 13:18:20 UTC
Created attachment 187659 [details] [review]
Bug 30568: Add maybe_span to opac patron-title
Comment 29 Nick Clemens (kidclamp) 2025-10-09 13:21:03 UTC
Created attachment 187660 [details] [review]
Bug 30568: Add maybe_span to opac patron-title
Comment 30 Andrew Fuerste-Henry 2025-10-09 19:26:04 UTC
Created attachment 187704 [details] [review]
Bug 30568: Correct reference to patron_title in patron-title.inc

In the staff interface we set the class for the patron's title (Mr/Mrs/etc) to "patron_title," but we were making it "patron-title" in the OPAC. This patch standardizes them.
Comment 31 Andrew Fuerste-Henry 2025-10-10 14:53:54 UTC
Created attachment 187740 [details] [review]
Bug 30568: Add classes to component name parts in intranet

This patch adds a wrapper function in patron-title.inc that can be used to either span, or not if no html requested
It replaces the same concept that was used for patron title

to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title
5 - Check page titles, patron search, placing a hold, patron search and confirm different links and views work as before

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Comment 32 Andrew Fuerste-Henry 2025-10-10 14:53:57 UTC
Created attachment 187741 [details] [review]
Bug 30568: Add classes to name components in OPAC

To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Comment 33 Andrew Fuerste-Henry 2025-10-10 14:54:00 UTC
Created attachment 187742 [details] [review]
Bug 30568: Add maybe_span to opac patron-title

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Comment 34 Andrew Fuerste-Henry 2025-10-10 14:54:03 UTC
Created attachment 187743 [details] [review]
Bug 30568: Correct reference to patron_title in patron-title.inc

In the staff interface we set the class for the patron's title (Mr/Mrs/etc) to "patron_title," but we were making it "patron-title" in the OPAC. This patch standardizes them.

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Comment 35 Martin Renvoize (ashimema) 2025-10-13 07:07:49 UTC
Created attachment 187785 [details] [review]
Bug 30568: Add classes to component name parts in intranet

This patch adds a wrapper function in patron-title.inc that can be used to either span, or not if no html requested
It replaces the same concept that was used for patron title

to test:
1 - have a patron with all name parts
2 - load pages with a variety of name displays, confirm lack of classes
3 - apply patch
4 - reload pages from step 2, confirm there are now classes *except for where the name is called with no_html, like a page title
5 - Check page titles, patron search, placing a hold, patron search and confirm different links and views work as before

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 36 Martin Renvoize (ashimema) 2025-10-13 07:07:52 UTC
Created attachment 187786 [details] [review]
Bug 30568: Add classes to name components in OPAC

To test:
1- have a patron with values in all parts of name (firstname, preferred name, surname, othername, middlename)
2- log into OPAC as patron, observe where are how name is displayed, lack of classes on component parts
3- apply patch
4- reload OPAC pages, observe name looks the same but now has classes when inspected

Signed-off-by: Lucas Gass <lucas@bywatersolutions.com>
Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 37 Martin Renvoize (ashimema) 2025-10-13 07:07:55 UTC
Created attachment 187787 [details] [review]
Bug 30568: Add maybe_span to opac patron-title

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 38 Martin Renvoize (ashimema) 2025-10-13 07:07:58 UTC
Created attachment 187788 [details] [review]
Bug 30568: Correct reference to patron_title in patron-title.inc

In the staff interface we set the class for the patron's title (Mr/Mrs/etc) to "patron_title," but we were making it "patron-title" in the OPAC. This patch standardizes them.

Signed-off-by: Sam Sowanick <sam.sowanick@corvallisoregon.gov>
Signed-off-by: Martin Renvoize <martin.renvoize@openfifth.co.uk>
Comment 39 Jonathan Druart 2025-10-14 14:33:08 UTC
I would like to note that we have currently an interesting tree in the queue (under bug 40995) which improve the JS counterpart (patron-format). The inc file is moved to a standalone JS file, Cypress tests are added, and more places are using it.

I do understand that we want to make the display more flexible, but here we need to keep the 2 versions in sync: they have the same purpose. However we don't include html tags in the JS function yet (why?)

I don't want to block it, but keep in mind that you are not affecting all the occurrences, which introduces more inconsistencies IMO.

A better solution seems to have a new syspref to let libraries provide their desire format, you could pick patron's fields, and add punctuation.

The both (tt and js) versions of the code will use it.

Maybe for a follow-up bug?

Hope that makes sense!
Comment 40 Lucas Gass (lukeg) 2025-10-22 12:43:09 UTC
(In reply to Jonathan Druart from comment #39)
> I would like to note that we have currently an interesting tree in the queue
> (under bug 40995) which improve the JS counterpart (patron-format). The inc
> file is moved to a standalone JS file, Cypress tests are added, and more
> places are using it.
> 
> I do understand that we want to make the display more flexible, but here we
> need to keep the 2 versions in sync: they have the same purpose. However we
> don't include html tags in the JS function yet (why?)
> 
> I don't want to block it, but keep in mind that you are not affecting all
> the occurrences, which introduces more inconsistencies IMO.
> 
> A better solution seems to have a new syspref to let libraries provide their
> desire format, you could pick patron's fields, and add punctuation.
> 
> The both (tt and js) versions of the code will use it.
> 
> Maybe for a follow-up bug?
> 
> Hope that makes sense!

I have filed that follow-up:

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41069
Comment 41 Lucas Gass (lukeg) 2025-10-22 13:44:48 UTC
Nice work everyone!

Pushed to main for 25.11
Comment 42 Lucas Gass (lukeg) 2025-10-23 16:57:33 UTC
I believe this has broken a selenium test, t/db_dependent/selenium/patrons_search.t
Comment 43 Lucas Gass (lukeg) 2025-10-23 17:12:04 UTC
In the updated include it looks like you have:

[%- WRAPPER maybe_span field_name='preferred_name' -%][%- data.preferred_name | html %][% END -%]

and then:

[%- BLOCK maybe_span -%] 
    [%- IF no_html -%] 
        [%- content | html -%] 
    [%- ELSE -%] 
        <span class="[% field_name | html %]">[%- content | html -%]</span>
    [%- END -%] 
[%- END -%] 


Could using html filter 2x cause the encoding to be weird?
Comment 44 Lucas Gass (lukeg) 2025-10-23 17:31:18 UTC
Seems like removing one the html filters is what is needed, but the QA tools won't like that.
Comment 45 Nick Clemens (kidclamp) 2025-10-23 18:56:05 UTC
Created attachment 188391 [details] [review]
Bug 30568: (QA follow-up) Don't double filter content in wrapper
Comment 46 Lucas Gass (lukeg) 2025-10-23 20:06:42 UTC
follow-up pushed to main