Sujet fermé
Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5

[Résolu] Caractères spéciaux dans les alias LISE, CustomGS, etc...
#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.
Sujet fermé


Messages dans ce sujet

Atteindre :


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