Blog Symfony2 - Lexik Montpellier » tips

Installation de SuPHP sur Ubuntu

laurent — Fri, 26 Aug 2011 08:00:40 +0000

Un problème récurrent pour beaucoup de développeurs utilisant Symfony est l’éternel conflit avec l’utilisateur « www-data » lors des accès, par exemple, aux fichiers du cache et aux logs. Sur Symfony 2 ce problème devient encore plus visible avec l’utilisation massive du répertoire cache même en environnement « dev ».

Le cas de conflit le plus flagrant est certainement le app/console cache:clear qui renvoie une erreur car le cache a été généré par www-data lors du chargement du site par apache. Le bon gros sudo rm -rf app/cache/* n’est pas une solution acceptable, tout juste une rustine.

Il existe différents moyens d’éviter ces conflits, que ce soit via scripts personnalisés, configurations avancées, ou packages additionnels. SuPHP est un module pour Apache très facile à mettre en place pour un environnement de « dev », et il va répondre à notre problème d’une manière très simple: Apache ne va plus éxécuter les sites via ‘www-data’, mais via l’utilisateur propriétaire des fichiers éxécutés, c’est-à-dire le plus souvent le compte du développeur.

L’installation comprend deux packages dispos sur synaptic ou directement depuis la console:

sudo apt-get install suphp-common libapache2-mod-suphp

Pour une station de dev, une configuration fonctionnelle et simple est très bien décrite sur http://doc.ubuntu-fr.org/suphp#installation_de_suphp. Cette configuration empêche l’intervention de suphp dans les répertoires de /usr/share pour permettre entre autres à phpmyadmin (dans son emplacement par défaut) de continuer à fonctionner sans problèmes.

Il faudra éventuellement supprimer les fichiers de sessions en cours appartenent encore à www-data (dans /var/lib/php5 par défaut).

Si vos projets ne sont pas stockés dans les répertoires /var/www ou ~/public_html, il faut éditer la valeur de « docroot » dans /etc/suphp/suphp.conf pour y ajouter les répertoires supplémentaires. Par exemple, mes projets sont dans ~/www/ :

docroot=/var/www:${HOME}/public_html

devient alors:

docroot=/var/www:${HOME}/public_html:${HOME}/www

Pensez à nettoyer vos fichiers appartenant encore à www-data (cette fois avec des sudo rm par contre), comme les répertoires cache et logs, et redémarrez simplement Apache (sudo service apache2 restart). Après ça vous ne devriez plus voir de www-data dans vos projets, et vous pourrez oublier ce mauvais réflexe du sudo rm -rf à tout bout de champ !

Présentation du plugin lxJavascriptPlugin

laurent — Tue, 18 Jan 2011 09:53:28 +0000

L’article d’hier sur les bonnes pratiques Javascript dans un projet Symfony faisait mention d’un plugin que nous utilisons en interne et qui est maintenant disponible sur Github: lxJavascriptPlugin. Ce court article va brièvement présenter son fonctionnement et son utilisation.

L’installation du plugin est très rapide:

téléchargez les sources sur Github dans le répertoire plugins de votre projet,
éditez le fichier config/settings.yml pour y inclure le helper lxJavascript:
^?View Code YML
all: .settings: standard_helpers: [ ... , lxJavascript ]

Et c’est tout! Voyons maintenant le fonctionnement.

Le premier but du plugin est de solutionner les problèmes de granularité du code Javascript dans un projet Symfony. Lorsque l’on utilise par exemple des widgets JQuery, des partials pour les réseaux sociaux, ou des composants pour des GoogleMap, on se retrouve vite avec du code Javascript éparpillé dans tout notre projet, et par conséquent tout autant éparpillé dans le code des pages générées.

Pour régler ce problème lxJavascriptPlugin propose un premier outil: le helper lxJavascriptHelper. Son utilisation est très similaire à celle du javascriptHelper de Symfony, mais avec la méthode lx_javascript:

pour inclure un fichier source externe à la page:

^?View Code PHP

 lx_javascript('http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js') ?>

pour inclure directement du code javascript, par exemple le bout de code pour Google Analytics, le fonctionnement est similaire à celui d’un slot:

^?View Code PHP

 lx_javascript() ?>
  var _gaq = _gaq || [];
  _gaq.push(['_setAccount', '*********']);
  _gaq.push(['_trackPageview']);
  (function() {
    var ga = document.createElement('script');
    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
    ga.setAttribute('async', 'true');
    document.documentElement.firstChild.appendChild(ga);
  })();
 lx_end_javascript() ?>

Ici la balise EOF , //arguments du sprintf ); }

Nous voyons bien le javascript retourné dans le code du widget, et donc en milieu de page. Cette fonction render() pourrait, avec lxJavascriptPlugin, ressembler à ça:

^?View Code PHP

public function render($name, $value = null, $attributes = array(), $errors = array())
{
  //code 
 
  $js = sprintf(<<// 
EOF
    ,
    //arguments du sprintf
  );
  lxJavascriptStorage::addJavascriptCode($js);
 
  return $this->getOption('date_widget')->render($name, $value, $attributes, $errors).
           $this->renderTag('input', array('type' => 'hidden', 'size' => 10, 'id' => $id = $this->generateId($name).'_jquery_control', 'disabled' => 'disabled'));
}

Peu de changements, mais ici le javascript sera rendu avec tout le reste du javascript en pied de page.

Notez enfin que la méthode lx_include_javascripts() rendra en premier les sources externes, puis le code javascript concaténé dans une unique balise end_slot() ?> // layout.php : include_javascripts() ?> include_slot('javascript') ?>

Vous pourrez ainsi éditer votre code javascript depuis votre template PHP, bénéficier par exemple de valeurs dynamiques de PHP et pour autant que le code soit bien inclus en bas de page. Toutefois je vous recommande d’écrire du javascript là où il doit se trouver, à savoir dans un fichier JS…

De plus l’inconvénient majeur du slot est qu’il ne peut contenir qu’une valeur, il est écrasé à chaque utilisation. La technique fonctionne mais est très limitée. Pour ces besoins nous avons écrit chez Lexik un petit plugin « lxJavascript », très similaire à l’utilisation d’un slot mais optimisé pour l’inclusion de javascripts. Il gère donc le multiple ajout, supprime les éventuelles multiples balises script pour en conserver qu’une seule, etc. Vous en saurez plus demain, le plugin sort en OpenSource sur le Github de Lexik.

2. Compression

La compression des javascripts (c’est valable aussi pour les CSS) est une des tâches d’optimisations les plus importantes et également une des plus simples, du moins via les plugins symfony. Cette technique consiste à compresser tous vos fichiers javascript en 1 seul et surtout d’y appliquer un numéro de version (un timestamp le plus souvent) afin de prévenir des problèmes de cache dans vos mises à jour.

Les principaux plugins :

Chez Lexik, nous utilisons npAssetsOptimizerPlugin, un plugin de Nicolas Perriault, extrêmement simple à installer et paramétrer. Sur votre environnement de production, vous obtiendrez ainsi un fichier javascript compressé /js/optimized.js?1294759429 qui contient un timestamp permettant à chaque modifications des fichiers d’être prises en compte sans problème de cache.

Nous n’appliquons pas la compression pour les librairies externes telles que jQuery que nous déléguons aux serveurs CDN de Google, cela apporte ces avantages notables :

l’avantage du CDN, à savoir de proposer des données statiques via un réseau de multiples serveurs dans de multiples points géographiques, afin de permettre un accès très court ;
les navigateurs sont limités sur le nombre de connexions HTTP simultanées sur un même domaine, le téléchargement d’un javascript sur les serveurs de Google se fera en parallèle ;
les librairies du CDN ont les bonnes en-têtes de cache, par exemple la version 1.4.4 de jQuery restera en cache pendant 1 an sur le client, cela signifie également qu’un internaute peut bénéficier du cache téléchargé depuis un autre site, pas forcément sur le votre.

3. Accéder à certaines données dynamiques depuis javascript

Il peut parfois être très utile depuis javascript d’accéder à certaines données dynamiques telles que la culture de l’utilisateur, du routing pour des appels Ajax ou encore de l’i18n. Il suffit de s’appuyer sur un simple fichier de configuration via un tableau de données JSON généré depuis une action symfony. J’ai écrit sur mon blog personnel un article détaillé sur le sujet Configurations Javascript dynamiques en Symfony.

4. Javascript depuis les widget

Maintenant que vos inclusions de javascripts se trouvent en bas de page, jQuery par exemple, que faire de nos chers widgets jQuery Autocompleter sfWidgetFormJQueryAutocompleter et autre Datepicker sfWidgetFormJQueryDate qui retournent des champs de formulaire et le javascript d’initialisation du composant ? Eh bien, ne plus les utiliser… Simplement car ils seront inclus avant jQuery et vous aurez donc droit à l’erreur « jQuery is not defined ». Sans être aussi extrême, vous pouvez charger jQuery en haut de page (via les CDN de Google) et votre script compressé en bas de page, les widgets de formulaire seront alors à nouveau fonctionnels.

Cela fait déjà quelques temps que chez Lexik nous avons fait le choix d’enlever tous ces widgets pour les ré-écrire et les adapter à nos besoins. Les javascripts des widgets passent par notre plugin lxJavascript ce qui permet de les inclure là où on le souhaite. Egalement, le javascript retourné par ces widgets correspond à une utilisation basique du composant, dans un cas concrêt il est souvent nécessaire d’en ré-écrire une bonne part. Il peut être pratique par contre que le widget retourne seulement la sémantique HTML adaptée, par exemple dans le cas d’un Autocomplete un champ hidden pour stocker la valeur et un champ texte pour l’autocomplete, aussi nos widgets ont une option pour retourner ou non le code javascript.

5. Optimisation frontend

Presque aussi important que la compression, la configuration d’apache pour mettre en cache certains de vos fichiers statiques. Typiquement, maintenant que vos fichiers javascripts et CSS sont compressés en 1 seul et possèdent un timestamp unique par version, il serait dommage de les recharger à chaque chargement de page… Vous devez donc configurer le module Expires d’apache via le fichier de config du vhost ou via le .htaccess, en voici un exemple :


  ExpiresActive on
  ExpiresByType text/css "access plus 1 year"
  ExpiresByType text/javascript "access plus 1 year"

Vos fichiers javascript et CSS seront ainsi en cache pendant 1 an, attention du coup à ne pas avoir de fichier sans numéro de version, car ils resteraient en cache et vos internautes ne bénéficieraient pas de vos mises à jour…

Dernière chose, si ce n’est pas encore fait, installez et testez Yslow pour trouver des pistes d’optimisations de performance de vos sites.

Exemple d’application utilisant la Graph API de Facebook

laurent — Wed, 07 Jul 2010 12:42:30 +0000

Facebook a lancé il y a maintenant quelques mois sa nouvelle Graph API, qui permet d’accèder et d’interagir avec les informations Facebook de l’utilisateur encore plus simplement. Seuelement la documentation qui l’entoure se fait encore rare et peu détaillée. Je vais donc profiter de cet article pour présenter quelques aspects de cette nouvelle API à l’aide d’une petite iframe application Facebook, et avec Symfony (pour rester dans la thématique du blog !).

Pour commencer nous avons bien sûr besoin de créer notre application Facebook. Cela n’étant pas le but de cet article, je vous laisse trouver la marche à suivre sur le net; les sites couvrant le sujet sont légion (par exemple créer une application Facebook).

On paramètre correctement l’application et celle-ci s’occupera ensuite de charger nos pages dynamiques depuis l’url spécifiée:

L’application Symfony n’a ici qu’un seul module « demo » qui s’occupe des quelques actions nécessaires. Editons « app.yml » pour y ajouter l’ID et le SECRET obtenus lors de la création de notre application:

^?View Code YML

all:
  facebook:
    app_id: 116399618389033
    api_key: *******************************************
    secret: *****************************************
    base_url: http://facebook.prestataire-symfony.com
    app_url: http://apps.facebook.com/demolexik

Il nous faut ensuite récupérer l’api Facebook PHP sur Github, que nous allons coller dans /lib/facebook/facebook.php.
Afin de ne pas avoir à initialiser les appels à l’api depuis chaque action, un filter va grandement nous simplifier la tâche:

^?View Code PHP

// lib/filter/FacebookFilter.class.php
class FacebookFilter extends sfFilter
{
 
  public function execute(sfFilterChain $filterChain)
  {
    $context = $this->getContext();
    $request = $context->getRequest();
    //initialisation de l'appel à l'api...
    $facebook = new Facebook(array(
          'appId'   => sfConfig::get('app_facebook_app_id'),
          'secret'  => sfConfig::get('app_facebook_secret'),
          'cookie'  => true,
      ));
 
    $context->getController()
            ->getActionStack()
            ->getLastEntry()
            ->getActionInstance()
            ->facebook = $facebook;
 
    $filterChain->execute();
  }
}

Pensez à éditer votre « filters.yml » en conséquence.

^?View Code YML

#apps/frontend/config/filters.yml
rendering: ~
security:  ~
# insert your own filters here
Facebook:
  class: FacebookFilter
cache:     ~
execution: ~

Pour l’api Javascript, nous allons éditer le layout de l’application:

^?View Code HTML


  
    
    
    Facebook App
    
    
  
  
    
    
    
    ...

Nous en profitons pour charger JQuery afin de faciliter l’ajax et le remaniement du Dom.

Voilà, nous sommes prêts à attaquer les actions.

La première action va être l’authentification de l’utilisateur Facebook, et la gestion des permissions que celui-ci devra accorder à notre application.
Le nouveau modèle de Facebook veut que nous demandions à l’utilisateur, dès le premier accès à l’application, qu’il accepte simultanément toutes les permissions nécessaires. Pour plus d’informations à ce sujet, consultez la liste des permissions sur le wiki Facebook Developer.
Voici l’action Login, qui sera appelée lorsque l’utilisateur n’a pas accordé ces permissions, ou lors d’une première visite de l’application:

^?View Code PHP

//apps/frontend/modules/demo/actions/actions.class.php
public function executeLogin(sfWebRequest $request)
  {
    //on génère l'url qui permettra le login à l'application
    $this->loginUrl = $this->facebook->getLoginUrl(array(
            'canvas'    => 1,
            'fbconnect' => 0,
            //ici on demande les permissions email, publication sur le mur, et changement du status
            'req_perms' => 'email,publish_stream,status_update',
            'next'      => ''
        ));
  }

Comme nous sommes dans une application iframe, il faut charger l’url de login depuis la frame parente, et notre template va s’en charger:

^?View Code PHP


<script type="text/javascript">
top.location.href = "$sf_data->getRaw('loginUrl') ?>";

Il faut maintenant que notre index redirige vers ce login dans les cas précédemment cités:

^?View Code PHP

//apps/frontend/modules/demo/actions/actions.class.php
public function executeIndex(sfWebRequest $request)
  {
    //on vérifie si l'utilisateur a une session facebook active
    $this->session = $this->facebook->getSession();
    if (!$this->session)
    {
      //sinon il doit s'identifier
      $this->redirect('demo/login');
    }
 
    //s'il a une session active, on vérifie si elle est valide pour notre application
    try
    {
      $this->uid = $this->facebook->getUser();
      $this->fbme = $this->facebook->api('/me');
    }
    catch (FacebookApiException $e)
    {
      //sinon il doit à nouveau s'identifier
      $this->redirect('demo/login');
    }
  }

On peut maintenant voir une demande de permissions s’afficher lorsque l’on se connecte à l’application:

En vérifiant la validité de la session, nous avons récupéré toutes les informations sur l’utilisateur auxquelles nos permissions nous donnent accès. Voyons l’étendue de ces informations en les affichant dans notre vue:

^?View Code PHP


<div class="section">
<h3>Informations utilisateurh3>
<pre>php print_r($fbme) ?> /pre>
div>

Nous accédons bien à l’adresse email comme spécifié, ainsi qu’aux informations génériques et publiques sur l’utilisateur.

Il est maintenant temps d’interagir avec l’utilisateur. Il nous a également accordé l’accès à son status, nous allons donc lui proposer de l’éditer via notre application:

^?View Code HTML


...

  Changer mon status via Ajax et l'API PHP
    

...

La méthode js « updateStatus() » va faire un appel ajax à une nouvelle action updateStatus de notre application:

^?View Code PHP

//apps/frontend/modules/demo/actions/actions.class.php
public function executeUpdateStatus(sfWebRequest $request)
  {
    $this->forward404Unless($request->isXmlHttpRequest());
    $status = $request->getParameter('status');
    try
    {
      //un simple appel a l'api suffit à poster un nouveau status sur le profile de l'utilisateur
      $this->facebook->api(
          '/me/feed',
          'post',
          array( 'message' => $status, 'cb' => '' )
        );
    }
    catch (FacebookApiException $e)
    {
      return $this->renderText('Erreur: '.$e);
    }
    return $this->renderText('Status mis-à-jour');
  }

L’api Javascript est toute aussi simple à utiliser. Proposons cette fois à l’utilisateur de parler de notre application sur son mur à l’aide de javascript:

^?View Code PHP


...
<div class="section">
  <a onclick="publishWall();return false;" href="#">Poster un article sur mon mur via l'API Javascript

...

Le résultat obtenu en cliquant sur le lien est le pseudo-popup bien connu de Facebook:

Nous venons de voir quelques méthodes simples d’accès ou de publication de données. Une liste plus complète des méthodes éxistantes est sur le wiki Facebook Developer.
Dans le cadre d’applications plus complexes, il sera souvent utile de pouvoir formuler précisément les informations que l’on souhaite récupérer, et celles-ci ne correspondront pas nécessairement à une méthode éxistante. Pour cela Facebook met à notre disposition FQL, un langage de requète similaire à SQL dans sa syntaxe, pour générer nos requètes spécifiques.

Par exemple, récupérons la liste des amis de l’utilisateur avec leur nom, leur uid, et leur photo. Voici la requète FQL pour cela, et son éxécution via l’api PHP:

^?View Code PHP

//apps/frontend/modules/demo/actions/actions.class.php
public function executeIndex(sfWebRequest $request)
  {
    ...
    //récupération des amis via FQL
    $query = "SELECT name, uid, pic_square FROM user WHERE uid in (SELECT uid2 FROM friend WHERE uid1 = ".$this->uid.")";
    $this->amis = $this->facebook->api(array(
        'method'    => 'fql.query',
        'query'     => $query,
        'callback'  => ''
    ));
  }

Et l’affichage de la liste dans la vue:

^?View Code PHP


<div class="section">
<h3>Liste d'amis


	pic_square'] ?>" alt="" />
	name'] ?>
	uid: uid'] ?>

Cet article n’était pas dédié à Symfony, mais l’utilisait plutôt pour proposer un environnement familier à notre application. Ce survol rapide de la nouvelle Graph Api permet surtout de donner un point de départ sur l’utilisation de la nouvelle librairie à un moment ou la documentation à son sujet n’est pas vraiment fournie, en particulier en français !
Vous pouvez voir l’application tourner sur http://apps.facebook.com/demoLexik.

Validation d’un numéro siret : sfValidatorSiret

thomas — Tue, 25 May 2010 06:30:00 +0000

Bonjour,

comme vous avez pu le voir avec les récents posts, nous avons eu pas mal de gestion de facturation: conversion de devises, validation d’un numéro de tva intracommunautaire.

Pour continuer sur la lancée, nous allons faire un petit validator sur les numéros siret.

Un numéro siret correspond à un petit algorithme assez simple expliqué ici (algorithme de Luhn)
Le principe est le suivant : on multiplie les chiffres de rang impair à partir de la droite par 1, ceux de rang pair par 2 ; la somme des chiffres obtenus doit être congrue au modulo 10, c’est-à-dire qu’elle doit être multiple de 10.
Un numéro siret comporte 14 chiffre.

Voici le code du validator: sfValidatorSiret.class.php

^?View Code PHP

class sfValidatorSiret extends sfValidatorBase 
{
  protected function doClean($values)
  {
    $siret = trim($values);
    if(empty($siret) || strlen($siret) != 14)
    {
      throw new sfValidatorError($this, 'Le numéro siret est invalide');
    }
    $sum = 0;
    for($i=0; $i<14; $i++)
    {
      if($i%2 == 0)
      {
        $tmp = $siret[$i]*2;
        $tmp = $tmp > 9 ? $tmp - 9 : $tmp;
      }
      else
      {
        $tmp= $siret[$i];
      }
      $sum += $tmp;
    }
    if($sum%10 !== 0)
    {
      throw new sfValidatorError($this, 'Le numéro siret est invalide');
    }
    return $siret;
  }
}

Pour expliquer rapidement:
1. si la valeur est vide ou de longueur différente de 14 on retourne une exception.
2. on parcours les 14 chiffres, si le chiffre est paire alors on le multiplie par 2 et si ce résultat est supérieur à 9 alors on retranche 9.
ex: 7 => 7×2 = 14 => 14 – 9 = 5.
faire 14 -9 reviens à additionner les 2 chiffres: 1 + 4 = 5.
3. On additionne tous les chiffres paires x2 et les chiffres impaires.
4. si le résultat est divisible par 10 alors c’est un numéro siret.

Attention ceci indique que le numéro fourni peut être un numéro siret, MAIS PAS que ce numéro est réellement un numéro siret inscrit à L’INSEE, actif et correspond à une société.

Vous pouvez télécharger le validator ici.