[Résolu] Caractères spéciaux dans les alias LISE, CustomGS, etc...

Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
#1
Code :
----------------------------------------------

Cms Version: 2.2.7

Installed Modules:

AdminSearch: 1.0.4
CGExtensions: 1.60
CGSimpleSmarty: 2.1.8
CGSmartImage: 1.22.2
CMSContentManager: 1.1.6
CSSPreprocessor: 3.0-beta1
CmsJobManager: 0.1.2
CustomGS: 3.2
DesignManager: 1.1.4
ECB2: 1.3.1
ExaExternalizer: 0.6
FileManager: 1.6.6
FilePicker: 1.0.2
LISE: 1.3.1
MenuManager: 1.50.3
MicroTiny: 2.2.2
ModuleManager: 2.1.3
Navigator: 1.0.8
News: 2.51.3
Search: 1.51.4
TinyMCE: 3.2-beta5

Config Information:

php_memory_limit:
max_upload_size: 256000000
url_rewriting: mod_rewrite
page_extension: .html
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: Europe/Zurich
permissive_smarty: false

Php Information:

phpversion: 7.1.16
md5_function: On  (Vrai)
json_function: On  (Vrai)
gd_version: 2
tempnam_function: On  (Vrai)
magic_quotes_runtime: Off  (Faux)
E_ALL: 22519
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: Aucune différence de date du système trouvée
test_db_timedifference: Aucune différence de date du système trouvée
create_dir_and_file: 1
memory_limit: 256M
max_execution_time: 60
register_globals: Off  (Faux)
output_buffering: 4096
disable_functions:
test_remote_url: Valable
file_uploads: On  (Vrai)
post_max_size: 256M
upload_max_filesize: 256M
session_save_path: Aucune vérification à cause de la restriction spécifiée par PHP open_basedir
session_use_cookies: On  (Vrai)
xml_function: On  (Vrai)
xmlreader_class: On  (Vrai)
check_ini_set: On  (Vrai)
curl: On

Performance Information:

allow_browser_cache: On  (Vrai)
browser_cache_expiry: 60
php_opcache: On  (Vrai)
smarty_cache: Off  (Faux)
smarty_compilecheck: Off  (Faux)
auto_clear_cache_age: On  (Vrai)
Server Information:

Server Software: Apache
Server Api: cgi-fcgi
Server Os: Linux 3.10.0-693.21.1.el7.x86_64 On  x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 10.0.34
Server Db Grants: Trouvé un privilège "GRANT ALL" qui semble être adapté

EDIT (27.04.2018): J'ai ajouté le bloc information ci-dessus si besoin. Mais à mon avis ça ne change rien au fait que tout le monde peux reproduire (sur sa propre install vanilla de CMSMS) le problème que j'explique ci-dessous. J'en suis quasiment sûr, mais ça reste quand-même à confirmer.

----------------------------------------------------------

Bonjour! ça faisait un bail...

Comme je continue d'utiliser CMSMS pour mes projets et que ça fait un moment que je décortique les MAJ, je sais que depuis une certaine version (2.1.6 peut-être) le staff à décidé d'implémenter le support des caractères spéciaux dans les url de cmsms...

Super, sauf que ça affecte aussi la génération des alias dans les modules...

Jusqu'a un certain point je m'en sortais en appliquant mon petit workaround, c'est à dire que j'ouvrais le fichier misc.function.php (dans le dossier lib) et je modifiais la fonction munge_string_to_url qui à la base faisait un include sur un fichier replacement.php pour pouvoir remplacer tout les caractères spéciaux.

Code :
[== PHP ==]
function munge_string_to_url($alias, $tolower = false, $withslash = false)
{
  include(dirname(__FILE__) . '/replacement.php');
  $alias = str_replace($toreplace, $replacement, $alias);
  if ($tolower == true) $alias = mb_strtolower($alias);

  // remove invalid chars
  $expr = '/[^\p{L}_\-\.\ \d]/u';
  if( $withslash ) $expr = '/[^\p{L}_\.\-\ \d\/]/u';
  $tmp = preg_replace($expr,'',$alias);

  // remove extra dashes and spaces.
  $tmp = str_replace(' ','-',$tmp);
  $tmp = str_replace('---','-',$tmp);
  $tmp = str_replace('--','-',$tmp);

  return trim($tmp);
}

Donc voilà je me disais: ok ils ont pris une décision, ils n'ont pas l'air de vouloir revenir dessus donc je m'adapte...
(workaround vraiment pas pratique soit dit en passant... chaque MAJ du cms l'écrase bien sur)

Et puis un beau jour, une version plus récente de CMSMS fait que même mon workaround ne fonctionne plus (uniquement pour les alias LISE)...
Et là le problème c'est que je ne sais plus où chercher...

(petite précision: ma modif faisait donc en sorte d'empêcher que CustomGS ou LISE ne génère des accents dans les alias)

Ma vraie question maintenant c'est: Est-ce que c'est normal que leur décision d'intégrer les accents dans les urls affecte aussi la génération des alias un peu partout (système et modules)? Ou c'est moi qui bade?

Est-ce que ça pourrait être un problème de mod_rewrite dans les paramètres php ?

Si vous pouvez m'éclairer je vous en remercie
#1
Code :
----------------------------------------------

Cms Version: 2.2.7

Installed Modules:

AdminSearch: 1.0.4
CGExtensions: 1.60
CGSimpleSmarty: 2.1.8
CGSmartImage: 1.22.2
CMSContentManager: 1.1.6
CSSPreprocessor: 3.0-beta1
CmsJobManager: 0.1.2
CustomGS: 3.2
DesignManager: 1.1.4
ECB2: 1.3.1
ExaExternalizer: 0.6
FileManager: 1.6.6
FilePicker: 1.0.2
LISE: 1.3.1
MenuManager: 1.50.3
MicroTiny: 2.2.2
ModuleManager: 2.1.3
Navigator: 1.0.8
News: 2.51.3
Search: 1.51.4
TinyMCE: 3.2-beta5

Config Information:

php_memory_limit:
max_upload_size: 256000000
url_rewriting: mod_rewrite
page_extension: .html
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: Europe/Zurich
permissive_smarty: false

Php Information:

phpversion: 7.1.16
md5_function: On  (Vrai)
json_function: On  (Vrai)
gd_version: 2
tempnam_function: On  (Vrai)
magic_quotes_runtime: Off  (Faux)
E_ALL: 22519
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: Aucune différence de date du système trouvée
test_db_timedifference: Aucune différence de date du système trouvée
create_dir_and_file: 1
memory_limit: 256M
max_execution_time: 60
register_globals: Off  (Faux)
output_buffering: 4096
disable_functions:
test_remote_url: Valable
file_uploads: On  (Vrai)
post_max_size: 256M
upload_max_filesize: 256M
session_save_path: Aucune vérification à cause de la restriction spécifiée par PHP open_basedir
session_use_cookies: On  (Vrai)
xml_function: On  (Vrai)
xmlreader_class: On  (Vrai)
check_ini_set: On  (Vrai)
curl: On

Performance Information:

allow_browser_cache: On  (Vrai)
browser_cache_expiry: 60
php_opcache: On  (Vrai)
smarty_cache: Off  (Faux)
smarty_compilecheck: Off  (Faux)
auto_clear_cache_age: On  (Vrai)
Server Information:

Server Software: Apache
Server Api: cgi-fcgi
Server Os: Linux 3.10.0-693.21.1.el7.x86_64 On  x86_64
Server Db Type: MySQL (mysqli)
Server Db Version: 10.0.34
Server Db Grants: Trouvé un privilège "GRANT ALL" qui semble être adapté

EDIT (27.04.2018): J'ai ajouté le bloc information ci-dessus si besoin. Mais à mon avis ça ne change rien au fait que tout le monde peux reproduire (sur sa propre install vanilla de CMSMS) le problème que j'explique ci-dessous. J'en suis quasiment sûr, mais ça reste quand-même à confirmer.

----------------------------------------------------------

Bonjour! ça faisait un bail...

Comme je continue d'utiliser CMSMS pour mes projets et que ça fait un moment que je décortique les MAJ, je sais que depuis une certaine version (2.1.6 peut-être) le staff à décidé d'implémenter le support des caractères spéciaux dans les url de cmsms...

Super, sauf que ça affecte aussi la génération des alias dans les modules...

Jusqu'a un certain point je m'en sortais en appliquant mon petit workaround, c'est à dire que j'ouvrais le fichier misc.function.php (dans le dossier lib) et je modifiais la fonction munge_string_to_url qui à la base faisait un include sur un fichier replacement.php pour pouvoir remplacer tout les caractères spéciaux.

Code :
[== PHP ==]
function munge_string_to_url($alias, $tolower = false, $withslash = false)
{
  include(dirname(__FILE__) . '/replacement.php');
  $alias = str_replace($toreplace, $replacement, $alias);
  if ($tolower == true) $alias = mb_strtolower($alias);

  // remove invalid chars
  $expr = '/[^\p{L}_\-\.\ \d]/u';
  if( $withslash ) $expr = '/[^\p{L}_\.\-\ \d\/]/u';
  $tmp = preg_replace($expr,'',$alias);

  // remove extra dashes and spaces.
  $tmp = str_replace(' ','-',$tmp);
  $tmp = str_replace('---','-',$tmp);
  $tmp = str_replace('--','-',$tmp);

  return trim($tmp);
}

Donc voilà je me disais: ok ils ont pris une décision, ils n'ont pas l'air de vouloir revenir dessus donc je m'adapte...
(workaround vraiment pas pratique soit dit en passant... chaque MAJ du cms l'écrase bien sur)

Et puis un beau jour, une version plus récente de CMSMS fait que même mon workaround ne fonctionne plus (uniquement pour les alias LISE)...
Et là le problème c'est que je ne sais plus où chercher...

(petite précision: ma modif faisait donc en sorte d'empêcher que CustomGS ou LISE ne génère des accents dans les alias)

Ma vraie question maintenant c'est: Est-ce que c'est normal que leur décision d'intégrer les accents dans les urls affecte aussi la génération des alias un peu partout (système et modules)? Ou c'est moi qui bade?

Est-ce que ça pourrait être un problème de mod_rewrite dans les paramètres php ?

Si vous pouvez m'éclairer je vous en remercie
#2
Les caractères spéciaux dans les URL...Une belle source d'em.... pour quel gain effectif ? Quelle idée ? Perso je préfère crier et récriminer avant de m'adapter. L'expérience montre que cela ne sert pas à grand chose, mais je me dis que la fois suivante on nous consultera peut être avant d'implémenter...
Pour votre problème malheureusement....S'il(s) pouvait(aient) avoir la bonne idée de rétropédaler en 2.3...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#2
Les caractères spéciaux dans les URL...Une belle source d'em.... pour quel gain effectif ? Quelle idée ? Perso je préfère crier et récriminer avant de m'adapter. L'expérience montre que cela ne sert pas à grand chose, mais je me dis que la fois suivante on nous consultera peut être avant d'implémenter...
Pour votre problème malheureusement....S'il(s) pouvait(aient) avoir la bonne idée de rétropédaler en 2.3...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#3
Je suis déjà content de ne pas être le seul à me dire que les caractères spéciaux dans les url c'est vraiment de la m....

Maintenant je ne sais pas comment on pourrait faire changer la chose? Car j'étais déjà tombé sur un post qui parle exactement du problème que je rencontre, mais l'issue est fermée car selon Robert Campbell (calguy1000), la personne demande une "feature request" et non pas une résolution de bug.

Pour moi c'est clairement un bug, car ça affecte la génération des alias dans système et modules, l'implémentation de l'option citée par Martin Malý n'est qu'un moyen efficace de résoudre ce bug. (Pour mieux comprendre, consulter le lien)
#3
Je suis déjà content de ne pas être le seul à me dire que les caractères spéciaux dans les url c'est vraiment de la m....

Maintenant je ne sais pas comment on pourrait faire changer la chose? Car j'étais déjà tombé sur un post qui parle exactement du problème que je rencontre, mais l'issue est fermée car selon Robert Campbell (calguy1000), la personne demande une "feature request" et non pas une résolution de bug.

Pour moi c'est clairement un bug, car ça affecte la génération des alias dans système et modules, l'implémentation de l'option citée par Martin Malý n'est qu'un moyen efficace de résoudre ce bug. (Pour mieux comprendre, consulter le lien)
#4
Si Calguy peut développer un peu, ça m'intéresse :
Citation :but implemented feature quests
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#4
Si Calguy peut développer un peu, ça m'intéresse :
Citation :but implemented feature quests
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#5
Yep... est-ce que je dois relancer le sujet moi-même en ajoutant un commentaire dans l'issue (même si elle est fermée) ? Ou bien il y aurait un moyen plus efficace ? Du style être plusieurs à mentionner ce problème et le remonter, histoire de montrer que c'est pas juste une "feature request" qu'on demande
#5
Yep... est-ce que je dois relancer le sujet moi-même en ajoutant un commentaire dans l'issue (même si elle est fermée) ? Ou bien il y aurait un moyen plus efficace ? Du style être plusieurs à mentionner ce problème et le remonter, histoire de montrer que c'est pas juste une "feature request" qu'on demande
#6
Je ne navigue pas dans les "hautes sphères" et suis bien incapable de vous conseiller sur ce point là. Dans tous les cas mieux vaut s'armer de patience en tous cas.
Le truc intéressant ce serait de connaître les raisons de cette modif et surtout les demandes qu'elle a permis de satisfaire, parce-que coller des caractères accentués dans les url, même d'un point de vue SEO, c'est quand même un poil capillotracté.
Y a sans doute une raison technique plus obscure mais là, j'avoue, elle m'échappe...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#6
Je ne navigue pas dans les "hautes sphères" et suis bien incapable de vous conseiller sur ce point là. Dans tous les cas mieux vaut s'armer de patience en tous cas.
Le truc intéressant ce serait de connaître les raisons de cette modif et surtout les demandes qu'elle a permis de satisfaire, parce-que coller des caractères accentués dans les url, même d'un point de vue SEO, c'est quand même un poil capillotracté.
Y a sans doute une raison technique plus obscure mais là, j'avoue, elle m'échappe...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#7
Ok je vais essayer d'investiguer dès que j'ai du temps, j'espère revenir ici avec quelques réponses en plus. Merci pierrepercee
#7
Ok je vais essayer d'investiguer dès que j'ai du temps, j'espère revenir ici avec quelques réponses en plus. Merci pierrepercee
#8
Alors honnêtement, avec le temps que j'ai pris pour les recherches j'ai seulement trouvé encore un autre post datant de 2016 qui parle du même problème: https://forum.cmsmadesimple.org/viewtopi...=8&t=74979

Le gars se fait rediriger sur la même issue que je citais précédemment et c'est tout...

En fait j'ai l'impression qu'ils ne veulent pas prendre le temps de comprendre la vraie nature du problème et ce qu'il engendre...

J'ai épluché tous les changelogs et release notes des versions de cmsms allant de 1.11.5 à 2.2.7 en cherchant les mots-clés: "latin" (pour "non-latin characters") / "url" / "munge"

Et leur décision d'implémenter les caractères spéciaux dans les url n'apparait nulle part (mis à part dans l'issue).
Tout ce que j'ai trouvé c'est des correspondances avec le mot-clé url, dont une correspondance qui ressort plusieurs fois à travers les différentes versions à savoir: "More fixes to the cms_url class"

Alors est-ce que "More fixes to the cms_url class" a quelque chose à voir avec tout ça, je ne saurais dire.

Bref, le fait est que j'aurais bien voulu (et je veux toujours) remonter le bug aux devs, mais on a vu que ça ne servait clairement pas à grand-chose lorsqu'on sait à l'avance qu'on va te répondre soit avec un simple lien qui te redirige sur l'issue et que même l'issue ne t'explique pas les raisons précises de leur décision.
#8
Alors honnêtement, avec le temps que j'ai pris pour les recherches j'ai seulement trouvé encore un autre post datant de 2016 qui parle du même problème: https://forum.cmsmadesimple.org/viewtopi...=8&t=74979

Le gars se fait rediriger sur la même issue que je citais précédemment et c'est tout...

En fait j'ai l'impression qu'ils ne veulent pas prendre le temps de comprendre la vraie nature du problème et ce qu'il engendre...

J'ai épluché tous les changelogs et release notes des versions de cmsms allant de 1.11.5 à 2.2.7 en cherchant les mots-clés: "latin" (pour "non-latin characters") / "url" / "munge"

Et leur décision d'implémenter les caractères spéciaux dans les url n'apparait nulle part (mis à part dans l'issue).
Tout ce que j'ai trouvé c'est des correspondances avec le mot-clé url, dont une correspondance qui ressort plusieurs fois à travers les différentes versions à savoir: "More fixes to the cms_url class"

Alors est-ce que "More fixes to the cms_url class" a quelque chose à voir avec tout ça, je ne saurais dire.

Bref, le fait est que j'aurais bien voulu (et je veux toujours) remonter le bug aux devs, mais on a vu que ça ne servait clairement pas à grand-chose lorsqu'on sait à l'avance qu'on va te répondre soit avec un simple lien qui te redirige sur l'issue et que même l'issue ne t'explique pas les raisons précises de leur décision.
#9
Désolé si je donne l'impression de faire un monologue Rolleyes mais je préfère apporter un maximum d'information dans ce post.

Je viens de tomber sur un paragraphe interessant dans le PDF officiel "Introduction to Writing modules for CMS Made Simple":

Citation :The munge_string_to_url() method will take a holiday name and translate the characters until they are all safe URL characters.

(le lien du pdf: https://docs.cmsmadesimple.org/uploads/M...torial.pdf)

Donc sachant que cette fonction ne filtre actuellement plus les caractères spéciaux (donc que la doc n'est pas à jour), ça fait que les développeurs de modules qui l'ont utilisée dans le but de générer des alias propres (par exemple), se retrouvent maintenant avec un énorme défaut au sein de leurs modules... Et qu'ils ne sont pas forcément au courant car ils ne sont pas confrontés aux caractères spéciaux dans leur routine de travail.

Et puis j'ai cité uniquement 2 modules affectés car je les utilise, mais il pourrait très bien y en avoir plus... Donc la solution de contacter chaque développeur pour leur communiquer le problème me parait peu réaliste.

Après si vraiment... il faut contacter chaque développeurs pour leur dire "hey munge_string_to_url ne convient plus pour générer des alias..." j'imagine qu'ils pourraient utiliser à la place un plugin modifier.safetext.php avec le code suivant:

Code :
<?php
function smarty_modifier_safetext($string){
    $string = preg_replace("`\[.*\]`U","",$string);
    $string = preg_replace('`&(amp;)?#?[a-z0-9]+;`i','-',$string);
    $string = preg_replace( '`"`i', "", $string);
    $string = htmlentities($string, ENT_COMPAT, 'utf-8');
    $string = preg_replace( "`&([a-z])(acute|uml|circ|grave|ring|cedil|slash|tilde|caron|lig|quot|rsquo);`i","\\1", $string );
    $string = html_entity_decode($string);
    $string = preg_replace( array("`[^a-z0-9]`i","`[-]+`") , "-", $string);
    return strtolower(trim($string, '-'));
}
?>

Ou un autre truc du genre.

Encore une chose (et après j'arrête Rolleyes ) je trouve étonnant que ce bug soit présent depuis 2016 (en tout cas) et que personne ou très peu de gens ne l'ait remarqué. Pour une communauté autre que anglophone c'est hyper handicapant et fastidieux professionnellement parlant, au point d'en venir à se poser la question "est-ce que je continue à utiliser ce cms?". J'exagère Wink mais honnêtement ce serait cool de voir apparaitre d'autres retours d'utilisateurs sur le sujet dans la communauté francophone, car pour le moment j'ai l'impression d'être le seul à en parler et y être confronté.
#9
Désolé si je donne l'impression de faire un monologue Rolleyes mais je préfère apporter un maximum d'information dans ce post.

Je viens de tomber sur un paragraphe interessant dans le PDF officiel "Introduction to Writing modules for CMS Made Simple":

Citation :The munge_string_to_url() method will take a holiday name and translate the characters until they are all safe URL characters.

(le lien du pdf: https://docs.cmsmadesimple.org/uploads/M...torial.pdf)

Donc sachant que cette fonction ne filtre actuellement plus les caractères spéciaux (donc que la doc n'est pas à jour), ça fait que les développeurs de modules qui l'ont utilisée dans le but de générer des alias propres (par exemple), se retrouvent maintenant avec un énorme défaut au sein de leurs modules... Et qu'ils ne sont pas forcément au courant car ils ne sont pas confrontés aux caractères spéciaux dans leur routine de travail.

Et puis j'ai cité uniquement 2 modules affectés car je les utilise, mais il pourrait très bien y en avoir plus... Donc la solution de contacter chaque développeur pour leur communiquer le problème me parait peu réaliste.

Après si vraiment... il faut contacter chaque développeurs pour leur dire "hey munge_string_to_url ne convient plus pour générer des alias..." j'imagine qu'ils pourraient utiliser à la place un plugin modifier.safetext.php avec le code suivant:

Code :
<?php
function smarty_modifier_safetext($string){
    $string = preg_replace("`\[.*\]`U","",$string);
    $string = preg_replace('`&(amp;)?#?[a-z0-9]+;`i','-',$string);
    $string = preg_replace( '`"`i', "", $string);
    $string = htmlentities($string, ENT_COMPAT, 'utf-8');
    $string = preg_replace( "`&([a-z])(acute|uml|circ|grave|ring|cedil|slash|tilde|caron|lig|quot|rsquo);`i","\\1", $string );
    $string = html_entity_decode($string);
    $string = preg_replace( array("`[^a-z0-9]`i","`[-]+`") , "-", $string);
    return strtolower(trim($string, '-'));
}
?>

Ou un autre truc du genre.

Encore une chose (et après j'arrête Rolleyes ) je trouve étonnant que ce bug soit présent depuis 2016 (en tout cas) et que personne ou très peu de gens ne l'ait remarqué. Pour une communauté autre que anglophone c'est hyper handicapant et fastidieux professionnellement parlant, au point d'en venir à se poser la question "est-ce que je continue à utiliser ce cms?". J'exagère Wink mais honnêtement ce serait cool de voir apparaitre d'autres retours d'utilisateurs sur le sujet dans la communauté francophone, car pour le moment j'ai l'impression d'être le seul à en parler et y être confronté.
#10
Bonjour Brick,
Pourquoi est-ce un problème d'avoir des caractères accentués dans les alias ?
#10
Bonjour Brick,
Pourquoi est-ce un problème d'avoir des caractères accentués dans les alias ?
#11
Hello Jean le Chauve!

Tout simplement car ça génère une erreur sur le front lorsque l'on veut utiliser du smarty avec accents (ou caractères spéciaux) dans un template. Smarty n'aime pas trop ça

Exemple avec le module CustomGS:

Je crée ma définition de champ et l'alias se base automatiquement sur le titre de ma definition pour se générer (petite particularité, le module ne permet pas de modifier l'alias manuellement, mais là n'est pas la question...).

Exemple de titre pour ma définition: Réglage par défaut du layout

CustomGS va me générer une balise comme ceci:

Code :
{$CustomGS.Réglage_par_défaut_du_layout}

Il y a 2 accents, je copie cette balise dans mon gabarit et là paf, j'ai mon erreur sur le front du site.

Citation :Syntax error in template "tpl_body:tpl_body:16" on line 19 "{$CustomGS.Réglage_par_défaut_du_layout}" - Unexpected "", expected one of: "}"

Et dès que j'enlève les accents de la balise, tout fonctionne.

Donc comme je le disais, c'est le cas pour CustomGS mais aussi pour LISE et le module Gallery... Donc déjà 3 modules

Pour reparler de la partie historique de munge_string_to_url, tout ce qui étais génération des alias (dans le cms et les modules), fonctionnait parfaitement avant qu'ils décident d'implémenter les caractères spéciaux dans les urls. Tous les alias étaient générés sans accents, donc c'est là que je me dis que c'est un bug majeur de cmsms.

Maintenant peut-être que je ne suis pas assez experimenté pour me rendre compte qu'il y a une solution hyper évidente pour éviter ces "Syntax error in template" mais à mon avis je pense plutôt que c'est logique que Smarty n'accepte aucun accents dans sa syntaxe.
#11
Hello Jean le Chauve!

Tout simplement car ça génère une erreur sur le front lorsque l'on veut utiliser du smarty avec accents (ou caractères spéciaux) dans un template. Smarty n'aime pas trop ça

Exemple avec le module CustomGS:

Je crée ma définition de champ et l'alias se base automatiquement sur le titre de ma definition pour se générer (petite particularité, le module ne permet pas de modifier l'alias manuellement, mais là n'est pas la question...).

Exemple de titre pour ma définition: Réglage par défaut du layout

CustomGS va me générer une balise comme ceci:

Code :
{$CustomGS.Réglage_par_défaut_du_layout}

Il y a 2 accents, je copie cette balise dans mon gabarit et là paf, j'ai mon erreur sur le front du site.

Citation :Syntax error in template "tpl_body:tpl_body:16" on line 19 "{$CustomGS.Réglage_par_défaut_du_layout}" - Unexpected "", expected one of: "}"

Et dès que j'enlève les accents de la balise, tout fonctionne.

Donc comme je le disais, c'est le cas pour CustomGS mais aussi pour LISE et le module Gallery... Donc déjà 3 modules

Pour reparler de la partie historique de munge_string_to_url, tout ce qui étais génération des alias (dans le cms et les modules), fonctionnait parfaitement avant qu'ils décident d'implémenter les caractères spéciaux dans les urls. Tous les alias étaient générés sans accents, donc c'est là que je me dis que c'est un bug majeur de cmsms.

Maintenant peut-être que je ne suis pas assez experimenté pour me rendre compte qu'il y a une solution hyper évidente pour éviter ces "Syntax error in template" mais à mon avis je pense plutôt que c'est logique que Smarty n'accepte aucun accents dans sa syntaxe.
#12
Ok, je vois, ce n'est pas l'url qui te gêne, car, n'en déplaise à Pierrepercée, c'est une bonne innovation : depuis 2010 l'icann a autorisé cela pour les langues arabes, chinoises...
Tu aurais peut-être plus de chance de te faire comprendre en écrivant dans le topic des modules : https://forum.cmsmadesimple.org/viewforum.php?f=7 en montrant l'exemple que tu viens de me donner.
Il y a déjà un autre post à ce sujet, peut-être que l'auteur a trouvé une façon de le contourner, tu devrais lui envoyer un message : https://forum.cmsmadesimple.org/viewtopi...as#p336178
Si ça foire, la solution la plus simple est de de ne pas mettre d'accent dans les définitions de champ Sad .
Bonne chance.
#12
Ok, je vois, ce n'est pas l'url qui te gêne, car, n'en déplaise à Pierrepercée, c'est une bonne innovation : depuis 2010 l'icann a autorisé cela pour les langues arabes, chinoises...
Tu aurais peut-être plus de chance de te faire comprendre en écrivant dans le topic des modules : https://forum.cmsmadesimple.org/viewforum.php?f=7 en montrant l'exemple que tu viens de me donner.
Il y a déjà un autre post à ce sujet, peut-être que l'auteur a trouvé une façon de le contourner, tu devrais lui envoyer un message : https://forum.cmsmadesimple.org/viewtopi...as#p336178
Si ça foire, la solution la plus simple est de de ne pas mettre d'accent dans les définitions de champ Sad .
Bonne chance.
#13
Voilà plus d'1 an que je n'ai plus ouvert le cms, mais n'y a-t-'il pas la possibilité d'ajouter un event au moment d'enregistrer la nouvelle page qui appellerait une udt de remplacement d'alias ?
#13
Voilà plus d'1 an que je n'ai plus ouvert le cms, mais n'y a-t-'il pas la possibilité d'ajouter un event au moment d'enregistrer la nouvelle page qui appellerait une udt de remplacement d'alias ?
#14
Salut Jean,

Cela faisait longtemps, tu utilises une autre plateforme ? Malheureusement le fait que l'icann l'autorise hein..., cela fait une très jolie jambe à nos clients! En matière de SEO (cela intéresse 99,99% de nos clients non ?) la littérature est abondante, pour Google (plus de 90% des recherches ici), les accents dans les url, c'est niet. Voir ce qu'en dit Olivier Duffez ici
Amazon semble les utiliser mais..non, si on fait un copier collé de l'url dans le notepad, c'est la version avec entités html.. Faut se méfier des apparences. Pour la Fnac, ils ont viré les accents... et l'on peut multiplier les exemples à l'envie.

Dans tous les cas l'intérêt de les implémenter en introduisant ce faisant de nombreux bugs ? Parce que l'icann les autorise.. Je ne souhaite pas polémiquer inutilement mais le plaidoyer est un peu court. Réponse: toujours la même, je ne sais pas !
Peut être une explication technique pointue ou une architecture mal pensée qui ferait qu'à un moment cela arrange de pouvoir passer des caractères accentués dans les url.
Aucun intérêt du point de vue utilisateurs et le recours à des rustines indigentes pour palier les difficultés rencontrées.
Quelle perte de temps et d'efficacité. Un petit sondage pour les utilisateurs réguliers de CMSMS, souhaitez-vous implémenter les caractères accentués dans les URL-> Oui/non -> non, on parle de choses plus utiles ! Smile

J'oubliais l'url rewritting toujours jouable pour aller chercher d'improbables niches SEO pour les plus intrépides...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#14
Salut Jean,

Cela faisait longtemps, tu utilises une autre plateforme ? Malheureusement le fait que l'icann l'autorise hein..., cela fait une très jolie jambe à nos clients! En matière de SEO (cela intéresse 99,99% de nos clients non ?) la littérature est abondante, pour Google (plus de 90% des recherches ici), les accents dans les url, c'est niet. Voir ce qu'en dit Olivier Duffez ici
Amazon semble les utiliser mais..non, si on fait un copier collé de l'url dans le notepad, c'est la version avec entités html.. Faut se méfier des apparences. Pour la Fnac, ils ont viré les accents... et l'on peut multiplier les exemples à l'envie.

Dans tous les cas l'intérêt de les implémenter en introduisant ce faisant de nombreux bugs ? Parce que l'icann les autorise.. Je ne souhaite pas polémiquer inutilement mais le plaidoyer est un peu court. Réponse: toujours la même, je ne sais pas !
Peut être une explication technique pointue ou une architecture mal pensée qui ferait qu'à un moment cela arrange de pouvoir passer des caractères accentués dans les url.
Aucun intérêt du point de vue utilisateurs et le recours à des rustines indigentes pour palier les difficultés rencontrées.
Quelle perte de temps et d'efficacité. Un petit sondage pour les utilisateurs réguliers de CMSMS, souhaitez-vous implémenter les caractères accentués dans les URL-> Oui/non -> non, on parle de choses plus utiles ! Smile

J'oubliais l'url rewritting toujours jouable pour aller chercher d'improbables niches SEO pour les plus intrépides...
Win 10 pro 64 - CMSMS 2.2.19 - grincheux parfois...
#15
Salut Pierre,
Non, je ne travaille plus et j'ai un autre hobby, mais je continue à suivre le forum en mode quiet.
Bonne continuation à vous
#15
Salut Pierre,
Non, je ne travaille plus et j'ai un autre hobby, mais je continue à suivre le forum en mode quiet.
Bonne continuation à vous
#16
Bonjour tout le monde, j'espère que vous avez passé un bon weekend.

Déjà merci pour vos retours, je me sens moins seul sur la problématique Wink

Ensuite je suis navré mais je n'ai malheureusement plus de temps à consacrer à ce problème... J'en ai déjà trop pris à l'exposer ici dans ce post. De plus, je vais être amené à peut-être changer de techno tout prochainement, ce qui fait que (selon moi) ce sera aux "hautes sphères" de s'en occuper si vraiment ça devient problématique et/ou que ça les concernent Wink ce qui n'a pas l'air d'être le cas pour le moment.

Le fait est aussi (j'avoue) que les devs CMSMS de la communauté anglophone n'en ont pas grand-chose à cirer de ce souci, même lorsqu'il est reporté plusieurs fois. Ce qui me démotive aussi globalement à aller plus loin honnêtement.

Je suis content d'avoir pu détailler ce bug et d'en avoir discuté, même si j'aurai aussi voulu avoir l'avis de 1 ou plusieurs admins du forum FR. Si c'est un jour résolu tant-mieux, sinon tant-pis. Je pense avoir rempli mon rôle Smile

À tout bientôt j'espère! Je continue à suivre cette discussion dans le cas où (je l'espère aussi) ça évoluerait.
#16
Bonjour tout le monde, j'espère que vous avez passé un bon weekend.

Déjà merci pour vos retours, je me sens moins seul sur la problématique Wink

Ensuite je suis navré mais je n'ai malheureusement plus de temps à consacrer à ce problème... J'en ai déjà trop pris à l'exposer ici dans ce post. De plus, je vais être amené à peut-être changer de techno tout prochainement, ce qui fait que (selon moi) ce sera aux "hautes sphères" de s'en occuper si vraiment ça devient problématique et/ou que ça les concernent Wink ce qui n'a pas l'air d'être le cas pour le moment.

Le fait est aussi (j'avoue) que les devs CMSMS de la communauté anglophone n'en ont pas grand-chose à cirer de ce souci, même lorsqu'il est reporté plusieurs fois. Ce qui me démotive aussi globalement à aller plus loin honnêtement.

Je suis content d'avoir pu détailler ce bug et d'en avoir discuté, même si j'aurai aussi voulu avoir l'avis de 1 ou plusieurs admins du forum FR. Si c'est un jour résolu tant-mieux, sinon tant-pis. Je pense avoir rempli mon rôle Smile

À tout bientôt j'espère! Je continue à suivre cette discussion dans le cas où (je l'espère aussi) ça évoluerait.
#17
Bonjour à tous,

je rejoins le sujet que je n'ai pas suivi - pour la problématique de CustomGS :
Code :
{$CustomGS.Réglage_par_défaut_du_layout}

Il suffit simplement d'utiliser l'autre syntaxe pour la clé du tableau :
Code :
{$CustomGS['Réglage_par_défaut_du_layout']}

Pour LISE, j'utilise les accents dans les URLs sans difficultés, mais j'ai peut-être mal compris le problème ?
#17
Bonjour à tous,

je rejoins le sujet que je n'ai pas suivi - pour la problématique de CustomGS :
Code :
{$CustomGS.Réglage_par_défaut_du_layout}

Il suffit simplement d'utiliser l'autre syntaxe pour la clé du tableau :
Code :
{$CustomGS['Réglage_par_défaut_du_layout']}

Pour LISE, j'utilise les accents dans les URLs sans difficultés, mais j'ai peut-être mal compris le problème ?
#18
Bonjour airelibre Smile

Brick (donc moi) a écrit :Maintenant peut-être que je ne suis pas assez experimenté pour me rendre compte qu'il y a une solution hyper évidente pour éviter ces "Syntax error in template"

Rolleyes Bon alors comment dire... Un grand merci pour cette solution qui je pense, en tant qu'utilisateur manquant encore cruellement d’expérience, me satisfait pleinement.

ça résout les soucis que j'avais un peu partout, même si dans LISE j'ai du faire un peu plus d'adaptations, notamment concernant un système de pagination. Mais bref, je pense que le sujet peut être fermé

Et ma fois désolé, c'était peut-être beaucoup de blabla pour pas grand-chose je ne sais pas... mais toujours est-il que (je le répète), je n'avais aucuns de ces soucis avant qu'ils n'intègrent les caractères spéciaux dans les urls. Pour moi ça a créé un changement un peu violent, dans le sens ou j'ai du adapter plein de choses dans l'utilisation normale de CMSMS et des modules. Si j'avais eu connaissance de cette technique les choses auraient été différentes.

Je maintient cependant qu'un switch "Autoriser les caractères spéciaux dans les urls" OUI/NON dans les réglages globaux aurait été bien. Je ne m'y connais pas énormément en SEO mais comme le disait pierrepercee, si ça doit influencer de manière négative le référencement, raison de plus pour ajouter cette fonctionnalité de switch, à gérer selon les préférences de chacun. Avec comme réglage par défaut sur OUI pour toutes les installations, comme ça tout le monde est content Cool

Un grand merci et bonne continuation à tous!
#18
Bonjour airelibre Smile

Brick (donc moi) a écrit :Maintenant peut-être que je ne suis pas assez experimenté pour me rendre compte qu'il y a une solution hyper évidente pour éviter ces "Syntax error in template"

Rolleyes Bon alors comment dire... Un grand merci pour cette solution qui je pense, en tant qu'utilisateur manquant encore cruellement d’expérience, me satisfait pleinement.

ça résout les soucis que j'avais un peu partout, même si dans LISE j'ai du faire un peu plus d'adaptations, notamment concernant un système de pagination. Mais bref, je pense que le sujet peut être fermé

Et ma fois désolé, c'était peut-être beaucoup de blabla pour pas grand-chose je ne sais pas... mais toujours est-il que (je le répète), je n'avais aucuns de ces soucis avant qu'ils n'intègrent les caractères spéciaux dans les urls. Pour moi ça a créé un changement un peu violent, dans le sens ou j'ai du adapter plein de choses dans l'utilisation normale de CMSMS et des modules. Si j'avais eu connaissance de cette technique les choses auraient été différentes.

Je maintient cependant qu'un switch "Autoriser les caractères spéciaux dans les urls" OUI/NON dans les réglages globaux aurait été bien. Je ne m'y connais pas énormément en SEO mais comme le disait pierrepercee, si ça doit influencer de manière négative le référencement, raison de plus pour ajouter cette fonctionnalité de switch, à gérer selon les préférences de chacun. Avec comme réglage par défaut sur OUI pour toutes les installations, comme ça tout le monde est content Cool

Un grand merci et bonne continuation à tous!


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)