TRUCS & ASTUCES ET PENSE-BÊTE DE SYMFONY 2.X

Savoir si on est en mode DEV dans un contrôleur

Pour connaitre l’environnement en cours dans un contrôleur on peut utiliser :

$this->container->getParameter('kernel.environment');

Ensuite il y a juste à mettre ça dans un if pour vérifier que le retour est bien égal à dev

Récupérer le jeton CSRF dans un formulaire construit à la main

Des fois on crée nos formulaires à la main et on oublie de rajouter le token csrf donc sans ce jeton qui est ni plus ni moins qu’une autorisation explicite de l’utilisateur pour une action donnée ça nous renvoie une erreur de jeton invalide. On sait vite d’ou vient le problème mais on sais plus trop comment le corriger.

{{ form_widget(form._token) }}

Cette ligne crée l’input hidden qui va bien et peut être placée n’importe ou dans le form.

Vérifier si un utilisateur est loggé

Pour verifier si un utilisateur est loggé il suffit de verifier si la variable app.user est définie.

{% if app.user %}
    # l'utilisateur est loggé
 {% else %}
    # l'utilisateur n'est pas loggé
 {% endif %}

Mail HTML avec le FosUserBundle

Par défaut, les mails envoyés par le FosUserBundle sont toujours au format texte, même après avoir rempli le block body_html des templates Twig. C’est a cause du mailer utilisé. Il faut le changer par twig_swift. Et hop ca marche.
Voila le yml a modifier dans app/config/config.yml.

fos_user:
    db_driver: orm
    # ...
    service:
        mailer: fos_user.mailer.twig_swift

PS :Je rajouterais des trucs dans cet article au fil du temps…

OptionsResolverInterface deprecated in SF2.6

Comme l’indique le titre OptionsResolverInterface est déprécié et n’existera plus dans Sf3 donc il faudrait utiliser Symfony\Component\OptionsResolver\OptionsResolver à la place. La méthode setDefaultOptions() sera quand a elle remplacée par configureOptions().

Forcer l’authentification d’un user sans login

Exemple de code :

use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Http\Event\InteractiveLoginEvent;
use Symfony\Component\Security\Core\Exception\UsernameNotFoundException;
// ......
$em = $this->getDoctrine();
$repo  = $em->getRepository("UserBundle:User"); //Entity Repository
$user = $repo->loadUserByUsername($username);
if (!$user) {
    throw new UsernameNotFoundException("User not found");
} else {
    $token = new UsernamePasswordToken($user, null, "votre_firewall", $user->getRoles());
    $this->get("security.context")->setToken($token); //maintenant le gars est loggé
    //maintenant il faut dispatch l'event du login 'classique'
    $request = $this->get("request");
    $event = new InteractiveLoginEvent($request, $token);
    $this->get("event_dispatcher")->dispatch("security.interactive_login", $event);
}

Ensuite il est possible de recuperer cet user comme ca

// n'importe ou
$user =  $this->get('security.context')->getToken()->getUser();
// dans un controller
$user = $this->getUser();

Appliquer un domaine de traduction pour tout un formulaire

Pour traduire tous les labels de vos formulaires vous pouvez ajouter le domaine a chaque items comme ça :

->add('foo','hidden',
 array(
   "label"=>"foo.form.label.foo",
   "required"=>true,
   'translation_domain' => 'rudak_domain'
 )
);

Mais du coup quand on en a beaucoup ca devient vite dégueulasse. Heureusement on peut parametrer le domaine pour tout le formulaire, c’est dans l’option resolver que ca se passe :

public function configureOptions(OptionsResolver $resolver)
{    
    $resolver->setDefaults(array(
        'translation_domain' => 'rudak_domain'
    ));
}

Gérer ses FlashBag dans TWIG

La doc de symfony explique un peu comment gérer ses messages flashs, mais des fois on peut vouloir gérer les types aussi et oublier la syntaxe m’arrive à chaque fois et comme je suis surement pas le seul, voici comment on peut faire :

{% for label, flashes in app.session.flashbag.all %}
    {% for flash in flashes %}
        <div class="alert alert-{{ label }}">
            {{ flash }}
        </div>
    {% endfor %}
{% endfor %}

Voir les erreurs 404 en mode DEV

(Edit : lire tout le paragraphe!)
Pour voir les erreurs 404 sur des templates perso en principe il faut passer en prod sinon on s’aperçoit de l’erreur mais dans le profiler alors ça nous avance pas trop quoi… Cependant on peut forcer l’affichage des pages d’erreurs personnalisées en modifiant un paramètre dans le fichier dev/app_dev.php comme ceci :

$kernel = new AppKernel('dev', false);

Voila c’est aussi simple que ca, par contre après avoir testé, remettez la valeur par défaut, merci.
Edit : Une technique plus académique a vu le jour, voir cette page.

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s