Le but de cet article est de chercher plus loin dans les fonctionnalités de base proposées par Symfony pour l’élaboration de notre backend.

La Homepage

Proposer à l’administrateur l’affichage d’une page de listing d’un modèle, dès le login effectué, est bien sûr une mauvaise idée. Une page d’accueil doit être présente et peut présenter les différentes informations pertinentes et vitales pour l’administrateur :

Accueil du backoffice : Statistiques et accés

Dans cette capture, l’accueil permet dès l’authentification, de connaitre les différentes statistiques du site et d’avoir un accés direct aux actions redondantes mais nécessaires : Utilisateurs en attente de validation, Visualisation de messages suspects etc…

Pour aller plus loin, vous pouvez afficher certaines indications propres à la fréquentation sur votre site. Si vous possédez un compte Google Analytics, c’est l’occasion d’en profiter ! En effet, une API pour accéder à ses statistiques est disponible depuis peu, et devinez quoi ? Il existe un plugin Symfony pour l’utiliser : sfGoogleAnalyticsPlugin. Alors plus d’excuses pour ne plus proposer une page d’accueil efficace à votre client.

Un listing précis et concis

Par défault, Symfony propose un listing complet des différents champs de votre modèle. Cela est souvent beaucoup trop confus et non adapté pour les besoins d’un client :

Il apparait comme essentiel de sélectionner et de renommer les différentes colonnes de votre modèle que vous souhaitez afficher. De même, selon la complexité de votre objet, il peut être intéressant de fournir des informations « associées » : Pour un objet Article de Blog, il est pertinent d’afficher le nombre de Commentaires associés. Dans mon cas, j’affiche le nombre d’utilisateurs associés à un projet :

Concernant les valeurs, il est déconseillé d’utiliser des IDs. Ils apportent aucune information quantitative ou qualitative pour l’administrateur. De plus, il est préférable de créer une action pour les tâches répétitives. Cela simplifie grandement l’administration pour un client et on évite ainsi de l’envoyer directement sur les pages d’éditions.

La documentation de Symfony étant très complète sur ce sujet, nous allons continuer notre tour d’horizon avec les filters.

Les filtres au service de la navigation

Symfony permet à l’aide du générateur d’administration, de trier vos modèles en fonction de filtres spécifiques. Mais comme pour la partie précédente, les problèmes sont similaires : Trop de champs renseignables, souvent complexes et non traduits. Outre la documentation de Symfony qui vient encore une fois à notre aide, il faudra faire un tour sur cet article pour compléter la traduction des filtres sur le backend.

Mais la véritable force des filtres, c’est leur utilisation de manière transparente par le client. En effet, si on reprend l’exemple de notre page d’accueil, on propose un lien « 3 projets en attente » sensé rediriger sur les projets concernés.

Comment cela est-il possible ?

Tout simplement en créant le filtre qui nous permet de trier nos projets, dès le chargement de la page. La manière la plus simple est de passer nos filtres dans l’URL.

Mise en place

Il faut d’abord surcharger notre action index du module concerné :

    public function executeIndex(sfWebRequest $request) {
        if($request->getParameter('filter')) {
            $this->setFilters($request->getParameter('filter'));
        }
        parent::executeIndex($request);
    }

On vérifie si l’on passe un paramètre « filter » lors du chargement de la page. Le cas échéant, on applique les filtres renseignés.

Mon lien permettant de voir seulement les utilisateurs en attente de validation aura le routing :

@user_user?filter[is_active]=0

Pour mes projets en attente de validation, c’est la pratiquement la même chose, on indique en plus le type de l’argument.

@project_project?filter[state][text]=1

Pensez à bien regarder la structure de vos filtres en cas d’erreur.

Allez plus loin

Maintenant que vous savez filtrer directement à partir d’un lien, vous allez pouvoir vous servir de cette astuce autre part que sur la page d’accueil. Revenons sur nos listing. Nous avons vu qu’il était pratique pour le client d’afficher par exemple le nombre d’objet Commentaire associés à un objet Article. Nous sommes maintenant capables de rediriger directement vers les objets associés.

On ajoute une méthode d’affichage sur notre objet Article :

    public function getCountPositioning() {
        return link_to($this->getComments()->count(),'@comment_comment?filter[article_id]='.$this->Id());
    }

On retourne ainsi le lien contenant le filtre permettant de trier les commentaires en fonction de l’ID de l’article. Il suffit de modifer notre action index afin de correctement afficher notre entité HTML :

    public function executeIndex(sfWebRequest $request) {
        sfConfig::set('sf_escaping_strategy', false);
        if($request->getParameter('filter')) {
            $this->setFilters($request->getParameter('filter'));
        }
        parent::executeIndex($request);
    }

Voilà pour nos petites idées pour vous aider à parfaire votre back office. N’hésitez pas à parlez de vos astuces dans les commentaires.

Mise à jour

La désactivation de la stratégie d’échappement des caractères (sfConfig::set(‘sf_escaping_strategy’, false)) est utilisée pour éviter l’affichage des balises <a> obtenues depuis notre modèle. Cette méthode à deux limites : D’une part, elle est inhérente à certaines failles de sécurité provoquées par une injection de code malicieux (cf commentaire de @Niko) ; D’autre part, on perd l’avantage lié à notre MVC en faisant parvenir le lien directement depuis le modèle.

Il est alors conseillé de déclarer dans notre generator.yml l’utilisation des partials pour afficher nos liens filtrants :

display: [_countComments]

Il suffit alors de créer notre partial _countComments.php dans le dossier templates/ de notre module :

<?php echo link_to($article->getComments()->count(), '@comments_comments?filter[article_id]='.$article->getId());?>

Pourquoi utiliser RSync ?

A l’instart du FTP, rsync permet d’effectuer une synchronisation distante basée sur des sauvegardes incrémentales. En clair, à l’aide d’une seule commande, vous pouvez mettre à jour sur votre serveur, seulement l’ensemble des fichiers modifiés depuis votre dernière synchonisation.

Rsync utilise le protocole SSH permettant une communication sécurisée lors du transfert des fichiers. Un autre avantage indéniable par rapport au protocole FTP beaucoup trop bavard sur le réseau, lors de la transmission de vos paramètres d’authentification.

Outre le confort et la rapidité du déploiement par rsync, il ne faut pas oublier son support natif par Symfony.

Configuration RSync

Avant de voir les différents paramètres de configuration, nous allons rapidement installer ce petit utilitaire via notre gestionnaire de packet sur notre Debian-Like :

apt-get install rsync

Pour les paramètres de connection, il faut  créer/modifier le fichier config/properties.ini :

[maconfig]
name=MonSite
author=Lexik.fr
host=66.249.64.0                               #IP du serveur
port=22                                        #Port par default pour ssh
user=votre-login                               #Utilisateur qui se connectera au serveur de destination
dir=/home/lexik/domains/lexik.fr/public_html   #Dossier qui recevera le projet symfony sur le serveur de destination
type=rsync                                     #Type de deploiement

Symfony permet de spécifier les dossiers à exclure lors de la synchronisation. Créer/Modifier le fichier config/rsync_exclude.txt :

.svn
/web/uploads/*
/web/*_dev.php
/cache/*
/log/*
.DS_Store
.cache
.project
.settings

Nous allons ensuite tester nos paramètres de configuration. Cette commande est utile pour effectuer une simulation du transfert. Cela signifie que rien ne sera synchronisé :

php symfony project:deploy maconfig

Nous y voila, effectuez votre rsynchronisation :

php symfony project:deploy maconfig --go

Et voila !

Déploiement sans spécifier le mot de passe

Dans un souci d’automatisation de synchronisation, il peut être embêtant de se faire demander le mot de passe serveur à chaque déploiement par rsync (ou même lorsque l’on souhaite se connecter au serveur directement par SSH).

Dans cette logique, on peut utiliser une encryption asymétrique (clé publique, clé privée) afin de rester « connu » par le serveur:
On génère le couple de clé en local avec la commande :

ssh-keygen -t rsa

On garde le chemin par défault pour la sauvegarde des clés, et nous n’aurons pas besoin dans notre cas de passphrase, en vue d’une possible automatisation des synchronisations.

Les 2 clés sont donc générées dans ~/.ssh/

Il suffit alors de copier la clé publique sur le serveur, dans le répertoire courant de l’utilisateur avec lequel on se connecte.

Voici une procédure possible avec scp (man scp pour plus d’information) :

scp /home/moi/.ssh/id_rsa.pub monlogin@ip-du-server:.ssh/authorized_keys

(Il faudra peut être créer le dossier .ssh à la racine du dossier personnel de l’utilisateur).

Bugs courant :

Agent admitted failure to sign using the key.

Peut se produire alors que la clé publique a bien été transmise au serveur (le bug semblerait provenir du client SSH natif d’ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/201786).

Voici la commande salvatrice :

export SSH_AUTH_SOCK=0

En savoir plus

• Cryptographie asymétrique
• Pratical symfony : Day 23