Découverte transmise par les gens de Desjardins: sur une installation Drupal de base, la page /node liste tous les noeuds d’un site. Essayez-le sur le site de Drupal: http://www.drupal.org/node. Il y a peut-être utilité, vous serez aimables de me l’indiquer, mais il y a aussi des inconvénients. D’abord, il ne faut pas oublier de prévoir l’affichage de tout noeud dans cette page et de faire l’intégration en conséquence. Ensuite, cela rend visible du contenu dont on voudrait peut-être limiter la diffusion à seulement ceux qui connaissent l’url (par exemple dans le cadre d’un sondage envoyé dans une infolettre à un public ciblé). Dans la plupart des cas, vous préférerez rendre inaccessible la page /node. Pour ce faire, créez un module et mettez-y la fonction suivante pour que la page /node donne un 404:

function monmodule_menu_alter(&$items){
$items['node']['page callback'] = ‘drupal_not_found’;
}

J’ai déjà dit que j’aimais le module Secure Pages pour Drupal 6 qui permet d’implanter le https sur un site: http://onfaitduweb.com/drupal-6/le-lien-entre-le-module-secure-pages-et-imce/. Au fil du temps, on se rend compte cependant que son utilité nécessite des… subtilités. Voici un résumé des éléments de configuration nécessaires.

Supposons que l’adresse du site est http://www.mondomaine.com et que vous désirez que certaines pages servies par Drupal soient accessibles exclusivement sur https://secure.mondomaine.com. Je suppose ici que la configuration du serveur pour servir le domaine sécurisé est faite (autrement dit, si vous placez un fichier test.txt à la racine de votre site, vous pouvez le voir en tapant https://secure.mondomaine.com/test.txt).

Il faut d’abord installer et activer le module Secure Pages. J’ai utilisé la version 6.x-1.8.

Dans le fichier sites/default/settings.php, remplacez la variable $base_url par:

$base_url = ((isset($_SERVER['HTTPS']) && $_SERVER['HTTPS']==’on’) ? ‘https://secure.mondomaine.com’ : ‘http://www.mondomaine.com’);

Cela permet d’éviter d’avoir une erreur d’AJAX interdomaine quand on travaille dans l’admin sécurisé et qu’il y a des appels AJAX, par exemple quand on configure une vue ou qu’il y a de l’autocomplétion d’un champ de type nodereference.

Toujours dans le fichier sites/default/settings.php, assurez-vous que le domaine des cookies est valide autant pour le domaine www.mondomaine.com et secure.mondomaine.com, de cette façon:

$cookie_domain = ‘.mondomaine.com’;

Ajoutez aussi cette ligne, qui est optionnelle mais qui peut vous éviter de chercher un problème qui n’existe pas:

$conf['drupal_http_request_fails'] = FALSE;

Sans cette ligne, lorsque vous visionnerez le tableau de bord (dashboard), Drupal vous indiquera que les appels curl ne fonctionnent pas alors qu’ils fonctionnent probablement.

Dans le fichier .htaccess, pour que la variable $cookie_domain configurée précédemment fonctionne, repérez les lignes suivantes et décommentez/adaptez-les:

# To redirect all users to access the site WITH the ‘www.’ prefix,
# (http://example.com/… will be redirected to http://www.example.com/…)
# adapt and uncomment the following:
RewriteCond %{HTTP_HOST} ^mondomaine\.com$ [NC]
RewriteRule ^(.*)$ http://www.mondomaine.com/$1 [L,R=301]

Plus loin dans le fichier, ajoutez ces lignes pour que https://www.mondomaine.com redirige vers http://www.mondomaine.com et que http://secure.mondomaine.com redirige vers https://secure.mondomaine.com:

# Éviter que la version https des pages soit indexée
RewriteCond %{HTTPS} =on
RewriteRule ^robots\.txt$ robots_ssl.txt [L]

# Éviter que les pages soient accessibles avec http://secure…
RewriteCond %{HTTPS} =off
RewriteCond %{HTTP_HOST} !^www.mondomaine.com$ [NC]
RewriteRule ^(.*)$ http://www.mondomaine.com/$1 [L,R=301]

RewriteCond %{HTTPS} =on
RewriteCond %{HTTP_HOST} !^secure.mondomaine.com$ [NC]
RewriteRule ^(.*)$ https://secure.mondomaine.com/$1 [L,R=301]

Dans le code précédent vous aurez noté qu’on parle de robots.txt et robots_ssl.txt. En général, on veut que le site principal soit indexé par les moteurs de recherche, mais pas les pages sécurisées. Pour ce faire, laissez intact le fichier robots.txt créé par Drupal mais créez un fichier robots_ssl.txt à la racine avec pour seul contenu les lignes suivantes:

User-agent: *
Crawl-delay: 10 # Ne rien indexer du contenu https. Voir le .htaccess pour la redirection vers le présent fichier
Disallow: /

Ouf! Il ne vous reste plus qu’à retourner dans l’admin de Drupal, menu Construction du site -> Secure Pages et entrer la configuration suivante:

Enable Secure Pages: activé

Switch back to http pages when there are no matches: oui Non-secure Base URL: http://www.mondomaine.com

Secure Base URL: https://secure.mondomaine.com

Make secure only the listed pages: oui

Pages:

node/add*
node/*/edit
user/*
admin*
cart/* [si vous utilisez Ubercart]
n’importe-quelle-autre-page

Ignore pages:

*/autocomplete/*
*/ajax/*
*/imagecache/*
imce*

Videz votre cache et vos cookies, et vous êtes en business.

Beaucoup de personnes, avec raisons, se plaignent de la laideur du code source généré par le module Views de Drupal. Le module Views va généré des div à chaque niveau possible pour faciliter le travail des intégrateurs, mais bien souvent, la plupart des niveaux sont inutiles.

Vient alors un petit module : semantic views! Ce module vous permet de spécifier vous même, quel tag utiliser (span ou div par exemple) et à quel(s) niveau(x). D’autres modules permettent de faire la même chose, mais celui-ci est particulièrement facile à utiliser, en plus d’être disponible pour Drupal 6 et 7(dev).

Une fois le module installé et activé, vous pouvez spécifier le style d’affichage Semantic Views (voir l’image) à votre style d’affichage (default, page, bloc, etc.). En cliquant sur le petit engrenage, vous aurez accès à toute la configuration possible (spécifier les tags à utiliser, le champ de regroupement, etc.).

Bref, un beau petit module simple qui au final, rend le travail de l’intégrateur beaucoup plus simple et qui génère un code beaucoup moins compliqué et long.

Path Filter est un module qui est méconnu ou simplement sous-estimé. Ce module vous permet d’ajouter des liens dans votre contenu sans avoir besoin d’écrire un chemin absolu à la main ou un chemin relatif en vous croisant les doigts que ce contenu ne sera pas réutilisé à un niveau plus bas dans le site.

Ce module est ce qu’on appelle dans le jargon un « input filter ». Lors de l’affichage du contenu, il traduira les liens en liens absolus. Il suffit de suivre une syntaxe simple : ajouter « internal: » devant le lien et mettre le tout entre guillemets.

Par exemple, si je veux faire un lien à ma node 30, j’écrirais dans mon contenu : <a href= »internal:node/30″ title= »Parce que les bons programmeurs spécifient toujours un titre intelligent et utile »>Exemple de Path Filter</a>. Path Filter va toujours me retourner http://www.quiboweb.com/drupal/exemple/path-filter, peu importe que le lien soit affiché dans la page http://www.quiboweb.com/equipe/la-meilleure-au-quebec ou à la racine du site.

Selon votre manière de travailler, en suivant cette technique vous pouvez laisser le client entrer son contenu sur un site de développement et faire une mise en ligne complète sans avoir besoin de passer la soirée (ou la nuit) à vérifier tous les liens et faire les modifications à la main.

L’exemple que j’ai donné plus haut ce sert du ID de la node, mais l’alias url peut aussi être utilisé. Exemple : « internal:drupal/exemples/path-filter » et le tout fonctionnera de la même façon. Le module fonctionne aussi avec les fichiers et les sites multilingues, en mode sous domaine (http://fr.quiboweb.com) ou même en mode sous dossier (http://quiboweb.com/fr/).

Maintenant que vous êtes accrochés et palpitez de joie d’avoir la solution à tous vos problèmes, voici les instructions pour l’installation :

1. On télécharge le module
2. On extrait le module dans notre dossier /sites/all/modules/ (contrib/ pour ceux qui aiment séparer les modules venant du site drupal.org et ceux faits maison.)
3. On active le module via notre interface d’administration
4. Dernière étape, la plus compliquée, il faut activer le filter. Sous la page Administration du site (« Administer » en anglais), vous devriez y trouver la page Format d’entrée (Input format). Choissisez un des formats et cliquez sur configurer. Activer le filter « Internal Path Filter ».

Lorsque vous ajoutez votre contenu, n’oubliez pas de choisir le bon mode d’entrée si vous n’avez pas activé le filtre pour tous les types d’entrée. C’était un exemple assez simple parce que je n’avais pas de wysiwyg d’activé, mais en résumé, il suffit de spécifier l’ordre dans lequel les filtres sont appliqués. N’hésitez pas à laisser un commentaire si vous avez une question, des problèmes avec votre wysiwyg ou si une étape manque de clarté.

Chaque année, la compagnie d’édition Packt Publishing offre un concours aux mille-et-un CMS de ce monde avec un prix en argent variant selon la catégorie et le classement.

Cette année WordPress s’est classé à égalité avec Drupal pour la catégorie « Hall of Fame CMS » qui comporte tous les CMS ayant déjà gagné un prix dans les années précédentes. Un juge externe indépendant (Mark King de opensourcecms.org) a dû être choisi afin de pouvoir trancher entre Drupal et WordPress.

WordPress a finalement gagné la première place (2500 $) et Drupal la deuxième (1000 $). Ces montants sont un peu ridicules si on regarde seulement les frais d’exploitation de chacun des deux sites, mais ces montants restent néanmoins une bonne tape dans le dos des développeurs qui travaillent sur ces CMS.

WordPress est fier d’avoir gagné, mais souhaite tout de même rappeler à tous que leur application est principalement dédiée aux blogues et non pas à une gestion de contenu générale (comme Drupal, typo3 ou une panoplie d’autres).

Félicitations à tous pour votre bon travail!