CodeIgniter est un framework php qui a pour principal caractéristique d'être leger (enfin plus que les autres) et plutôt simple a utiliser. Ce n'est pas vraiment un concurrent de frameworks comme Simfony ou Zend Framework qui sont plus des usines a gaz visant a concurrencer des framework comme ceux existant en Java et non a aider/simplifier le travail du developpeur. En dehors du fait que ZF soit issue de l'entreprise qui developpe PHP, je n'aime vraiment pas ce « truc », je le trouve vraiment pas fini (au départ, je pensais que le probleme venait de moi, et puis finalement, des amis Québécois m'ont confortés dans ma vision).

La nouveauté de la nouvelle version de CodeIgniter, c'est qu'elle intégre maintenant 'que' php5 (donc OOP). Son Fork, kohana l'intégrait, lui depuis le debut... m'enfin passons.

Il faut savoir que les mises a jours de CodeIgniter sont beaucoup plus rares, notamment par rapport a drupal par exemple (la communauté est également drôlement moins importante !). Donc quand il en sort, on peut se permettre (on doit?) de faire les mises a jours. Ce changement de version est spécial puisque comme mentionné plus haut, il retire le support de PHP4 et ajoute enfin les aspects de programmation orienté objet permis par PHP5. Donc si votre code est très laid, ce n'est pas la peine (remarquez, on peut également faire du code assez laid avec la version 5).

Bref, on remarque vite lors de la mise a jour que la doc pour aider est assez pauvre... d'ou ce billet.J'ai décomposé mes étapes pour la mise a jour d'un projet perso. Ce dernier est assez simple, utilise déjà pas mal (voir tous) les concept php orienté objet (enfin le plus possible en fait). Et dans ce cas ne devais pas poser de probleme a la lecture de la documentation officielle. Il y en a eu (quasiment a chaque étape) et SVN m'a permis de gagner bien du temps (j'ai fait pas mal de roll back !).

Enfin, voici ce qui nous intéresse, les étapes que j'ai suivis :

1 → Sortir (copier/coller) le repertoire system/application a la racine (de manière a avoir /application au même niveau que /system).

2 → Remplacer /system de la version actuelle (dans mon cas 1.7.3) par le nouveau de la version que l'on aura télécharger sur le site officiel (http://www.codeigniter.com), c'est a dire dans mon cas la version 2.0.1

3 → Remplacer le fichier index.php de la racine par celui de la nouvelle version.

4 → Renommer le fichier application/config/autoload.php et copier celui de la nouvelle version.

5 → Ouvrir les 2 fichiers d'autoload, y remplacer « APPPATH.'third-party' » (ligne 40) par rien (on aura alors « array() ») et remplacer les lignes utiles a partir de l'ancien fichier (libraries, helpers, models, etc...). ATTENTION : certains éléments n'ont plus les mêmes nom (par exemple 'validation' devient 'form_validation').

6 → Remplacer pour tous les controlleurs le « extends Controller » par « extends CI_Controller ».

7 → Faire de même avec les modeles de manière a avoir « extends CI_Model ».

8 → Remplacer dans les fonctions du code du repertoire application tous les constructeurs la ligne « parent ::[...] » par « parent ::__construct() ; ».

Voila pour la recette, j'espère qu'elle pourra aider certain d'entre vous...

Le theming drupal n’est pas facile à comprendre quand l’on commence à s’y intéresser. En effet, certains conseillent de partir de rien et de construire son thème « from scratch » d’autres conseillent de partir d’un thème existant… mais ceux-ci sont souvent complexes pour une première approche.

Personnellement, je pense que partir d’un thème existant est la meilleure solution, sous certaines conditions. Il s’agit de partir d’un thème simple, de l’adapter à notre besoin et de ainsi comprendre de nouveaux mécanismes (que l’on n’aura pas forcément saisis dès le départ) et ainsi progresser pour appréhender des thèmes plus complexes.

 
Quel kit de départ choisir ?

Pour commencer, il faut se rappeler des bases !

En suite, il s’agit simplement de prendre un thème simple pour le modifier. Dans mon cas, j’aime utiliser le kit de départ « Basic » , en le modifiant un peu. Je ne garde que les fichiers « .tpl.php » et le dossier « css ». Je supprime les autres fichiers, renomme le fichier basic.info en fonction du nom de mon nouveau thème… et j’adapte son contenu à mes besoins. Par exemple je n’utilise pas les « features » car je considère que cela est bien pour des thèmes génériques mais pas pour un thème custom… Finalement, je garde le fichier « template.php » au départ, mais je le vide complètement.

En bref, déjà que ce kit de départ est simpliste, mais moi, je le nettoie encore de son code, selon moi superflu.

Certains conseillent d'utiliser le starter kit "Zen"... personnellement, je ne le conseil pas car il est complexe. En effet, les thèmes de départ, sensés être simples dépendent fortement du thème principal (dont en fait ils sont des "sous-theme"). Ainsi, le thème Zen est sympa, mais pas simple a exploiter. Si vous l'utilisez, vous constaterez que le thème drupal de ce blog ressemble a l'un des sous thème Zen... sauf qu'il est en fait construit avec une copie personnalisé par mes soins du thème "basic". 

La structure des css

Le système d’organisation de drupal permet de remplacer les fichiers par ceux que l’on souhaite… en fait, par défault, drupal va utiliser ses fichier de gabarit a lui dans le cas ou le thème choisi n’en possède pas. Ainsi, on remplace en quelque sorte les gabarits du système par les nôtres en utilisant un thème spécifique. Ces remplacements concernent les fichiers « .tpl.php ». 

Bien évidemment, nos gabarits utilisent nos feuilles de style (css) qui sont elle même contenu dans le répertoire du thème.

La structure des fichiers CSS est elle aussi un peu spéciale, mais terriblement logique et efficace. Cette structure permet de savoir tout de suite quel fichier est à modifier pour obtenir un style précis sur un élément du code html.

Dans le cas de notre thème de base, nous avons :

• css/default.css : contient les propriétés concernant la structure de la page (wireframe), c’est a dire les mises en formes génériques concernant les différents blocks html. Il est le cadre le plus haut et concerne les éléments tel que le header, le wrapper (content) et le footer.
• css/layout.css vient juste en dessous de default.css et affine les mises en forme en gérant les principaux blocks que sont les « sidebars », les régions, etc. Cependant, ce fichier contient surtout des propriété de positionnement des éléments les uns par rapports aux autres. Ce fichier contient des propriétés portant sur les id et classes laissés sur les balises html (#content, .sidebar, etc).
• css/style.css concerne quant à lui les balises html. On retrouvera ainsi les mises en forme de liens, etc…

Ces trois fichiers permettent de tout mettre en forme. En effet, on part de default.css pour une organisation générale du rendu. On passe en suite a layout.css pour mettre en forme les blocks de la page tel que les dimension et positionnement des « sidebars », pour finalement finir par les balises html. On constate que tout reste général. Cela permet de garder une cohérence sur tout le site. Cependant, dans le cas d’un besoin précis de mettre en forme un élément en particulier, je vous invite a le faire dans un nouveau fichier css que vous indexerez dans le fichier montheme.info pour qu’il soit pris en considération par « montheme ».

Outils conseillés

Pour ces manipulations, vous n’aurez pas besoins de logiciels spécifiques. Un « block note » avec une coloration syntaxique suffit (Notepad++, SciTE, Smultron, etc). La coloration n’est pas obligatoire, mais est plus confortable ! Pour vous aider dans le choix des éléments a mettre en forme et déterminer quelle propriété intervient sur l’élément concerné, je vous conseil d’installer le plugin pour firefox nommé firebug.  

Créer un thème n’est pas très complexe, mais il faut savoir comment ils fonctionnent pour arriver à un résultat propre. Vous constaterez que je n’ai pas parlé de modification concernant le fichier template.php. En fait, j’utilise ce fichier essentiellement pour la suggestion de Template. Ce sujet sera abordé lors d’un prochain billet. 

Les thèmes s’appuient sur un moteur de Template. Par défaut et dans 99% des cas, ce moteur de Template est PHPTemplate.

.info

Le fichier « .info » est obligatoire car c’est lui qui contient les paramètres de configurations :

• Métadonnées,
• Emplacement des fichiers CSS dédiés au thème (généralement, on a un layout.cssqui concerne les « boites » et un style.css qui concerne plus globalement toutesles balises), 
• Emplacement des fichiers JS dédiés au thème (différents de ceux des modules), 
• Les noms des régions, ‐ Les « Features » (Ce sont les éléments personnalisables dans l’interfaced’administration de drupal tel que l’affichage du logo, du slogan du site, etc...) 
• Etc...

La version du thème est à négliger, voir oublier. Les informations concernant le drupal core et le moteur de Template utilisé sont obligatoires. Pour que le drupal core soit égal à la version utilisée, on ne tapera pas « 6.14 » par Exemple mais « VERSION ».

.tpl.php

Les fichiers d’extension « .tpl.php » sont les gabarits xhtml utilisés par le thème. Ils ne sont pas obligatoires et s’ils sont présents, ils viennent en remplacement de ceux du cœur de Drupal ou des différents modules. Le code PHP qu’ils contiennent doit se réduire que a la fonction « print ». Par défaut, on constate que certains thèmes comme Garland, zen ou d’autres contiennent également des conditions (if). Idéalement, ces conditions ne devraient pas apparaitre, sauf que dans le cas de ces thèmes, cela leur permet une plus grande généricité. Pour un thème fait « sur mesure », ces conditions sont inappropriées. Il en va de même pour les features du « .info » qui deviennent alors inutiles !

Tout autre élément « logique » écrit en PHP ET lié au thème sera à inclure dans un autre fichier (template.php par exemple).
Il y a cinq gabarits principaux :

• page.tpl.php, modèle principal des pages. 
• node.tpl.php, modèle de construction des nœuds (node), 
• block.tpl.php, modèle de construction des blocks, 
• comment.tpl.php, modèle de construction des éléments liés aux commentaires, 
• box.tpl.php, est cité comme étant le modèle de construction des boites, sauf quecelles-ci ne sont plus utilisées dans la construction des pages Drupal (depuis la version 6.x incluse !).

Il est possible d’utiliser d’autres fichiers de gabarit. Pour cela, on peut utiliser des noms de fichier réservés (tel que page‐front.tpl.php pour le gabarit de la page d’accueil) ou en spécifiant le fichier a utiliser dans le fichier template.php. 

La version complète en VO est ici !

Drupal, pour ceux qui ne connaissent pas encore, c’est un CMS open source créé par Dries Buytaert. Cet outil a été plusieurs fois récompensé, notamment en 2008 (...). Aujourd’hui, c’est le CMS qui monte dans la communauté des développeurs Web Open Source. Je vous propose une petite présentation de Drupal et de ses principes de bases ainsi que des éléments qui font que j’accroche pour la première fois pour un CMS !

Drupal, c’est plus de 1 600 modules, et une communauté de 350 000 membres au 01/08/2008.

L’installation de drupal se fait en 3 secondes… juste le temps de créer une base de données avec MySQL (en standard) et de lancer l’installeur graphique. Certains geek linuxiens pourront même utiliser l’outil Drush (...) pour installer une instance de Drupal en ligne de commande à la manière commandes apt-get. 

L’installation de drupal ne pose pas de problème et on dispose rapidement d’un site standard. On peut directement commencer à entrer du contenu. Ce qui est dans un premier temps assez déroutant, c’est que l’on confond le back office du front office. En fessant une analogie avec d’autres CMS tel que le vieillot SPIP ou encore les moteurs de blog tel que Wordpress, on a pas de réelle différenciation entre la présentation du front et celle du back. On peut cependant définir des thèmes différents pour la partie administration et la partie publique.

Vue de la surface :

Drupal s’articule autour de 3 « briques » : un système de base, des modules et des thèmes. 

Le système de base est la partie intéressante du CMS. C’est en effet cette partie qui fait l’originalité du système. On pourrait le comparer a un noyau linux : c’est le cœur du système. Les développeur de Drupal l’on conçu de manière a ce qu’il reste ultra-performant. 

Les modules sont assez rebutant à installer pour le néophyte car cela demande de naviguer dans les répertoires du site. Mais comme dirait la publicité Apple, « Si vous voulez faire un truc, il y a un module pour cela ! ». Drupal dispose d’un système de hook. Ce dernier permet aux modules d’être bien intégré au cœur du système. Pour schématiser le fonctionnement interne des interactions entre les modules et le cœur, quand un évènements se déroule, le système demande « Un module veut-il faire cette chose ??? », si un module répond oui, alors il le fera, sinon c’est le système qui gérera le truc. Les modules s’installent indépendamment du reste. Ainsi, la désinstallation d’un module n’entraine pas de suppression en cascade des données, mise à part celle concernant le module lui même. Par exemple en installant un module de galeries d’images, en le désinstallant, on supprimera les galeries créer, mais pas forcement les images qui ont été créées et qui dépendent d’un autre module. Une solution intermédiaire est également proposé et consiste en la désactivation du module… sans impact sur les données qui seront en quelque sorte dépubliées. 

Vue de la surface le système de thème est très performant. Il constitue en quelque sorte un super module a lui seul. J’aime beaucoup le système de région. Il permet de choisir d’affecter des blocks à une région et de choisir les pages sur lesquelles on souhaite l’afficher ou non et/ou en fonction de quel rôle d’utilisateur également.

Le dernier point intéressant lors d’une approche rapide de ce CMS concerne justement la gestion des permissions et des rôles des utilisateurs. En effet, on peut ajouter des rôles et leur affecter des permissions d’accès spécifiques. On peut ainsi créer un site de création de contenu communautaire et avoir des rôles tels que le visiteur (internaute standard, on inscrit), l’utilisateur, le modérateur, le contributeur, le super contributeur, le webmaster et l’administrateur. Par défaut, il y a deux rôles : l’utilisateur enregistré et l’utilisateur non enregistré… ainsi que un troisième rôle implicite d’administrateur (qui est défini par le compte créé lors de l’installation du site).

Sous la surface : une plongée (en apnée) dans le code.

Comme tout CMS, Drupal dispose d’une logique bien a lui. Cela se reflète dans la manière dont le code a été écris et dans la manière dont il faut l’écrire. Les premiers coups d’œil rapides sur les sources peuvent faire peur…
Ainsi par exemple, ce CMS n’est pas codé selon les méthodes dites Object… Cela m’a surpris au départ. Cependant le système de hook est implanté de telle manière que finalement, on s’y retrouve, même si cela peut prendre du temps. En fait, on s’aperçoit très vite que l’on n’aura généralement pas besoin de coder un module à partir de rien. Vu le nombre de module existant, il y en a toujours un qui fait a peu près ce que l’on souhaite. Il s’agit alors d’adapter ce qui existe à notre besoin. Par contre, si on ne trouve pas ce que l’on cherche, la tâche peut vite devenir lourde…

Le theming et le développement de module sont deux chose bien distinct dans le monde Drupal. Au départ, ce n’est pourtant pas évidant à saisir. En effet, certains modules vont géré la manière d’afficher certaines données… venant en quelque sorte parasiter le thème choisi. Mais dans se cas, l’affichage de ces données se fera de la même manière quelque soit le thème.
De plus, on constate que Drupal a adopté une approche MVC selon les sources officielles… Personnellement, j’ai toujours pensé que ce système MVC permettais a des acteurs ayant des profils différents de travailler ensemble a la réalisation d’un site web. Or il sera bien difficile a un graphiste ne maitrisant pas un minimum PHP d’intervenir sur Drupal. 

Bref, les contacts avec les sources ne sont pas forcements simples. Cela demande en effet la lecture de nombreuses documentations pour comprendre le fonctionnement du système. 

En conclusion :

Drupal est le CMS à la mode en ce moment. Il permet de faire quasiment tout ce que l’on veut via un système de gestion de modules assez redoutable et un système de thèmes performant.

L’avantage de ce CMS est d’être extrêmement modulaire et de pouvoir fonctionner aussi bien en temps que CMS (normal, c’est son objectif premier) mais également un peu comme un Framework PHP lorsque l’on maitrise son architecture interne et son système d’API. 

Pour les néophytes débrouillés, il permettra de programmer un site web au moyen de la souris… ce qui est rebutant pour le développeur plus confirmé !

D’ailleurs, c’est sans doute ce dernier qui aura besoin de plus de temps pour apprivoiser Drupal. Le système de hook est bluffant mais encore faut-il le maitriser…

Drupal semble pouvoir tout faire mais a condition de rester quand même dans une réalité proche… d’abord pour qu’il y ai dans la communauté quelqu’un qui ai développer LE module dont on a besoin et en suite pour que le thème que l’on ai choisi nous convienne et que l’on ai pas besoin de trop le modifier.

Ce billet n’est qu’une introduction. Pour vraiment comprendre pourquoi j’aime bien cet outil, il faudrait que je mentionne le développement de module ainsi que le theming (dans des futurs billets !). Cependant, mes premières impressions étaient celles décrites ici !