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...

J’aime pas les IDE. Souvent, ils sont complexes et finalement n’aident pas forcément a gagner du temps lors de certains développements. Sauf que lorsqu’un projet se complique, c’est souvent un outil qui permet de ne pas trop se perdre (dans les répertoires et arborescence d’un projet web par exemple). 

Bref, j’ai longtemps préféré les éditeurs de textes aux IDE. Sauf que ce qui manque aux éditeurs de texte, c’est justement tous les outils de gestion (ou d’aide) de projet. Par contre, ils offrent généralement un système de coloration syntaxique bien plus simpa que les logiciels comme Netbeans ou Eclipse (malgré la possibilité de changer les configurations dans ces derniers). 

SUN Netbeans vs Eclipse 

D’un coté, nous avions donc une solution proposé par SUN et proposant 5 ou 6 « language » tel que php, java, c/c++, etc. Peu face a Eclipse et tous ses plugins. Sauf que du coup, le logiciel reste relativement simple. On ne s’y perd pas et l’installation reste relativement stable. Cependant, Netbeans semble évoluer plus lentement. 

Ce dernier point est troublant car SUN disposait d’une communauté de contributeurs talentueux, même si elle n’était surement pas aussi fournit que celle d’eclipse. Par expérience, j’ai pu constater que le travail de cette communauté était très cadré (ce qui pour moi est un avantage), c’est a dire qu’une équipe est suivit et les relations entre les intervenant sont optimales. Personnellement, j’ai rapidement été déçu du manque de Français. En France, on ne veux pas payer pour des logiciels, mais on n’aide pas a fournir une solution viable.

Bref, Depuis le changement de distributeur, SUN Netbeans est devenu ORACLE Netbeans. La communauté a été mise de coté sans vraiment l’être et netbeans est disponible aujourd’hui en version 6.7 beta (qui relève plus de l’alpha d’ailleurs).

Eclipse, la référence ?

Eclipse est l’IDE que tout le monde semble utiliser… D’ailleurs, le sdk android utilise cet outil. Mais également les enseignant d’informatique (notamment de programmation). Donc forcement, les élèves utilisent l’ide qu’ils ont appris a utiliser en cours. Le point insolite est de savoir que SUN signifie Stanford University Network (A vérifier quand même, je n’ai pas trouvé de sources sures) et que tous les cours que j’ai pu voir (via iTunes U) montrent une utilisation d’Eclipse, et non de Netbeans… ;-)
Bref, finalement, je suis retombé sous Eclipse comme tout le monde. Il semble qu’en fait, a défaut de trouver mieux, cette solution soit la « moins pire »… Elle peut tout faire a condition d’installer un plugins qui va bien. 

Après, il existe aussi d’autres solutions, tel que Coda qui peuvent répondre a des besoins plus spécifiques (ou a des goûts différents). Ainsi, j’utilise Coda pour le travail, Eclipse pour mes « projets perso ».

REST, SOAP et autres sont a la mode en terme d'architechture web. Notamment en temps que part intégrantes d'une implémentation de SOA (Services Oriented Architecture). Ne connaissant ni REST, ni SOAP, ce livre avait pour but de corriger ce manque.

Finalement, ce livre est excellent. Il explique très simplement comment mettre en place un service REST et quelques exemple pour intégrer quelques services tel que Flickr ou Yahoo! Maps. Les exemples sont codés en php un peu « a l'arrache », pas forcement très propre, mais d'un autre coté, cela permet a l'auteur de rester simple et d'illustrer clairement ses propos. 

J'ai été surpris par les exemples de codes... en effet, on pourait facilement pomper les bouts de code sans réfléchir. Sauf que les explication sont claire et donc on comprend dans la foulé. Les explications sont claires et précises, pas trop longues, ce qui fait qu'on a tendance a les lire aussi.

Je conseillerais grandement ce livre... mais ceci est un ouvrage pour les developpeur PHP. Si vous ne maitriser pas ce langage, cet ouvrage ne vous apprendra rien. (Notions XML utiles également !)

Environ 200 pages en Anglais.

C'est parce que je cherche un job que j'évite de poster sur mon blog. Pour éviter des conflits avec de futures opportunités entre ce que j'écris et ce que je pourrais faire. Par exemple quand je compare Google a Big Brothers et qu'ils me proposent un job, c'est normal que finalement, ça ne passe pas. Mais bon, comme je n'ai pas toujours le sens de la mesure, j'évite.

Aujourd'hui, j'écris sur un sujet d'étonnement, de notion que je mélange et pourquoi. En effet, j'ai fait pas mal d'entretiens d'embauche (j'ai du mal a trouver ce que je cherche). Bref, j'ai été confronté a des DRH et des chefs de projet qui mélangent SCRUM, MOA et MOE... et j'y comprend rien.

MOA/MOE : Truc made in France... 

La MOA, maitrise d'ouvrage, représente généralement les utilisateurs finaux (internes ou non). La MOE, maitrise oeuvre, représente les geeks qui construisent le truc (DSI ou autre). Cette séparation entre les utilisateurs et les concepteurs est une invention purement Française qui fonctionne plutôt bien (dans l'industrie automobile en tout cas). Le problème dans l'informatique, c'est que la séparation entre les développeurs et le métier cible n'est pas imaginable. Les développeurs ne connaissent pas toujours les métiers pour lesquels ils développent. Cela entraine des décalages entre les attentes des clients (souvent concernant des éléments implicites liées a un métier. 

Ainsi, la communication entre MOA et MOE entraine la production d'une quantité importante d'informations et documents divers...

Avec les quelques stages que j'ai pu effectuer, je me trouvais dans une autre situation. En effet, l'avantage que j'ai toujours eu, c'est de travailler pour un « client interne » la plupart des temps. Ainsi, en cas de doutes, une simple question (orale) suffisait a débloquer une situation.

L'agilité et SCRUM

SCRUM est a la mode en ce moment. Cependant, a part les développeurs, je ne suis pas certains que tout le monde emploi ce terme en sachant vraiment ce qu'il signifie... 

En bref, SCRUM est une méthode permettant de mettre en place un cadre général. Cela défini des interactions entre les membres d'une équipe, aussi bien les développeurs que le client (ou le représentant des clients). Cette méthode favorise la communication plutôt que les outils. Pour faire simple, l'avantage de scrum est de faire en sorte que tout le monde communique ensemble pour construire quelque chose de fini plus rapidement et de manière plus efficace. Le principe le plus connu concerne les « itérations » qui visent a obtenir a chaque fois un livrable (qui pourrait être mis en production).

Il existe d'autres méthodes dans le même genre, appelées méthodes agiles, Extreme Programming entre autre.

Pourquoi je suis perdu ?

SCRUM et MOA/MOE ne sont pas vraiment compatibles. Ce qui me perd lors des entretiens, c'est lorsque l'on me précise que l'entreprise mélange ces méthodes... Le gros truc des méthodes agiles est de rapprocher les informaticiens des clients, au contraire des MOA/MOE. J'ai peur que certains comprennent seulement le principe des itérations, qui n'est qu'une petite partie des principes et cadres définies par les méthodes agiles.

Je pense que je me trompe, mais je n'arrive pas a obtenir plus d'informations... (si vous en avez, je suis preneur !)

On me parle également de prestation au « forfait », sauf que la aussi, cela me dérange. Comment fait-on pour définir une prestation avec un périmètre fixé a l'avance en choisissant d'utiliser une méthode agile pour les développements ?
Bref, j'ai encore pas mal de chose a apprendre ! 

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. 

Le journal du net fait un appel a contribution concernant la différence entre PHP et DotNET.

En lisant les témoignages, on se rend compte que ce sont deux mondes très différents, et que les gens ne peuvent pas être d’accord. Cependant, on constate aussi que personne n’a construit de réponses réellement argumentées. C’est ce que je vais tenté ici en proposant 3 éléments positifs et trois éléments négatifs de chacun.

DotNet

Points forts :

• Support Microsoft
• Communauté de développeur employés Microsoft
• Les entreprises pensent que parce que c’est payant, c’est mieux (en bref).

Points Faibles :

• Support des technologies tierces inexistant, et intégration super complexe voir impossible.
• Ne fonctionne QUE avec IIS.
• Fonctionne mal avec les clients non Microsoft.

PHP

Points forts :

• Libre
• Standard du développement d’application web
• Fonctionne sur toute plateforme

Points faibles : 

• Les entreprises n’ont pas confiance dans les technologies libres…
• Langage de script
• Dépendance vis a vis de la société Zend

Conclusion

Personnellement, je n’aime pas DotNet… donc ce qui suis n’est pas vraiment des plus objectif ! Mais j’ai constaté, lors de collaboration avec des développeurs DotNet, que le code obtenu est plus rapidement crade qu’avec PHP. En fait, normalement, PHP permet plus facilement de faire n’importe quoi, mais comme les développeurs de ce langage le savent, ils sont nettement plus attentifs a cela. 

Je n’ai sans doute pas rencontré les bonnes personnes. Cependant, les (autres) développeurs que j’ai rencontré sont souvent du même avis… pourquoi essayer d’utiliser une technologie propriétaire via sont outil libre Mono pour finalement se retrouver avec une application reposant sur le .net Framework, particulièrement connu pour ses bugs et failles de sécurité (assez simples a exploiter d’ailleurs). Quand je parle des bonnes personnes a rencontrer, c’est aussi parce que je ne connais pas aujourd’hui de développeurs qui travaillent sous environnement Microsoft. Et si j’en rencontre un, j’avoue que mes préjugés feront que j’aurais de sérieux doutes concernant ses compétences. C’est marrant, parce que j’ai l’impression que c’est le contraire en entreprise… (PHP en entreprise, c’est tabou, imaginez, c’est gratuit, libre et puissant !).

Le monde du libre permet de modifier un environnement du tout au tout. C’est cela qui fait sa force et qui nous permet de construire des applications robustes et performantes. Si on a besoin de quelque chose de précis, alors il est assez facile de construire l’outil pour cela, même si cela demande de modifier un applicatif du noyau du système d’exploitation. Essayez de faire pareil avec les produits Microsoft ! 

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 ! 

Mac OS X Snow Léopard est livré avec une version préinstaller du serveur web Apache en version 2 et de PHP en version 5.3. Ainsi, pour avoir une configuration de type AMP (Apache, MySQL, PHP), il nous faudra juste activer apache, configurer ce dernier et PHP, puis installer et configurer MySQL.

Configurer Apache :

Pour activer Apache, il suffit d’aller dans les préférences système, de cliquer sur l’icône « partage » et d’activer le « partage web ». Maintenant, aller voir l’url ... a l’aide d’un navigateur web.

Ainsi, le serveur apache fonctionne et ne demande plus qu’à être configuré pour pouvoir supporter PHP. Pour cela, nous allons ouvrir une session en ligne de commande en utilisant le terminal (application -> outils systèmes -> Terminal).Entrez la commande suivante pour éditer le fichier de configuration du serveur apache (sans le $) : $ sudo nano /etc/apache2/httpd.conf

Le mot de passe administrateur vous sera demandé (la commande sudo permet d’obtenir les droits administrateurs momentanément). Nano est l’éditeur que j’utilise en ligne de commande. Vous pouvez bien sur en utiliser un autre. 

Le fichier http.conf s’affiche dans le terminal. Vous pouvez l’éditer. On recherchera la ligne « #LoadModule php5_module libexec/apache2/libphp5.so » a l’aide des flèches directionnelles du clavier et on supprimera le ‘#’. Ce signe permet de passer les lignes en commentaires, c’est a dire que les lignes commençant par ‘#’ ne seront pas lu par le serveur apache.

Appuyez sur « Ctrl + X » pour quitter nano. Celui ci vous demandera de confirmer l’enregistrement des changements apportés au fichier, répondez oui (‘Y’ et entrer), appuyez sur entrer pour confirmer le nom du fichier a modifier (ne pas le changer !).

A ce stade, le serveur apache aura besoin d’être redémarré pour prendre en compte les changement que nous venons d’effectuer, nous le ferons a la fin. Vous pouvez fermer le terminal pour le moment.

Installation de MySQL :

Téléchargez MySQL (...) en choisissant la version correspondant à votre ordinateur. Ce logiciel s’installe comme n’importe quel autre logiciel mac… il faut penser a bien installer les trois éléments que sont MySQL (serveur SQL de base), StartUp Items (les outils de démarrage et arrêt du serveur MySQL) et Prefpanes (Permet l’ajout d’un onglet dans le panneau des préférences systèmes pour arrêter ou lancer le serveur MySQL).

Il est important de noter que par défaut lors de l’installation de MySQL, le compte administrateur initialisé n’est pas du tout sécurisé (identifiant « root » sans mot de passe !). Vous pourrez utiliser  les outils graphiques proposés pour gérer plus facilement vos bases de données locales et les utilisateurs. Pour cela, il existe un package MySQL GUI Tools (...) pratique notamment pour les sauvegardes et restaurations de bases de données. Pour ce qui est de la gestion des bases de données en elles-mêmes, je préfère utiliser le logiciel Sequel Pro (...) plutôt que phpMyAdmin…

Configuration de PHP :

Pour configurer  PHP, nous allons relancer le terminal. Nous allons copier le fichier php.ini.default en php.ini en utilisant la commande $ sudo cp /etc/php.ini.default /etc/php.ini (toujours sans $). Maintenant, nous allons éditer le fichier que nous venons de créer en tapant la commande $ sudo nano /etc/php.ini .

Pour faire fonctionner correctement PHP avec MySQL, il sera nécessaire de remplacer tout les « /var/mysql/mysql.sock » par « /tmp/mysql.sock ». On peut également en profiter pour configurer le fuseau horaire nous concernant pour éviter des problèmes éventuels en renseignant la ligne « date.timezone = Europe/Paris ».

Voilà, on peut quitter pico en enregistrant les modifications que nous venons d’effectuer. 

Conclusion :

Maintenant, il ne nous reste plus qu’a relancer le serveur apache en tapant dans le terminal la commande $ sudo apachectl restart et en suite fermer le terminal.
L’installation  de notre plateforme AMP est maintenant finie. Les éléments contenus dans votre dossier « Sites » seront affichés à l’adresse http://localhost/~VotreNomUtilisateur