Limiter la longueur d’une chaîne avec TWIG et le filtre truncate

Avec TWIG, il est possible d’appliquer des filtres à nos variables, et des fonctionnalités semblables à la function truncate() utilisée avec PHP. Pour pouvoir utiliser ces filtres, il est nécessaire d’activer certaines extensions TWIG.

L’extension dont nous avons besoin pour limiter la longueur d’une chaîne est l’extension text. Sans avoir ajouté cette extension, vous avez l’erreur suivante:

The filter « truncate » does not exist in …

Pour l’activer, rendez vous dans votre config.yml, et rajoutez dans le service suivant :

//app/config/config.yml
services:
    twig.extension.text:
       class: Twig_Extensions_Extension_Text
       tags:
           - { name: twig.extension }

 

A partir de là, vous pouvez depuis votre template utiliser le filtre Truncate, avec la syntaxe suivante :

{# in twig template #}
{{ myString | truncate(20, false, '') }}
{# cette première utilsation coupe directement la chaîne myString #}
{{ myString | truncate(20, true, '...') }}
{# cette deuxieme utilsation coupe la chaîne myString en rajoutant ' ... ' à la suite #}

Une autre méthode pour couper une chaîne de caractères avec Twig est de faire comme suivant :

{{ uneVideo.titreVideo[:25] }}

C’est assez explicite aussi de cette façon ! Néanmoins, cette méthode ne permet pas de rajouter des points de suspension en fin de chaîne tronquée… mais si vous avez la solution, je veux bien la connaître par curiosité ;) !

Comparer deux dates avec TWIG

Lors du développement d’un projet, il est fréquent de devoir comparer deux dates. Grâce à TWIG, c’est très pratique de manipuler les objets mais aussi d’en faire autant avec les dates, et ceci sensiblement de la même manière qu’avec PHP et sa fonction date();

Voici la syntaxe TWIG à utiliser dans un template :

{% if "now"|date('Ymd')  > evenement.date|date('Ymd') %}
   Mon évènement est terminé
{% else %}
   Mon évènement est à venir / en cours
{% endif %}

Attention à bien vérifier l’ordre ‘Ymd’ comme paramètre de date(), en étant étourdi on arrive vite à des résultats improbables : 20121005 (YearMonthDay) n’est pas égal à 05102012 (DayMonthYear).

De même que date(‘Ymd’) n’est pas égal à date(‘Y m d’).

Indexation indésirable sur les moteurs de recherche

Lors du développement d’un projet, il est utile de prévoir une version développement, ou de pré-prod. Cette version permet d’une part d’avoir une version dite de « répétition générale », mais aussi de pouvoir faire une présentation des prochaines mises à jour à une personne tierce (comme un commanditaire par exemple). Par habitude, je mets cette version accessible sur l’adresse dev.mon-site.com avant de la rendre accessible sur l’adresse principale www.mon-site.com. Récemment, en utilisant comme d’habitude une version de dev, je me suis rendu compte que mon URL dev.mon-site.com était d’ores et déjà indéxée par Google.

Constat et analyses

Aujourd’hui, la plupart des internautes recherchent un site en tapant son URL dans le moteur de recherche google, et pas dans la barre d’adresse. C’est en observant un ami tentant de rejoindre la version de dev que j’ai remarqué justement, qu’en entrant l’expression/url mon-site.com sur Google, il lui était proposé ma version dev.mon-site.com. Ce n’est pas une catastrophe en soit, mais ça pourrait le devenir si certaines rectifications ne sont réalisées. Explications.

Tout d’abord, si le site à lancer vise à faire un ‘buzz’ ou un quelconque effet de lancement : permettre à certains internautes d’accéder à la version non-finale présente en dev ferait perdre une grande partie de l’effet d’annonce en dévoilant une partie du futur produit.

Deuxième gros désavantage : au point de vue référencement SEO. En effet, chaque référenceur sait que pour conserver un maximum de pertinence aux yeux des moteurs, un contenu (donc une page) doit être accessible par une et une seule adresse. 2 URLs pour un même contenu est donc pénalisant. Or, dans notre cas, il existe une page dev.mon-site.com/page-a et dans un futur proche (lors de la sortie officiel du site) une du type mon-site.com/page-a. Ces deux pages possèdent/posséderont exactement le même contenu, mais accessibles depuis 2 URL différentes.

La solution

Pour les débutants en SEO, la solution est simple : indiquer aux robots indexeurs de ne pas indexer la version de dev avec la connue balise méta suivante :

<meta name="robots" content="noindex,nofollow">

Le « noindex » indique aux robots d’une part de ne pas indexer les pages qui contiennent cette balise méta, et le nofollow de ne pas suivre les liens présents sur cette page.

Dans certains cas, il est suffisant d’indiquer seulement la requete « noindex » sur la page d’index, puisque tous les liens partent depuis cette page. En revanche, si des liens de cette page index pointent vers des sites externes, il peut y avoir des fuites. L’exemple simple serait qu’un webmaster remarque dans ses statistiques des visites en provenance de dev.mon-site.com/.

Mais… d’où ?

Google indexe les pages dans ses bases de données en naviguant sur l’Internet au fil des liens qu’il croise. Chaque fois qu’il croise une URL qu’il ne connait pas, il s’empresse de l’enregistrer et de faire sa tambouille habituelle.Dans le cas rencontré, il s’agit d’une version de dev, dont l’URL n’a été indiquée nulle-part, et encore moins mis à la disposition de l’Internet via des liens. Mais alors comment cette URL dev.mon-site.com a t-elle été rencontrée par les robots indexeurs ?

Suppositions

Une imprudence, un lien diffusé sur un réseau social ? peut être, mais peu probable. Une autre hypothèse, effrayante (mais pas pour autant si farfelue) : Google lirait nos échanges de mails entre développeurs et aurait croisé cette URL durant un envoi de messages ? Peut être, mais pas sur qu’il se servirait à foison. Sur la page accessible de mon-site.com est présent un splash screen, ou une page de présentation du futur service est dévoilée. Après vérification, aucun lien ne pointent vers dev.mon-site.com.

On m’a toujours dit : « si tu veux voir ce que google voit, ouvre ton site avec Lynx ». Après vérification, aucun lien ou relation entre dev.mon-site.com et mon-site.com était possible… sauf que : sur cette page de teasing était présent une image, image elle même hébergée sur dev.mon-site.com/image. Serait-ce par ce trou de souris que les robots auraient découvert l’url rendant à la version de dev ? Après tout, google indexe bien les images, bien qu’invisible aux yeux de Lynx…

Rectifications faites, j’aimerai désormais l’avis de mes collègues et pairs développeurs/référenceurs sur cette question, par où est-ce que mon url de dev a pu se faire connaître des robots google ?

Récits d’un développeur Symfony2.

En tant que développeur web, j’ai régulièrement besoin d’aller fouiller à droite à gauche sur l’Internet pour qu’il m’aide à sortir vainqueur face à des problèmes de développeur. Si tu en es toi même un, tu sais qu’il n’est même plus possible de compter combien de temps tu as passé sur StackOverflow, combien de blogs tu as écumé dans l’espoir que quelqu’un puisse résoudre ton problème en t’indiquant quelles solutions avaient été envisagées, et surtout …combien de fois as-tu trouvé la solution idéale qui t’as permis de continuer et de faire avancer tes projets grâce aux généreuses contributions de nos pairs internautes ?

Moi aussi, dans mes journées de labeur, je me mords parfois les doigts sur des incohérences, des bugs, ou tout simplement des erreurs stupides. Mais souvent, les solutions arrivent et les problèmes se règlent à force de persévérance, de relecture et d’heures passées entres les lignes de codes.

Voilà pourquoi j’ai choisi moi aussi d’ajouter ma petite touche, aussi modeste soit-elle, de conseils et de petites astuces qui m’ont permis d’avancer. Peut être que toi aussi, amis internaute / développeur / référenceur / chef de projet / { tout autre corps de métier du web }, tu trouveras un peu de réconfort dans la solitude que ton erreur 500 te procure, et qui sait… une solution digne de ce nom.