Je rechignais à mettre à jour ma version de shaarli pour deux raisons :

• Utilisation de Composer. Je ne voulais pas de ça sur mon serveur. Au-delà de Composer, mais à travers lui, je considère que shaarli s'est empoté, qu'il a pas mal de dépendances, ce qui l'éloigne de l'esprit KISS (Keep It Simple, Stupid) du début ;
  
  
• J'insère des balises HTML, comme <br />, au sein de mes articles. Or, pour des raisons de sécurité, les versions ultérieures de shaarli les neutralisent.

Trois points m'ont motivé à franchir le pas :

• La classe PHP qui manipule la base de données, LinkDB, contient du code déprécié depuis plusieurs années. La pérennité est en jeu ;
  
  
• Mon shaarli est lent. time curl : 690-700 ms en moyenne sur la page d'accueil ; 630 ms pour afficher un court article. Outils de développement web de Firefox : 580 ms en moyenne. Même mon Wordpress, avec son SGBD, était plus rapide (avant que je le démantèle) ! Je ne constate pas cette lenteur sur d'autres shaarlis pourvus d'un nombre d'articles similaire au mien, et que dire de celui de SebSauvage, quasiment 6 fois plus d'articles ! J'avais profilé le code et j'avais compris que la lenteur venait de la lecture et du traitement (échappement HTML) de l'ensemble des articles de la base de données, même pour afficher un article. Les notes de versions ultérieures de shaarli annoncent du changement. Pourquoi refuser de tester ? ;
  
  
• J'étais ignorant concernant Composer. La note de version expose plutôt clairement qu'il n'y a point besoin d'avoir Composer sur son serveur, ni même sur son ordinateur perso. Sur l'éloignement du KISS, peut-être faut-il un compromis : c'est l'air du temps, je n'y peux rien, il faut accepter, et shaarli reste raisonnable contrairement à la première merde Node ou Go ou Rust ou… qui télécharge la moitié d'Internet pour un « Hello, World! ».

Je suis donc passé, étape par étape, de version majeure en version majeure, de la version 0.7.0 (de mai 2016 😮️, ce que le temps passe vite !) à la version 0.16.5 (la dernière, d'il y a un mois).

J'ai galéré sur plusieurs points :

• Pour une version, il faut modifier la config JSON, ça ne se fait pas tout seul : donner la valeur tpl\/ à raintpl_tpl et default à theme ;
  
  
• La version 0.10 ne fonctionne pas : PHP Fatal error:  Uncaught Error: Shaarli\\Security\\LoginManager::__construct(): Argument [#1](http://shaarli.guiguishow.info/./add-tag/1) ($globals) could not be passed by reference in <CENSURE>/index.php:126. Je suis passé à la version 0.11 sans chercher à comprendre ;
  
  
• Rigolo, la version 0.11 affiche les articles dans l'ordre chronologique (le plus récent est sur la page d'accueil) 😄️ ;
  
  
• La version 0.12 apporte une nouvelle version de la base de données. Il y a donc une migration automatique. Dans mon cas, il fallait autoriser 256 M de mémoire par script au lieu de 128 M. Attention, le changement ne se fait pas dans php.ini, mais dans le fichier init.php de shaarli 😑️. (Je déteste les applis qui touchent les paramètres serveurs.) Cette migration aura pour conséquence que tous les articles seront présentés comme ayant été modifiés le jour de la migration ;
  
  
• La même version exige la réécriture d'URL. Je désactive la prise en compte des .htaccess. Je l'ai activé. Marche pas. J'ai mis un temps démesuré à comprendre que ma méthode de déploiement de shaarli dans le DocumentRoot n'englobait pas le .htaccess livré par shaarli 🙄️. Entre-temps, J'ai suivi la doc pour se passer de réécriture : ça ne fonctionne pas. Enfin, si, root_url répare les liens vers les flux RSS et Atom, mais pas celui pour s'identifier, ni celui, direct, vers chacun des articles, ni l'ancien format des liens (« /?6PDbnA », par ex.) ;
  
  
• Dans le thème vintage, dans /tpl/vintage/linklist.paging.html, l'élément div[@class=paging_current] n'est affiché que s'il y a plus d'une page d'articles. Donc, sur l'affichage individuel d'un article, il y a un décalage, une ligne blanche, entre l'entête de page et l'article. Pour réparer sans prise de tête, j'ai ajouté une espace insécable avant la condition ;
  
  
• Plusieurs autres difficultés ont pour origine ma configuration durcie (limitation des droits sur les fichiers, notamment d'écriture, etc.).

Pour rétablir l'utilisation des balises HTML dans le cœur des articles, pas besoin de crapahuter dans le code, il suffit d'ajouter "markdown_escape": false dans le bloc security du fichier de conf'. Dommage que cette option n'est pas documentée. J'en ai eu connaissance uniquement car j'ai consulté le fichier de configuration après chaque montée de version et que l'outil de migration apparue avec la version 0.12 positionne cette directive.

Après, il a fallu modifier le thème :

• Augmenter la taille des caractères (ce qui se fait en retirant « font-size: 10 pt; » du sélecteur body, la propriété identique dans le sélecteur « .markdown » prendra le relai) ;
  
  
• Justifier le texte des articles ;
  
  
• Insérer les mentions légales ;
  
  
• Je n'ai pas eu la foi de remettre en œuvre ma hiérarchie du contenu avec des titres (h1, h2, etc.) plutôt que tout en liste à puces. Idem pour le non-dépôt de cookie tant que le visiteur n'essaye pas de s'identifier ou de modifier le nombre de liens par page.

Il reste des bugs dans la version 0.16.5 :

• Un article fraîchement publié sera annoncé comme ayant été modifié après publication ;
  
  
• Quand la base de données (datastore.php) n'est pas accessible en écriture, mais l'est en lecture, le message d'erreur est « Your data might be corrupted, or your file isn't readable. », ce qui est trompeur ;
  
  
• Il faut créer à la mano le fichier de log (par défaut : data/log.txt).

Au final les deux objectifs recherchés sont satisfaits à moitié :

• Le code déprécié de l'ancienne classe LinkDB fait place à d'autre code déprécié, dans des stacktraces encore plus interminables qu'avant qui sont mises sous le tapis par shaarli. Consolation : quand ça pétera, il y aura sûrement un développeur pour réparer, ce qui n'aurait pas été le cas de la version obsolète que j'utilisais ;
  
  
• xdebug montre que le gros du temps est consommé dans BookmarkFilter (notamment la fonction noFilter()) et BookmarkArray (notamment la fonction current()), donc toujours la lecture de la base de données, mais, au fond, rien à signaler. Surtout, il n'y a plus 4-5 assainissements par article dès leur lecture dans la base de données. time curl tourne autour de 480 ms pour la page d'accueil, et 400 ms pour un article. Les outils de développement de Firefox tournent autour de 350 ms, parfois 280 ms, parfois 480 ms. Sur mon ordinateur personnel, je suis à 230 ms voire moins, constamment. J'en déduis que la fluctuation est causée par la charge de mon serveur (je n'ai qu'un vCPU) et par celle de mes colocataires (je loue une machine virtuelle). Cependant, le gain est déjà notable. Je ne peux pas aller plus loin : les dossiers « cache », « pagecache », et « tmp » sont déjà des tmpfs (du stockage en mémoire vive) ; la base de données est déjà mise en cache par Linux (j'observe cela avec vmtouch, lire ici).