https://bugzilla.wikimedia.org/show_bug.cgi?id=32478
--- Comment #5 from Brion Vibber <[email protected]> 2011-11-18 23:28:49 UTC --- Good catch, Platonides! Looks like this is where AbuseFilter stores variable state dumps on filter matches so they can be checked out later. AbuseFilter::storeVarDump() and AbuseFilter::loadVarDump() are manually using the text table and ExternalStore -- this probably should be using a common interface underneath Revision's use of the same. Since it doesn't use the Revision code paths right now the var dumps won't be run through $wgLegacyEncoding conversion on load, but if they get refactored into a common code path, that conversion might start happening before a refactored AbuseFilter::loadVarDump gets its data back. This should not be fatal but would at least cause those old entries to display incorrectly on some sites[1] where non-ASCII chars were contained in the text. [1] from http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php 'wgLegacyEncoding' => array( 'enwiki' => 'windows-1252', 'dawiki' => 'windows-1252', 'svwiki' => 'windows-1252', 'nlwiki' => 'windows-1252', 'dawiktionary' => 'windows-1252', 'svwiktionary' => 'windows-1252', 'default' => false, ), // all other sites will not attempt conversion A bigger worry is that batch recompression or other maintenance work might try to renormalize those entries in a way that AbuseFilter's code path doesn't recognize. Switching to using a common code path would avoid having to worry about new data formats (or saving the wrong data format, as it currently does!) but we'd have to fix the old data entries or devise a workaround. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
