Doctrine postRemove et extension SoftDelete

Avez-vous déjà utilisé l’extension SoftDelete fournie par la librairie Doctrine Extensions ?

Si oui peut être vous êtes vous aperçu que l’événement postRemove habituellement intercepté par vos listeners / suscribers lors de la suppression d’une entité ne l’est plus lorsque celle-ci est marquée comme SoftDeleteable.

Pas de panique, ne jetez pas votre code ! En mode SoftDelete le nom de l’événement à écouter est postSoftDelete, et il est aussi de type LifecycleEventArgs. La logique de vos listeners / suscribers n’a donc pas besoin d’être modifiée.

LexikMailerBundle, gérez vos templates de mails en base de données

N’avez-vous jamais eu un client qui vous demande régulièrement de modifier le contenu des emails envoyés depuis le site ? Ou mieux un client qui souhaite lui même modifier le contenu des emails ? Dans ce genre de cas le plus simple est souvent de stocker le contenu modifiable dans la base de données, c’est ce que permet le LexikMailerBundle, une gestion de vos templates de mail depuis la base de données. Ces templates supportent la syntaxe Twig, vous pouvez ainsi facilement passer des paramètres lors de la génération du mail. Le bundle fournit deux CRUD I18N, un pour gérer les templates de mail et un second pour gérer les templates des layouts.

Contrôler la santé de son application Symfony2

Il peut parfois être utile de pouvoir faire un bilan rapide sur la santé de son application Symfony2. Ce bilan peut reposer sur des « check » plus ou moins avancés comme par exemple vérifier que la base de données répond correctement.
Pour réaliser cela la société Liip a récemment sortie le LiipMonitorBundle qui permet de lancer une série de « check » depuis la console ou une page web, et le LiipMonitorExtraBundle qui fournit quant à lui des classes pour effectuer ces « check ».

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.

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.