Summary: | Default for `OPACSearchForTitleIn` syspref misses class assignment | ||
---|---|---|---|
Product: | Koha | Reporter: | Alexander Wagner <alexander.wagner> |
Component: | OPAC | Assignee: | Owen Leonard <oleonard> |
Status: | NEW --- | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | schodkowy.omegi-0r |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36805 | ||
GIT URL: | Change sponsored?: | --- | |
Patch complexity: | --- | Documentation contact: | |
Documentation submission: | Text to go in the release notes: | ||
Version(s) released in: | Circulation function: |
Description
Alexander Wagner
2024-01-19 09:20:16 UTC
It definitely looks like an omission after some CSS refactor. I'll add to it that adding said class would also have to be added to the update scripts, to fix this in all the existing installations! Maybe replacing `<a href=` with `<a class="dropdown-item" href=`, but such naive approach is certainly not ideal for obvious reasons. If Koha has some Perl module for HTML parsing included, and if it's non-destructive to the layout apart from changing the explicitly changed items, then the best course of action would be to use that and then add/expand the `class` attribute, in case someone's links already have `class`... This definitely seems like pain. The former lazier solution in theory should fix 99% of cases, while risking the remaining rounded-up 1% to be broken and having to figure out things manually in worst case scenario. Might be acceptable, since it's expected that various manual Koha HTML/JS/CSS customizations might need adjustment after major upgrades. Also the fact that there's that other bug that proposes moving away from using HTML at all, it hardly justifies then spending a lot of time on some advanced HTML-parsing migration script rather than dead simple one. |