[pierrepercee]

#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 2.2.2
#~ Url du site :
#~ Hébergeur / Soft :
#~ Informations Système :
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Tiens, si quelques courageux, téméraires, ont installé la version 2.2.2, sous Wamp, j'ai la flemme de regarder en ligne,
essayez donc de créer un nouveau contenu, et d'y écrire le mot "jusqu'à" dans MicroTiny : c'est irrésistible !
Visiblement une apostrophe suivie d'un "à" et plus moyen d'envoyer ou d'appliquer. En fait ça applique mais ça retourne une zolie erreur d'encodage. Allez courage, encore 1 heure de perdue pour détecter le truc.

Code :

[== Indéfini ==]
ERROR: Incorrect string value: '\xC3' for column 'word' at row 1

J'imagine la tête d'un organisme public qui doit faire des mises à jour régulières. Le webmaster n'a pas vu le truc (il a ouvert deux ou trois pages après mises à jour...)
L'absence de versions de test n'est pas juste préjudiciable à CMSMS : c'est entrain de le flinguer à vitesse grand V. :/

[jce76350]

Tiens, si quelques courageux, téméraires, ont installé la version 2.2.2, sous Wamp

ha ... windaube c'est vraiment de de la "d a u be" :/
Cela fonctionne sous un système type Gnu-Linux sans soucis

J'imagine la tête d'un organisme public qui doit faire des mises à jour régulières

[Avec ma mauvaise fois réaliste] ha oui mais il faut en général depuis un certain temps, pour les mises à jour attendre la version n.3 pour la 2.2.x donc attendre le 2.2.3 :lol: [/Avec ma mauvaise fois réaliste]

[pierrepercee]

On pense ce qu'on veut de Windows, moi pas du bien Reste qu'une bonne partie du développement se fait sous Wamp (pas envie de faire un dualboot, pas le temps de monter un autre poste dédié développement etc...). Et puis 99,9999% des autres CMS s’accommodent de cette contrainte.
A partir de là on peut jouer au casuiste pour éviter les constats déplaisants, mais c'est ainsi et je doute fort que cela change sous l'influence (hautement respectable) des développeurs de CMSMS .
Résultat: j'aimerai bien connaître les stats de fréquentation du forum .org entre 2009 disons et 2017, histoire de rire jaune.

Quelqu'un pour confirmer le bug sous Wamp ? (ça prend deux secondes)

[airelibre]

Je viens d'installer Wamp et je confirme le problème.

Si on ajoute un espace après l'apostrophe, ca fonctionne - il doit y avoir un problème sur le décodage des entités html avant l'envoi vers le module de recherche, et ce sur un apostrophe suivi d'une lettre avec accents ou caractère spécial encodé par MicroTiny.

Je te conseille de remonter le bug sur http://dev.cmsmadesimple.org/bug/list/6

Merci

[Eric11]

Même chose sur WampDevelopper Pro.
Tester avec TinyMce 3.2-beta2 même message d'erreur.
Par contre dans les deux cas le contenu est bien enregistré.

[pierrepercee]

Bon j'ai signalé la chose Merci d'avoir confirmé!

[pierrepercee]

Bon Calguy n'est pas équipé pour tester sous environnement Windows. Je viens de faire un test en 2.2.5 avec un Wampserver neuf en 3.19, php 7.1.9, Mysql 5.7.19. Le bug est toujours d'actualité or il ne s'agit pas d'un petit détail.
AirLibre peux-tu me dire à qui je dois l'assigner pour qu'un développeur y jette un œil ?
Sur CMSMS, c'est assez curieux on travaille bien en utf-8 mais on continue d'encoder les entités HTML pour les enregistrer dans la base de données, du coup on retouve "jusqu'à"
J'ai installé Drupal, Wordpress et Joomla, aucun ne traîne ces vieilleries en base de données. Cela me semble tout compliquer pour la recherche plein texte etc...
Pour les 2 concurrents sérieux toutes les tables sont en innodb, tiens donc , ça me rappelle un truc..., avec un interclassement utf8mb4_unicode_ci pour Joomla et utf8mb4_general_ci pour Drupal.

Bon mais dans l'immédiat c'est d'une vilaine rustine dont on a besoin !

[pierrepercee]

Bien vu AireLibre, le fait de changer l'interclassement de la table "cms_module_search_items_seq" au niveau de la table puis au niveau de la colonne "id" de "latin1_swedish_ci" en "utf8_general_ci" permet de retrouver un fonctionnement normal.

Pour info sous Wamp 3.1 voici la liste des tables avec un mauvais interclassement (et pour cause l'interclassement n'est pas précisé lors de la création des tables...d'où un comportement différent entre Windows avec Wampserver et Linux):


Ce serait bien de remonter l'info et de faire en sorte également que les modules tierce partie créent correctement les tables.

La version 2.3 étant encore loin, cela pourrait peut être faire l'objet d'un peu d'attention....

[pierrepercee]

Salut,

Quelqu'un pour me dire si ce problème a été examiné. L'avantage c'est que 90% des modules tierce partie les plus utilisés sont développés par Calguy. Avoir une structure de base de donnée complètement indépendante de l'OS utilisé, ce n'est un pas un luxe. Systématiser la déclaration d'interclassement et le jeux de caractères utilisés à la création de chaque table: en voila une bonne idée.
En attendant si je pouvais avoir une petite remontée d'info pour savoir si c'est prévu pour la 2.3 ce serait particulièrement bienvenu. Parce qu'il y a parfois des silences bruissants....

[airelibre]

Pas à ma connaissance, mais je te garde sous le coude - j'avoue être relativement en retrait en ce moment car très chargé ... je regarde dès que je peux

[pierrepercee]

Salut Aire Libre,

Merci de ta réponse. Le bug en lui même n'est pas trop pénalisant mais il aura au moins permis de mettre le nez sur ce problème de structure en fonction des environnements qui pourrait à terme avoir des "effets de bord" autrement plus problématiques....

[pierrepercee]

Des nouvelles ?

[Eric11]

Test sous 2.2.5 puis 2.2.6 (Windows 10 + WampDeveloperPro), le problème est toujours là.

Eric

[pierrepercee]

Merci du retour,

pour l'heure je n'en sais pas plus. Cela traine déjà depuis plusieurs mois. Avoir la même structure de base de données sous Windows et Linux, cela me semble indispensable mais n'étant pas développeur (hard) j'ai du mal à évaluer les conséquences et l'ampleur du travail.
J'imagine volontiers qu'en terme de rétro compatibilité cela peut avoir des conséquences non négligeables (qu'advient-il pour certains caractères si l'on change l'interclassement de la table....)
Préciser explicitement l'interclassement à chaque création de table c'est sans doute assez facile à mettre en œuvre, mais changer l'interclassement des tables avec une requête lors d'une éventuelle mise à jour c'est sans doute plus risqué...
Encore un joli chantier en perspective !
Si Aire Libre passe dans le coin il pourra peut être nous en dire un peu plus.
Je n'ai obtenu aucune réponse de Calguy donc wait and see !
J'espère que cela pourra être corrigé pour la version 2.3.

[airelibre]

Je viens de tester sous windows avec wamp, en php 7.0 sur deux nouvelles installs :
- une avec l'interclassement de la DB par défaut (latin1_swedish_ci)
- une avec interclassement utf8_general_ci

Dans le premier cas, certaines tables sont installées en latin1, les autres en utf8
Dans le second, toutes les tables sont en utf8
A noter que la table cms_content_props est dans les deux cas en utf8

Et dans les deux cas, le fait d'ajouter "jusqu'à" dans une page ne pose pas de problème.

Maintenant j'imagine que le problème survient dès lors qu'on fait un upgrade d'une ancienne version qui serait elle tout en latin1... Sais-tu pierrepercee depuis quelle version tu avais fait la mise à jour ?
Il me semble dès lors compliqué de changer directement l'interclassement d'une table sans tout casser (PMA a peut être des outils pour cela ? Je ne crois pas que le simple fait de changer l'interclassement dans la structure change les données elles-mêmes)

A suivre !

[archeo]

Les accents et le apostrophes agaces Robert enfin c'est l'impression que j'ai eu lors des tests de la version 2.0. Personnellement je fuis TinyMce et pas seulement sur CMSmadesimple car systématiquement il bousille le texte dés qu'il y a des accents. Au passage il semble q il y ait des fanatiques qui maintenant ecrivent le français sans apostrophes ni accents.

[jce76350]

Les accents et le apostrophes agaces

ben oui car il faut modifier le code pour s'adapter

Par contre je n'ai pas de problème d'accents sur TinyMce ou MiroTiny sur les textes.

[pierrepercee]

@airlibre: non non, il s'agissait de nouvelles versions installées uniquement pour les tests, idem pour eric11 je suppose. Je ferai de nouveaux tests avec un Wampserver neuf (le mien j'ai bien du gratter 2 ou 3 fichiers) mais la chose semble largement confirmée...
J'espère que ce sera bientôt réglé et que ces s.... d'incompatibilités avec Windows ne seront plus qu'une vieille histoire.
Les autres plateformes l'ont fait de longue date : certaines d'entre elles de part leur positionnement visent un public peut être plus spécifiquement Linuxien que CMSMS dont le nom même incline à penser que....
Dans le développement, il y a ce qu'on aime faire, développer de nouvelles applis, plugins, classes, fonctionnalités, et le reste... je veux dire ce qui emm... tous les développeurs du monde : les phases de test poussées, les questions de compatibilité multi-systèmes etc...
Après qu'il s'agisse de développement bénévole ou professionnel, la deuxième partie n'est malheureusement pas à considérer comme une simple option

[airelibre]

Il est sûr que c'est la partie la moins sympa les tests Tiens-nous au courant de tes futurs tests, et si tu as une position où je pourrai re-tester et vérifier sur les dernières versions, ce serait top. Il me semblait avoir pu reproduire il y a quelques temps, mais plus avec la version récemment installée.

[pierrepercee]

Je confirme pour la énième fois le bug. Pour être le plus précis possible:
w10 neuf, iso tout juste téléchargé chez Krosoft, formatage et installation
version de CMSMS: 2.2.6 téléchargée sur le .org, vesion non francisée format zip
Wampserver 3.10 v(tout neuf aussi)
Apache 2.4.27
PHP 7.0.23 ou 5.6.31
MYSQL 5.7.19

Toujours la même erreur :

Code :

[== Indéfini ==]
ERROR: Incorrect string value: '\xC3' for column 'word' at row 1

Et toujours une liste de tables avec un interclassement inapproprié :



Aire Libre, je saisis mal, tu souhaites que je t'ouvre une url sur un poste Windows avec un wampserver actif ? Pas possible pour les raisons que tu imagines...
Par contre la reproduction du Bug ne pose absolument aucun problème. Je trouve d'ailleurs la copie d'écran de PhpMyAdmin assez parlante. J'avoue volontiers : quand j'ai vu le nombre de tables affectées par un mauvais interclassement, je me suis dit que parler de version Beta, de procédures de test, de dispo d'une nightly build, cela relève plutôt du folklore ! Là c'est juste pas très sérieux...

[airelibre]

@pierrepercee Non je ne souhaite pas d'accès à ton windows

Quand tu crée ta base, tu sélectionne quoi comme interclassement ?

En l'occurrence dans ta capture, les tables concernées ne sont que les tables _seq et l'interclassement en latin1 ne devrait pas poser de pb (ce n'est qu'un numéro à chaque fois). Les reste est en utf8_general(ou)unicode_ci ?
Ou peut être en utf8mb4_XXX_ci ?

[pierrepercee]

Je crée un nouvel utilisateur et je coche "Créer une base portant son nom et donner à cet utilisateur tous les privilèges sur cette base" ce qui reste la façon la plus simple/ standard de procéder. Wampserver ne demande donc pas l'interclassement.
Les autres tables ont un interclassement utf8_general_ci.
Il est tout à fait anormal d'avoir des interclassements différents en fonction des environnements(Linux/Windows). Ceux-ci doivent être explicitement déclarés lors de la création des tables. Pour prendre un exemple plus parlant, Drupal et Joomla gèrent correctement la chose depuis belle lurette... CMSMS n'est pas un "bricolage", c'est utilisé par des centaines de milliers de personnes. Il est logique, normal que des bugs soit identifiés, le contraire relèverait du miracle. Que des bugs de cette farine soient mis à jour sans que l'on rencontre de réponse articulée et audible sur le sujet après plusieurs mois de la part de l'équipe de développement ça me paraît un brin plus problématique...

[airelibre]

Je viens de lire le code de l'installateur, et l'encodage et interclassement sont bien spécifiés pour les tables hors _seq (respectivement utf8 et utf8_general_ci).
Voyez la version "expanded" de CMSMS (l'accès au code est plus simple), dans app/install/schema.php - ligne 98 sur cmsms 2.2.6

Et il semble que c'est ce que tu as sur PHPMyAdmin d'après tes infos. De mon côté sous cette configuration et sous le même Wamp / même windows, je n'ai pas de problème de message d'erreur à l'enregistrement.

Je tâcherai de refaire des tests sur une autre machine demain

[airelibre]

Retenté ce matin, et quand les tables sont en utf8, je retrouve à présent l'erreur sur Wamp (aucun pb sous linux, j'ai retesté également).

Quand les tables sont en latin1, pas de soucis sous windows.

Je vais creuser de ce côté là et du côté du module Search (si on désactive la recherche dans la page via l'onglet "Options", pas de problème non plus)

[jce76350]

Je pense que le soucis vient de Windows qui ne sait pas gérer le utf8 tout simplement et donc rien a voir avec le CMS