Je me gardais sous le coude ces quelques notes pour ne plus perdre trop de temps à chaque fois que le plugin wordpress Post View Counter se met à jour. Post Views Counter me permet d’afficher le nombre de vue pour chaque article et d’y importer (manuellement) les valeurs de Google Stat. Peu de plugin permette de faire cela hormis l’usine Jetpack que j’ai choisi d’abandonner depuis l’année dernière. J’utilise l’option de positionnement manuelle de ces données dans mon template, mais pour que cela s’intègre proprement, j’ai dû faire également un petite modification dans le template du plugin.
Depuis son lancement en 2006, j’ai gardé comme approche que ce blog serait un archive, une trace du passé en évitant au mieux d’avoir un regard critique sur son contenu. En effet, durant ces premières années, ce que j’y mettais était d’un intérêt aujourd’hui probablement peu intéressant. Un billet pour parler d’un ami, de travaux, d’une nouvelle décoration dans ma maison… C’était le concept des Blogs avant l’arrivée des réseaux sociaux. N’importe qui pouvait alors partager n’importe quoi en associant une image avec du texte… Vive le Web 2.0 !
Tout a commencé sur Skyblog en juillet 2006 !
Aujourd’hui, 18 années plus tard, le Blogs sont devenus désuets, j’en conviens… et je me suis retrouvé il y a quelques mois face à une situation bien désagréable liée à une photo controversée d’un village italien, conservée dans un de mes roadbook préparatoire, pour laquelle une société belge adepte du Copyright Trolling me réclame d’important montant.
Si mon approche a toujours été de partager avec vous,… même si je vous compte sur les doigts de ma main, mais aussi participer à la conservation d’une époque, il m’a fallut revoir le « comment », réfléchir au « pourquoi ». Il était claire que je ne voulais pas juste pousser sur le bouton auto-destruction. Rendre l’ensemble du blog inaccessible pouvait être une sécurité, mais restait une injustice.
J’ai donc longuement réfléchi, expérimenté et repensé tout ceci, m’obligeant néanmoins à cadenasser, censurer certains contenus afin d’éviter tout risque face à des entreprises qui cherchent à tirer profit du « flou » autour du droit d’auteur et qui seront aidées de jours en jours par des outils d’Intelligence Artificielle plus redoutables, et surtout ne prenant aucune considération quant à l’approche ouverte, équitable et non-lucrative d’un Blog Personnel.
Bref, je ne m’arrêterais pas aujourd’hui sur la problématique « légale » de la chose, je poursuis d’approfondir le sujet, mais bien sur ce que j’ai mis en place techniquement pour détruire le moins de contenus possibles tout limitant l’accès à certains contenus à titre privé.
Je garde donc ici, en mémo, tout ce qui a été mis en place depuis 3 mois, autre que le passage en revue de plus de 2.000 articles et 16.000 images afin de les supprimer ou de les mettre en mode privé. Cette seconde option, certes moins radicales conservant l’existence même des fichiers images accessibles par des bots ou moteurs de recherche. Ce qui ne m’était pas suffisant pour dormir tranquille !
Je poursuis mes analyses afin d’optimiser ce qui peut l’être sur mon blog. Depuis le mois de juin, Goolge semble avoir renforcé les conditions pour proposer une expérience Mobile acceptable, et je sais que cela peut avoir un impact sur le référencement. Je m’étais donc mis à l’analyse de ce que je pouvais mettre en place pour réduire la lenteur d’affichage de ce dernier, profitant pourtant d’un des meilleurs hébergeurs européen. Après avoir renforcé l’optimisation des fichiers images avec le plugin Smush, supprimé une série de plugins inutiles, adapter Related Post et modifié les réglages de la mise en cache… Il restait une action que je trouvais pertinente à envisager.
J’aime avoir un joli site, et dans la configuration de mon thème, je charge un image originale et pourtant discrète en arrière plan. Cela se constate essentiellement sur un ordinateur à grand écran, en revanche, au format mobile, on ne la voit pas. Je me suis donc dit que je pourrais, avec un peu d’aide de ChatGPT, repérer comment ajouter une condition qui contournerait cette consommation de bande passante lorsque l’on visite le site depuis un Device mobile.
Dans cette modification, nous utilisons la fonction wp_is_mobile() pour vérifier si le site est en mode « mobile ».
Ah les statistiques de visite des sites web, c’est un truc qui m’a toujours passionné ! J’avais bien sur mon petit compteur de visite dès mes premiers site en HTML et je me suis rapidement mis à intégrer PHPMyVisit lorsque j’ai créé mes premiers sites webs en Xoops puis WordPress il y a déjà 15 années. De quoi savoir qu’à l’époque c’était mes articles sur l’utilisation d’un linker R4 Revolution sur ma DS qui avait plus de succès que la présentation de mes nouvelles musiques !
Depuis lors, Google a mis en place des outils propres au suivi statistique, non plus uniquement pour les amateurs de chiffre que je suis, mais également pour travailler à optimiser son référencement et l’achat de publicité. Néanmoins, l’outil « Universal » de Google Analytic n’était pas complexe à utiliser ou à intégrer dans son site web lorsque l’on avait l’habitude de mettre son nez dans le code, et par ailleurs rapidement des outils et plugins WordPress ont permis de rendre cela plus facile encore.
Mais depuis près d’un an, Google nous annoncé que la balise « Universal » serait remplacée dès le 1er juillet 2023 par la nouvelle méthode GA4.
Après avoir longuement reporté le problème, j’ai dû mettre en route la procédure de « »migration« » sur les différents sites principaux que je gère, dont celui-ci. Et le moins que l’on puisse dire c’est que la nouvelle approche est loin d’être aussi simple. Il ne s’agit plus de pouvoir « simplement » suivre les statistiques et comportements de manière simple des internautes, tout peut-être croisé, personnalisé à un niveau tels que la configuration est une veritable torture, même pour l’amateur de chiffre que je suis…
Grosso modo, on se retrouve régulièrement avec 5 à 6 sous niveau de menu, des balises qui se croisent et dont la référence change à chaque croisements avec les autres outils Google et je ne peux que faire le constat que rien n’est intuitif.
— Cette article reste en construction, j’y ajouterais petit à petit les éléments d’analyse et solution —
Et bien, en plus de 15 ans de WordPress, je pense que je ne m’étais jamais retrouvé dans une situation où envisager un downgrading de version se présente être la meilleure option. Il faut admettre que par le passé, ce genre d’option était assez complexe à mettre en place, devant toucher au noyau du CMS sur le serveur FTP et dans la base de données. J’ai toujours cherché d’autres options.
Mais ici, en utilisant la surcouche ProPhoto 7 si l’un de nos sites professionnels, je n’ai plus autant la main dans l’affichage finale, ce qui était par ailleurs mon intention ! Dès lors, lorsque problème il y a, les solutions à ma disposition me sont moins nombreuses.
ProPhoto 7 bug avec WP 5.9.2
J’avais évité le passage à la version 5.9.x sur ce serveur alors que je préparais le développement du nouveau site, et je pensais que migrer de la 5.8.last vers la 5.9.2 ne serait pas risqué, puisque 2 versions avaient déjà pu éventuellement corriger les bugs de jeunesse. C’était sans compter un gros changement de la part de WordPress dans sa version 5.9.1 ! Et un message rapporté par ProPhoto recommandant de ne pas passer à la version 5.9.1 et d’attendre, peut-être la 5.9.2 … ARF
Dans les solutions proposées, un roll-back à la version 5.9 , en autre via le plugin « WP Dowgrade » dont la doc est en allemand. Techniquement, on cible le numéro de version, par exemple la 5.9 (et non la 5.9.0). Une fois validé, la page des mise à jour de WordPress va, non plus proposer de ré-installer la dernière version, mais ciblera la version souhaitée. C’est rudimentaire, certes, mais après avoir croisé les doigts et fait deux « Je vous salue Mario »… Le retour en arrière avait réussi et le site était corrigé !
