Bug 14584

Summary: Encoding broken with system preferences
Product: Koha Reporter: Blou <philippe.blouin>
Component: Architecture, internals, and plumbingAssignee: Jonathan Druart <jonathan.druart>
Status: CLOSED FIXED QA Contact: Testopia <testopia>
Severity: major    
Priority: P5 - low CC: chris, eric.begin, francois.charbonnier, jonathan.druart, mirko, sophie.meynieux, tomascohen
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12411
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11944
Change sponsored?: --- Patch complexity: Trivial patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: Bug 14584 - Encoding broken with system preferences
Bug 14584: Encoding broken with system preferences
[SIGNED OFF] Bug 14584: Encoding broken with system preferences
[PASSED QA] Bug 14584: Encoding broken with system preferences

Description Blou 2015-07-21 20:07:49 UTC
This bug is related to #12411 and #11944, since then pushed to master.

Whatever we enter with accents in NoLoginInstructions is displayed as gibberish because it ends up being encoded TWICE.

It was not doing that before.

My solution is to modify Koha::Template::Plugin::Koha::Preference.  It might be naive and missing all the changes done in aforementionned bugs, but this does fix my immediate issue in 3.20 and master.
Comment 1 Blou 2015-07-21 20:12:10 UTC Comment hidden (obsolete)
Comment 2 Jonathan Druart 2015-08-04 07:28:34 UTC
Actually I would say that the line could only be replaced with a call to C4::Context->preference.
Comment 3 Blou 2015-08-17 13:32:15 UTC
Well, I'm fine with that, but isn't it just making this function useless?  I think what you're suggesting is what it was before the latest change.  I just presumed there had been a need for that "encode('UTF-8'" call...
Comment 4 Jonathan Druart 2015-08-18 17:39:19 UTC
(In reply to Blou from comment #3)
> Well, I'm fine with that, but isn't it just making this function useless?  I
> think what you're suggesting is what it was before the latest change.  I
> just presumed there had been a need for that "encode('UTF-8'" call...

Not useless, it can be called from the templates.

Back 1 year ago, from bug 12411:

"This will fix the encoding issues existing in 3.14 and 3.16.
The issue still appear in master but is fixed by bug 11944."

So bug 12411 should not have been pushed to master or 11944 should have reverted the changes.
Comment 5 Jonathan Druart 2015-08-18 17:41:05 UTC Comment hidden (obsolete)
Comment 6 Jonathan Druart 2015-08-18 17:42:54 UTC
Should be backported to 3.20, not 3.18!
Comment 7 Tomás Cohen Arazi 2015-08-18 21:18:07 UTC Comment hidden (obsolete)
Comment 8 Katrin Fischer 2015-09-01 21:55:46 UTC
Created attachment 42183 [details] [review]
[PASSED QA] Bug 14584: Encoding broken with system preferences

The pref are double encoded.

From bug 12411:
"This will fix the encoding issues existing in 3.14 and 3.16.
The issue still appear in master but is fixed by bug 11944."

They should not have been pushed together.

Test plan:
1) You need an accentuated language installed.
2) Go to NoLoginInstructions pref, and add some accentuated message like
"Hélo médames é mècieüx"
3) refresh opac home page, message should be gibberish
4) apply patch.  Message should be ok now.

Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Works as expected.

Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Comment 9 Tomás Cohen Arazi 2015-09-02 14:10:57 UTC
Patch pushed to master.

Thanks Jonathan!
Comment 10 Chris Cormack 2015-09-22 01:29:33 UTC
Pushed to 3.20.x will be in 3.20.4
Comment 11 Sophie MEYNIEUX 2015-10-26 11:19:02 UTC
(In reply to Jonathan Druart from comment #6)
> Should be backported to 3.20, not 3.18!

Seems to have been pushed in 3.18.11 despite Jonathan's comment