10.4.00 demande de test

[sylvainlelievre 261]

Il y a 3 heures, roger a dit :

Voilà juste du code css à placer dans le module concerné et ceux à seulement deux endroits là où il y a le css pour la configuration des articles et celle des commentaires postés (config.css & comment.css) et roule ma poule, un bins de moins pour l'avenir.

Testé !

Nickel !

Merci @roger

[Gilux 176]

Le 29/10/2020 à 22:05, Fred a dit :

Bêtement, j'ai suivi le conseil de @Gilux ce qui était une erreur, je travaille actuellement sur un serveur sous macos dans lequel UTF-8 n'est pas déclaré dans php.ini, résultat, les dates sont en anglais. Normal, l'encodage n'est pas par défaut en UTF-8 !

 

Supprimer les encodage utf8_encode était donc une connerie. Cependant au lieu de les remettre en place, je préfère compléter index.php avec ceci :

 

setlocale(LC_ALL, 'fr','fr_FR','fr_FR.utf8','fr-FR','fra');

C'est chargé mais ça devrait fonctionner avec différents OS et serveurs.

 

Ce week-end je pourrai faire le test sous une machine linux, selon vos retours, on avisera pour clore ce problème définitivement.

 

 

Citation

Bêtement, j'ai suivi le conseil de @Gilux ce qui était une erreur,

 

Bien au contraire, c'est exactement ce qu'il fallait faire pour que l'encodage soit par défaut en UTF-8, contrairement à ce qu'il y avait avant :
setlocale (LC_TIME, 'fra_FRA', 'french');
Ou aucun encodage par défaut n'éxistait

 

Citation

    je travaille actuellement sur un serveur sous macos dans lequel UTF-8 n'est pas déclaré dans php.ini, résultat, les dates sont en anglais. Normal, l'encodage n'est pas par défaut en UTF-8 !

 

Si, l'encodage des dates est bien UTF8 par défaut dans tout le CMS avec :
setlocale (LC_TIME, 'fr_FR.utf8','fra');

 

Et pour tous les textes du CMS avec :
setlocale (LC_ALL, 'fr_FR.utf8','fra');
Mais ce dernier n'est pas vraiment utile, vu que les textes sont déjà codés en UTF8

 

Si les dates sont en anglais, ce n'est pas parceque l'encodage n'est pas par défaut en UTF-8, mais tout simplement parce qu'il n'éxiste pas, tu le dis toi même :

 

Citation

    je travaille actuellement sur un serveur sous macos dans lequel UTF-8 n'est pas déclaré dans php.ini

 

Donc s'il n'est pas déclaré il n'éxiste pas ! C'est un peu comme si tu voulais manipuler des images en PHP sans que la librairie GD soit installée, tu pourras essayer tant que tu veux ça ne marchera jamais

 

Citation

Supprimer les encodage utf8_encode était donc une connerie.

 

Bien sur que non, l'encodage des dates étant déjà en UTF8, j'ai démontré que les coder une seconde fois en UTF8 avait pour conséquence d'afficher le texte en code source UTF8, utf8_encode est non seulement totalement inutile mais contre productif (se référer à mon post à ce sujet)

 

Citation

 

     Cependant au lieu de les remettre en place, je préfère compléter index.php avec ceci :

    setlocale(LC_ALL, 'fr','fr_FR','fr_FR.utf8','fr-FR','fra');
    C'est chargé mais ça devrait fonctionner avec différents OS et serveurs.

 

 

Ceci n'éxiste pas, ça ne peut donc pas fonctionner !

 

[sylvainlelievre 261]

Bonjour @Gilux,

 

Ce problème d'interprétation par les serveurs de l'instruction setlocale(), bien délicate, est à l'étude.

 

On constate dans la doc. php que les commentaires sont particulièrement nombreux !

 

Quelques petits tests sur la 10.4.00 (en dehors des problèmes soulevés qui sont en cours de résolution) ?

 

Merci d'avance, le CMS a besoin de tous les actifs du forum pour progresser.

 

Bonne journée

 

Sylvain

[Fred 1 575]

Il y a 4 heures, Gilux a dit :

Bien sur que non, l'encodage des dates étant déjà en UTF8, j'ai démontré que les coder une seconde fois en UTF8 avait pour conséquence d'afficher le texte en code source UTF8, utf8_encode est non seulement totalement inutile mais contre productif (se référer à mon post à ce sujet)

Pas du tout, si le paramètre char_set de php.ini n'est pas défini ou est défini avec un autre jeu de caractère, l'utf8 n'est pas appliqué par défaut, c'est pour cela que Rémi avait placé les fonctions d'encodage.

 

Il y a 4 heures, Gilux a dit :

Ceci n'éxiste pas, ça ne peut donc pas fonctionner !

Sauf que oui, cette ligne de commande a fait revenir les accents et les mois en fr. De toute manière rien n'est clos comme le dis @sylvainlelievre.

 

Te souviens-tu que tu voulais supprimer les paramètres  dans ces deux appels et que tu me disais qu'ils étaient inutiles ?

		<link rel="stylesheet" href="<?php echo helper::baseUrl(false) . self::DATA_DIR; ?>theme.css?<?php echo md5_file(self::DATA_DIR.'theme.css'); ?>">
		<link rel="stylesheet" href="<?php echo helper::baseUrl(false) . self::DATA_DIR; ?>custom.css?<?php echo md5_file(self::DATA_DIR.'custom.css'); ?>">

Je me suis abstenu et j'ai fini par comprendre leur utilité, ils servent à recharger le cache du navigateur lors de la modification du thème. J'applique la même technique au chargement d'admin.css dans 10.3.04 :

echo '<link rel="stylesheet" href="' . self::DATA_DIR . 'admin.css?' . md5_file(self::DATA_DIR .'admin.css') . '">';

 

 

[Eric 46]

test de la version 10-4 ici : https://ericrogergarcia.legtux.org/a/test-10-4/

avec une copie des même données que mon site

(certains liens ne fonctionnent pas mais ce sont des liens faits "à la main" donc pas un problème de la nouvelle version)

 

je reviens si je découvre quelque chose de nouveau.

[Eric 46]

test de la version 10-4 ici : https://ericrogergarcia.legtux.org/a/test-10-4/

avec une copie des même données que mon site

(certains liens ne fonctionnent pas mais ce sont des liens faits "à la main" donc pas un problème de la nouvelle version)

 

je reviens si je découvre quelque chose de nouveau.

[Gilux 176]

Il y a 1 heure, Fred a dit :

Sauf que oui, cette ligne de commande a fait revenir les accents et les mois en fr.

 

Si on veut ... Mais il ne faut pas qu'il y ait d'accents :

[Fred 1 575]

Pour le test de cette v10400 @sylvainlelievre a besoin de retour d'usage du blog. Merci à tous d'ouvrir un fil de discussion par pb rencontré, je ferme celui-ci.