Déploiement de Wiki.js sur mon serveur FreeBSD

Les notes constituent un outil fondamental pour l’organisation et la gestion des connaissances personnelles. Leur valeur s’accroît considérablement lorsque l’on introduit une dimension collaborative. C’est pourquoi j’ai décidé d’abandonner Logseq, une application de prise de notes performante mais conçue pour une utilisation individuelle, au profit de Wiki.js hébergé sur mon propre serveur FreeBSD.

Ce changement représente bien plus qu’une simple transition logicielle : c’est une véritable évolution dans ma façon d’aborder la gestion des connaissances, désormais axée sur la collaboration et le partage.

En déployant Wiki.js sur mon serveur FreeBSD, je mets en place une infrastructure qui me permet de conserver la maîtrise complète de mes données tout en ouvrant de nouvelles possibilités pour la collaboration et la documentation partagée.

Par ailleurs, j’ai progressivement délaissé Logseq au profit de mon éditeur de prédilection, Neovim, avec une synchronisation via Nextcloud. Wiki.js m’offre l’avantage de pouvoir continuer à utiliser Neovim grâce au module de stockage Git, tout en bénéficiant d’une interface web adaptée à la collaboration.

Quand Wiki.js et Git posent problèmes

Avant d’implémenter cette solution sur mon serveur, j’ai d’abord voulu tester ce qui m’intéressait le plus : l’édition via le stockage Git. Les résultats étant satisfaisants, j’ai procédé à la configuration sur mon serveur et importé mes notes Logseq à l’aide d’un script bash pour les reformater correctement.

La problématique

Récemment, j’ai fait face à un problème particulièrement frustrant avec mon installation Wiki.js connectée à un backend Git. Malgré de nombreuses tentatives de synchronisation depuis l’interface d’administration, notamment via les options “Tout mettre à jour” et autres fonctionnalités de synchronisation, les modifications ne se propageaient pas correctement entre mon dépôt Git et mon instance Wiki.js.

La solution radicale (et inutile)

Après avoir épuisé toutes les solutions de dépannage classiques, j’ai opté pour la solution radicale : effacer entièrement ma base de données Wiki.js pour repartir de zéro. Cette opération n’a pourtant pas résolu le problème.

C’est seulement après cette intervention drastique que j’ai découvert le véritable coupable : la présence d’espaces dans les noms de fichiers.

Si j’avais identifié cette cause plus tôt, j’aurais pu éviter de réinitialiser complètement la base de données. Ce simple détail typographique entravait toute synchronisation efficace entre mon dépôt Git et Wiki.js.

Bonnes pratiques pour éviter ce désagrément

Pour prévenir des problèmes similaires avec l’intégration de Wiki.js et Git :

1. Bannissez complètement les espaces dans les noms de fichiers et de dossiers - Privilégiez les tirets ou les underscores
2. Définissez des conventions de nommage précises avant de peupler votre wiki
3. Effectuez les modifications structurelles via l’interface Wiki.js plutôt que directement dans Git
4. Réalisez des sauvegardes régulières de votre base de données avant toute opération de synchronisation majeure

Leçon retenue

L’intégration entre Wiki.js et Git offre de puissantes fonctionnalités de documentation collaborative, mais elle comporte certaines subtilités qui demandent une attention particulière. Un élément apparemment anodin comme un espace dans un nom de fichier peut engendrer d’importants dysfonctionnements de synchronisation.

Si vous rencontrez des problèmes de synchronisation avec votre installation Wiki.js, vérifiez d’abord la présence d’espaces dans vos noms de fichiers avant d’envisager des mesures drastiques comme la réinitialisation de votre base de données. Une simple modification de nommage peut vous épargner des heures de reconstruction fastidieuse.