[sf 1.4.x] slugify ne fonctionne pas après hébergement [Résolu]

[plastic1st]

Salut.

Je suis en train (d'essayer) d'héberger mon site chez 1and1.
Alors que tout fonctionne parfaitement en local, ma fonction 'slugify' ne marche pas à 100% chez 1and1 : les termes accentués sont supprimés

Voici ma fonction slugify (issue du tuto Jobeet)

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
  static public function slugify($text)
  {  
    // Replace non-letters and non-digits with "-" in the string
    $text = preg_replace('#[^\\pL\d]+#u', '-', $text);
 
    // Trim the resulting string
    $text = trim($text, '-');
 
    // Transliterate the resulting string
    if (function_exists('iconv'))
      $text = iconv('utf-8', 'us-ascii//TRANSLIT', $text);
 
    // Make the resulting string lowercase
    $text = strtolower($text);
 
    //Remove unwanted characters from the resulting string
    $text = preg_replace('#[^-\w]+#', '', $text);
 
    // Return "n-a" if the resulting string is empty
    if (empty($text))
      return 'n-a';
 
    return $text;
  }

J'ai débuggé en déplaçant mon "return $text" après chaque opération, et le problème vient de la fonction iconv, qui remplace mes "é" par des "?".
J'en déduis qu'il y a un problème d'encodage, mais dans ce cas, pourquoi est-ce que ça marche en local ??
Ma base de données est bien en utf8.
Bref, je patauge.
Est-ce que quelqu'un a déjà eu (réglé) ce problème ?
Merci d'avance pour votre aide.

[PeytaWodka]

L'hébergeur ne doit pas utiliser utf8 avec PHP, donc la fonction iconv ne fonctionne pas je pense. Il me semble que c'est précisé dans Jobeet.

[plastic1st]

Ben... a priori, si, mes pages sont bien encodées en utf8.
D'ailleurs tous les caractères accentués sont affichés correctement sur le reste de ma page. Seules les chaînes reformattées à l'aide de slugify sont incorrectes.

[PeytaWodka]

Voir http://www.symfony-project.org/jobee...Doctrine/fr/08 à l'encadré Vers une meilleure méthode slugify.

Edit : Pardon, j'avais pas vu que c'était adapté chez toi.

[plastic1st]

Oui, merci, je connais (et j'ai commencé par retourner sur cette page avant de poster mon message)

Mais ça ne répond pas à ma question.

J'ai ajouté

Code :

1
2
 
<?php echo $_SERVER['HTTP_ACCEPT_CHARSET']; ?>

sur ma page. J'obtiens "ISO-8859-1,utf-8;q=0.7,*;q=0.7 "

Donc le serveur accepte ISO-8859-1 et UTF-8.

Si je n'étais pas en UTF-8, je serais en ISO-8859-1, et donc la modification suivante :

Code :

1
2
 
      $text = iconv('ISO-8859-1', 'us-ascii//TRANSLIT', $text);

permettrait de régler le problème.

or ce n'est pas le cas...

[Michel Rotta]

C'est sans doute un peu tard, mais doctrine gère directement les champs slug, sans nécessiter que tu t'en occupe...

[plastic1st]

Ah oui ?
Et ça marche comment ?

@PeytaWodka : Merci pour ton aide.
Finalement, après avoir joué avec l'encodage de mes pages pendant trop longtemps, j'ai finalement modifié un peu ma fonction slugify, en rajoutant :

Code :

1
2
3
4
 
$find    = array("à", "á", "â", "ã", "ä", "å", "ò", "ó", "ô", "õ", "ö", "ø", "è", "é", "ê", "ë", "ç", "ì", "í", "î", "ï", "ù", "ú", "û", "ü", "ÿ", "ñ");  
$replace = array("a", "a", "a", "a", "a", "a", "o", "o", "o", "o", "o", "o", "e", "e", "e", "e", "c", "i", "i", "i", "i", "u", "u", "u", "u", "u", "n");  
$text    = str_replace($find, $replace, $text);

C'est moche, mais ça marche, et comme je n'utilise la fonction slugify que pour formatter mes url, je ne suis pas assez motivé pour passer plus de temps sur ce problème ;-)

[Michel Rotta]

Pour info :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#shema.yml  (non testé)
Matable:
  actAs:
    sluggable:
      fileds: [ champ1, champ3 ]
      # paramètres (valeurs par défaut)
      name: slug
      alias: null
      type: string
      lenght: 255
      options: []
      uniqueBy: []
      uniqueIndex: true
      builder: [Doctrine_Inflector, urlize]
      provider: ''
      indexName: ''
      unique: true
      canUpDate: false
  columns:
    champ1: 
      type: string(50.)
      notNull: true
    champ2: string(40)
    champ3: date
    champ4: string(250)
    ...

A noter que les objets d'accès aux données (sfDoctrineRoute) et les outils qui vont avec (url_for(),...) permettent alors d'utiliser indifféremment l'Id ou le slug pour désigner un enregistrement dans une table et que le changement ce fait dans la description de l'url de la route. Simple, non ?

Par contre, ceci ne peut fonctionner que pour un slug stocké, ce qui n'est pas ton cas, donc, cela ne peut pas marcher.

[plastic1st]

Ah oui, J'avais pas compris que tu faisais allusion à schema.yml.

J'utilise des champs slug (qui fonctionnent très bien, du reste!).
Mais bon, dans mon cas, c'est surtout le formatage des urls qui posait problème.

Merci pour ton aide !!

[Michel Rotta]

J'ai bien vu.

Par contre, le slug sert essentiellement à formater des url...

D'où mon premier réflexe.

Ensuite il pourrait être intéressant de démonter l'objet pour voir comme lui a résolut le problème de slug a travers celui des charset.