- WordPress :4.6.1
- Statut : non résolu
- Ce sujet contient 29 réponses, 5 participants et a été mis à jour pour la dernière fois par
, le il y a 4 années et 3 mois.
-
Messages
-
Ma foi j’ai mis juste le premier lien qui m’est tombé sous la main juste pour illustrer.
Effectivement informatiquement parlant je ne saurais pas dire d’où vient le problème…
De mémoire toutes les solutions que j’avais pu voir c’était toujours la même : désactiver…
Je vais vérifier pour Magpie depuis le temps qu’il est installé il est fort probable que… oups
Je viens de jeter un œil et effectivement tu as déjà 256 mo de données dans cette table, essentiellement du Xiti et pub/shockwave. Le support WordFence dit ceci à son propos :
<span id= »result_box » class= » » lang= »fr » tabindex= »-1″><span class= » »>Cette table est utilisée pour stocker temporairement les URL détectées lors d’une analyse avant de les vérifier via la liste des URL malveillantes connus et des URL de phishing de Google Safe Browsing (GSB).</span> <span class= » »>Ceci est utilisé lors d’un scan et dans d’autres endroits, nous vérifions les choses contre le GSB.</span> <span class= » »>Je me demande si le problème de Google avec les raccourcis url comme bit.ly aurait quelque chose à voir avec ça.</span></span>
Donc là c’est un truc qui est lié à la vérification des url des nombreuses pubs implantées dans le site et le tracking.
La commande SQL pour vider cette table est la suivante (à saisir dans l’onglet SQL) :
Il existe une extension pour Wordfence (WF Assistant) qui permet de vider les données ou une partie des données, malheureusement rien pour la table wp_wfHoover. J’ai indiqué au support ce manque crucial face à ce problème.
Ouh la déjà 250 mo…
On va se retrouver avec un problème identique au précédent 🙂
Comme quoi le problème existe bel et bien… c’est assez insensé que Wordfence qui est tout de même une référence n’ait pas prévu un vidage automatique programmable …
La vider avec phpmyadmin (vider) est correct ou une erreur.
À cet instant elle est à 135mo donc cela veut dire qu’elle varie «toute seule»
Mais d’après les témoignages que j’avais pu lire (et ma malheureuse expérience) elle peut monter rapidement en «température» et comme OVH met 24h avant de débloquer la situation une fois la base explosée par cette table puis vidée manuellement c’est plutôt embêtant…
S’il faut la surveiller comme le lait sur le feu autant se passer de Wordfence et trouver autre chose.
Reste à savoir si d’autres utilisateurs ont déjà rencontré ce soucis et comment ils l’auraient réglé…
Il me semble curieux que je sois le seul à être confronté au problème alors qu’il n’y a rien de particulièrement exotique dans mon WordPress
Je ne suis pas assez connaisseur pour savoir si on ne pourrait pas programmer une règle de vidage auto dans le cas ou Wordfence n’aurait pas déjà prévu ce réglage et que nous l’ignorerions…
Et encore merci
Bon, je trouve au fur est à mesure de l’info sur cette table, en fait les données stockées doivent être supprimées à chaque scan de WordFence (truncate), il semble que le problème survient à cause de droits insuffisants de l’admin SQL :
Cette table est effacée après chaque numérisation. Elle est également effacée si vous annulez une numérisation. Il doit y avoir quelque chose de spécifique à votre système qui empêche cela.
L’utilisateur de la base de données que votre installation WordPress manque-t-il de privilèges à effacer ?Il faut donc voir ça du côté d’OVH, les sites que je supervise ne rencontrent pas ce souci, ton installation chaotique doit sans doute générer ça avec l’ancienne base qui était sur 18 mobiles.
Je vais tester quelque chose car on a gardé les tables WF de ta configuration précédente, je vais tout supprimer et réinstaller WF, car maintenant on est sur ton hébergement. Je te tient au courant.
Qu’il y ait un automatisme d’effacement parait effectivement plus normal…
Ok d’ac bien possible qu’une scorie soit demeurée dans les anciennes tables
316298 files indexed… quand même. Il y a ton site statique dedans, ça pèse un peu.
En tout 7.23 GB of data à analyser… une paille.
Voici les 3 tables qui grossisses sur WordFence :
wp_wfFileMods = 48 Mo
wp_wfHoover = 185 Mo
wp_wfKnownFileList = 29 MoJe viens killer le scan et la table wp_wfHoover c’est vidée, donc ça semble bon.
J’ai désactivé le scan global de l’hébergement, tu as trop de choses annexes à WP et c’est du statique donc moins dangereux, ça va alléger le travail de WF et faire maigrir ces tables au final.
A surveiller demain dans la journée.
Ça roule, ce matin avec un scan de seulement l’espace WP :
wp_wfFileMods = 1 Mo
wp_wfHoover = 34 Mo
wp_wfKnownFileList = 630 KoBravo Momo,
@Nico J’ai cru comprendre que WP Rocket était installé sur votre site et si c’est bien la cas, cette extension intègre une application fort utile de nettoyage et d’optimisation de la base de données, alors pensez à la paramétrer 😉Perso, je programme un nettoyage et une optimisation hebdomadaires.
Oui il y a une option d’optimisation de la base de données dans WPRocket, ici c’est un problème de droits user SQL hérités de l’installation précédente sur une autre serveur SQL qui bloquait l’effacement de données sur wp_wfHoover. Le fait de scanner tout l’hébergement n’arrangeait pas les choses avec plus de 7 Go de données en tout.
Une réactivation de l’extension après suppression des données (à la désactivation) tout st rentré dans l’ordre, notez que vous pouvez sauvegarder la configuration WF et l’importer pour retrouver tous vos réglages, très pratique.
Maintenant WordFence fait son travail sans prendre d’embonpoint notable. 🙂
Désactivation (en cochant l’option effacement) puis activation c’est ce qui est préconisé un peu partout et c’est ce que je faisais précédemment jusqu’au blocage total par OVH (ce qui n’avait jamais été le cas auparavant)
Là on est toujours à 34mo donc cela semble stable… on croise les doigts 🙂
Précédemment tu faisais ça sur SQL 18Mobiles et les droits étaient sans doute restreints (offre basique oblige).
C’est bon nico239, les scans sont effectué toutes les heures, donc là comme tu peux le voir les données sont bien supprimées chaque fois.
Bonjour,
J’ai exactement le même problème. La table wfhoover arrive à 800 Mo . Est ce que c’est un réglage au niveau de Wordfence à effectuer ? Sinon j’ai vu qu’il fallait <span class= »tlid-translation translation » lang= »fr »><span class= » » title= » »>vérifier que l’utilisateur de la base de données dispose de toutes les autorisations. Comment on fait? Merci </span></span>
- Vous devez être connecté pour répondre à ce sujet.