plow

Bonjour En effet, dans le menu du bas "retirer de la quarantaine" semble correspondre au "vider les spam" de l'ancien bouton... Spam-experts reste un très bon outil

Pas de réponse ? Dans les travaux, ça semble être résolu à 100% mais en réalité, ça ne l'est pas ☹️

Maintenant j'ai, moi aussi, le message d'erreur : domaine inconnu ! Mais la page des spams s'affiche quand-même. Et toujours impossible de vider les spams. Y-a-t-il du nouveau ?

Pas de message d'erreur pour moi, mais le bouton permettant de vider les spams est remplacé par un bouton "montrer les résultats" qui ne fait que rafraichir la page. Impossible de vider les spams qui vont donc s'accumuler ? Est-ce normal ?

Bonjour, Sur mon site, aussi bien en tant qu'admin qu'en tant que visiteur, avec firefox et chrome juste avant d'envoyer le message, vers 10h donc ; ça n'a heureusement, pas duré.

Message reçu pendant une bonne minute : La connexion avec le serveur a été réinitialisée pendant le chargement de la page. La page que vous essayez de consulter ne peut pas être affichée car l’authenticité des données reçues ne peut être vérifiée. Veuillez contacter les propriétaires du site web pour les informer de ce problème.

J'ai beau chercher, je ne trouve pas la section Utilisation des ressources Où se cache-t-elle ? ça y est j'ai trouvé mais même erreur côté fichiers

Ce sujet ayant été visionné de nombreuses fois, il vaut peut-être la peine de dire où j'en suis. J'ai ouvert un ticket qui n'a pas abouti et que j'ai donc clôturé. La seule solution que j'ai trouvée, ne souhaitant pas quitter yulpa, est de changer de programme de cache. Et effectivement, plus d'erreurs depuis. Mais les utilisateurs de Comet cache, en tout cas de Comet cache pro doivent savoir que la même erreur peut leur advenir ici

C'est à dire abaisser ce que le manager appelle le seuil de quarantaine, c'est ça ? Je vais tester

Depuis cette intervention, j'ai quelques spams évidents qui arrivent jusqu'à Zimbra... c'est dommage, car jusque là, c'était parfait

Bonjour et très bonne année Voici la réponse reçue sur le forum de Shark (Comet cache pro) : @plow Unfortunately this is a host-related issue. Some web hosting companies use file systems that cause problems with atomically reading, writing, and deleting files in the cache directory and when one of those problems occurs, and Comet Cache is unable to delete or rename files, you get this error. My recommendation is to either try a different web hosting company or work with your hosting company to see if they can resolve the issue. Je préfèrerais de loin la deuxième solution et vais donc relancer le ticket ouvert à ce sujet

Bonjour et merci pour la réponse Je vais interroger le développeur. Mais j'avoue que "race condition" et NFS ne veulent pas dire grand chose pour moi. L a fréquentation de mon site n'est pas si importante que ça et votre hypothèse m'étonne un peu. Comet cache est un plugin très répandu et il y a sûrement d'autres utilisateurs sur ce forum. Quelqu'un aurait-il déjà eu ce type de problème ?

Lorsque je veux vider le cache de mon site fncta-midipy.fr (cache créé par le plugin comet cache pro), j'ai régulièrement le message d'erreur joint. Ce message disparaît à la deuxième, troisième ou quatrième tentative et le cache se vide normalement. J'ajoute qu'il apparaît aléatoirement mais me semble lié à des problèmes de ralentissement du serveur pendant l'administration du site beaucoup plus fréquents qu'auparavant. J'ai ouvert un ticket mais pour l'instant mon problème reste entier. Quelle est cette "fatal error" et comment l'expliquer ? Est-ce que quelqu'un peut m'aider à comprendre ce message ?

En ce qui me concerne, je n'utilise pas Total Cache mais Comet Cache Pro qui est configuré pour ne pas utiliser le cache lors des accès administrateur. Et ça fonctionne sans problèmes. J'ai un minimum de plugins et pas question de s'en passer. Ceci dit, quand ça ne va pas, il faut le dire mais quand ça va bien, il faut le dire aussi. Et là, après les incidents d'hier, pour la première fois depuis un bon moment, le temps d'accès moyen utilisateur sur 24h à mes sites est repassé sous les 300 ms et j'ai longuement travaillé à l'admin sans ralentissements Bravo Yulpa, ça prouve bien qu'on peut le faire !

Désolé si ça n'était pas clair. La question principale est : comment expliquer que l'administration d'un site wordpress qui se faisait avec une rapidité et une réactivité tout à fait correcte puisse devenir inconfortable : temps de chargement des pages irrégulier, parfois très long, nécessité assez souvent de recharger les pages après changements, problèmes dans les mises à jour de plugin ... cela, alors que le site n'a connu aucun changement structurel notable. Ceci ne peut évidemment pas se prouver par des tests type doyoucheck ou Gtmetrix mais c'est ce que je constate Question supplémentaire : le passage au https peut-il être un élément d'explication au ralentissement, très relatif de 200/250ms dans le temps d'accès utilisateur (celui que mesurent les tests)