Avant de me lancer dans la conception d’un thème j’ai voulu essayer de voir comment Drupal fonctionnait au niveau de la gestion des extensions. Tout d’abord les thèmes et les modules sont séparés ce qui permet d’intégrer plus facilement un concepteur graphique dans un projet. Les thèmes sont à rajouter dans ‘sites/all/themes‘ et les modules dans ‘sites/all/modules‘.

Je cours chercher un premier module à intégrer dans mon site: FCKeditor. J’utilise déjà cet éditeur en ligne dans Plone, cela me permettra de comparer la difficulté d’installation dans les deux cas.
Pas de chance, ce module est relativement complexe à installer. Une fois l’archive décompressée dans votre arborescence il faut encore aller chercher une version de fckeditor sur son site officiel et la déposer dans le module. J’espère que la dernière version de FCKeditor est compatible avec cette version du module.
Ensuite, pour avoir la possibilité d’utiliser un navigateur de fichier lors de l’édition des pages il faut encore suivre une procédure pour l’activer. Le fichier README est là pour me guider, mais la procédure est pour Drupal 5.2. Je croise les doigts.
Au final, de retour dans l’interface de configuration des modules le menu FCKeditor est bien présent, mais il me demande d’aller configurer les permissions pour savoir si les anonymes et les utilisateurs authentifiés peuvent utiliser ce module… beaucoup de chose à faire pour avoir une installation fonctionnelle par défaut.

Les autres modules présents par défaut dans Drupal 6 présentent un niveau de complexité moins élevés dans le sens où il faut les activer (forum, blog, sondage,…) puis gérer les permissions.

Pour installer FCKeditor dans Plone il faut décompresser l’archive, redémarrer le serveur puis appuyer sur le bouton ‘installer’ dans l’interface de configuration. L’installation est fonctionnelle immédiatement sans même avoir lu le README.

Pour moi c’est un mauvais point pour drupal : mes modules n’intègre aucune procédure d’installation automatique qui les rend fonctionnel
 immédiatement pour un débutant. Cela me ramène 4 ans en arrière pour le monde Zope.

Maintenant que je peux créer un peu de contenu je vais pouvoir m’atteler à la création d’un thème.

En tant que salarié du groupe Alterway nous avons eu compte d’essai chez Nexen services pour hébergé un site en PHP/MySQL. En temps que développeur Python nous nous sommes posé la question: « C’est bien gentil, mais à quoi cela va-t-il nous servir ? ». Pourquoi ne pas tester un framework LAMP en reprenant un site fait de bric et de broc pour en faire un site professionnel… pour l’instant le nom du site restera secret.

Après investigation auprès de mes camarades de Nexen c’est sur Drupal que je vais faire mes armes. Cela fait 5 ans que je n’ai pas touché à du PHP, j’ai un brin de nostalgie. La première chose à faire est de trouver de la documentation. Un coup d’œil dur le site de la communauté drupal française et me voilà avec un tutorial un peu court mais suffisant pour commencer.

Viens la question fatidique de la gestion du projet. Je serai seul pour le moment, mais le développeur de la version précédente du site viendra sans doute me donner un coup de main durant la phase de migration. De plus, je voyage beaucoup, un système centralisé n’est pas envisageable.

Il me reste bazaar, darcs, mercurial et git. J’ai déjà testé les trois premiers avec un penchant pour darcs mais c’est un bonne occasion pour tester git qui semble avoir le vent en poupe. un coup de ‘man
gittutorial’ pour démarrer :

Préparation des sources en local

$ tar zxf /home/encolpe/Desktop/drupal-6.4.tar.gz
$ mv drupal-6.4/ drupal-nexen
$ cd drupal-nexen/
drupal-nexen$ git init

Initialized empty Git repository in /…/drupal-nexen/.git/

drupal-nexen$ git config –global user.name “Encolpe Degoute”
drupal-nexen$ git config –global user.email encolpe@gmail.com

drupal-nexen$ git add .
drupal-nexen$ git commit
…
drupal-nexen$ tar zxf /home/encolpe/Desktop/fr-6.x-1.x-dev.tar.gz

drupal-nexen$ git status
…
drupal-nexen$ git add */*/translations *.fr.txt
drupal-nexen$ git commit
…

La prise en main de git semble simple jusque là.
Faire un ‘git add .’ est beaucoup plus explicite que la commande ’svn import’: c’est le dossier courant qui est importé, pas de doute possible.

Il faut ensuite configurer un client FTP pour déposer vos fichiers sur votre compte hébergé. Je choisi le logiciel en ligne de commande ‘ncftp‘ dans l’espoir de pouvoir le coupler avec les commits dans la branche principale de git pour gagner un peu de temps.
Ce couplage devra être asynchrone…

J’ai maintenant un beau site qui me montre sa page d’installation sans me demander de mot de
passe (sic). D’ailleurs il ne semble pas très content. Soit disant il faut que je copie ‘sites/default/default.settings.php‘  dans ‘sites/default/settings.php‘ . Pas de panique.

drupal-nexen$ git mv sites/default/default.settings.php sites/default/settings.php
drupal-nexen$ git commit sites/default

Ensuite vous pouvez modifier le paramètre db_url pour les accès à votre base (notez la triple présence de username) :

$db_url = ‘mysql://username:********@mysql.username.nexenservices.com/username’;

Après un nouveau commit et le transfert du fichier vers votre compte hébergé vous pouvez maintenant terminer l’installation en choisissant la langue de votre site et en laissant faire l’installeur… ou non.

Erreur en installant Drupal

Vu d’ici cette histoire de ‘register_globals‘ à désactiver semble un brin complexe. Est-il possible de configurer ce genre de paramètre avec mon compte Nexen ?

Il faut aller voir sur la page d’accueil du compte http://www.nexenservices.com/webmestres/index.php pour aller chercher la solution. Une fois connecté il faut choisir votre site mutualisé en bas de la colonne de gauche puis cliquer sur ‘Configuration avancée‘ à nouveau en bas de la colonne de gauche.

Il faut configurer la racine du site, soit le dossier ‘/‘ et désactiver ‘register_globals‘, ce qui se fait en deux étapes et en image :

Choisir php et / pour le dossier racine

Il suffit de laisser les choix par défaut et de valider

Maintenant il faut reprendre l’installation en allant sur la page http://mysite.nexenservices.com/install.php et en recommençant la procédure complète. L’installation se termine bien cette fois.

La prochaine étape sera de créer un thème pour le site. Nom de code: Opération Zèbre.

Just a bill to announce the first release of Nagare that use stackless Python.
If you want to test it you can try the Full Demo
If you want to install it you can follow the Quick Start Guide

Les distributions GNU/Linux usent et parfois abusent de python comme langage de script pour la configuration du système. En contrepartie il devient difficile d’utiliser easy_install sans casser le système. Il se peut aussi que certains logiciels python est une liste de dépendances tellement longue qu’il soit impossible de les installer tel quel dans le système avec easy_install. Pour éviter ces écueils, plusieurs parades ont été mises au point et la plus aboutis est sûrement virtualenv.

Les eggs des modules comme python-ldap ou Python Imaging Library sont très dépendants du systèmes et demandent des installations particulières selon les plateformes (PILwoTK ne fonctionne pas sous win32 par exemple). D’autres eggs comme gaphor ou i18ndude demandent quasiment une installation séparée. Pour ces derniers il est possible de sans toucher au Python du système.

Pour commencer il vous faudra choisir sur quelle version de python vous souhaitez travailler :

# easy_install-2.5 virtualenv

ou

# easy_install-2.4 virtualenv

Ensuite vous aller créer une boîte pour votre python :

$ virtualenv --no-site-packages monprojet cd monprojet$ ls

bin         lib

# voici une commande toute prête pour modifier le PATH

$ source ./bin/activate

(monprojet)$ which easy_install

/home/encolpe/monprojet/bin/easy_install

(monprojet)$ which easy_install-2.4

/home/encolpe/monprojet/bin/easy_install-2.4

(monprojet)$ which python2.4

/home/encolpe/monprojet/bin/python2.4

(monprojet)$ which python

/usr/bin/python

À partir de maintenant vous pouvez utiliser easy_install dans votre répertoire sans craindre d’interaction avec le système.

Cela faisait un bon moment que je n’avais pas écrit un billet ici… et pour cause: on temps libre est principalement occupé par le développement et les tests de la version 2.0 de ArchGenXML. Contrairement à la version 1.5 qui ciblait Plone 2.1avec une compatibilité Plone 2.5 cette version est construite autour du support de Plone 3.0 avec une compatibilité vers Plone 2.5.

Les buts atteints de cette version sont le passage en egg de ce module, le support des profils Generic Setup , la génération des interfaces Zope3, la généaration des tests unitaires et des tests fonctionnels en python et au format doctest. Des gros changement en perspective, et une incompatibilité avec la génération précédente. Nous restons bloqués en phase d’évaluation béta par manque testeurs. Nous cherhcons en particulier des testeurs pour la partie génération de workflows.

L’autre nouveauté, plus contraignante celle-ci, est l’utilisation de nouveaux connecteurs dans les schémas UML pour symboliser les ‘adapter’. Les versions précédentes d’ArchGenXML se satisfaisaient d’éditeurs utilisant UML 1.4 et il faut à présent des éditeurs utilisant UML 2.0 au minimum pour cette nouvelle fonctionnalité. Exit donc les éditeurs tel que ArgoUML qui était le seul éditeur UML libre supporté. J’ai passé beaucoup de temps à tester d’autres éditeurs libre comme gaphor, umbrello et papyrus (une extension d’eclipse). Pour l’instant aucun ne permet d’être utilisé avec ArchGenXML. Du coté des éditeurs propriétaires Poseidon UML est toujours supporté avec son nouveau système de rente pour la version communautaire. Par contre le greffon Apollo pour eclipse du même éditeur n’est pas du tout utilisable. Si vous connaissez un bon éditeur UML 2.0 faites-le moi savoir.

Le test du plugin Apollo m’a montré une vue intéressante de la génération de code : la vue du développeur. Avec un projet Java et ce greffon dans eclipse il est possible d’attacher un schéma UML à chaque package Java puis de faire évoluer le diagramme de classe en même temps que le code et réciproquement. Ce greffon prend en charge l’ingénieurie inverse des fichiers Java comme la génération de code puis la synchronisation entre les deux. C’est particulièrement bluffant. Il existe déjà des outils pour faire ces opérations en Python, mais ceux-ci ne peuvent pas être réunis en un seul pour faciliter la vie des développeurs Python. Pour atteindre ce niveau de fonctionnalité il faut un IDE (Pype, WingIDE, Eric, …) et éditeur UML (gaphor, umbrello) et un composant d’ingénieurie inverse (python… epydoc et happydoc montrent comment faire).

Du coté du futur de la génération de code, ArchGenXML génère déjà du code Zope 3 (pour son utilisaton dans Plone) et d’autres projets de CMS en python commencent à s’intéresser à cette possibilité (voir la branche Django). Cet été il y a eu un projet « Google Summer of Code » autour de Genesis qui se présente comme le succésseur de ArchGenXML, mais faute de communication ce projet semble être retombé dans les limbes des vaporwares.