P@t a écrit:

Pour nous, c'est très facile de passer en php5...
Mais pour un utilisateur lambda, pour qui c'est déjà un peu fastidieux d'installer pwg, ca risque de le rebuter plutot qu'autre chose...

pas pour moi ^^;
mon serveur est en PHP 4 / MySQL4.1 ; je sais que c'est possible de le passer en PHP 5/MySQL 5, mais c'est pas quelque chose de super aisé et il est fort probable que je doive par la suite faire moi même toutes les mises à jour (faire less compils : berk ) alors qu'aujourd'hui la distribution étant maintenue, toutes les mises à jour sont compilées et testées avant diffusion.

certes, je n'ai qu'à pas utiliser de serveur personnel ^^; mais c'est tellement pratique :)

Il faudrait-y pas regarder avant quelles améliorations intéressantes apportent les nouvelles versions avant de migrer ?

çà serait-y pas aussi simple que de mettre l'extension .php5 ?

a une lointaine époque, les serveurs différenciaient les scripts php3 et php4 par l'extension...

ddtddt a écrit:

grum a écrit:

çà serait-y pas aussi simple que de mettre l'extension .php5 ?

a une lointaine époque, les serveurs différenciaient les scripts php3 et php4 par l'extension...

ce serais super long ! non je me rappel je croix que Vincent me l'a fait faire avec un fichier .htaccess avec simplement php 1 dedans à la racine du répertoire que l'on veut faire passer en php 5

un fichier .htaccess avec simplement php 1 dedans à la racine du site chez free uniquement

8-)

Si certains veulent fixer les versions minimales qu'ils le fassent.

Le sujet ici est bien Utf-8 et je ne veux pas avoir des installations avec des colonnes varchar/text/enum converties en BLOB et d'autres pas.
Cela serait à mon sens trop compliqué à gérer dans les upgrades suivants.

Le 3, on force la galerie à rester en iso...

Les paramètres: PWG_CHARSET et DB_CHARSET (pas PWG_DB_CHARSET, non? )


et si
PWG_CHARSET = utf-8
&
DB_CHARSET = latin1
alors PWG_CHARSET = iso-8859-1

A mon avis...
8-)

Oui, mais le plus difficile à convertir c'est la base et si le changement de charset n'est pas supporté...

Alors avoir 2 versions de structure de table différentes c'est prendre un maximum de risques et cela complique trop.

Tant pis, ceux qui ne peuvent pas passer en utf-8 à cause de leur version MySQL attendront que leur hébergeur propose le support.
C'est ce que je pense.

Pas d'usine à gaz, qu'il faudra dépanner sur 25 000 sites.

8-)

rvelices a écrit:

E. gerer l'encodage des iptc pour l'affichage et la synchronisation avec la base ...

Bonjour,

Comment cela va-t-il se passer sur ce point ?

Il faudrait à mon avis prévoir au moins 3 cas :
1) le codage des IPTC est en latin1 ou windows-1252. Le cas le plus fréquent.
2) codage en MacRoman, utilisateurs de Mac. (voir cette galerie par exemple...)
3) codage en UTF-8.

Il y a bien un champ IPTC ou le jeu de caractère utilisé doit être spécifié,  malheureusement la plupart des logiciels ne le remplissent pas.
La solution la plus réaliste serait que l'utilisateur puisse choisir dans un fichier de configuration l'encodage utilisé (en se limitant peut-être à ces trois jeux de caractères).

Mais le problème, je crois, c'est que tous les hébergeurs ne proposent pas iconv ou recode. Pour latin-1 ou utf-8, ça ne pose pas de problème. Mais pour MacRoman, il faudrait ce genre de solution.

Dernière modification par galain (2007-10-07 17:36:33)

rub a écrit:

VDigital a écrit:

Le sujet ici est bien Utf-8 et je ne veux pas avoir des installations avec des colonnes varchar/text/enum converties en BLOB et d'autres pas.

Oui, je te rejoins aussi!
Pourquoi, faut-il convertir en BLOB? Le varchar/test/enum supporte bien l'utf8?

Il ne faut pas les laisser en BLOB, juste passer par blob avant UTF-8 ...

VDigital a écrit:

Les paramètres: PWG_CHARSET et DB_CHARSET (pas PWG_DB_CHARSET, non? )

Je dirais plutot:
  PHP_CHARSET et DB_CHARSET


En fait pour résumé les différents charsets, nous avons:
  o HTML charset: encodage utilisé pour restituer les infos au niveau du browser
  o PHP charset: encodage utilisé pour les méthodes et les fichiers php
  o DB charset: encodage utilisé pour communiquer avec la base de données
  o MySQL Charset: encodage utilisé pour stoker les données
  o IPTC charset: encodage des photos

Dans ce que propose rvelices, on part du principe que:
  o HTML charset et PHP charset sont identiques
  o MySQL Charset va dépendre du DB Charset utilisé lors de l'installation avec conversion implicite entre DB charset et MySQL charset.
  o PHP charset et DB charset seront identiques:
     > UTF8 si nouvelle installation
     > ISO-8859-1 si upgrade

C'est bien ca?
C'est à dire tout en UTF-8 ou en ISO-8859-1?

Ce qui m'embête c'est l'encodage du PHP charset en UTF8 ou IS0-8859-1.
Car, il va falloir suivant le cas ré-encoder les fichiers de traduction.
Est-ce qu'on ne peut pas avoir:
  o HTML charset: UTF-8
  o PHP charset: UTF-8
  o DB charset: UTF-8
  o MySQL Charset: UTF-8 si nouvelle install ou ISO-8859-1

Cela impliquera sûrement de devoir changer les versions minimales de PHP et MySQL (pour que les conversions se passent sans soucis)!
Pour les browsers, ils supportent tous l'UTF-8, je penses!

Bien entendu PHP charset et HTML restent paramétrable mais de base pas besoin de changer les fichiers langues si on passe le stockage des tables en UTF-8, ISO-8859-1 ou à autre chose.
Le seul truc, c'est lors de la création de tables ou de colonnes de le faire avec le MySQL charset!

Non?
Me trompes-je?

PS: Je ne suis étendu sur les IPTC , car je ne sais si on peut savoir le charset utilisé dans la photo, etc.
Ce qui est sur c'est les données IPTC doivent être ré-encodées dans le PHP charset, non?