Aide générale [PBTV3] Perte des input avec php > 5.3 probleme d'encodage de caracteres.
Le problème :
Vous êtes en local ou sur un site de test.
vous avez une version de php a dispo superieure a 5.3
Lors de la saisie de texte vos chan ou zone de texte disparaissent.
Alors
1) vous ne devenez pas fou.
2) votre installation wamp, easyphp, ou lamp n'est pas forcement en cause.
Inutile de trituré la base de donnée elle n'y est pour rien.
Avec les évolutions php passe en utf-8
Le souci c'est que pbt V3 est en Iso.
Le traitement des information soumise au CMS sont (normalement) et celon le risque passé en interne dans diverses fonction qui sécurise les input.
Le but de passé en utf-8 php est la même chose un souci de sécurité.
Le fait de basculé d'un charset a un autre peut avoir des incidences, et c'est pour cela que php par défaut les dropent.
ici le souci est du a des balises habituelle de php pour sécuriser des input :
Normalement en interne on peut faire en sorte que cela fonctionne, mais vu que pbt déclare des le debut qu'il est en iso, sa foire.
la solution est de passer les input en utf-8 , faire les traitement et repasser en iso pour le reste des traitement.
Si on ne reviens pas en iso dans la foulé, on pourrais faire cela avant l'affichage uniquement (dans une autre fonction), cela mettrais le dawa dans les informations déjà traiter.
C'est pas forcement jolie, mais c'est fonctionnel et n'est a tester que si vous avez des souci avec votre site de test/local en php supérieur a 5.3
La fonction a modifier est dans /kernel/framework/fonction.inc.php à la ligne 652 et dois au final ressemblé a :
Vous êtes en local ou sur un site de test.
vous avez une version de php a dispo superieure a 5.3
Lors de la saisie de texte vos chan ou zone de texte disparaissent.
Alors
1) vous ne devenez pas fou.
2) votre installation wamp, easyphp, ou lamp n'est pas forcement en cause.
Inutile de trituré la base de donnée elle n'y est pour rien.
Avec les évolutions php passe en utf-8
Le souci c'est que pbt V3 est en Iso.
Le traitement des information soumise au CMS sont (normalement) et celon le risque passé en interne dans diverses fonction qui sécurise les input.
Le but de passé en utf-8 php est la même chose un souci de sécurité.
Le fait de basculé d'un charset a un autre peut avoir des incidences, et c'est pour cela que php par défaut les dropent.
ici le souci est du a des balises habituelle de php pour sécuriser des input :
Code PHP :
htmlspecialchars() et htmlentities()
Normalement en interne on peut faire en sorte que cela fonctionne, mais vu que pbt déclare des le debut qu'il est en iso, sa foire.
la solution est de passer les input en utf-8 , faire les traitement et repasser en iso pour le reste des traitement.
Si on ne reviens pas en iso dans la foulé, on pourrais faire cela avant l'affichage uniquement (dans une autre fonction), cela mettrais le dawa dans les informations déjà traiter.
C'est pas forcement jolie, mais c'est fonctionnel et n'est a tester que si vous avez des souci avec votre site de test/local en php supérieur a 5.3
La fonction a modifier est dans /kernel/framework/fonction.inc.php à la ligne 652 et dois au final ressemblé a :
Code PHP :
function strparse(&$content, $forbidden_tags = array(), $addslashes = true) { $content = mb_convert_encoding($content,'utf-8', 'iso-8859-1') ; // <========================================================================================== on passe de utf8 à iso //On utilise le gestionnaire de contenu $content_manager = new ContentFormattingFactory(); //On lui demande le parser adéquat $parser = $content_manager->get_parser(); //On assigne le contenu à interpréter. Il supprime les antislashes d'échappement seulement si ils ont été ajoutés par magic_quotes $parser->set_content($content, MAGIC_QUOTES); //Si il y a des balises interdites, on lui signale if (!empty($forbidden_tags)) { $parser->set_forbidden_tags($forbidden_tags); } //Au travail maintenant ! $parser->parse(); //Renvoie le résultat. Echappe par défaut les caractères critiques afin d'être envoyé en base de données return mb_convert_encoding($parser->get_content($addslashes), 'iso-8859-1','utf-8'); // <====================================================== on passe de iso a utf8 }
Accroche toi au clavier, je retire le shell...
En gros quand tu tapes des accents é, è dans ta barre de titre des mini-module (ajout de contenu) lors de leur création, cela ne passe pas .. c'est pas grave en soit mais terriblement agaçant
Bonjour,
@saturnin, tu as essayé "d'override" le charset par défaut (UTF-8 donc) de htmlspecialchars() et htmlentities() ?
Exemple en PHP 5.4+ :
Ce qui est équivalent en PHP 5.3- à :
Cordialement, janus57 Edité par janus57 Le 08/11/2014 à 18h19
@saturnin, tu as essayé "d'override" le charset par défaut (UTF-8 donc) de htmlspecialchars() et htmlentities() ?
Exemple en PHP 5.4+ :
Code PHP :
htmlspecialchars($string, ENT_COMPAT,'ISO-8859-1', true); htmlentities($string, ENT_COMPAT,'ISO-8859-1', true);
Ce qui est équivalent en PHP 5.3- à :
Code PHP :
htmlspecialchars($string); htmlentities($string);
Cordialement, janus57 Edité par janus57 Le 08/11/2014 à 18h19
As tu la moindre idée du nombre de fois ou cette fonction est utilisée ?
Le bout de code que j'ai modifier permet de faire cela sur la fonction qui est inclus a la reception des $_POST // $_GET (donnée transitant par les formulaires)
Normalement, le fait de corriger a cet endroit dois resoudre le souci pour les modules officiels.
Mais non, ce n'est pas le cas. Ces modules étant mis a jour de version anterieure, et jamais vraiment revu, il arrive (souvent )que ce controle ne soit fait que plus loin, apres reception, et sous le coude d'un autre traitement.
donc en gros il faut tout revoir. c'est long, et de longue haleine.
Autre chose, si les pages de codes sont en utf-8 sa foire encore un peu plus le tout.
pbt déclare des le lancement des 1er protocole qu'il est en iso, donc le moindre fichier en utf-8 pose souci.
Et pour finir, ce souci actuel de 5.3 // 5.4 ne se limite pas ici, il y a encore 5.5 et 5.6 qui arrive.
A savoir au final que php aura pour charset natif l'utf-8
C'est pour cela que j'ai mis mon php en utf-8 et que je cherche une solution plus globale.
le dernier recours serais de passer pbt en utf-8, en sachant que pour tout les pbt deja en fonction ce serais une cata, et un casse tete pour chaque admin....
Le bout de code que j'ai modifier permet de faire cela sur la fonction qui est inclus a la reception des $_POST // $_GET (donnée transitant par les formulaires)
Normalement, le fait de corriger a cet endroit dois resoudre le souci pour les modules officiels.
Mais non, ce n'est pas le cas. Ces modules étant mis a jour de version anterieure, et jamais vraiment revu, il arrive (souvent )que ce controle ne soit fait que plus loin, apres reception, et sous le coude d'un autre traitement.
donc en gros il faut tout revoir. c'est long, et de longue haleine.
Autre chose, si les pages de codes sont en utf-8 sa foire encore un peu plus le tout.
pbt déclare des le lancement des 1er protocole qu'il est en iso, donc le moindre fichier en utf-8 pose souci.
Et pour finir, ce souci actuel de 5.3 // 5.4 ne se limite pas ici, il y a encore 5.5 et 5.6 qui arrive.
A savoir au final que php aura pour charset natif l'utf-8
C'est pour cela que j'ai mis mon php en utf-8 et que je cherche une solution plus globale.
le dernier recours serais de passer pbt en utf-8, en sachant que pour tout les pbt deja en fonction ce serais une cata, et un casse tete pour chaque admin....
Accroche toi au clavier, je retire le shell...
Sawk:
Bonjour,
c'est prévu dans la prochaine version (pas la V4.2 mais après il me semble), mais pas de rétro-compatibilité avec la V3, V4.0 et V4.1
Sachant que ce problème n'existe pas en V4.0 et V4.1
Cordialement, janus57
Il faudrait peut être, pour limiter la casse, que les admins de PBT code les prochaine version en prenant en compte que par défaut, php est encodé pour l'UTF-8
Bonjour,
c'est prévu dans la prochaine version (pas la V4.2 mais après il me semble), mais pas de rétro-compatibilité avec la V3, V4.0 et V4.1
Sachant que ce problème n'existe pas en V4.0 et V4.1
Cordialement, janus57
sur google code, la 3.0.11 est censée etre compatible php 5.4
mais la ou le mal blesse c'est que les modification qui fâche on été réellement apporte en php5.4.X a cause de faille.
de telle modification au niveau de php n'on pas du être aisée a prendre.
il est facile de voir tout ce qui est en jeu.
nous on a pbt de touché, mais a échelle mondiale c'est les 3/4 des site qui le sont.
une solution est de tout passer en utf-8, c'est le futur standard, mais a ce jour tout n'y est pas compatible et la transition sera dure.
On a pas fini de voir des faille de sécurité dans les sites ...
mais la ou le mal blesse c'est que les modification qui fâche on été réellement apporte en php5.4.X a cause de faille.
de telle modification au niveau de php n'on pas du être aisée a prendre.
il est facile de voir tout ce qui est en jeu.
nous on a pbt de touché, mais a échelle mondiale c'est les 3/4 des site qui le sont.
une solution est de tout passer en utf-8, c'est le futur standard, mais a ce jour tout n'y est pas compatible et la transition sera dure.
On a pas fini de voir des faille de sécurité dans les sites ...
Accroche toi au clavier, je retire le shell...
Bonsoir,
Et comment faire pour passer pbt en utf8 ? Si on m'explique je veut bien essayer.
Sinon je veut bien essayer sa aussi : http://www.phpboost.com/forum/topic-15108-3+tout-mes-texte-ne-sont-pas-enregistrer-en-base-de-donnees.php#m141274
Je suis prêt a tout, même si faut que je mis mette toute la journée pour continuer a utiliser la v3, je le ferai, la v4 moi je la trouve... bof.
Merci.
Et comment faire pour passer pbt en utf8 ? Si on m'explique je veut bien essayer.
Sinon je veut bien essayer sa aussi : http://www.phpboost.com/forum/topic-15108-3+tout-mes-texte-ne-sont-pas-enregistrer-en-base-de-donnees.php#m141274
Je suis prêt a tout, même si faut que je mis mette toute la journée pour continuer a utiliser la v3, je le ferai, la v4 moi je la trouve... bof.
Merci.
Toutes l'équipe de easy-design.net sont des personnes très gentils et vraiment très forts
Actuellement je regarde a trouver une update pour ne pas tout avoir a faire a la main.
il y a plusieurs souci, et celon la version de php et la future 5.6 sera encore plus stricte, les modification sont plus stricte.
mon php est en 5.5.9, celui de swan en 5.4, et un serveur en 5.3
Normalement je devrais arriver a sortir une modification plus efficace.
Bon c'est pas pour aujourd'hui, je suis conscient que le délai est pour hier.
je préfère prendre un peu de temps et sortir un truc qui sera pas a retouché, que un truc qui marchera que a moitié.
Passer pbt en utf-8 serais trop risqué à mon avis. La DB est en ANSI, pbt déclare ISO, et les fichier sont censer être en ISO aussi.
Dans un premier temps, modifier les variable pour les compléter, et vérifier que les fichiers sont bien en ISO devrait permettre de passer en 5.4 sans gros souci.
Mais .... a voir
il y a plusieurs souci, et celon la version de php et la future 5.6 sera encore plus stricte, les modification sont plus stricte.
mon php est en 5.5.9, celui de swan en 5.4, et un serveur en 5.3
Normalement je devrais arriver a sortir une modification plus efficace.
Bon c'est pas pour aujourd'hui, je suis conscient que le délai est pour hier.
je préfère prendre un peu de temps et sortir un truc qui sera pas a retouché, que un truc qui marchera que a moitié.
Passer pbt en utf-8 serais trop risqué à mon avis. La DB est en ANSI, pbt déclare ISO, et les fichier sont censer être en ISO aussi.
Dans un premier temps, modifier les variable pour les compléter, et vérifier que les fichiers sont bien en ISO devrait permettre de passer en 5.4 sans gros souci.
Mais .... a voir
Accroche toi au clavier, je retire le shell...
Bonjour,
@saturnin vu que tu es sur un Dédié et que tu utilise un Debian ou un OS qui permet d'avoir PHP5.6 je pense que tu n'aura pas besoin de faire de modifications majeur vu que tu as la main sur la config de PHP.
Je m'explique, d'après la doc de PHP, la branche 5.6 inclus un nouveau paramètres à savoir "default_charset", donc si je dit pas de conneries ceci devrait régler pas mal de problème pour ceux qui ont la main sur leur configuration de PHP (donc ceux sur dédié/vps ou mutualisé et qui ont accès au php.ini).
Après si tu veux je peu toujours faire un test avec la V3.0.11 et PHP5.6 en local sur du Debian, mais avec un peu (beaucoup ?) de chance le simple fait de basculer default_charset en iso-8859-1 devrait suffire à faire passer la V3.0.11 sur la branche 5.6 de PHP sans trop se casser la tête.
Et pour le passage en full UTF-8 de PHPBoost honnêtement cela prendrais plusieurs mois/années, même les dev's l'on repoussé et l'on prévu sur la version qui viens après la V4.2 tellement il y a de boulot.
Cordialement, janus57
@saturnin vu que tu es sur un Dédié et que tu utilise un Debian ou un OS qui permet d'avoir PHP5.6 je pense que tu n'aura pas besoin de faire de modifications majeur vu que tu as la main sur la config de PHP.
Je m'explique, d'après la doc de PHP, la branche 5.6 inclus un nouveau paramètres à savoir "default_charset", donc si je dit pas de conneries ceci devrait régler pas mal de problème pour ceux qui ont la main sur leur configuration de PHP (donc ceux sur dédié/vps ou mutualisé et qui ont accès au php.ini).
Après si tu veux je peu toujours faire un test avec la V3.0.11 et PHP5.6 en local sur du Debian, mais avec un peu (beaucoup ?) de chance le simple fait de basculer default_charset en iso-8859-1 devrait suffire à faire passer la V3.0.11 sur la branche 5.6 de PHP sans trop se casser la tête.
Et pour le passage en full UTF-8 de PHPBoost honnêtement cela prendrais plusieurs mois/années, même les dev's l'on repoussé et l'on prévu sur la version qui viens après la V4.2 tellement il y a de boulot.
Cordialement, janus57
saturnin:
Bonjour,
pour moi c'est pas vraiment "bugé" sachant que la dernière MAJ de la V3 (donc la V3.0.11) a été sortie à peine 3mois après la publication officiel de la branche 5.4 en RC sachant que la branche 5.4 a vraiment été jugé stable vers Mai 2012 et que le patch 3.0.11 date de juin 2012.
Donc après ceux qui sont en PHP5.6 et qui on accès à cette fonctionnalité (à savoir ceux qui sont sur VPS/Dédié voir serveur mutualisé) peuvent peut être continuer à utiliser la V3(.0.11) sans pour autant y appliquer une quelconque modifications.
Après c'est sûr cela ne passera toujours pas sur la branche 5.4 et 5.5, mais bon après la V3 date de 2009, au moment où PHP utilisé encore comme encodage par défaut ISO-8859-1 mais ou que l'encodage par défaut à commencé a être changé à partir de la branche 5.4, d'ailleurs y a pas que PHP mais aussi tous les OS qui ont migré au fur et à mesure sur UTF-8.
D'ailleurs après une recherche un peu plus approfondie de cette valeur de configuration, il serait possible de dire à PHPBoost de forcer PHP en ISO-8859-1 (via PHP en lui même ou .htaccess si l'hébergeur l'autorise).
Cordialement, janus57
le but de ma manip est de debugger la V3 pas que pour moi, mais afin de la re-rendre fonctionnelle.
Bonjour,
pour moi c'est pas vraiment "bugé" sachant que la dernière MAJ de la V3 (donc la V3.0.11) a été sortie à peine 3mois après la publication officiel de la branche 5.4 en RC sachant que la branche 5.4 a vraiment été jugé stable vers Mai 2012 et que le patch 3.0.11 date de juin 2012.
Donc après ceux qui sont en PHP5.6 et qui on accès à cette fonctionnalité (à savoir ceux qui sont sur VPS/Dédié voir serveur mutualisé) peuvent peut être continuer à utiliser la V3(.0.11) sans pour autant y appliquer une quelconque modifications.
Après c'est sûr cela ne passera toujours pas sur la branche 5.4 et 5.5, mais bon après la V3 date de 2009, au moment où PHP utilisé encore comme encodage par défaut ISO-8859-1 mais ou que l'encodage par défaut à commencé a être changé à partir de la branche 5.4, d'ailleurs y a pas que PHP mais aussi tous les OS qui ont migré au fur et à mesure sur UTF-8.
D'ailleurs après une recherche un peu plus approfondie de cette valeur de configuration, il serait possible de dire à PHPBoost de forcer PHP en ISO-8859-1 (via PHP en lui même ou .htaccess si l'hébergeur l'autorise).
Code PHP :
ini_set('default_charset', 'ISO-8859-1');
Cordialement, janus57
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie