- Statut : non résolu
- Ce sujet contient 5 réponses, 2 participants et a été mis à jour pour la dernière fois par
, le il y a 9 années et 7 mois.
-
Messages
-
Bonjour,
Ma configuration WP actuelle
– Version de WordPress : 3.4.2.
– Version de PHP/MySQL : OVH-perso
– Thème utilisé : SimpleCorp 2.1.1
– Extensions en place : Better WordPress Minify, Hyper Cache Extended, Smooth Slider, Use Google Libraries,Widget Context
– Nom de l’hebergeur : OVH perso
– Adresse du site :
Problème(s) rencontré(s) : La base SQL a été bloquée >200Mo, les statistiques montrent une très forte activité SQL entre les 28 et le 30 avril 2015.
Site et boutique réalisés par un stagiaire il y a trois ans pour une association.Nettoyage efficace de la table wp_options à l’aide de :
DELETE FROM `wp_options` WHERE `option_name` LIKE (‘_transient_%’);Retour à la normale apparente après 24h, vérification de la boutique en cours par les habitués.
Quels sont les risques de faire les mises à jours, et mes chances de ne pas bloquer la boutique trop longtemps ?
Merci,
RichardQuels sont les risques de faire les mises à jours, et mes chances de ne pas bloquer la boutique trop longtemps ?
Dans cette configuration, il y a des risques de piratage c’est pas mieux.
Comme il faut passer de 3.4 à 4.2, la mise à jour automatique risque de planter… Il y a trop de versions majeur d’un coup, cela implique donc des mises à jour manuelles et par étape, ce qui est forcément plus long.
Il faudrait aussi savoir la version de PHP, si elle n’a pas évolué depuis 3 ans, il est aussi nécessaire de faire la mise à jour, comment est faite la boutique et ses liens avec WordPress, si le thème a été modifié ou pas pour pouvoir répondre à la question.
De plus le thème n’est plus mis à jour depuis plus de 2 ans, il y a donc un risque d’incompatibilité avec des versions récentes de WordPress qui vient s’ajouter.La base SQL a été bloquée >200Mo, les statistiques montrent une très forte activité SQL entre les 28 et le 30 avril 2015.
Tu devrais investiguer sur ce problème… Si effectivement cela s’est fait en quelque jours, ce n’est pas normal.
La base SQL a été bloquée >200Mo, les statistiques montrent une très forte activité SQL entre les 28 et le 30 avril 2015.
Tu devrais investiguer sur ce problème… Si effectivement cela s’est fait en quelque jours, ce n’est pas normal.
C’est sur trois ans sans surveillance, je vais vérifier chaque semaine.
En fait tu parlais d' »une très forte activité SQL entre les 28 et le 30 avril 2015″ j’ai fait un raccourci un peu rapide. 😉
3 ans avec les spams, les révisions c’est moins surprenant mais avec les « transient » cela me paraît quand même beaucoup.
Il faudrait aussi savoir la version de PHP, si elle n’a pas évolué depuis 3 ans, il est aussi nécessaire de faire
J’ai trouvé ça dans htaccess
SetEnv PHP_VER 5et ça chez OVH :
« Comment activer PHP-FPM ?
Il vous suffit de déposer le fichier .ovhconfig à la racine de votre espace disque, via http://FTP. »Si je devais commencer l’évolution pour une mise à jour ?
Je comprend que je peux commencer par dupliquer le site chez OVH dans un dossier bis et travailler sur ce dossier fantôme après avoir fait un dump de la base SQL en cas d’accident.
Faut-il aussi dupliquer les tables de la base avec un autre préfixe pour que le fantôme travaille sur une base fantôme ?Il vous suffit de déposer le fichier .ovhconfig à la racine de votre espace disque, via http://FTP. »
Apparemment OVH change la façon de configurer les environnements et met en place progressivement sur toutes ses offres vers un fichier .ovhconfig pour remplacer les instructions présentes dans les fichiers .htaccess. Les versions de PHP actuellement supportées sont 5.4, 5.5 et 5.6. Là aussi pour éviter des incompatibilités (notamment avec les thèmes et extensions mieux vaut tester en 5.4 avant de tenter 5.5 voir 5.6).
Je comprend que je peux commencer par dupliquer le site chez OVH dans un dossier bis et travailler sur ce dossier fantôme après avoir fait un dump de la base SQL en cas d’accident.
C’est faisable sans dupliquer les sites par contre, dans tous les cas, il est important de faire une sauvegarde des fichiers (par FTP) et de la base de données (par phpMyAdmin) en cas de problème, OVH a aussi un système de restauration de son espace web en cas de gros pépin.
Après, il peut y avoir un intérêt de travailler sur une version de développement (« fantôme ») c’est de ne pas interrompre le fonctionnement du site de production sans avoir de pression pour remettre rapidement le site en route, mais c’est plus lourd à gérer.
Il faudra en effet dupliquer la base avec un autre préfixe pour éviter d’écraser les données (sans dépasser le quota) dupliquer les scripts, puis une fois les mises à jour et les ajustements terminées et il faudra mettre le site de développement à la place du site en production ce qui nécessitera de modifier les URLs dans la base de données.
- Vous devez être connecté pour répondre à ce sujet.