Created attachment 10734 [details] screenshot While testing something else... I found a bug in the highlighting of the system preference editor. I used the system preference search on top of the module page and searched for "query". I was looking for the OPACNoResultsFound system preference. When opening the preference to check its content it showed: Something {_KW} This is not correct. Searching "NoResults" shows the correct content when opening the preference: Something {QUERY_KW}
I can confirm this behavior and it can have some serious consequences. I was working with the Self Checkout and was editing the SCOUserCSS. I have several entries similar to #selfCheckOutHeader. To get back to the SCOUserCSS I would search for "self". If I made any changes and saved, the word "self" would be dropped from any entry. Example: #selfCheckOutHeader would become #CheckOutHeader.
*** Bug 9404 has been marked as a duplicate of this bug. ***
Example: Search for "opac" in the global system preferences. The search term "opac" will mysteriously vanish from OPACUserCSS entries that contain the term. Our pseudo-class "#opac-main" becomes "#-main" The same thing happens when searching for self-checkout css. I am searching for SCO to change the SCOUserCSS. All of my css entries for SCOUserCSS show up with the letter combination "sco" edited out. The result of this bug is that when I re-save the css changes, my custom css breaks because the entries are saved as "-main" instead of "opac-main" or "selfhelp" instead of "scoselfhelp" The same thing happens to custom javascript code. For example in the SCOUserJS: "document.write(myscore);" becomes "document.write(myre);" The workflow at issue is: 1. Use the same term or letter combination in your custom css or javascript as part of the preference name. Enter your custom css and javascript in the global system preferences. 2. Search for the preference using part of the name. < Search term drops out of css and javascript > 3. Make a change to the preferences and save. < site css and javascript suddenly broken >
I had it happen to me too which ended in rewriting checking lots of html code. Upping severity a bit, as this bug results in unintentional data loss.
I believe the problem originates with this file: File: jquery.highlight-3.js Path: /home/koha/kohaclone/koha-tmpl/intranet-tmpl/prog/en/lib/jquery/plugins Removal of this function appears to resolve the issue, not sure about side-effects: -------------------------------------- jQuery.fn.removeHighlight = function() { return this.find("span.term").each(function() { this.parentNode.firstChild.nodeName; with (this.parentNode) { replaceChild(this.firstChild, this); normalize(); -----------------------------------------
(In reply to comment #5) > Removal of this function appears to resolve the issue, > not sure about side-effects: Side-effects would be breaking the functionality of search term highlighting in all areas of the staff client which use the plugin. The solution is either to disable search term highlighting altogether on this page (perhaps the short-term solution) or to fix the scope of the highlighting so that it excludes textareas (something I'm not sure is possible).
Instead of editing jquery plug-ins, which may be referenced offsite, a simple edit to the Koha code fixes the problem. Needs testing, but I am not seeing any issues. Notice this function only affects the preferences table: File: preferences.js Path: /home/koha/kohaclone/koha-tmpl/intranet-tmpl/prog/en/js/pages if ( to_highlight ) { var words = to_highlight.split( ' ' ); $( '.prefs-tab table' ).find( 'td, th' ).not( '.name-cell' ).each( function ( i, td ) { $.each( words, function ( i, word ) { $( td ).highlight( word ) } ); - } ).find( 'option' ).removeHighlight(); } Replace the second-to-last line: + } ) }
This seem to work disabling highlighting on both 'option' and 'textarea' File: preferences.js Path: /home/koha/kohaclone/koha-tmpl/intranet-tmpl/prog/en/js/pages if ( to_highlight ) { var words = to_highlight.split( ' ' ); $( '.prefs-tab table' ).find( 'td, th' ).not( '.name-cell').each( function ( i, td ) { $.each( words, function ( i, word ) { $( td ).highlight( word ) } ); } ).find( 'option, textarea' ).removeHighlight(); } changed .find( 'option' ).removeHighlight(); to .find( 'option, textarea' ).removeHighlight();
Created attachment 14685 [details] [review] Patch for preferences.js to repair highlighting bug 8401 As per Jorge's most recent comment.
Created attachment 14688 [details] [review] Bug 8401 : Highlighting of search terms in preference causes loss of data To test: 1/ Go to system preferences 2/ Go to SCOUserCSS 3/ Add #self 4/ Search for self 5/ Open SCOUserCSS 6/ Note it now contains only # (Do not click save) 7/ Apply the patch 8/ Refresh the page, and check SCOUserCSS and note it now says #self 9/ Rejoice! Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Created attachment 14689 [details] [review] Bug 8401 : Highlighting of search terms in preference causes loss of data To test: 1/ Go to system preferences 2/ Go to SCOUserCSS 3/ Add #self 4/ Search for self 5/ Open SCOUserCSS 6/ Note it now contains only # (Do not click save) 7/ Apply the patch 8/ Refresh the page, and check SCOUserCSS and note it now says #self 9/ Rejoice! Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>
Created attachment 14690 [details] [review] [SIGNED-OFF] Bug 8401 : Highlighting of search terms in preference causes loss of data To test: 1/ Go to system preferences 2/ Go to SCOUserCSS 3/ Add #self 4/ Search for self 5/ Open SCOUserCSS 6/ Note it now contains only # (Do not click save) 7/ Apply the patch 8/ Refresh the page, and check SCOUserCSS and note it now says #self 9/ Rejoice! Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Works nicely and passes all tests.
This patch has been pushed to master. Welcome to our 201st committer, Fred Pierre!
Pushed to 3.8.x and 3.10.x will be in 3.8.10 and 3.10.3