Search highlighting affects OPAC title display

Bug #1752434 reported by Dan Wells on 2018-02-28
This bug affects 2 people
Affects Status Importance Assigned to Milestone

Bug Description

With the new search infrastructure, the way highlighting is turned on and off via different data paths leads to some display oddities. For example, in the Concerto set, do a search for 'gaiman', go in a record, then turn highlighting on/off. When highlighting is 'on', the page title is just the title, but when it is off, it reverts back to the complete 245 field. (Obviously this isn't particular to these records, but is actually likely to happen more often than not for most records.) I, for one, would be happy to finally jettison the pre-formatted silliness that is MARC field 245 (well, most of MARC, unfortunately), but to have it tied to the highlight state is a bit odd.

It seems like the impetus here is to make the 'title' be consistent from display down to index, which makes a ton of sense, but the good old 245 has a lot of history, so maybe we continue to treat "page title" (i.e. 245) as a special case, and as a slightly different thing from the "real title"? The other obvious option is to make the non-highlight display a closer match for the highlighted version so that the switch isn't as jarring.

Dan Wells (dbw2) on 2018-02-28
Changed in evergreen:
milestone: none → 3.1-rc
Mike Rylander (mrylander) wrote :

I was confused for a while ... the difference is that we're depending on the titleNonfiling XSLT template in the mods32 stylesheet (in stock) to pull out the title string when using the Display Field highlighting, which restricts the subfields to a, b, f, g, and k, while the previous mechanism used a rather big hammer of get_graphic_880s() defined in misc_util.tt2. There are other titles extracted elsewhere, but that one in particular is, indeed, "all of 245, minus e, w, 0, 4, 5, 6, 7, 8, and 9". While I could certainly see adding n and p to the titleNonfiling XSLT definition, we don't want to go back to showing subfield "h", for instance.

I mentioned this in IRC, but IMO, the way forward is to always use the Display Field data when we have it, but only use the highlighted version when highlighting is turned on. The logic to do that would actually be a simplification of what's in there now, with just an adjustment to the DF mapping code in misc_util.js to choose between the appropriate versions, and removal of any other "are we highlighting" tests in the rest of the templates.

I will work on that soon, so I'll just assign myself now.

Changed in evergreen:
assignee: nobody → Mike Rylander (mrylander)
Mike Rylander (mrylander) wrote :
Changed in evergreen:
assignee: Mike Rylander (mrylander) → nobody
Remington Steed (rjs7) wrote :

I gave Mike's branch a trial run, and it seems to fix the issue. Here's my sign-off:;a=shortlog;h=refs/heads/user/rsteed/lp-1752434-use_more_display_fields

Dan Wells (dbw2) on 2018-03-20
Changed in evergreen:
importance: Undecided → Low
Changed in evergreen:
milestone: 3.1-rc → 3.1.1
Changed in evergreen:
milestone: 3.1.1 → 3.1.2
Michele Morgan (mmorgan) on 2018-04-24
tags: added: signedoff
Michele Morgan (mmorgan) on 2018-04-30
tags: added: pullrequest
Galen Charlton (gmc) on 2018-04-30
Changed in evergreen:
assignee: nobody → Galen Charlton (gmc)
status: New → Fix Committed
status: Fix Committed → Confirmed
Galen Charlton (gmc) wrote :

Pushed to master and rel_3_1, along with a patch that fixes a regression introduced in the control of highlighting in the author field. Thanks, Mike and Remington!

Changed in evergreen:
status: Confirmed → Fix Committed
assignee: Galen Charlton (gmc) → nobody
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers