[Résolu] Problème de charset - accents sous OSC 2.2 et PHP 5.3 Options

[seintokikki]

Bonjour à tous,

Pas mon genre de passer ma vie à poser des questions pour rien, en général plus de la passer à arpenter ce forum pour y trouver des réponses - le plus souvent avec succès (merci encore à l'énorme travail de tous).

Bref, vu que je viens de résoudre mon problème et que manifestement on ne pouvait pas trouver de réponse ici, je la poste pour d'autres développeurs.

Après installation d'une N'ème version 2.2 RC1 sur un serveur Infomaniak, plus d'accent côté front, sauf dans les éditeurs WYSIWYG. En clair, le fait d'écrire un mot comportant un accent dans un titre, fait disparaître - non seulement l'accent, mais le reste du mot / phrase. Ex.; pour "Rue de la chèvre 22" entré par un client, je reçois "Rue de la Ch" côté admin; idem pour les mots de passes, références d'articles, titres et Tutti quanti.

Par contre, tout ce qui est natif et vient de l'insta' d'origine est correctement accentué (dans l'admin et le front, idem côté BDD).

Résumons, je suis en PHP 5.3 (la réelle source du problème) et infomaniak renseigne le serveur en UTF-8 (jusque là et avec les autres sites, tout fonctionnait), les fichiers quant à eux, sont tous iso.

Ce que j'ai tenté :

- Insertion d'une ligne de renseignement charset dans les .htaccess pour forcer le charset en UTF-8 (génère des caractères erronés - du coup pour l'entier du site - mais permet au moins l'affichage du restant de la ligne); dans le doute, j'ai aussi tenté l'ISO 8859-1 (à un moment je ne savais plus qui renvoyait quoi à qui), naturellement rien à faire.

- Utilisation de code html dans les descriptions type "Café au lait" - ATTENTION, c'est la dernière chose à faire, même si l'affichage est visuellement correct ! L'accent s'affiche correctement en front, mais le client ne pourra plus jamais retrouver l'article en mode recherche avec "Café" (il faudrait qu'il entre "Café" - pratique), alors ne parlons même pas d'un client qui entrerait un accent dans son mot de passe ou dans son adresse...

- Corrections de fonctions soit disant responsables de bugs d'affichages sous PHP 5.3 (c'est toujours bon de les corriger, même si ça ne change rien).

- Modification de l'interclassement en BDD (ça créé juste des erreurs supplémentaires) - idem pour l'interclassement général.

- Contrôle de la fonction mysql_escape_string, connue pour générer des erreurs de charset sous php.5.3 lien.

Ce que j'étais sur le point de faire : Passer l'intégralité du site en UTF-8. Pour les suicidaires, il y a cet excellent post : lien. L'inconvénient de cette solution - outre sa longueur - est que toutes les contributions ajoutées et à venir doivent êtres contrôlées et passées en UTF-8. Un travail de titan et un sérieux frein à tout développement ultérieur.

Ce que j'ai trouvé : Le dual support de Tim

Cette "bête" contribution va tout simplement donner une alternative au serveur en cas de mauvaise compréhension.

Bref, je suis à des KM d'être un expert et ne peux pas dire si oui ou non cette solution fonctionnera toujours sous PHP6 (en même temps je ne vois pas en quoi ça changerait quoi que ce soit), le fait est qu'elle s'adapte parfaitement à une MS2.2 RC1, pour peut qu'on ne colle pas le code n'importe où (la contribe est faite pour un 2.3)... Et puis, avec PHP6, des problèmes, on en aura d'autres...

L'avantage final de cette contribution, c'est que vous pouvez ignorer l'encodage de toute contribution ajoutée par la suite (j'imagine qu'il ne faut pas non plus qu'elle soit encodée en n'importe quoi).

Bref, j'espère que ce post aidera au moins une ou deux personnes ayant le même problème à savoir : Une MS2.2 sous PHP 5.3 avec un gros problème d'encodage.

[Bonbec]

Bonjour,

Je suis aussi chez Infomaniak et je viens de terminer la transposition de tout mon site MS 2.2 en UTF-8.
C'est vrai que cela prend du temps, mais ce n'est pas insurmontable. Deux jours pour le passage en UTF-8 et la modification du Php déprécié (d'ailleurs j'ai trouvé toutes mes réponses sur ce dernier point en lisant la FAQ et en utilisant la fonction recherche ici même).
Il faut procéder par ordre :
- régler son éditeur de texte pour qu'il sauvegarde les fichiers en UTF-8 sans BOM. Une fois cela paramétré, l'installation de futures contributions ne pose pas de problème.
- se servir de l'excellente FAQ d'Infomaniak sur le sujet.
- modifier les fonctions Php dépréciées

Par contre j'ai eu le problème du tep_db_insert_id() qui me retournait 0 au lieu de la valeur du prochain ID de libre, en particulier dans create_acount.php
Les différentes astuces trouvées ici sur le forum anglophone n'ont pas résolu mon problème :
- mettre la connexion persistante à false dans les configure.php
- remplacer dans les fichiers database.php la function

Code

function tep_db_insert_id() {
    return mysql_insert_id();
  }

par

Code

function tep_db_insert_id($link = 'db_link') {
    global $$link;
    
    return mysql_insert_id($$link);
  }

Alors j'ai ajouté une requête pour le $customer_id et le $address_id.

J'ai préféré faire le grand saut maintenant, comme cela je suis tranquille pour le futur

Ce message a été modifié par Bonbec - 1 Jun 2012, 14:08.