Installation de SuPHP sur Ubuntu

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.

Envoi d’email avec Symfony et Mailjet

Petit constat :

La gestion des expéditions de mails dans les projets Web est souvent laborieuse. En effet, les serveurs ne sont pas toujours bien configurés pour ça. Il arrive que les emails partent en spam ou encore qu’ils soient bloqués avant même d’entrer dans la boite mails des utilisateurs… Bref, c’est jamais pratique et le suivi se fait très difficilement.

Présentation du lxErrorLoggerPlugin

Voici le petit dernier des plugins Symfony de chez Lexik, lxErrorLoggerPlugin, son but est simple : vous alerter en cas d’erreurs PHP ou Exceptions sur vos projets Symfony.
Le besoin est simple, être alerté et éventuellement logger chaque erreurs, qu’elles soient PHP, Exception ou erreurs remontées par Symfony. En effet le logger de base de Symfony s’arrête aux erreurs remontées par ses soins mais ne remontent pas forcément aux erreurs PHP. Le système de notification du plugin est très flexible grâce à une série de « notifier » que l’on peut activer ou non de façon indépendante les uns des autres.

Astuces de développement javascript avec symfony

Dans cet article nous allons voir quelques astuces et bonnes pratiques, non pas directement de développement symfony mais de développement javascript au sein d’un projet symfony.

Si l’on reprend quelques bases de bonnes pratiques de développement javascript, on constate :

  • que vos javascripts doivent être non-intrusifs, autrement dit là pour améliorer l’expérience utilisateur et en aucun cas être indispensable au fonctionnement d’une page ;
  • que les javascript doivent être combinés en 1 seul fichier et minifié (ceci afin de limiter le nombre de requête HTTP et car le chargement de la page est arrêté à chaque balise script, notamment à cause d’un éventuel document.write(); ;
  • que l’appel au javascript doit être en bas de page ;

Cette liste est bien entendu non exhaustive, vous trouverez une liste plus détaillée par ici.

Toutes ces bonnes pratiques de développement Javascript n’ont pas toujours été facilitées dans symfony, notamment à la grande époque des helpers link_to_remote() & co. qui en ont ravi certains et fait cauchemarder d’autres. Et aujourd’hui encore bon nombre de widgets de formulaire retournent directement du code javascript (dépendant de jQuery ou autre) et qui ne fonctionneront évidemment plus dès lors que vos javascripts se trouveront en bas de page.

Utilisation de l’event dispatcher depuis les classes du modèle.

Le but de cet article n’est pas d’expliquer le fonctionnement des événements symfony, la documentation officielle est très bien faite à ce sujet, et pas mal d’articles expliquant leur implementation existent déjà.

Le but est juste de savoir comment faire pour avoir accès à l’event dispatcher depuis les classes du modèle, de manière à pouvoir lever des événements « métiers » qui permettent des traitements qui se rapprochent des trigger sql. L’avantage est de rester au sein de l’application symfony et ne pas disperser la logique. C’est une problèmatique que nous avons rencontré à plusieurs reprises dans les projets et nous avons pu trouver cette implementation grace à n1k0 de chez Akei.

Utilisation de VHost pour l’accès au backend

L’idée est de ne plus accéder au backend de notre site web en utilisant backend.php dans l’url, mais de passer par un sous domaine.

  • http://www.super-website.com → frontend
  • http://admin.super-website.com → backend

Supposons que mon projet Symfony se trouve dans /home/public_html/.
Commençons par ajouter un vhost pour définir le sous domaine dans Apache. On précise au sous domaine que le fichier index pour ce sous domaine sera backend.php à l’aide de la directive DirectoryIndex.

?View Code CONSOLE
<VirtualHost *:80>
  ServerName admin.super-website.fr
  DocumentRoot "/home/public_html/web"
  DirectoryIndex backend.php
 
  <Directory "/home/public_html/web">
    AllowOverride All
    Allow from All
  </Directory>
 
  Alias /sf /home/public_html/lib/vendor/symfony/data/web/sf
  <Directory "/home/public_html/lib/vendor/symfony/data/web/sf">
    AllowOverride All
    Allow from All
  </Directory>
</VirtualHost>

Ensuite il faut modifier le .htaccess de Symfony afin qu’il redirige les requêtes http du sous domaine vers le fichier backend.php.

?View Code CONSOLE
Options +FollowSymLinks +ExecCGI
 
<IfModule mod_rewrite.c>
  RewriteEngine On
 
  # uncomment the following line, if you are having trouble
  # getting no_script_name to work
  #RewriteBase /
 
  # we skip all files with .something
  #RewriteCond %{REQUEST_URI} \..+$
  #RewriteCond %{REQUEST_URI} !\.html$
  #RewriteRule .* - [L]
 
  # we check if the .html version is here (caching)
  RewriteRule ^$ index.html [QSA]
  RewriteRule ^([^.]+)$ $1.html [QSA]
 
  # redirect to the backend web controller
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{HTTP_HOST}  ^admin.*
  RewriteRule ^(.*)$ backend.php [QSA,L]
 
  # no, so we redirect to our front web controller
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteRule ^(.*)$ index.php [QSA,L]
</IfModule>

Au niveau de la config Symfony, nous pouvons maintenant masquer le nom du script dans les urls du backend:

?View Code CONSOLE
# apps/backend/config/settings.yml
prod:
  .settings:
    no_script_name:    true
    ...

Et pour finir ne pas oublier de vider le cache =), le backend est maintenant accessible sur http://admin.super-website.com.