Pour cela, l’utilitaire symfony met à votre disposition la commande propel:data-dump. En ligne de commande :

symfony propel:data-dump > data/fixtures/fixtures.yml

Cette commande exporte tout le contenu de la base de données vers un fichier de fixtures qui sera automatiquement rechargé au prochain load. Si toute fois vous souhaitez n’exporter qu’un ou plusieurs modèles, vous pouvez les préciser en paramètres :

symfony propel:data-dump –classes=”BlogPost,BlogComment” frontend  > data/fixtures/blog.yml

Petit rappel pour charger les fixtures :

symfony propel:data-load && symfony cc

Il devient cependant difficile d’utiliser plusieurs sessions de Putty simultanément et ce n’est pas rare que je me retrouve avec 5 ou 6 fois le logiciel de lancé. Et c’est là que Putty Connection Manager intervient.

PuttyCM permet de lancer plusieurs instances de Putty et des les organiser au sein d’une interface commune.

“the approach we’d prefer is a separate application that can swallow instances of PuTTY and provide the tabbing interface” (PuTTY’s team)

Un petit bijou à installer de suite : http://puttycm.free.fr/

Il vous est sans doute déjà arriver de vouloir écrire un fichier de log bien à vous dans votre application sans vouloir forcément passer par les fichiers existants du frameworks. Les développeurs de Symfony ont pensez à vous et vous proposent l’utilisation de la classe sfFileLogger. Pour cela, rien de plus simple, ajoutez dans votre code :

$logger = new sfFileLogger(sfContext::getInstance()->getEventDispatcher(), array(’file’=> dirname(__FILE__).’/../log/testlog.log’));

Vous pouvez ensuite utiliser l’objet $logger comme bon vous semble pour y ajouter des lignes :

$logger->log(”[".date('Y-m-d H:i:s')."] Test de Emerg”, 0);
$logger->log(”[".date('Y-m-d H:i:s')."] Test de Alert”, 1);
$logger->log(”[".date('Y-m-d H:i:s')."] Test de Crit”, 2);
$logger->log(”[".date('Y-m-d H:i:s')."] Test de Err”, 3);
$logger->log(”[".date('Y-m-d H:i:s')."] Test de Warning”, 4);
$logger->log(”[".date('Y-m-d H:i:s')."] Test de Notice”, 5);
$logger->log(”[".date('Y-m-d H:i:s')."] Test de Info”, 6);

Le code ci-dessus crée les lignes suivantes dans le fichier log/testlog.log :

niels@devbox:/var/www/roidusexe/dev$ cat log/testlog.log
Apr 14 03:17:42 symfony [emerg] [2009-04-14 03:17:42] Test de Emerg
Apr 14 03:17:42 symfony [alert] [2009-04-14 03:17:42] Test de Alert
Apr 14 03:17:42 symfony [crit] [2009-04-14 03:17:42] Test de Crit
Apr 14 03:17:42 symfony [err] [2009-04-14 03:17:42] Test de Err
Apr 14 03:17:42 symfony [warning] [2009-04-14 03:17:42] Test de Warning
Apr 14 03:17:42 symfony [notice] [2009-04-14 03:17:42] Test de Notice
Apr 14 03:17:42 symfony [info] [2009-04-14 03:17:42] Test de Info

Comme vous pouvez le voir, le deuxième paramètre de la méthode log() correspond au level de la ligne :

1. Emarg
2. Alert
3. Crit
4. Err
5. Warning
6. Notice

[Sun Apr 19 06:40:36 2009] [error] [client 85.25.17.43] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind

Ces requêtes proviennent d’un scanner de failles nommé DFind. Pour les bloquer rien de plus simple. Ajoutez une règle de blocage à iptables :

iptables -I INPUT -d 94.23.12.185 -p tcp –dport 80 -m string –to 70 –algo bm –string ‘GET /w00tw00t.at.ISC.SANS.’ -j DROP

Toutes ces requêtes seront bloquées ce qui pourrait ampêcher la détection d’une faille sur votre serveur web.

Nous commençons donc par le générateur d’administration (admin generator) et son option peer_method.

Imaginons le schéma de données suivant :

sponsor:
id:             ~
name:           { type: varchar(255), required: true, index: unique }
url:            { type: varchar(255), required: true }
…

website:
id:             ~
sponsor_id:     { type: integer, foreignTable: sponsor, foreignReference: id, required: true }
category_id:    { type: integer, foreignTable: category, foreignReference: id, required: true }
name:           { type: varchar(255), required: true, index: unique }
url:            { type: varchar(255), required: true }
…

category:
id:             ~
name:           { type: varchar(255), required: true, index: unique }

Un site (website) appartient à une catégorie et à un sponsor. Pour l’exemple, six sites sont saisis. Si l’on utilise le générateur par défaut pour afficher le module website du backend, la page provoque 17 requêtes en base.

Cinq sont nécessaires :

# Définit l’encodage des caractères
SET NAMES ‘utf8′
# Compte le nombre total de sites pour la pagination
SELECT COUNT(*) FROM `website`
# Récupère toutes les données des sponsors (liste déroulante)
SELECT sponsor.ID, sponsor.NAME, sponsor.URL, sponsor.LANGUAGE, sponsor.ACCOUNT, sponsor.PASSWORD, sponsor.TRACKING FROM `sponsor`
# Récupère toutes les données des catégories (liste déroulante)
SELECT category.ID, category.NAME FROM `category`
# Récupère toutes les données des 20 premiers sites (tableau de résultat)
SELECT website.ID, website.SPONSOR_ID, website.CATEGORY_ID, website.NAME, website.URL, website.LANGUAGE FROM `website` LIMIT 20

Le problème est que nous avons ensuite deux requêtes par ligne de résultats pour récupérer les données des sponsors et des catégories :

SELECT sponsor.ID, sponsor.NAME, sponsor.URL, sponsor.LANGUAGE, sponsor.ACCOUNT, sponsor.PASSWORD, sponsor.TRACKING FROM `sponsor` WHERE sponsor.ID=1 LIMIT 1
SELECT category.ID, category.NAME FROM `category` WHERE category.ID=49 LIMIT 1

Ces requêtes supplémentaires peuvent être gênantes sur des sites à fort traffic ou sur une administration possédant de nombreux objets en base. On peut les réduire en réalisant une seule requête composée de jointures ce qui ramène le nombre de requêtes au total à 5:

SELECT website.ID, website.SPONSOR_ID, website.CATEGORY_ID, website.NAME, website.URL, website.LANGUAGE, sponsor.ID, sponsor.NAME, sponsor.URL, sponsor.LANGUAGE, sponsor.ACCOUNT, sponsor.PASSWORD, sponsor.TRACKING, category.ID, category.NAME FROM `website` LEFT JOIN sponsor ON (website.SPONSOR_ID=sponsor.ID) LEFT JOIN category ON (website.CATEGORY_ID=category.ID) LIMIT 20

Pour cela, il suffit dans le generator.yml du module website de rajouter :

list:
peer_method: doSelectJoinAll

Pourquoi la valeur doSelectJoinAll ? Car nous souhaitons joindre toutes les tables liées au modèle website. Vous avez en effet le choix sur les jointures à réaliser. Il suffit de saisir le nom de la classe que vous souhaitez joindre (si bien sur le modèle est conscient de la relation entre ces tables). On aurait donc pu utiliser seulement : peer_method: doSelectJoinCategory ou peer_method: doSelectJoinSponsor.

Au niveau performances, on observe une baisse de 10% sur le temps de chargement global de la page sur un environnement virtualisé en mode développement.

Comment un projet de cette envergure peut échouer sur quelque chose d’aussi bête, surtout quand on voit le prix d’un domaine à l’année !

Je plains le chef de projet qui risque de se retrouver à la porte pour faute grave. Messieurs il ne vous reste plus qu’à enlever tous les embed wat.tv que vous aviez sur vos sites.