OVHcloud ou PlanetHoster pour éviter un compteur WordPress incomplet

Deux inscriptions sont enregistrées et le compteur n’augmente qu’une fois

Une extension WordPress garde un compteur d’inscriptions pour un événement. Quand deux demandes arrivent presque en même temps, les deux fiches sont présentes dans le registre, mais le total affiché n’a augmenté que d’une unité. Le premier contrôle consiste à comparer les identifiants réellement enregistrés au total dans la base. Si le total stocké vaut déjà un alors que le registre contient deux inscriptions distinctes, l’écart se produit avant l’affichage.

Une façon courante de créer cet écart est de lire le compteur, calculer le nouveau total en PHP et écrire cette valeur. Si les deux traitements lisent zéro, chacun prépare le même total de un. La deuxième écriture laisse alors la première valeur en place. Le moteur peut terminer les deux instructions SQL sans erreur, même si la seconde ne change aucune ligne. Ce cas s’appelle une mise à jour perdue.

Le comparatif concerne un compteur maintenu par une extension ou un code personnalisé. Les fonctions WordPress `get_option()` et `update_option()` illustrent les deux étapes d’une lecture et d’une écriture d’option. L’exercice reproduit le mécanisme sur une table dédiée, sans charger WordPress. Il compare ensuite un incrément exécuté dans la base et un registre où chaque inscription possède un identifiant unique.

Prouver la différence entre une inscription et son compteur

Travaillez sur une copie privée et préparez deux inscriptions fictives distinctes, avec des identifiants faciles à reconnaître. Notez le total de départ et vérifiez que chacune est enregistrée par le traitement prévu. Relevez ensuite le total dans la table réellement utilisée par l’extension. Si une inscription manque du registre, examinez sa validation. Si les deux inscriptions sont présentes et que le total a perdu une unité, examinez les écritures qui entretiennent ce total.

Un essai manuel où les demandes sont très espacées peut réussir à chaque fois. Demandez au mainteneur de relever, pour les deux traitements, la valeur lue avant l’écriture et la valeur proposée. Dans l’exercice, les deux lectures sont terminées avant la première écriture. Cela donne un ordre reproductible sans créer de charge importante. Les identifiants fictifs permettent de rapprocher les résultats sans enregistrer de données d’inscrits.

Contrôlez aussi la portée de la ligne mise à jour. Si un événement possède plusieurs compteurs ou si l’extension fonctionne sur plusieurs sites, vérifiez l’identifiant qui figure dans la condition de la requête. Un résultat incohérent peut aussi venir d’une ligne différente de celle que lit la page. Une fois le bon périmètre confirmé, comparez la valeur avant et après, le nombre de lignes modifiées et le registre des deux inscriptions.

• Créer deux inscriptions témoins et vérifier leurs identifiants dans le registre.
• Relever la valeur lue par chaque traitement et le total stocké après les deux écritures.

Séparer la mise à jour perdue de la nouvelle tentative

Deux demandes différentes peuvent se chevaucher et écraser une valeur calculée. Une demande déjà traitée peut également être relancée à cause d’une erreur d’affichage ou d’un délai. Ce sont deux situations distinctes. L’incrément dans la base peut compter correctement deux demandes différentes. Si la première demande est rejouée sans identifiant stable, le même incrément ajoute aussi une troisième unité. Le nombre obtenu ne correspond plus à deux inscriptions uniques.

Avant de changer le code, définissez ce que le total représente. S’il compte les inscriptions distinctes acceptées, le registre de l’extension constitue une référence. S’il compte seulement des occurrences et que chaque appel doit augmenter le total, un incrément sur la ligne dédiée peut suffire. Pour une inscription, conservez le même identifiant pendant une reprise. Le registre permet de distinguer une opération déjà traitée d’une nouvelle inscription.

Pour le relevé de recette, provoquez d’abord deux opérations distinctes. Rejouez ensuite une seule opération avec le même identifiant. Vérifiez les résultats séparément. Une règle correcte pour la concurrence peut rester insuffisante face aux reprises. Faites aussi un témoin où une requête ne trouve aucune ligne de compteur. L’application doit savoir si elle doit créer cette ligne selon sa procédure ou signaler un écart à corriger.

OVHcloud Perso pour retrouver la base du site

Pour un WordPress déjà hébergé chez OVHcloud, partez du service d’hébergement et relevez le nom de la base utilisée par la copie de recette. Dans l’espace client, ouvrez Web Cloud, puis Hébergements. Sélectionnez le service voulu et ouvrez l’onglet Bases de données. Le menu de la base donne accès à phpMyAdmin. Faites correspondre le nom affiché avec celui que WordPress utilise, puis vérifiez le préfixe des tables. Deux sites sur un même hébergement peuvent se ressembler dans le gestionnaire.

Utilisez l’onglet SQL de phpMyAdmin pour relever la version du serveur et le moteur de la table du compteur. Une lecture du compteur et une lecture du registre suffisent à établir le premier constat. Comparez les résultats avec ce que relève l’application lors des deux demandes témoins. La documentation des bases incluses limite leur accès direct depuis l’extérieur de l’hébergement. Le client MariaDB de l’exercice vise donc son serveur local. Côté hébergement, choisissez phpMyAdmin ou un contrôle exécuté depuis le site par son mainteneur.

L’offre Perso de la gamme Eco annonce cinq bases de données de 1 Go chacune, 100 Go de stockage SSD web et jusqu’à quinze sites. Une nouvelle table pour le compteur et son registre partage le quota de la base WordPress qui la contient. Relevez la place occupée par cette base avant d’importer une copie. Pour un site unique déjà présent sur Perso, l’accès direct depuis le panneau et la possibilité de garder une base de recette distincte sont les critères utiles, selon les bases encore disponibles sur le compte.

• Identifier le service, la base et le préfixe utilisés par la copie de WordPress.
• Ouvrir phpMyAdmin depuis la ligne de la base, puis contrôler la version et le moteur en lecture.

PlanetHoster The World pour rattacher le diagnostic au bon projet

Dans The World, commencez par identifier le Projet Web qui héberge la copie de WordPress. Donnez à cette copie un nom reconnaissable et vérifiez son domaine de recette. Ouvrez ensuite le panneau N0C de ce projet. La documentation N0C indique le parcours Bases de données, puis PhpMyAdmin. Dans l’arborescence de l’outil, sélectionnez la base utilisée par WordPress et vérifiez le préfixe avant de relever les deux valeurs. Notez ensemble le nom du projet et celui de la base dans le compte rendu.

Le pack étudié comprend dix Projets Web Standard. La page commerciale affiche 10 Go NVMe ou SSD par projet Standard. Cette capacité décrit le stockage du projet et ne donne pas à elle seule un quota SQL indépendant. Si le registre doit croître, vérifiez dans le panneau les limites qui s’appliquent à la base du projet et mesurez la taille du jeu de recette. Repérez aussi le compte SQL associé à l’application. Les opérations possibles dans le panneau administrateur et les droits effectivement accordés à WordPress se vérifient séparément.

Le rattachement au projet facilite la passation lorsqu’une équipe maintient plusieurs installations et doit identifier celle qui produit le chiffre. Pour tester une reprise, utilisez toujours la même base et le même identifiant fictif. Un compteur relevé sur un projet et un registre consulté sur un autre produisent un écart impossible à interpréter. Dans la fiche de recette, indiquez le domaine de test, la base sélectionnée, le préfixe et la table dont le moteur a été relevé. Gardez les identifiants de connexion hors du compte rendu.

• Ouvrir N0C dans le Projet Web de recette, puis choisir Bases de données et PhpMyAdmin.
• Consigner le projet et la base avec les deux relevés du compteur et du registre.

Comparer les tarifs sur leur durée et les limites sur leur périmètre

Au relevé du 11 novembre 2026, OVHcloud Perso affiche 2,99 € HT par mois et un équivalent affiché de 3,59 € TTC par mois. La page donne un total d’entrée de 35,88 € HT pour douze mois. Le renouvellement affiché est de 5,99 € HT par mois, soit 71,88 € HT pour douze mois à ce tarif. L’équivalent TTC mensuel affiché est arrondi. Pour connaître le montant débité toutes taxes comprises, reprenez le total présenté dans le panier.

PlanetHoster affiche une offre de lancement à 5,49 € par mois sur un cycle de vingt-quatre mois. Elle s’applique au pack de dix Projets Web Standard étudié ici, ainsi qu’à une configuration Ultra distincte. Les conditions précisent que les tarifs du site sont TTC. Au taux affiché, le calcul donne 131,76 € TTC pour vingt-quatre mois. Le montant de reconduction de ce pack reste à vérifier dans le panier ou l’espace membre. Les conditions prévoient un renouvellement automatique par défaut et une désactivation au plus tard trente jours avant l’échéance.

Pour une décision d’achat, inscrivez la somme à engager au départ, la durée couverte, la fiscalité et le renouvellement sur des lignes distinctes. Les cinq bases d’OVHcloud et les dix projets de PlanetHoster désignent deux unités différentes. Pour cet incident précis, retenez le service où la copie peut être identifiée, où les lectures SQL sont possibles et où l’équipe a la main sur la table de son extension. En restant sur le service actuel, vous pouvez souvent valider le correctif avant d’engager une migration.

Appliquer l’incrément dans la table dédiée de l’extension

Si chaque opération distincte doit ajouter exactement une unité et que la ligne du compteur existe déjà, faites calculer le nouveau total par la base. Le principe est `UPDATE compteur SET total = total + 1 WHERE id = 1`, avec un identifiant de compteur issu de l’application et lié par une requête préparée dans le code réel. La table illustrée appartient à l’extension. Sur InnoDB, les modifications concurrentes de la ligne ciblée se succèdent sous verrou. La seconde instruction ajoute une unité à la valeur laissée par la première.

Commencez par confirmer que la table utilise InnoDB, que la condition vise la clé de la ligne et que la colonne est initialisée avec un entier. Prévoyez dans l’installation de l’extension la création de la ligne qui portera le compteur. Après chaque opération de recette, contrôlez que la requête a modifié une ligne. Dans ce montage, zéro ligne modifiée impose de vérifier la cible et l’initialisation. Une erreur SQL doit remonter à l’appelant avec le contexte de l’opération afin que le mainteneur puisse décider de la suite.

Faites l’inventaire des traitements qui écrivent ce total. Une ancienne tâche qui relit le compteur et réécrit une valeur calculée peut annuler un incrément correct si elle reste active. Les réglages généraux de WordPress conservent leurs API habituelles. Pour un compteur actuellement stocké comme option, le passage à une table dédiée demande une évolution de l’extension avec une lecture et une écriture basculées ensemble. Sur la copie, contrôlez la valeur de départ, les deux opérations, puis la valeur affichée une fois les écritures terminées.

• Vérifier le moteur, la clé de la ligne et la valeur de départ avant de tester la requête préparée.
• Exécuter les deux opérations témoins et contrôler qu’elles modifient chacune une ligne.

Compter les inscriptions distinctes à partir de leur registre

Si une inscription peut être relancée, utilisez le même identifiant pour toutes les tentatives de cette inscription. Faites porter l’unicité par une clé de la table du registre. Sur un site qui gère plusieurs événements, la clé peut inclure l’identifiant de l’événement et l’identifiant d’inscription. L’extension calcule alors le total en comptant les lignes de l’événement avec les critères qui définissent une inscription acceptée. Si le registre métier possède déjà ces données, partez de ce registre.

Traitez un conflit d’unicité sur la clé prévue comme une invitation à relire la ligne existante. Si elle correspond à la même opération, l’application peut reprendre le résultat déjà enregistré. Si des données métier diffèrent pour cet identifiant, signalez le conflit. Les autres erreurs SQL suivent le circuit normal d’échec. Dans le laboratoire, une clé primaire sur l’identifiant suffit puisque les deux inscriptions appartiennent au même groupe fictif. La troisième insertion reprend la clé de la première et MariaDB renvoie l’erreur 1062. Si l’extension doit aussi maintenir un compteur stocké, faites enregistrer la nouvelle inscription et son incrément dans la même transaction sur des tables transactionnelles. En cas d’échec, annulez l’ensemble. Une tentative déjà enregistrée retrouve son résultat sans nouvel incrément. Ce parcours se vérifie dans l’extension.

Pour réparer le total d’un site, relevez l’ancien chiffre et calculez le total à partir des inscriptions qui font autorité. Notez la date de coupure et vérifiez la règle appliquée aux inscriptions annulées, en attente ou importées. Si des écritures continuent pendant la correction, coordonnez leur arrêt ou une bascule cohérente avec le mainteneur afin de prendre en compte les arrivées de la période. Conservez la sauvegarde de la table et le relevé avant intervention. Si une partie du registre manque, faites valider l’écart avant de modifier le total.

• Rejouer une inscription avec sa clé d’origine et vérifier que le nombre d’inscriptions acceptées reste identique.

Rejouer la recette locale et valider la reprise sur une copie

Le ZIP contient le script Python et sa notice pour Windows. Décompressez-le sur le lecteur de travail et indiquez le dossier bin d’une distribution portable de MariaDB. Le script démarre un serveur temporaire sur l’adresse de boucle locale, crée deux tables InnoDB et utilise des connexions indépendantes. Les données sont fictives. L’archive a été extraite et rejouée avec Python 3.14.4 et MariaDB 10.11.14. Le rapport joint conserve les huit contrôles et le résultat de chaque étape.

Dans le premier cas, les deux clients lisent zéro et proposent un. L’une des écritures modifie la ligne et l’autre laisse la valeur en place. Le total observé est de un. Après remise à zéro, les deux incréments modifient chacun une ligne et le total atteint deux. Un incrément supplémentaire sans identifiant porte le total à trois. Dans le registre, le rejeu d’une des deux clés déclenche le conflit prévu et le comptage reste à deux. Ces observations mesurent les opérations du laboratoire, avec sa table et son moteur.

Pour terminer sur la copie de WordPress, validez un cas simple, deux demandes distinctes qui se chevauchent et une reprise de la première demande. Après chaque cas, rapprochez l’écran, le registre et la ligne de compteur si elle subsiste. Vérifiez aussi que le retour à la version précédente conserve les inscriptions intervenues depuis la sauvegarde. Les menus et limites des hébergeurs proviennent de leur documentation. La validation du correctif dans l’extension et sur le compte d’hébergement appartient à cette étape de recette.

• Noter les trois valeurs attendues avant la recette et rapprocher chaque résultat du registre.

Pour aller plus loin

• Lire la fiche OVHcloud
• Lire la fiche PlanetHoster
• Préserver les commandes et contenus récents lors d’une restauration
• Télécharger la recette du compteur WordPress (ZIP)