What’s up

#

Pour un petit projet perso, on m’a demandé de développer un petit site de location de chambres. En soi, j’aurais pu simplement créer quelques pages HTML statiques, copier le tout sur un serveur et le tour aurait été joué. Il y avait cependant quelques contraintes à prendre en compte:

• Besoin d’un site multilangues (en, fr, nl)
• Besoin d’une gallerie d’images, une gallerie devant être associée à une page.
• Besoin d’une carte, pour présenter les choses intéressantes à voir dans le quartier.
• Et beaucoup de discussions, pour arriver à un résultat convaincant.

Il me fallait quelque chose de flexible, permettant de gérer facilement les images, de mettre le texte en forme, de gérer l’affichage des informations, … Le tout, sans que cela ne prenne trop de temps.

En parcourant les différents CMS existants, je me suis rendu compte qu’il existait assez peu de solutions autorisant ces trois contraintes nativement :

• Wordpress le permet, mais seulement grâce à l’installation de plusieurs plugins
• Drupal me semblait trop compliqué à appréhender
• PluXML nécessiterait sans doute trop de paramétrage,
• …

Celle qui m’aurait le plus botté était Wagtail, mais le temps fait (un peu) défaut pour le moment… En gros, j’avais le choix entre les deux solutions suivantes:

1. Un vrai CMS dynamique, où mon utilisateur adoré pourrait se débrouiller tout seul. Il aurait alors fallu renforcer la sécurité, configurer la base de données, configurer les backups, vérifier la cohérence des données au restore, le former à la manipulation des données et aux traductions
2. Ou alors, partir sur un site statique présentant les informations de manière fixe, nécessitant relativement peu de paramétrage, mais l’obligeant à me contacter pour toute modification.

Puisqu’on parle d’une personne (très) proche, je suis parti sur la seconde option. Et puisqu’on parle d’un site statique, je suis parti sur Pelican.

Multilinguisme

#

Pour gérer un site multilangue, il y a deux solutions:

1. Soit utiliser les métadonnées lang et slug dans chaque article/page. Cette solution ne convient qu’à moitié, car la langue principale du site reste inchangée, quelle que soit l’entrée sur laquelle l’utilisateur se trouve: si le visiteur clique sur un lien, il arrivera donc sur la page traduite dans la langue par défaut, mais s’il se trouvait sur une page traduite dans une autre langue. Ce qu’on souhaite, c’est que le site soit en fait un sous-site du site principal, avec sa langue spécifique: en traduisant la page dans une langue, on resterait dans cette langue-ci.
2. Soit utiliser le plugin i18n_subsites, qui permet de définir un site principale (basé sur une langue), puis un ensemble de sous-sites, chacun d’entre eux correspondant à une langue.

En gros, la structure devient la suivante:

pages/
  en/
    page1.md
    page2.md
  fr/
    page1.md
    page2.md
  nl/
    page1.md
    page2.md

Ceci colle déjà plus à ce que l’on souhaite. Pour activer le plugin, il suffit de cloner le dépôt pelican-plugins (ou de copier le plugin dans un sous-répertoire de l’installation, à la hussarde). Attention qu’on trouve quelques problèmes de compatibilité entre greffons: i18n_subsites pose plus ou moins problème avec le plugin gallery si des images d’albums différents portent le même nom.

Gallerie d’images

#

Pour la gallerie d’images, je suis parti des plugins gallery et thumbnailer. Le premier permet de créer une gallerie et y copiant un ensemble de photos ; le second permet de créer des thumbnails pour chacune des images (au format square, wide ou cropped). Dans chaque page, j’ajoute une métadonnée gallery: , qui indique le nom du répertoire dans lequel les images doivent être récupérées. Dans le template (également fixé au niveau des propriétés de la page), on peut alors parcourir les différentes images et les afficher.

En associant ce mécanisme avec un plugin Lightbox pour jQuery, on peut ainsi charger les miniatures à l’affichage, et présenter l’image originelle lorsque l’utilisateur cliquera sur le thumbnail.

{% for image in page.galleryimages %}
    <a class="thumbnail" data-lightbox="pictures-set" href="/pictures/gallery/{{page.album}}/{{ image }}">
        <img class="img-thumbnail img-responsive" src="/thumbnails/thumbnail_wide/{{ image }}" alt="">
    </a>
{% endfor %}

Home page

#

La page d’accueil est fixe et ne se base pas sur du contenu dynamique ou provenant d’un fichier. Je l’ai configurée directement au niveau du thème.

La navigation pour l’utilisation est la suivante: lorsqu’il se connecte au site, l’utilisateur arrive sur la page d’accueil - quelques images, menu en anglais par défaut.

Il peut alors sélectionner une langue, ce qui l’enverra vers la page {lang}/index.html. Cette dernière page correspond à du contenu rédigé en Markdown, dans lequel on trouve les métadonnées suivantes:

Title: Around us
Slug: index
Lang: en
Translation: true
Template: pagewithmap
Gallery: brussels

A priori, toutes les propriétés spécifiées ont une utilité :

• Le titre est utilisé dans le template et dans les menus de navigation
• Le slug permet d’overrider le nom du fichier (mais on aurait aussi pu passer par la propriété save_as). Il s’agit aussi de la clé qui associera tous les contenus ayant le même slug.
• La propriété Lang définit la langue
• Le template permet d’associer la présentation à une page HTML spécifique. Celle-ci est placée dans le répertoire themes/{theme_name}/templates/pagewithmap.html.
• La propriété gallery est utilisée par le plugin gallery que l’on a chargé plus haut. Celui-ci va charger toutes les images qui se trouvent dans le répertoire pictures/gallery/{gallery_name}/.

Améliorations à prévoir

#

Plutôt que d’avoir des pages statiques, toutes liées à un template, j’aurais apprécié pouvoir structurer mes données dans des blocs. Par exemple, dans une page, j’aurais pu avoir un bloc description, un bloc comment nous joindre, un bloc prix, … A répéter dans les différentes langues. Wagtails le permet (et c’est même son mode de structuration par défaut - à coupler avec Django Medusa). Je crois que Hyde fonctionne un peu selon le même principe, avec l’avantage qu’il génère par défaut du contenu statique. En fait, il y a des propriétés globales au site que j’aurais aimé pouvoir définir (dans les différentes langues :-)) et réutiliser à des endroits précis.

En même temps, j’aurais aimé pouvoir associer plusieurs galleries d’images à une même page. Le plugin gallery ne permet d’associer qu’un répertoire; il ne gère pas les sous-répertoires (la méthode utilisée est un listdir et pas un walk - et cela impliquerait de modifier la structure de retour pour associer le nom du sous-répertoire aux images, en plus du répertoire initial).