http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11302
--- Comment #9 from Jacek Ablewicz <[email protected]> --- (In reply to Dobrica Pavlinusic from comment #8) > Sorry Jacek your simpler approach doesn't work for authorized values with > UTF-8 characters in them (in fact, it doesn't even return double encoded > utf-8, it just doesn't return anything which is somewhat puzzling since I > can't figure out from code why it does so). It took me a while to reproduce this issue, but indeed there seems to be at least one serious problem with this particular approach, which is affecting bug 10855 in non intuitive way (I'm not entirely sure it's the same problem you've encountered - it can be yet another/new one as well). Anyway, it boils down to this: - unpatched C4/Template.pm does not encode hash keys, and does not deal with objects at all - patched C4/Template.pm does deal with whitelisted objects, but it only encodes scalar values within them (in the same exact manner as unpatched version deals with ordinary, unblessed hashes) - if there are utf8 characters in additional field names, some code fragments introduced by 10855 - e.g. this one, used repeatedly in subscription-add.tt additional_fields.${field.name} wouldn't work any longer. While field.name (being a scalar value) gets encoded by patched C4/Template.pm, keys in additional_fields hash do not. What's worse, I don't see any easy solution for this problem (other than making some - pretty substantial - changes to 10855). We can patch Template.pm somehow further, so it will encode hash keys - but that's rather risky move IMO; who knows how many regressions we may get elsewhere in the system.. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
