Par chance, nous n’avons pas besoin de faire le sale travail à la main. Du genre prendre une capture d’écran de la première page du PDF ou je ne sais quelle autre astuce impliquant travail et effort. Image Magick est là pour nous aider et à plus forte raison, Imagick. Il s’agit d’une librairie native à PHP se basant sur l’API d’Image Magick.

Vous me direz : oui mais Image Magick c’est fait pour manipuler des images. Certes mais un PDF, c’est un peu comme une image.

Convertir un PDF mono-page

Partons d’un cas simple : votre PDF ne contient qu’une page. Le code est d’une grande simplicité :

<?php
$im = new Imagick('/chemin/vers/pdf-mono-page.pdf');
$im->writeImage('/chemin/vers/couverture.png');

2 lignes ont suffit à créer notre prévisualisation. Cette manipulation enregistre une image au format PNG sans aucune compression. Nous pourrions l’activer et régler le taux de compression avec 2 lignes supplémentaires :

$im->setCompression(Imagick::COMPRESSION_LZW);
$im->setCompressionQuality(90);

LZW est un algorithme de compression sans perte utilisé entre autre par PNG et GIF. On aurait pu choisir du JPEG sans perte ou une autre constante de compression d’Image Magick.

Convertir un PDF multi-pages

Que se passerait-il si notre code précédent était utilisé sur un PDF contenant plus d’une page ? Et bien seule la dernière page du document serait enregistrée. En fait, toutes les pages seraient enregistrées jusqu’à la dernière (pas terrible côté performances donc).
L’API d’Image Magick nous permet toutefois de connaître le nombre d’images impliquées et d’en définir l’index. Depuis PHP5, Imagick fournit des méthodes propres aux interfaces Iterator et Traversable.

Notre code bouge … mais pas tant que ça. Disons que nous souhaitons prévisualiser la 6ème page du document (donc l’index 5) :

$im = new Imagick('/chemin/vers/pdf-multi-pages.pdf');
$im->setIteratorIndex(5);
$im->setCompression(Imagick::COMPRESSION_LZW);
$im->setCompressionQuality(90);
$im->writeImage('/chemin/vers/couverture.png');

Une petite ligne de plus fait l’affaire. Pour compter le nombre d’images contenues dans le document ouvert, un appel à la méthode getNumberImages fera l’affaire.

Convertir directement avec Image Magick : convert

Pour les amateurs du shell ou les détracteurs de PHP, on peut arriver aux mêmes résultats en 1 ligne de commande. L’outil de conversion est fourni par convert. Sa documentation et ses options sont particulièrement riches. On peut tout faire … ou presque !

convert /chemin/vers/pdf-mono-page.pdf /chemin/vers/couverture.png
convert /chemin/vers/pdf-multi-pages.pdf[5] /chemin/vers/couverture.png

La seule différence réside dans les crochets suivant le nom du fichier d’entrée. Vous avez bien sûr deviné qu’il s’agit de l’index du document PDF que l’on convertit. Si on ne précise rien, convert convertira toutes les pages du document mais cette fois, en les exportant dans des fichiers uniques (pas de réécriture qui tienne).

Conclusion

Image Magick est vraiment une application sympathique. Les possibilités de manipulation offertes surpassent à mes yeux largement celles de la librairie GD (qui est toujours mieux que rien).

Cette manipulation permettrait aussi de décomposer les multiples images composant un GIF animé ou un APNG. Ou inversement, nous pourrions créer une animation à partir de plusieurs images. Ou encore créer une vignette carrée et centrée. Les possibilités ne manquent pas.

C’était également une autre façon de teaser le projet le plus chronophage qui m’ait été donné de connaître mais bon, en septembre c’est dans les bacs. Toujours pas d’idées sur le sujet couvert ?

Il existe cependant une méthode alternative reposant sur Subversion (SVN). C’est la méthode idéale pour tout développeur WordPress ou gestionnaire de blogs. C’est celle que j’emploie depuis la version 2.6 grâce notamment à la constante WP_CONTENT.

Explications et application concrète.

Avant toute chose, sachez que ce tutorial est optimisé pour les personnes qui versionnent entièrement leur projet. Il n’est pas question ici d’avoir une arborescence libre et de procéder à des checkout un peu partout. C’est possible mais pas du plus grand intérêt.

L’avantage évident ici est de pouvoir déployer son blog n’importe où en un rien de temps.

Structure des fichiers

Installer WordPress en tant que dépendance SVN revient à mélanger 2 techniques :

• Installer WordPress dans son propre répertoire
  
• Installer WordPress proprement depuis SVN

Je suis pénible donc je n’ai pas spécialement envie de modifier un fichier core ou autre chose que wp-config.php. Tout le contraire de ce qu’indique la première méthode.

La seconde explication m’a toutefois posé légèrement problème puisqu’un peu brutale et posant soucis chez OVH.

Celles et ceux qui voient la capture d’écran ci-dessus peuvent constater que tout WordPress a été déplacé dans un sous-répertoire wordpress au même niveau que wp-content.
On ne garde à la racine que le fichier .htaccess et wp-config.php.

Sur le répertoire racine, j’ai appliqué ces propriétés pour WordPress 2.7 :

• svn:ignore :
  

  wp-config.php

• svn:externals :
  

  wordpress http://svn.automattic.com/wordpress/branches/2.7

Je ne versionne volontairement pas le fichier wp-config.php car c’est le seul fichier susceptible de changer d’une instance à une autre. Je le récupère depuis wordpress/wp-config-sample.php et je le personnalise selon mes besoins.
Et puis versionner des mots de passe … qui y tient ?

Configuration

Après cette restructuration, on aura toutefois besoin de configurer 2-3 bricoles. Vraiment rien de méchant promis.

Le .htaccess

Voici ma configuration. Elle peut être aisément déportée dans votre déclaration de Virtual Host pour des raisons de performance. Sur un serveur mutualisé vous n’avez en général pas accès à ce dernier type de configuration.

<IfModule mod_rewrite.c>
Options -Multiviews -Indexes +FollowSymlinks
RewriteEngine On
RewriteBase /
# Moving to dependency
RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . wordpress/index.php [L]
</IfModule>
# BEGIN WordPress
# END WordPress

Ce fichier est très inspiré de la configuration SVN proposée sur le Codex WordPress. Seulement voilà, cette renvoie tout sur index.php … et omet ainsi tous les accès aux fichiers situés à la racine, avec entre autre :

• wp-cron.php
• wp-link-opml.php
• wp-trackback.php
• xmlrpc.php

Je vous fais grâce des contrôleurs de flux (Atom, RSS & cie) et des appels en directs à index.php effectués par certains plugins.

Donc non on ne peut pas vraiment se passer de ces fichiers. D’où ces 2 règles :

• RewriteRule ^(index.php|wp-[a-z0-9-]+\.php|xmlrpc.php)?$ wordpress/$1 [L]
  

  On capte tous les fichiers PHP (les contrôleurs) originellement situés à la racine de WordPress.

• RewriteRule ^(wp-admin|wp-includes)/(.*)$ wordpress/$1/$2 [QSA,L]

  Et là c’est pour le confort de conserver les adresses initiales … mais aussi pour éviter de modifier un bout de paramétrage dans l’admin. Le jour où vous décidez de rebasculer à l’ancien système, ça se fera sans douleur

Enfin, pourquoi avoir poussé les commentaires WordPress vers le bas ? Tout simplement pour éviter que nos règles personnalisées soient écrasées par WordPress lors d’une mise à jour des permaliens. Nos règles primeront toujours ainsi.

Le fichier wp-config.php

Dans le fichier wp-config.php, nous n’allons rien modifier. Nous allons juste ajouter forcer 2 paramètres. Ils indiqueront à WordPress où se trouve le véritable répertoire wp-content (renommable mais je ne jouerai pas avec).

Le blog

Bon j’ai menti un peu toute à l’heure en indiquant qu’on ne toucherait qu’à wp-config.php. Cependant la modification est on ne peut plus mineure et ne concerne que l’upload de medias.

En effet si on ne touche pas à l’emplacement des fichiers envoyés, WordPress considère qu’ils sont uploadés dans wordpress/wp-content/uploads. C’est fort gênant mais heureusement, en préfixant le chemin par ../ ou en tapant un chemin absolu tout rentrera dans l’ordre.

À noter qu’il s’agit du seul paramétrage hors d’un fichier. Si j’avais pu m’en passer je l’aurais fait.

Dépendance SVN pour la traduction

C’est en tombant sur un autre article traitant de svn:externals pour WordPress que j’ai été interpelé sur la prise en charge des langues via SVN également.
Le système n’est pas parfait puisqu’on ne peut gérer qu’une seule langue par ce biais là. Ça ne conviendra donc pas aux blogs multilingues.

La technique consiste à transformer wp-content/languages en svn:externals.
Ça donnerait ceci pour la version française de WordPress 2.7, au niveau du svn:externals du répertoire wp-content :

languages http://svn.automattic.com/wordpress-i18n/fr_FR/branches/2.7/messages/

Simple et efficace mais ça reste encore de la bricole.

Cas particulier : plugins et i18n

Je vous expose le problème mais malheureusement vous ne pourrez pas y faire grand chose. Par contre ami développeurs, pour rendre votre code de plugin 100% portable, merci de prendre note

Le chargement des traductions s’effectue à l’aide de la fonction load_plugin_textdomain(). Elle prenait seulement 2 paramètres jusqu’à l’arrivée de WordPress 2.6. Ça n’a pas été crié sur les toits mais elle prend désormais 3 … et c’est du 3ème argument qu’il faut utiliser désormais :

1. $domain : l’espace de nom des traduction (inchangé)
2. $abs_rel_path : chemin relatif par rapport à l’emplacement de WordPress (déprécié, on y mettait PLUGINDIR.'/'.dirname(plugin_basename(__FILE__)) en général)
3. $plugin_rel_path :  chemin relatif par rapport à l’emplacement des plugins (c’est qui nous intéresse ; dirname(plugin_basename(__FILE__)) nous suffira désormais)

Vous trouverez un exemple sur le Codex, du côté de l’internationalisation des plugins.
Un exemple de code pérenne :

load_plugin_textdomain('votreplugin', dirname(plugin_basename(__FILE__)), dirname(plugin_basename(__FILE__)));

Et si jamais vous utilisez votre plugin en lien symbolique ça ne fonctionnera pas … mais on s’éloigne du sujet

Et pour WordPress Mu ?

Je ne m’attarderai pas dessus mais les manipulations sont sensiblement les mêmes. Je n’ai pas encore eu l’occasion d’essayer mais j’ose imaginer qu’il n’y a pas tant de différences que ça

Conclusion

Le jour où vous souhaitez migrer vers une autre version majeure de WordPress, c’est simple : il suffit de changer les externals vers le tag adéquat.

Pourquoi ne pas utiliser le trunk directement me demanderez-vous ? Le trunk de WordPress est plutôt instable puisque c’est là que se construit la prochaine version de manière systématique. L’utilisation des branches permet de bénéficier des correctifs sans avoir à modifier le moindre external.
Si vous avez un grand besoin de stabilité, alors utilisez les tags qui sont en principe figés.

On remarquera aussi que malgré son âge, WordPress commence à peine à proposer des solutions d’industrialisation.
Les liens symboliques sont en effet très mal gérés. Tentez d’utiliser un seul répertoire source pour plusieurs blogs avec des liens symboliques et tout s’effondre.

La preuve en est aussi avec le manque de ressources disponibles sur le Web et traitant ce sujet. Ça m’étonnerait d’être le premier à vouloir déployer du WordPress via SVN.
Les choses s’améliorent mais pour le côté code is poetry, on en est encore loin.

J’ai déjà expliqué comment modifier l’emplacement des données d’un serveur MySQL mais cette fois-ci on va aller encore plus loin :

• on ne va pas toucher aux fichiers de configuration par défaut
• on va pouvoir conserver toute notre configuration sur une partition séparée
• on va être tranquille pour les éventuelles futures réinstallations

C’est pas très compliqué à mettre en œuvre et au final, tout le monde y gagne !

Organisation du répertoire /home

Le titre de l’article le suggère bien, cet article se consacre à la configuration des serveurs et programmes suivants :

• Apache 2
• PHP 5
• MySQL 5
• AppArmor (installé et activé par défaut depuis Ubuntu 8.04)

Pour des raisons évidentes de facilité, j’ai donc créé un répertoire qui rassemble toutes mes configurations spécifiques. En voici son arborescence :

• ~/config
  • /apache2
    • sites-available
      • 000-default-custom
      • local.monprojet.com
      • etc.
  • /apparmor
    • usr.sbin.mysqld-custom
  • /mysql
    • my-custom.cnf
  • /php5
    • php-custom.ini

Nous écrirons dans ces fichiers uniquement les points de configuration que l’on souhaite adapter. C’est plus simple à maintenir. Qui plus est, si les fichiers de configuration sont mis à jour par leur serveur respectif, nos fichiers resteront à l’abri.

Un des moto de Debian c’est la configuration à base de fichiers. Vous trouverez régulièrement des répertoires ayant un nom suivant le motif application.d. Donc plutôt que d’avoir 1 seul fichier de configuration, on a 1 fichier initial plus des configurations additionnelles dans ces fameux répertoires « .d ».

Configuration d’Apache

Pour Apache la démarche est la suivante :

1. créer les Virtual Host dans son répertoire personnel
2. lier les fichiers dans sites-available
3. activer les sites à l’aide de la commande a2ensite
4. recharger Apache

La seule étape par rapport à d’habitude c’est qu’on ne crée par les Virtual Host directement dans /etc/apache2/sites-available et qu’on les lie depuis notre répertoire personnel.
Admettons que je souhaite créer un Virtual Host pour une instance locale de mon blog. Je vais procéder ainsi :

1. gedit ~/conf/apache2/sites-available/local.case.oncle-tom.net
   J’y ai placé une configuration somme toute minimaliste :

   <VirtualHost *:80>
   ServerName local.case.oncle-tom.net
   DocumentRoot /home/oncletom/workspace/case.oncle-tom.net
   ErrorLog /var/log/apache2/error.case.oncle-tom.net.log
   LogLevel warn
   CustomLog /var/log/apache2/access.case.oncle-tom.net.log combined
   ServerSignature On
   </VirtualHost>

2. sudo ln -s ~/conf/apache2/sites-available/local.case.oncle-tom.net /etc/apache2/sites-available/local.case.oncle-tom.net
3. sudo a2ensite local.case.oncle-tom.net
4. sudo service apache2 reload

On se fendra de l’ajout d’un hôte local dans le fichiers hosts pour coller au plus près à l’instance de production. Toutefois je ne connais pas d’autre moyen que de modifier le fichier d’origine :-/ Si vous avez une solution je suis preneur.

Configuration de MySQL

Pour MySQL c’est un peu plus compliqué car on va également en profiter pour déplacer l’emplacement par défaut des données. Pourquoi ? Pour les placer sur une partition qui ne craindra pas les formattages et les réinstallation système.
Si vous aviez déjà suivi ma procédure de déplacement des données MySQL : oubliez là. Celle-ci est largement plus aboutie.

Avant de se jeter à corps perdu dans les manipulations, voici la démarche entreprise :

1. créer le fichier de configuration MySQL
2. créer le répertoire qui accueillera les données MySQL
3. lier la base mysql d’origine
4. modifier la configuration d’AppArmor
5. recharger la configuration des serveurs AppArmor et MySQL

C’est déjà un peu plus long mais là encore, il n’y a pas grand chose à faire en fin de compte :

1. gedit ~/conf/mysql/my-custom.cnf
   On y indique le nouvel emplacement de ses données MySQL :

   [mysqld]
   datadir            = /home/oncletom/Apps/mysql

2. mkdir /home/oncletom/Apps/mysql
   sudo chown mysql:mysql /home/oncletom/Apps/mysql
3. ln -s /var/lib/mysql/mysql /home/oncletom/Apps/mysql/mysql
4. sudo gedit /etc/apparmor.d/usr.bin.mysql
   J’y ai remplacé

   /var/lib/mysql/ r,
   /var/lib/mysql/** rwk,

   par l’ancien chemin + le nouvel emplacement des données MySQL

   /var/lib/mysql/ r,
   /var/lib/mysql/** rwk,
   /home/oncletom/Apps/mysql/ r,
   /home/oncletom/Apps/mysql/** rwk,

5. sudo service apparmor reload && sudo service mysql reload

Si vous avez bien suivi toutes mes explications, vous vous demanderez pourquoi j’ai modifié le profil existant de MySQL dans AppArmor au lieu de lier un nouveau profil ?
Je me suis rendu compte qu’au démarrage de l’OS, AppArmor ne chargeait pas le profil personnalisé et bloquait le démarrage de MySQL. J’ai créé un sujet sur Ubuntu Forums après une lecture de la documentation AppArmor mais pas de nouvelles. Là aussi je suis preneur car en relançant les serveurs à la main, tout fonctionne.

Ensuite à vous de repeupler vos bases de données à partir d’un dump. Si vous procédez à un déplacement des répertoires, n’oubliez pas de tout préserver : propriétaire et permissions ! Ça se passe avec l’option -a de cp par exemple.

Configuration de PHP

Fort heureusement pour PHP c’est plus simple puisqu’il n’y a qu’un seul petit lien symbolique à faire.
À noter que la configuration modifiée sera répercutée sur toutes les configurations de PHP, que ça soit pour Apache, en CLI ou CGI.

1. gedit ~/conf/php/my-custom.ini
   J’ai ai mis par exemple :

   memory_limit = 64M

2. sudo ln -s ~/conf/php/my-custom.ini /etc/php5/conf.d/my-custom.ini

Et voilà c’est tout pour PHP. Il faut bien entendu recharger votre serveur Web (Apache ou Lighttpd par exemple) pour qu’ils prennent en compte la modification.

Conclusion

J’ai déjà appliqué cette méthode par 2 fois et que dire si ce n’est que tout va plus vite ainsi !
Vos fichiers de configuration restent accessibles depuis votre gestionnaire de fichiers (pas besoin de passer en sudo pour sauvegarder les changements). Ils sont préservés de toute réinstallation impromptue.

Vous ne touchez que de manière minimaliste aux fichiers de configuration d’origine :

• /etc/hosts pour ajouter un nom d’hôte (utile seulement si vous ne souhaitez pas utiliser localhost)
• /etc/apparmor.d/usr.bin.mysql pour la raison évoquée plus haut … sinon on s’en serait passé

J’ai cherché à faire pareil avec phpmyadmin mais il ne semble pas y avoir de mécanisme de ce type. Dommage.

J’imagine qu’il doit y avoir des moyens similaires avec d’autres serveurs et d’autres langages. Vous procédez à un reparamétrage systématique ou bien vous utilisez une technique de ce genre ?

Tout développeur, que ce soit à l’école ou en apprenant sur le tas, écrit du code. J’espère n’avoir perdu personne à ce stade de l’explication

Inconsciemment on cherchera à utiliser un style d’écriture avec lequel on se sent à l’aise, qu’on pourra et saura relire facilement et dans le meilleur des cas, qui pourra être relu par une autre personne sans avoir à engager d’interprète.

Tout développeur tend donc à utiliser des conventions de programmation (coding standards), que ce soit en HTML, PHP, CSS, JavaScript ou même en Cobol. Et utiliser des conventions, c’est bien !

Quelle convention de nommage adopter ?

Avant de choisir une convention, encore faudrait-il savoir quelles conventions existent :

• pas de convention
• convention hongroise
• convention PEAR
• convention symfony
• convention Zend Framework
• convention WordPress (que j’abhorre)
• etc.

Autant dire qu’il y a de tout et pour tous les goûts.
Ce qu’il faut retenir d’une convention c’est qu’elle explicite des règles de développement :

• sur le nommage des éléments
• sur l’indentation des éléments
• sur les structures de contrôle (if, else, tout ça quoi)
• sur la syntaxe des commentaires
• sur la syntaxe de la documentation (le code auto-documenté c’est bon !)
• sur l’organisation des fichiers, éventuellement

C’est pour ça que partir sur une convention parfaite sur le papier mais inapplicable est une vaste fumisterie. L’idéal étant de pouvoir reprendre du code dans un projet sans avoir eu besoin de lire la documentation pour en comprendre l’organisation.

Mon conseil : essayez, choisissez mais ne prenez pas non plus trop laxiste en terme de notation.
Une chose est sure : quand on a essayé une belle

Mes conventions de nommage en PHP

J’avoue, la notation utilisée dans symfony m’a tellement plu que je la réutilise quasiment partout. Ci-dessus, une illustration montrant du code pour un plugin WordPress (en PHP 4 malheureusement …). Elle en présente un bon aperçu.

Notation

J’utilise UpperCamelCase pour le nommage des classes sauf s’il y a un préfixe qui, lui, reste en minuscule.
Exemples : class AmazonWidgetsShortcodes, class sfUploader.

Pour ce qui est méthodes de classes, j’utilise lowerCamelCase. Comme ça on sait qu’on reste dans un objet et c’est pas plus mal.

Enfin, pour les fonctions orphelines, helpers & cie, c’est tout en minuscule séparé par des underscore (un nom particulier à ça ? lowered_and_underscored ? )
Exemple : add_filter()

Indentation

Dans l’indentation il y a 2 camps : celui des espaces et celui des tabulations.

J’ai suivi celui des espaces pour une simple et bonne raison : 1 tabulation a une taille différente selon les éditeurs, que ça soit votre IDE, votre shell ou n’importe quel logiciel de texte. L’idéal est d’avoir un rendu identique dans tous les éditeurs sans paramétrage.

En revanche, là encore je suis mais j’aime, je suis sur une tabulation à 2 espaces : c’est bête mais je trouve ça plus esthétique et on arrive moins rapidement à la limite de 80 caractères.

Cette « limite » n’est que virtuelle mais ouvrez un terminal, 80 lignes par défaut. C’est plus confortable de rester en-dessous de ce nombre. Ceci dit je fais quelques exceptions, des fois

Structures de contrôle

On pourrait résumer à 1 ligne = 1 action et 2 types d’utilisation.

Tout d’abord les structures dans le code à proprement parler :

• un espace entre l’opérateur et la parenthèse ouvrante
• un retour à la ligne à chaque accolade
• pas d’espaces dans les lignes vides (résidus d’indentation)
• systématiquement les accolades, même en cas de ligne unique après l’opérateur
• opérateur ternaire quand ça reste simple, pas trop long et plus lisible

Côté templating en revanche j’utilise la syntaxe alternative de PHP à raison d’un opérateur par ligne :

<ol class="posts">
<?php foreach($posts as $post): ?>
  <li id="post-<?php echo $post->getId() ?>">
    <a href="<?php $post->getPermalink() ?>">
      <?php echo $post->getTitle() ?>
    </a>
  </li>
<?php endforeach ?>
</ol>

Syntaxe de la documentation

Enfin, pour terminer sur la partie PHP, PHPDoc est surpuissante en plus d’être simple à utiliser. Comble du bonheur, sa syntaxe est réutilisable dans d’autres langages.

PHPDoc est le principe du code autodocumenté :

1. vous commentez votre code avec la syntaxe PHPDoc
2. vous générez sa documentation avec le programme PHPDoc (en HTML, PDF etc.)

L’idéal est de documenter en même temps qu’on produit le code. Par principe on revient rarement sur son propre code juste pour le loisir de le décrire, par manque de temps ou par flemme.

Mes conventions de nommage en JavaScript

Ne vous inquiétez pas, je ne vais pas tout recommencer pour JavaScript Je suis à peu près la même logique qu’en PHP à part pour les accolades.

En effet si je conserve un comportement similaire pour les structures de contrôles (1 accolade par ligne) :

• je ne fais pas de retour à la ligne sur les accolades/parenthèse ouvrante d’une fonction/objet anonyme
• je ne fais pas de retour à la ligne après une accolade/parenthèse fermante s’il y a une virgule ou parenthèse après

var OncleTom = {
  age:      25,
  pensee:   function(){
    return this.age * Math.random()
  }
};

Mes conventions de nommage en CSS

Inutile de paraphraser ce que j’ai déjà écris dans mon article sur les bonnes pratiques de codage CSS.

Deux lectures en une oui

Conclusion

Bon au final on voit que ce n’est pas si compliqué que ça d’apporter un brin de rigueur.
On pourra même s’amuser à compléter le tout par la disposition des méthodes et fonctions d ans un fichier par ordre alphabétique (j’en connais un que ça fera sourire ).

Les vues Outline fournissent un plan du code et certains logiciels ne semblent pas disposer d’une fonction de tri. Et au cas où un jour vous n’auriez pas votre IDE favori sous le nez, ça ne mange pas de pain de fonctionner ainsi.

Que l’on travaille seul à plusieurs, et à plus fortes raison dans ce dernier cas, l’utilisation de notations et conventions est un gage de qualité. Ça rend le travail plus facilement interopérable avec d’autres développeurs, plus facile à relire, plus facile à maintenir.

Ça n’empêchera jamais des bugs ou de sortir du mauvais code mais c’est ça, c’est une autre histoire.

Enfin, j’aimerais terminer cet article en écrivant qu’il a fait l’objet d’une chaîne par le Padawan PHPiste Damien Alexandre. C’était l’occasion de faire une réponse qui passe inaperçue

Ça ne m’empêchera en revanche pas de refiler la patate chaude à NicoDePrendreUnCafé, de tenter d’insuffler de l’activité au blog de Xavier Lacot, de Spipifier Gastero Prod, d’extirper une technique ninja pyjama à remouk et pourquoi pas lire avec attention l’avis pythonien de David Larlet ?

Et just for fun, un petit coup d’électrode à un de mes futurs étudiants, Thierry Poinot.

Il existe 4 phases dans la vie d’un développeur :

1. celle où il aime tout créer lui-même
2. celle où il aime utiliser un outil déjà tout prêt
3. celle où il aime concevoir son outil avec d’autres outils tout prêt
4. celle où il aime que les autres conçoivent pour lui (mais là il est patron ou armé d’une horde de stagiaires )

Les frameworks font partie de cette troisième catégorie. Ils existent dans à peu près tous les langages : CSS, PHP, JavaScript, Java, C#, Python, Ruby etc.
Mon discours portera sur les frameworks PHP, parce que c’est mon langage de prédilection mais aussi parce qu’un livre blanc sur les frameworks PHP pour l’entreprise est récemment sorti. Il parlera aussi bien aussi bien aux décisionnels qu’aux développeurs, à leur compte ou pour celui d’une entreprise.

De l’intérêt d’utiliser un framework

Un framework est littéralement ce que l’on peut appeler un socle logiciel : il propose des fonctionnalités de base et vous les utilisez pour concevoir votre propre application.

J’essaierai de faire court en énumérant une liste de quelques points à faire valoir dans l’utilisation d’un framework pour concevoir une application Web :

• développement accéléré
• convention over configuration : suivez les rails des conventions plutôt que de tout paramétrer
• DRY : écrivez le code une fois et réutilisez-le pour éviter le copier-coller (sans parler des gains de maintenabilité)
• mutualisation du code : un même socle pour plusieurs applications
• concentration du développement sur le code métier
• le framework vous décharge des tâches pénibles : sécurité, gestion des URL, gestion des permissions utilisateur, manipulation des bases de données, gestion du cache, accès aux fichiers etc.
• génération automatique d’interfaces (admin generator), de base de données (ORM), de modules/applications (scaffolding) etc.
• vecteur d’apprentissage individuel et collectif
• bénéfices de tout le travail d’une communauté … et de celui que vous réinjecterez

A contrario, on pourra critiquer les frameworks pour leur plus forte consommation en ressources qu’un développement maison.
Ce n’est évidemment pas une raison valable pour passer à côté d’autant plus qu’il existe de nombreuses solutions pour palier/réduire ce problème avec les gestionnaires de cache et les accélérateurs de code.

Framework PHP ou CMS ?

Maintenant vous me direz : pourquoi développer un logiciel avec un framework au lieu d’utiliser un bon CMS des familles ou tout autre logiciel faisant son office ?
Ce n’est à mon sens pas la bonne question à se poser : un framework n’est pas une fin en soi. Le choix du logiciel dépendra essentiellement du besoin, immédiat et futur. Vous aurez beau avoir le meilleur développeur d’un CMS de votre pays, si le choix de la solution technique est déjà erroné, il ne suffira pas à éviter la catastrophe.

J’ai beaucoup accroché à cette formule le jour où je l’ai entendu : si vous estimez à au moins 50% l’utilisation de spécifiques dans une solution logicielle existante de type CMS, vous faites fausse route. Le spécifique EST votre solution, le CMS devient une simple fonctionnalité.
Dans le cas d’un développement spécifique, le choix d’un framework est dans ce cas naturellement prescrit.

Dans tous les cas, ce sont vos besoins qui doivent vous guider vers le choix d’une solution et non l’inverse. Ne partez pas surtout d’une solution pour tenter d’y combler vos besoins.

Les principaux frameworks PHP

Le livre blanc sur les frameworks PHP expose en détail les frameworks majeurs en PHP avec leurs avantages, inconvénients et surtout une grille comparative permettant de mettre à bout à bout leurs différentes fonctionnalités.

Toutefois on peut retenir ces noms de frameworks PHP :

• CakePHP
• CodeIgniter
• EZ Components
• PEAR
• symfony
• Zend Framework

On pourrait classer ces frameworks en 2 catégories :

• les briques logicielles : ils se présentent comme des briques indépendantes qu’on peut utiliser à souhait dans n’importe quel projet, y compris d’autres frameworks. C’est notamment le cas de PEAR, EZ Components et Zend Framework ;
• les frameworks à proprement parler : ils imposent une structure particulière et des lignes directrices de développement pour être plus efficace. On citera dans ce cas symfony, CodeIgniter et CakePHP

symfony : champion toutes catégories

Lors de la lecture du livre blanc sur les frameworks PHP, vous remarquerez très probablement que le framework symfony a tout pour plaire. C’est en effet à l’heure où j’écris ces lignes le framework PHP le plus abouti et le plus intéressant à analyser.
Il jouit d’une excellente réputation, d’une incroyable stabilité et d’une communauté très active, quantitativement et qualitativement parlant. Si on ne devait en garder qu’un, ça serait lui.

Pourquoi j’apprécie énormément symfony :

• une documentation fonctionnelle et une documentation de l’API complètes
• utilisation intensive de fichiers YAML pour le paramétrage
• les fonctionnalités d’amin generator, de gestion de base de données avec l’ORM Propel et les outils d’automatisation qui en découlent
• facilité d’intégration d’Ajax sans pondre une seule ligne de JavaScript
• grand confort de développement
• des conventions inspirées des plus grands (Ruby on Rails, Django etc.)

Conclusion

Développeurs : renseignez-vous et intéressez-vous à au moins un framework. C’est bien pour le CV et vous gagnerez du temps.
Décideurs : exigez de savoir quelle solution on vous préconise et surtout, pourquoi celle-là. À plus forte raison si votre projet comporte beaucoup de besoins spécifiques, demandez s’il s’agit d’un framework et si ce n’est pas le cas, pourquoi ça n’a pas été envisagé. Vous gagnerez aussi du temps et j’espère de l’argent.

Les frameworks sont aujourd’hui partout et ont acquis une certaine maturité. Ces lettres de noblesse les rendent utilisables aussi bien pour des petits besoins que ceux d’entreprises, peu importe leur taille. Les gains de temps et l’incitation à la production de qualité sont des facteurs non-négligeables pour la pérennité de vos applications.

Attention toutefois : un mauvais développeur et/ou une mauvaise conception prédomineront toujours. Votre fromage industriel aura toujours le même goût, peu importe la qualité du pain

Je radote mais j’espère que vous trouverez suffisamment d’informations pour vous convaincre dans le livre blanc des frameworks PHP pour l’entreprise. C’est ce genre de publications qui me font aimer la société dans laquelle je travaille