Un site Drupal, étape par étape, partie 6 sur 6

Référence en espagnol sur Cuenco Digital : http://cuencodigital.com/articulos/un_sitio_en_drupal_paso_paso_parte_6.html
5 Avril 2009


Dans les cinq articles précédents, j'ai décrit le processus d'installation de Drupal. L'installation et le paramétrage de modules essentiels. Le paramétrage de CCK et Views. La création d'un thème et, pour finir, le paramétrage de modules apportant des fonctionnalités supplémentaires.

Il reste cependant quelques touches finales avant de mettre le site en production.

Traductions

Dans le deuxième article de cette série, j'ai abordé comment installer la langue espagnole dans Drupal (ça marche aussi avec le français ! NdK).

Les traductions de Drupal dans les langues de chaque pays dépendent, comme c'est souvent le cas dans le milieu du logiciel libre, de la communauté qui l'utilise. Ainsi, les responsables de la traduction de Drupal en espagnol sont des gens comme vous et moi. Et pour cette raison, certaines parties de Drupal ne sont pas encore traduites.

Ce qui en découle principalement c'est que vous pouvez voir la presque totalité du site en espagnol mais que certaines chaînes seront encore en anglais.

Parmi ses options, Drupal dispose d'une interface pour traduire les chaînes non traduites. A mon avis, cette interface pourrait être bien meilleure. La bonne nouvelle c'est que cela changera avec Drupal 7, la mauvaise nouvelle c'est que je suis encore sous Drupal 6.

Pour cette raison, un développeur a très opportunément programmé un module pour améliorer le processus de traduction des textes non traduits.

Localization Client ajoute une barre dans la partie inférieure du site où l'on peut voir les chaînes non traduites et celles traduites sur deux colonnes. C'est assez intuitif, et il n'est pas nécessaire de recharger la page pour traduire beaucoup de chaînes de caractères.

Il contient encore des erreurs, mais on peut obtenir d'excellents résultats en l'utilisant conjointement avec l'interface de traduction de Drupal.

p6-1.png

Patchs, ça ça ne marche pas...

Tous les développeurs qui utilisent Drupal depuis longtemps savent que tout ne marche pas toujours comme cela devrait. Pour prendre un exemple réel et plutôt sensible, j'indique ce qui m'est arrivé avec ce site.

Drupal 6 apporte comme nouveauté la possibilité de traduire les chaînes des fichiers javascript. Cela veut dire que si vous êtes en train de créer un calendrier de type pop-up, et que vous voulez que les mois soient indiqués dans la bonne langue, vous pouvez le faire avec Drupal 6 (Drupal 5 et les précédents ne disposaient pas de cette fonctionnalité).

Le problème c'est que cette fonction ne marche pas bien lorsque vous utilisez le cache pour javascript. Ce qui veut dire que toute chaîne, même traduite, sera affichée en anglais dans le site.

Par chance, il existe une rustine (patch) qui corrige cette erreur. Bien qu'il ne soit pas encore disponible dans le noyau de Drupal 6, on peut l'appliquer sans problème.

Le processus d'application d'une rustine est le même quelque soit la rustine.

# Télécharger la rustine dans le dossier indiqué
cd Drupal6/includes
wget <a href="http://drupal.org/files/issues/locale-338630-30.D6.patch


#" title="http://drupal.org/files/issues/locale-338630-30.D6.patch


#">
http://drupal.org/files/issues/locale-338630-30.D6.patch


#</a> appliquer la rustine
patch locale.inc < locale-338630-30.D6.patch

De la sorte, une rustine pour le module Date corrige le bug signalé dans cet issue. Mise à jour : la rustine est comprise dans les nouvelles version de Date, il n'est plus nécessaire de l'appliquer.

Bloc personnalisé

Tôt ou tard, un développeur utilisant Drupal devra programmer quelque chose qui n'existe pas.

Dans mon cas, j'avais besoin d'un bloc affichant le prochain article à paraître.

Sans trop rentrer dans des détails de programmation, Drupal 6 demande que le module PHP Filter inclus dans le noyau soit activé pour pouvoir écrire des bouts de code (snippets) en PHP.

Une fois ce module activé, j'ai créé un bloc avec le code suivant :

<?php

  $sql 
"SELECT n.title titulo, c.field_fecha_value fecha, c.field_resumen_value resumen
             FROM content_field_fecha c
             INNER JOIN  {node} n ON n.vid = c.vid
             WHERE n.status = 0 AND n.type IN ('articulo', 'video')
             LIMIT 1"
;
 
  
$res db_query($sql);

  
$articulo NULL;
   while(
$ob db_fetch_object($res)) {
     
$articulo['titulo'] = check_plain($ob->titulo);
     
$articulo['fecha'] = format_interval(strtotime($ob->fecha) - time());
     
$articulo['resumen'] = check_markup($ob->resumen);
   }

   print 
'<h3 class = "title">Prochainement...</h3>';
   if (
is_array($articulo)) {
     print 
'<div class = "date">A paraître dans <strong>'$articulo['fecha'] .' </strong>:</div>';
     print 
'<p><a title = "en savoir plus" href = "/prochainement">'$articulo['titulo'] .'</a></p>';
   }
   else {
     print 
t('Pas d\'articles à paraître prochainement');
   }

?>

Le principe consiste à chercher dans la base de données tous les articles et vidéos non publiés et afficher leur titre dans un bloc.

Bon, ce qui précède est un exemple. Pour ce site, j'ai en fait utilisé Views pour réaliser ce bloc. Mais pour la version 5 de Drupal de ce site j'avais réellement utilisé un code comme celui-là et j'ai pensé utile de le laisser à titre d'exemple.

Automatisation

Il doit tous nous arriver la même chose un jour ou un autre, on manque de temps pour faire tout ce dont on a envie. Cela impacte un peu la vie du site dans la mesure où je ne publie rien pendant un certain temps alors qu'à d'autres moments je peux publier plusieurs articles et vidéos. Pour éviter au site ces périodes d'inactivité prolongée, j'ai décidé d'implémenter un système de publication automatisée d'articles et de vidéos.

Bien que le module Scheduler semble être le plus approprié pour cette tâche, je n'ai pas été convaincu par le fait de devoir définir une date pour la publication et que ce ne soit pas cette date qui soit utilisée comme date de publication de l'article. J'ai donc choisi d'utiliser le module Rules.

A mes yeux, Rules est un des modules le plus importants de Drupal. Il permet d'exécuter des actions déclenchées par les événements du site. En pouvant également exiger que certaines conditions soient remplies pour exécuter l'action. Les possibilités apportées par ce module sont vraiment nombreuses.

Pour la publication différée des articles, j'ai utilisé la même requête que dans le code ci-dessus, ainsi, lors de l'exécution de Cron, je vérifie que la date de parution du premier article ou vidéo non publié soit inférieure à celle de la date du jour. Si c'est le cas, je publie le contenu.

p6-2.png

Tout est prêt, mise en ligne du site

Comme je l'ai indiqué dans le premier article, le développement du site a été effectué sur un serveur en local. Pour que tout le monde puisse lire les articles, il est nécessaire de déménager le site sur un serveur en production.

Cette opération consiste à copier les fichiers de l'installation de Drupal (tout ce qui se trouve dans le dossier Drupal 6) et copier la base de données.

Selon la taille du site, il peut être judicieux de compresser les fichiers et de les décompresser sur le serveur de production :

Le code qui suit requiert une connexion ssh avec le serveur.

#Compresser le dossier parent du site entier
tar czf cuenco.tar.gz drupal6

mysqldump -u utilisateur -p nom_de_la_base_de_données > sauvegarde.sql
tar czf sovegarde.tar.gz sauvegarde.sql

Copier les fichiers sur le serveur via FTP ou sFTP

et faire ensuite l'opération inverse, sur le serveur de production :

#Décompresser le dossier parent de tout le site
tar xzf cuenco.tar.gz drupal6

tar xzf sovegarde.tar.gz sauvegarde.sql

#Restaurer la base de données
mysql -u utilisateur -p nom_de_la_base_de_données < sauvegarde.sql

Touches finales

Dans le dossier racine de Drupal vous trouverez un fichier nommé .htaccess, ceux qui utilisent un serveur Apache devront probablement lui apporter quelques modifications.

www.cuencodigital.com et cuencodigital.com sont en fait le même site. Certains trouvent plus pratique d'accéder au site avec www et d'autres sans www. Le fichier .htaccess peut contenir une règle pour qu'il considère les deux sites comme un seul :

  RewriteCond %{HTTP_HOST} ^cuencodigital\.com$ [NC]
  RewriteRule ^(.*)$ http://www.cuencodigital.com/$1 [L,R=301]

En ajoutant ces deux lignes, chaque fois que quelqu'un indiquera www.cuencodigital.com, il sera automatiquement redirigé vers cuencodigital.com.

C'est tout ?

Si ça pouvait être aussi simple... Cette section devrait s'intituler tester, tester, tester ! Pour m'assurer que tout soit en ordre, j'ai dû vérifier et paramétrer les options des commentaires, paramétrer la méthode d'enregistrement au site, vérifier de nombreuses chaînes de caractères qui n'avaient à priori pas été traduites (par exemple, essayez d'indiquer une mauvaise réponse pour la question arithmétique).

RSS, l'option par défaut de Drupal n'était pas adaptée à ce site. Paramétrer les blocs des barres latérales. Tester à nouveau. Désactiver la reconstruction du cache des pages. Paramétrer Cron. Paramétrer Google Analytics. Tester les commentaires au hasard. Réaliser le thème pour les commentaires. Vérifier les paramètres des chemins automatiques pour les nouveaux types de contenus.

Tester ! Essayer Cron, chercher dans les contenus. Créer au hasard des comptes Utilisateur avec moins de privilèges. Tester la publication de commentaires avec ces utilisateurs. Tester est quelque chose de sérieux, vraiment !

Conclusions

Plutôt long, non ? Je ne pense pas en écrire autant la prochaine fois mais j'espère vous avoir donné une idée général de ce qu'est un développement avec Drupal.

Je suis conscient de passer outre de nombreux détails. Les écrire ici aurait vraiment indiqué comment réaliser un site pas à pas. Mais comme je l'ai dit dans le premier article de cette série, il est impossible de sur-détailler chaque étape. En plus, les lire serait vite fastidieux (sans parler de les écrire...). Il est plus fructueux que vous créiez et résolviez vos propres problèmes. Venez ensuite en parler.

En dernier lieu, j'aimerais parler des outils utilisés pour ce développement.

Éditeurs graphiques : Inkscape, gimp, gthumb

Éditeur HTML : gedit

Éditeur php : gPhpEdit

Serveur : Apache

Navigateurs : Firefox 3, Opera 9

Moteur SQL : Mysql 5

Systèmes d'exploitation : Linux Ubuntu et Linux Debian

Je veux ainsi signaler qu'il est possible de réaliser un développement complet avec des logiciels libres. Peut-être serait-il temps que cela soit pris en compte par les institutions d'enseignement.

Merci beaucoup d'avoir lu ce dernier article sur la réalisation d'un site Drupal étape par étape. J'attends vos commentaires.

Mariano D'Agostino - Cuenco Digital