NPDS : Gestion de contenu et de communauté

J'avais fait un outil pour la reconnaisance de la configuration exact du serveur en ce qui concerne les paramètres de date ... il permet d'analyser la configuration et donc d'adapter celle de NPDS ... car dans les configuration des serveurs (local) on peut trouver tout et n'importe quoi ... bon je vois si je le retrouve et te dis ce sui cloche pour tes dates ...

mais à mon sens sur ce coup là ce n'est pas NPDS qui est vraiment en cause

à partir du moment où on n'obtient pas le même résultat avec !date! et !N-date! (l'un ou l'autre est OK suivant qu'on paramètre l'heure locale en fr_FR.UTF-8 ou en fr_FR) et que ca fait exactement la même chose sur deux serveurs différents, j'aurais quand même tendance à penser que c'est bien NPDS qui est en cause :#

Pour récapituler :

fr_FR.UTF-8
!date!(dans le header) OK !N_date! (dans le titre des articles) pas OK

fr_FR
!date!(dans le header)pas OK et !N_date!(dans le titre des articles) OK

:-(

c quoi le titre des article plus précisément ?...

Ndate dans le header des articles c'est l'utilisation du méta dans le fichier index-new.html

je pense qu'il faut partir avec toutes les informations:

mettre comment est configuré la bdd en encodage, l'encodage de la page, ainsi que les paramètres des dates ainsi que le code source des fichiers html.

Pour ma part, il faut savoir:
si le config au niveau Windows ou Linux est bien configuré.

Desolé des raccourcis j'écris de mon smart phone

yes ... :-? y'a effectivement un probleme npds qui n'existait pas dans la version précédente

+1 ... je n'avais pas ce problème avant de passer en REV13

je suis entrain de faire des test mais ne trouve pas encore ..

Je vais peut-être dire une bêtise, mais suis pas à une prêt.

Est-ce que le méta !N_date! ne "passerait" pas par une fonction d'encodage depuis REV13 alors que !date! est resté tel quel.

euh attend je sais pas si je me suis pas avancé un peu vite ...

juste pour dire que le problème peut se résoudre en modifiant le meta-mot !date! ainsi

return (utf8_encode($MT_date));

Mais c'est une rustine parce qu'à la prochaine MAJ il faudra recommencer et en plus faudrait faire une condition sur le charset pour ceux qui sont pas en UTF8

peut etre ... mais pour moi c'est plutôt sur N_date qu'on a un prob pas sur le metamot date qui me semble avoir un comportement correct

Là, je ne suis pas capable de dire. Pas assez compétant ... mais effectivement, comme il n'y avait pas ce problème avant :#

ça doit me crever les yeux mais je trouve pas ... :paf
meme serveur meme config juste la version de npds n'est pas la meme 11 et 13

bon j'ai trouver pourquoi ... mais je n'ai pas trouver encore la différence entre les deux versions :paf

et aussi la différence entre les deux versions...

dans theme.php ou est defini Ndate
ligne 118

   "'!N_date!'i"=>formatTimestamp($time),


dans mainfile.php dans la fonction formatTimestamp()
ligne 728,729, 730



   if (cur_charset=="utf-8") {
      $datetime = utf8_encode($datetime);
   }



ligne 728,729, 730

dans le cas qui nous intéresse site en utf-8 avec locale bien paramétré (et évidemment disponible sur le serveur)
on réencode donc en utf-8 alors que c'est déjà en utf-8 dans ce cas là d'où le problème...


donc pour moi à supprimer (ce n'était pas dans les versions précédentes) ou à affiner si ces lignes sont nécessaire dans un autre contexte d'utilisation de la fonction formatTimestamp() ...

en tous cas dans l'état celà ne peut pas fonctionner pour ce cas de figure

et pour finir cette fonction (que ce soit en iso ou utf-8) retourne du texte brut alors qu'au final elle devrait retourner du html avec ses entités comme le stipule le doc type et les meta tags ;-)

Merci jpb ... ca résoud effectivement le pb. Donc à corriger ou à compléter pour les prochaines versions.
:=! :=!

Merci de ton investissement et bon dimanche.

En résumé JP - il faudra faire quoi ? 8-)