Revenir à un site web statique chez OVH ?

Publié le dim. 12 avril 2020 dans Partager



Puzzle


Vents et Jardins a d'abord tourné sous Joomla, parce que c'était le CMS que je connaissais déjà. Je l'ai ensuite transféré sous MediaWiki pour plus de simplicité. Il était ainsi beaucoup plus facile de tout changer, y compris la structure du site, depuis plusieurs ordinateurs différents (en vacances notamment).

Mais j'envisage maintenant de changer encore une fois! Comment? Pourquoi? Au prix de quelles difficultés?


Avantages et inconvénients de MediaWiki

Pour moi, l'avantage de MediaWiki par rapport à Joomla, c'était:

  • Meilleur suivi des version. Simplicité pour récupérer tout ou partie d'un ancien article.
  • Theme hyper sobre pour la consultation et la rédaction courante (Tweeki), modifiable à la volée (Monobook ou Vector) en cas de besoin plus pointus pour la maintenance.
  • Simplicité d'utilisation en cas d'écriture à plusieurs sur un article donné.
  • Facilité d'écriture et de mise en page. Le code wiki est beaucoup plus facile à taper et à modifier que le html et on reste indépendant des options et particularités de tel ou tel éditeur wysiwyg de Joomla.

Les inconvénients que je n'avais pas prévus!

Je me suis rendu compte depuis le passage à MediaWiki d'une augmentation assez notable du trafic. Au bout d'un moment, il est apparu que cette augmentation était le fait de robots d'indexation auquels je n'ai pas porté trop d'attention dans un premier temps, n'étant pas informaticien de métier. Ce n'est que quand j'ai vu qu'un fichier "verrou" qui protégeait l'accès à une partie de mon site a disparu que j'ai commencé à fouiller tout ça un peu plus.

Il s'avère que ces robots qui encombrent mon trafic (et rendent les logs difficilement utilisables) sont des nuisibles. Ils sont à la recherche de failles dans la système et ils fouinent vraiment partout, y compris dans chaque des innombrables versions successives de chaque petite page d'un wiki. Même en faisant en sorte que ces pages ne soient pas visibles par l'utilisateur normal du site, les robots malveillants n'ont pas besoin de liens internes pour y accéder. Ils savent où elles se trouvent sur un wiki et ils vont les chercher directement.

Pas étonnant que le trafic explose!

Retour au web 1.0 ? Bah pourquoi?

Après consultation d'un copain dont c'est le métier (encore merci Pierre!), j'ai réalisé que je ne pouvais pas laisser les choses dans cet état. J'ai deux possibilités:

  1. Filtrer tout le trafic en mettant des htaccess compliqués et en surveillant régulièrement qu'ils n'ont pas été modifiés par un intrus. Faisable, mais un poil technique pour moi. Pour être efficace dans ce genre de démarche, il faut être au courant de l'évolution des techniques des pirates, donc être un pro ou faire réaliser le boulot par un pro.
  2. ou... revenir à un site statique, tout simplement! Cette dernière solution qui semblait absurde quand le site commençait et qu'il fallait sans cesse modifier des tas de petits détails dans des tas de pages différentes ne l'est pas forcément tant que ça maintenant que le site est à peu près stabilisé, et que les pages changent moins souvent.

L'avantage du statique, c'est:

  • qu'il est plus facile à maintenir (plus besoin de mises à jour régulières des extensions)
  • beaucoup plus facile à protéger des robots (plus d'accès à contrôler vis à vis des pages spéciales ou d'historique)
  • beaucoup plus facile à protéger des pirates.
  • plus facile pour un amateur de contrôler le code html et le rendu css qu'avec un logiciel de type CMS ou Wiki.

Le prix à payer ce sera: - Il faudra rédiger et préparer les pages ailleurs. Par exemple sur un wiki local. Et du coup les visiteurs ne voient plus le travail progresser en temps réel.

  • Ce sera beaucoup plus long de corriger un mot, une faute d'orthographe ou de typo sur le site une fois l'article publié.

Retour au statique, oui mais comment?

Pour le moment, j'envisage trois possibilités:

  1. Continuer à '''préparer mes articles sur un wiki interne, puis récupérer le html''', page par page avec la fonction "enregistrer" de Firefox ou globalement avec un logiciel du genre wget ou httrack. Ce serait le plus simple à première vue, mais au prix de quelque difficultés, notamment:
    1. des liens internes au wiki qui ne fonctionneraient plus et qu'il faudrait cacher via le CSS. Comme par exemple le bouton "Edit" du wiki.
    2. un code html assez moche et inutilement compliqué à la fin et pas facilement modifiable.
  2. Tout faire en PHP à la main. Après tout, au départ, PHP était fait pour ça. Pas de base de données piratable, pas de scripts, pas d'interface administrateur, rien de tout ça. Uniquement des ''include'' en php histoire de ne pas avoir à tout refaire quand on modifie un pied de page. Pour un site comme le mien, ce serait la solution la plus simple. Et pour transformer le code wiki de chaque article en html propre et simple, utiliser le logiciel Pandoc, qui fait ça super bien.
  3. Utiliser un logiciel dédié à la conception de sites statiques. Après quelques recherches, je suis en train de faire un essai avec Pelican.
    1. Inconvénients:
      1. Encore un autre logiciel à apprendre. J'ai trouvé un tuto qui à l'air bien sur zestedesavoir.com .
      2. Encore un autre langage de doc à apprendre (Markdown), mais ça n'a pas l'air d'être la mer à boire et il reste Pandoc qui semble traduire plutôt bien le MediaWiki en Markdown.
      3. Les thèmes par défaut génèrent des codes html inutilement compliqués pour mon cas. J'aime bien quand c'est simple et que ça ne contient que les ressources que j'utilise vraiment. Il va falloir que je modifie l'un des thèmes pour le simplifier drastiquement.
    2. Avantages:
      1. Pelican génère automatiquement des pages de suivi, (par catégories, tags, sitemap, etc.) dont je n'aurai pas forcément besoin sur le site en ligne, mais qui pourraient être bien utiles au niveau de la conception
      2. Une fois le thème correctement paramétré, le modifier devrait devenir considérablement plus simple que de tout faire en php à la main, notamment en ce qui concerne les metadatas.

A suivre...