Après MAJ en 0.7.4, les libellés de contributions et de statuts avec accent sont vides (Anomalie #578)


Added by Raphaël Hertzog over 1 year ago. Updated 6 months ago.


Status:Fermé Start date:03/05/2013
Priority:Normal Due date:
Assignee:- % Done:

100%

Category:Base de données
Target version:-
Version utilisée:0.7.4

Description

J'utilise PostgreSQL et lors de ma tentative de mise à jour en 0.7.4, j'ai constaté que tous les libellés de contribution et de statuts qui contenaient des acccents étaient vides (du moins sur la page web, je n'ai pas vérifié dans la base de données).

J'ai vu ce message dans les logs ceci dit:
92.243.16.27 - 2013-03-05 09:43:57 - 4 - PHP Warning: htmlspecialchars(): Invalid multibyte sequence in argument in /var/cache/galette/templates_c/a2019a98bfadd6abad76c4684c85611f9fdc0a1a.file.gestion_intitule_content.tpl.php on line 108

Je suis en Debian Squeeze avec toutes les mises à jour.


Related issues

related to Galette - Anomalie #711: Problème d'encodage suite à migration depuis une 0.63 Fermé 09/28/2013

Associated revisions

Revision 6c267cf2
Added by Johan Cwiklinski 8 months ago

Set charset at database connection, to avoid encoding issues; fixes #711 #578

History

Updated by Raphaël Hertzog over 1 year ago

Quelques informations supplémentaires.

Avant la mise à jour, dans la base les chaînes sont en ISO-8859-1 (tables galette_statuts et galette_types_cotisation) et PostgreSQL est configuré en ISO-8859-1. Les caractères accentués s'affichent correctement dans "Configuration > Gestions des statuts" et "Configuration > Gestions des types de contribution". Bizarrement les accents codés en ISO-8859-1 dans la table galette_adherents ne s'affichent pas correctement dans tous les écrans de gestions des adhérents... Il serait intéressant de comprendre le pourquoi de cette différence et le résoudre.

Après la mise à jour, je n'ai pas pris le temps de regarder ce qui s'était passé au niveau de la base de données.

Updated by Johan Cwiklinski over 1 year ago

Merci pour les précisions :)

J'ai récemment supprimé des conversions d'encodage (pour des raisons de performance principalement) ; puisque le plugin admintools est en mesure de résoudre ce type de soucis pour MySQL, et que je n'ai jamais encore rencontré le cas avec un Postgres.

Je pense que ça fonctionne à certains endroits et pas à d'autres à cause de « problèmes » de traductions/traductions dynamiques. Je sais que ce point n'est pas parfaitement fonctionnel, et que pas mal de choses ne sont pas trop logiques voire relèvent presque du « bricolage ».

La mise à jour n'est pas censée modifier quoi que ce soit côté base de données, certainement pas l'encodage ;)

Updated by Johan Cwiklinski over 1 year ago

Les modifications pour activer la conversion d'encodage pour les bases Postgres requiert deux petites modifications (une dans Galette, l'autre dans le plugin) :

 1diff --git a/galette/lib/Galette/Core/Db.php b/galette/lib/Galette/Core/Db.php
 2index 0e5cbab..ce3568b 100644
 3--- a/galette/lib/Galette/Core/Db.php
 4+++ b/galette/lib/Galette/Core/Db.php
 5@@ -538,7 +538,7 @@ class Db extends \Zend_Db
 6             $tables = $this->getTables($prefix);
 7
 8             foreach ($tables as $table) {
 9-                if ( $content_only === false ) {
10+                if ( $content_only === false && !$this->isPostgres() ) {
11                     //Change whole table charset
12                     //CONVERT TO instruction will take care of each fields,
13                     //but converting data stay our problem.
 1diff --git a/templates/default/admintools.tpl b/templates/default/admintools.tpl
 2index 660d2c5..a55731c 100644
 3--- a/templates/default/admintools.tpl
 4+++ b/templates/default/admintools.tpl
 5@@ -22,10 +22,8 @@
 6                 <div class="warningbox">
 7                     <p>{_T string="Make sure you've done a backup of the database before using any of the following tools!"}</p>
 8                 </div>
 9-{if $smarty.const.TYPE_DB == 'mysql'}
10                 <article>
11                     <p>
12-                        <span>{_T string="That function is available for MySQL installations only!"}</span><br/>
13                         {_T string="Converts the whole database data to UTF-8, do not change anything on the tables, just proceed data conversion."}<br/>
14                         {_T string="You should use that function if you can see strange characters in your datas; after a manual import, or if you've not used Galette's update scripts."}<br/>
15                         {_T string="That conversion stuff will read your entire database, and write back each non UTF-8 values after conversion; this may take a while."}
16@@ -34,7 +32,6 @@
17                         <input name="convert_encoding" type="submit" value="{_T string="Convert encoding"}"/>
18                     </p>
19                 </article>
20-{/if}
21             </fieldset>
22         </form>
23     </section>

N'ayant pas de base ISO sous la main, je n'ai pas pu tester le fonctionnement, mais la conversion des données est faite côté PHP, ça devrait donc aller. La méthode admintools ne touche qu'aux données (en mysql comme en postgres).

À noter : cette modification affecte aussi la mise à jour à partir d'une version < 0.7 ; pour laquelle une requête ALTER est exécutée lorsqu'il s'agit de MySQL, je ne sais pas s'il faut un équivalent pour Postgres (je n'ai pas de base galette postgres < 0.7 en iso pour ma part) ; faute de tests possibles, je pense désactiver la conversion à l'installation pour Postgres ; si toutefois ce correctif fonctionnait :)

Updated by Raphaël Hertzog over 1 year ago

Hum, tout ceci est plutôt contre-productif. Ce qu'il faudrait c'est que la connexion à la base de données indique le jeu de caractère désiré et laisser PostgreSQL faire la conversion à la volée.

En cas de changement d'encodage à l'insu de Postgres alors après on peut faire le changement manuel avec "update pg_database set encoding = pg_char_to_encoding('UTF8') where datname = 'galette'" mais en vérité cela ne devrait pas être nécessaire. Cette modif nécessite les droits d'admin (user postgres) et ne peut pas être effectuée automatiquement par galette.

Tu peux te créer une base ISO très facilement en faisant "createdb -E LATIN1 -O galette galettetest" et ensuite exécuter un dump d'une de tes bases en UTF-8. Le fichier commence par "SET client_encoding = 'UTF8';" et la conversion se fera à la volée.

http://stackoverflow.com/questions/5090858/how-do-you-change-the-character-encoding-of-a-postgres-database

Updated by Johan Cwiklinski over 1 year ago

Raphaël Hertzog a écrit :

Hum, tout ceci est plutôt contre-productif. Ce qu'il faudrait c'est que la connexion à la base de données indique le jeu de caractère désiré et laisser PostgreSQL faire la conversion à la volée.

Oui, mais MySQL n'est pas capable de faire ça, et je souhaiterai autant que possible éviter les cas particuliers (j'en ai déjà bien trop alors que j'utilise un framework censé m'abstraire ce genre de considérations...).

Cela dit, c'est certainement bien plus simple, en effet.

En cas de changement d'encodage à l'insu de Postgres alors après on peut faire le changement manuel avec "update pg_database set encoding = pg_char_to_encoding('UTF8') where datname = 'galette'" mais en vérité cela ne devrait pas être nécessaire. Cette modif nécessite les droits d'admin (user postgres) et ne peut pas être effectuée automatiquement par galette.

Tu peux te créer une base ISO très facilement en faisant "createdb -E LATIN1 -O galette galettetest" et ensuite exécuter un dump d'une de tes bases en UTF-8. Le fichier commence par "SET client_encoding = 'UTF8';" et la conversion se fera à la volée.

http://stackoverflow.com/questions/5090858/how-do-you-change-the-character-encoding-of-a-postgres-database

Ok, je testerai ça, merci pour les infos.

Updated by Johan Cwiklinski over 1 year ago

  • Category set to Base de données
  • Priority changed from Haut to Normal

Updated by Johan Cwiklinski 8 months ago

  • Status changed from Nouveau to Résolu
  • % Done changed from 0 to 100

Updated by Johan Cwiklinski 6 months ago

  • Status changed from Résolu to Fermé

Also available in: Atom PDF