Pascal

Content pour vous Bonne journée également. Pascal

Bonjour, Un petit tuto ici C'est bien dans htdocs qu'il faut transférer le fichier installer.php Bien lire le chapitre sur la création de la base de données Si l'idée c'est d'avoir deux sites sur le même hébergement, vous devez avoir : var/www/ cpie61.fr/htdocs suissenormande.fr/htdocs Si je comprends bien, vous avez un nom de domaine avec les DNS qui pointent sur votre site hébergé en local. Pour accéder à votre espace sur yulpa, il faut faire pointer les DNS vers le répertoire suissenormande.fr chez Yulpa (ce n'est pas immédiat, temps de transfert des DNS). C'est surement pour cela que vous ne pouvez pas accéder au répertoire. Changement DNS : https://docs.yulpa.io/hosting-shared/configuration-dns-zones

Bonjour, Il est toujours conseillé d'effectuer une sauvegarde du site et de la base de données. https://docs.yulpa.io/hosting-shared/sauvegardes Autrement, je n'ai jamais eu de problème lors de la mise à jour de PHP. Attention tout de même à ne pas avoir de trop vieux plugins non maintenus à jour. Ce n'est déjà pas conseillé mais cela pourrait poser problème. En principe, si votre Wordpress est à jour, plugins et thèmes également, il ne devrait pas y avoir de soucis

Bonjour, Avec quel logiciel vous faites cela ? Un plugin Wordpress, un logiciel tiers ou maison ?

C'est dans Iwal. Hébergement - Publication web - Dépôt certificats SSL La liste des certificats s'afichent avec un onglet "supprimer" en bout de ligne

Idem que mdata

Et enfin, dernier test concernant la vitesse qui confirme mon impression d'attente de connexion

Je continue de chercher... Recherches concernant le SSL : L'activation de HTTP Keep-Alive permettra aux requêtes suivantes d'être traitées plus rapidement, sans qu'il soit nécessaire d'établir une nouvelle connexion SSL/TLS. La quantité de données échangées pour établir une session avec ce serveur est importante. Cela entraînera une connexion initiale plus lente. L'utilisation d'un certificat avec moins de chaînes intermédiaires et/ou une taille de clé publique plus petite peut réduire la quantité de données. Comme on peut le constater, il y a pas mal de temps entre la demande et l'affichage. Tests réalisés depuis plusieurs systèmes et à chaque fois, mêmes problèmes. https://gtmetrix.com/reduce-initial-server-response-time.html

Je viens de faire des test sur plusieurs de mes sites, en direct et en sous-domaines. La vitesse d'affichage est sensiblement la même, environ 8 secondes. www ou pas www, temps identique. Les 8 secondes, c'est le temps entre la demande et l'affichage. On a l'impression qu'il y a un temps d'attente entre ces deux moments, comme si il y avait un problème de redirection, ou recherche du site avant son affichage qui est très rapide par contre. C'est comme si on attendait une autorisation avant de lancer l'affichage. A noter, pendant ces 8 secondes, niveau SSL , le site est marqué comme non sécurisé jusqu'à l'affichage du site, là ça passe en sécurisé. Tous mes sites sont en SSL, il faudrait faire des tests sur des sites non SSL pour voir si ça vient de là, ou pas...

Peut être une piste pour nos problèmes actuels de lenteur ? Normalement, www ou pas, ça devrait fonctionner... Si c'est vraiment récent, il faut peut être attendre un peu mais si ça date un peu (plus d'une journée je pense), il vaut mieux ouvrir un ticket

Trop curieux pour en rester là Peut être une piste... Il existe une vulnérabilité dans Easy WP SMTP qui se trouve dans un fichier journal de débogage. Ce que font d'abord les "assaillants", c’est obtenir un nom d’utilisateur de niveau administrateur à partir du site WordPress qu’ils essaient de pirater en utilisant des méthodes largement connues. Ensuite, ils accèdent à la page de connexion WordPress et envoient une réinitialisation de mot de passe pour le compte administrateur. Enfin, ils accèdent au fichier journal de débogage et récupèrent un enregistrement du lien de réinitialisation du mot de passe envoyé par le site WordPress. Une fois qu’ils ont récupéré ce lien, ils peuvent le saisir, réinitialiser le mot de passe, puis profiter d’un accès complet au site WordPress. Cette faille de sécurité a été découverte décembre 2020 et corrigée dans la dernière version (celle que j'avais installé). Je ne connais pas "les méthodes largement connues"...

Mailpoet - Emails et newsletter Easy WP SMTP - Envoi mails par smtp

Analyse approfondie... Sur 6 sites, Il n'y en a qu'un seul (le dernier) dont les pseudos ont fuité. Sur 5 sites, suite à l'installation d'un plugin qui empêche l'accès à la page habituelle de connexion de Wordpress. Les attaques ont considérablement diminuées. Sur le 6ème site (celui concerné par la récupération des logins admins), désactivation de 2 plugins (pourtant à jour et réputés), blocage des IP par pays (c'est un site entièrement privé). Idem, attaques en baisse. Les 2 plugins désactivés n'étaient utilisés que sur le 6ème site, les 5 premiers sont construits sensiblement sur la même architecte au niveau des plugins. Je pense que "le vol" des logins venaient d'une faille dans un plugin. Grr...

Bin moi aussi ça m'interpelle... comment et en si peu de temps ? That is the question !!!

Ce ne sont pas les pseudos par défaut J'ai plusieurs sites, ils sont tous impactés. Tous, sauf le seul qui n'est pas sous wordpress. Après, vu la popularité de wordpress, c'est pas étonnant qu'ils essayent de rentrer par là. J'ai mis des restrictions pour réduire le nombre de tentatives...blocage d'IP pendant deux jours en cas de 2 tentatives de connexions. Le soucis, c'est qu'il faudrait que tout le monde le fasse sur le mutualisé, c'est pas gagné sachant pertinemment qu'il y a beaucoup de sites qui ne sont même pas mis à jour...