Valéry-Xavier Lentz.eu

To content | To menu | To search

Tag - SPIP 2.0

Entries feed - Comments feed

Sunday 14 March 2010

Un domaine par langue pour un site SPIP

Ce billet rassemble quelques notes sur les manipulations que j'ai mis en oeuvre pour permettre l'utilisation de plusieurs domaines sur le site du webzine Le Taurillon, construit en SPIP. N'hésitez pas à faire part en commentaire de vos observations sur la méthode retenue.

SPIP propose tout ce qu'il faut pour construire un site web éditorial de type magazine. C'est même ce qu'il fait le mieux. De même il dispose de nombreuses possibilités pour la construction d'un site multilingue.

Le Taurillon, conçu initialement en français, rapidement pendant l'été 2005, est un site désormais publié en quatre langues. Chaque langue correspond en réalité à une publication différente car, même si de nombreux articles sont traduits, les équipes éditoriales sont distinctes.

  • Le Taurillon est publié par JEF-France, en français, utilise taurillon.org ;
  • The New Federalist est édité par JEF-Europe en anglais, a pour domaine thenewfederalist.eu ;
  • Eurobull est publié par JEF-Italie, en italien, avec eurobull.it ;
  • Treffpunkt Europa, enfin, est publié par JEF-Allemagne, en allemand, donc, avec treffpunkteuropa.de.
Le site est organisé à l'aide d'un secteur par langue. Chaque secteur (rubrique de premier niveau) ne contiens donc que des articles dans la même langue.
Les articles et rubriques ayant une langue, il est possible au sein de la boucle ARTICLE, ou RUBRIQUE, d'utiliser la balise #LANG pour récupérer la langue du contexte. Pour le reste du site il faut utiliser un paramètre de langue dans l'URL : &lang=fr que l'on récupère à l'aide de #ENV{lang}. Le critère {lang} permet ensuite dans les boucles l'acceptant de filtrer le contenu par langue. Pour en savoir plus lire la rubrique "Multilinguisme" sur site "Programmer avec SPIP 2.0".
C'est ainsi le cas de la page d'accueil. Ainsi, http://www.taurillon.org/?lang=fr affiche la page d'accueil du Taurillon, mais http://www.taurillon.org/?lang=de affichera la page d'accueil... de Treffpunkt Europa.

Un domaine par langue

La première étape a été de demande aux propriétaires des domaines de les configurer avec les NS de OVH, l'hébergeur du site. Chez ce dernier, j'ai pu faire pointer tous les domaines vers le même répertoire, celui où est installé le site, à l'aide d'enregistrements DNS de type A.
Par défaut, c'est la page francophone (langue par défaut du site) qui s'affiche. Pour que chaque domaine retrouve la page d'accueil correspondante c'est le fichier .htaccess qui est appelé à l'aide :
RewriteCond %{HTTP_HOST}  ^www.thenewfederalist\.eu$
RewriteRule (.*) spip.php?lang=en [QSA,L]
Jusqu'à la page d'accueil, tout vas bien, donc. Le problème est qu'un clic vers un article dans une autre langue conserve le nom de domaine actif. On se retrouve donc avec des articles en français ou en allemand sous le domaine anglophone.
Et c'est mal.
Pour parer à cette situation j'ai mis en place deux systèmes :
1) Indiquer l'URL canonique de la page : afin de ne pas troubler les robots (c'est fragile ces engins), j'ai ajouté dans le head une ligne indiquant l'URL canonique de la page, c'est à dire l'URL que je leur demande de prendre en compte pour chaque page. Un article en allemand aura donc dans le code de la page une ligne du type : 
<link rel="canonical" href="http://www.treffpunkteuropa.de/Chronik-eines-angekundigten-Todes" />
2) Pour les humains, et les robots malcomprenants, je modifie les #URL_ARTICLE et #URL_RUBRIQUE, qui génèrent un lien relatif, pour proposer un lien absolu avec le domaine.
Pour ce faire j'avais envisagé d'utiliser le plugin "Multidomaines". Celui-ci permet, à l'aide d'un champ Extra (oui il faut installer aussi ce plugin), d'associer un domaine à une rubrique. Je ne l'ai pas utilisé pour trois raisons : je n'ai pas besoin de toutes ses fonctions, je n'aime pas (plus) installer trop de plugins (impact sur lesperformances, complique la maintenance et l'évolutivité du site), enfin, quand je l'ai activé j'ai eu un message d'erreur et je n'ai pas insisté.
J'ai utilisé les chaines de langue de SPIP : j'ai créé une chaine <:domaine:> et indiqué dans chaque fichier de langue le domaine correspondant. Je peux donc utiliser cette chaine partout où j'ai besoin du domaine, car je dispose de la langue dans le contexte partout, soit dans la boucle, soit dans l'URL (paramètre lang).  Par exemple dans une boucle ARTICLES, j'indique comme lien href="<:domaine:>/#URL_ARTICLE". 

Les limites de l'approche retenue

Naturellement, cette méthode a des limites.
  • elle implique de modifier tous les squelettes. C'est également le cas avec le plugin qui propose ses propres balises. Pour l'instant je n'ai traité que les squelettes essentiels. J'adopterai l'approche systématiquement lors d'une refonte, et au fur et à mesure d'ici là.
  • elle ne peut avoir d'effet pour une boucle affichant des contenus en plusieurs langues (une boucle FORUM par exemple, celle-ci n'acceptant pas le critère lang) : les URL utilisent alors le domaine en cours.
  • les statistiques de fréquentation sont en partie faussées, chaque URL étant comptabilisée comme un site référent tiers. Il faut que j'étudie les configurations possibles dans Google analytics 

Méthodes alternatives

Plusieurs autres méthodes sont à étudier.
  • le mutualisé : plusieurs sites SPIP (dans des répertoires différents) qui pourraient partager une même base de données (pour permettre la gestion des liens de traduction ou des auteurs communs). À vérifier: cette solution permet-elle de partager un même jeu de squelettes ?). 
  • Utilisation du htaccess pour réécrire l'URL en fonction du paramètre lang pour y placer le bon domaine : je ne suis pas sur que ce soit possible, il faut que j'étudie plus la syntaxe pour RewriteCond
Un billet à mettre à jour donc, si je découvre une meilleure méthode. Mais pour l'instant l'essentiel semble fonctionner.

Mise à jour

31/03/2010 : Le carnet-SPIP propose différentes méthode, notamment à base de php. Cf. http://www.spip-contrib.net/MultilinguismeExemple6

Monday 24 November 2008

Sortie de SPIP 2.0 RC1

La version 2.0 de l’excellent outil de gestion de contenus est sortie avec le statut Release Candidate c’est à dire en version admissible. En d’autres termes le gros des tests est terminé et la communauté demande à un plus grand nombre d’utilisateurs de mettre en oeuvre cette nouvelle version afin de pouvoir remonter les quelques anomalies qui subsisteraient.

Les nouveautés de SPIP 2.0 sont évoquées dans un de mes billets et dans deux billets de Marcimat ici et .

Lire l’annnonce sur spip-contrib : SPIP 2.0 RC1 (Release Candidate 1) est sortie

Wednesday 20 August 2008

Spip 2.0 : tout change et rien ne change

L’outil de gestion de contenu libre SPIP va prochainement passer à sa version 2, une fois la phase de tests en cours achevée. Cette sortie risque de passer pour un non-événement aux yeux d’une grande partie des utilisateurs actuels tout en enthousiasmant dans le même temps les autres.

En effet pour les contributeurs ou webmasters, les évolutions visibles seront minimes dans un premier temps. L’évolution de SPIP s’est faite progressivement. En huit ans d’existence c’est par ajout successifs que s’est constitué toute la richesse de ce CMS et non pas par des grands bonds en avant. La version 1.7 a vu arriver le multilinguisme, la version 1.8 un nouveau design de l’espace d’administration et un moteur aux capacités plus étendues, la version 1.9 a permis l’ajout de plugins. Le passage à la version 2 ne représentera donc pas une révolution mais plus surement l’officialisation d’un travail de maturation de plusieurs années.

En revanche pour les concepteurs de sites, les dizaines de nouvelles fonctionnalités, somme du travail colossal d’une équipe de développeurs bénévoles, représentent autant de pistes pour construire plus facilement encore des sites fonctionnellement très riches. SPIP n’est plus depuis longtemps un simple outil de gestion de contenu éditorial mais constitue désormais une boite à outils permettant de construire des sites bien plus complexes pour qui sait en tirer parti.

“Tout change” donc, puisque la nature de l’outil est désormais bien différente de ce qu’il était par le passé. Mais “rien ne change” également compte tenu de l’attention particulière apportée à la rétrocompatibilité et à maintenir intacte l’expérience utilisateur actuelle ainsi que la courbe d’apprentissage très douce pour ceux qui souhaitent aller plus loin dans l’exploitation de l’outil et le développement de sites. La nouvelle version ne perturbera donc pas les utilisateurs.

Les nouveautés marquantes

La liste des nouvelles fonctionnalités étant particulièrement longue, je ne retiens ici que celles qui ont attiré mon attention, compte tenu de mon expérience personnelle avec SPIP. N’étant pas pour ma part développeur, la portée de bon nombre nombre de changements m’échappe complètement (comme la compatibilité avec plusieurs types de bases de données) là où d’autres m’interpellent tout de suite (l’usage simplifié d’AJAX pour qui ne connais pas le javascript par exemple).

Les petits trucs agaçants qui sont résolus :

  • l’interface simplifiée du backoffice trépasse : hip hip hip hourra. Il était juste trop compliqué d’expliquer aux utilisateurs qu’il existait deux interfaces.
  • SPIP va toujours générer des paragraphes alors qu’il ne le faisait pas sans utiliser le Couteau suisse.
  • exit les class=”spip” inutiles
  • enfin et surtout un nouveau système d’URL arborescente (reprenant de nom des rubriques) et une gestion de l’historique des URL (lorsque l’on change le nom d’un article par exemple).
  • l‘“officialisation” d’un certains nombre de plugins et la possibilité de les télécharger depuis le backoffice rend leur utilisationplus accessible aux nouveaux utilisateurs.

Des innovations potentiellement intéressantes :

  • un squelette par défaut basé sur layoutgala. En tant que grand utilisateur de ces squelettes, la facilité de les personnaliser que cela devrait apporter est appréciable. Nous ne devrions pas tarder à voir paraitre un plugin permettant le passage d’une mise en page à l’autre d’un clic en backoffice.
  • des jointures automatiques à travers les critères d’une boucle : un peu plus technique mais à ce que j’ai compris cela devrait me permettre d’afficher les commentaires postés sur toutes les traductions d’un article.
  • la gestion des conflits lors de l’édition d’un objet (si Fabien et Ronan modifient un même article en même temps dans l’espace d’administration par exemple).
  • la mutualisation des sources est à expérimenter : un seul Spip pour plusieurs sites (avec des backoffices distincts : il s’agit plus de réaliser l’équivalent d’une ferme de blogs que e permettre de gérer plusieurs sites dans le même backoffice omme le permettent Dotclear ou Typo3 par exemple).
  • une meilleure gestion des relations entre plugins et une balise plugin (à ce que j’ai compris cela permet de faire en sorte que le code concernant un plugin particulier ne s’applique que si le plugin est activé, exit les messages d’erreur en dront dès que l’on décoche une extension).
  • la possibilité d’utiliser plusieurs bases de données pour un même site : cela devrait permettre, par exemple, d’afficher des données issus d’une application métier installée parallèlement à Spip dans les squelettes SPIP sans développements particuliers (autre celui du squelette SPIP bien sur). À tester.

Une occasion de faire connaître SPIP ?

La maturité des nombreuses innovations de SPIP de ces dernières années doit permettre de faire découvrir ou redécouvrir SPIP à ceux qui l’avaient connus il y a plusieurs années. Toutefois force est de constater que la promotion de l’outil, notamment auprès d’un public professionnel, n’est pas une priorité de ses concepteurs. Les sites faisant la promotion de l’outil nécessitent un investissement non négligeable pour trouver la bonne information ou simplement une liste de fonctionnalités. Là où la plupart des autres CMS disposent de sites officiels plutôt bien conçus (cf. Dotclear ou Wordpress par exemple), avec un travail d’organisation de l’information rendu visible par un webdesign approprié, spip.net et spip-contrib sont plus difficiles d’accès. Le site de contribution ne hiérarchise pas non plus ses contenus mettant sur le même plan une expérimentation utilisée par trois personnes et un plugin indispensable utilisé par la plupart des utilisateurs expérimentés.

En outre il manque une distribution par défaut “clé en main” et personnalisable. Quelque soit la richesse fonctionnelle de la dist, elle ne peut être utilisé comme tel de manière satisfaisante. Ce n’est pas d’ailleurs son objectif. De nombreuses tentatives dispersées mettent à profit les évolutions de SPIP dans cette perspective mais au jour d’aujourd’hui installer la distribution de base de SPIP ne permet pas de choisir par exemple l’emplacement des colonnes, de choisir les blocs d’infos à y faire figurer, de modifier les couleurs ou les polices de caractère. SPIP restera pour l’instant réservé à ceux qui n’hésitent pas à bricoler un petit peu ne serais-ce qu’en allant fouiller SPIP contrib pour trouver un squelette leur convenant.