- WordPress :6.0
- Statut : non résolu
- Ce sujet contient 14 réponses, 4 participants et a été mis à jour pour la dernière fois par
, le il y a 1 année et 11 mois.
-
Messages
-
Bonjour,
Ma configuration WP actuelle
- Version de PHP/MySQL :
- Thème utilisé :
- Extensions en place : woocommerce principalement
- Nom de l’hébergeur : infomaniak
- Adresse du site : https://www.artisanathai.com/ vers https://artisansta.com/
Problème(s) rencontré(s) :
vue que mon sujet précédent https://wpfr.net/support/sujet/site-malade-a-revoir-en-entier/
n’inspire personne je vais le poser d’une autre manière :
j’ai des bases en bon état avant les problèmes rencontrés depuis 2 semaines,
si j’en charge une sur un autre site vierge est-ce que tout ce que contenait le site du temps de sa santé vient se charger sur ce nouveau, et qu’en est-il des images… ?
merci
Bonjour,
Chez infomaniak pourquoi ne restaurez-vous pas une sauvegarde de site (base de donnés + dossiers du site) datant de plus de deux semaines? Si c’est possible ce serait le mieux.
Autrement:
si j’en charge une sur un autre site vierge est-ce que tout ce que contenait le site du temps de sa santé vient se charger sur ce nouveau?
Oui, pour les posts au sens large: pages, articles, menus, liens des images .
Pour les images, elles sont dans le dossier content/uploads.
Donc pour reconstruire votre site, il vous faut la base de données (d’il y a quinze jours, donc) + le dossier wp-content qui contient les thèmes, les plugins et surtout les images dans le dossier « uploads ».
Bien entendu, tout ce qui a été ajouté depuis 15 jours sera perdu.
Vous avez un site local. Vous ne conservez pas de sauvegardes locales?
Vous ne conservez pas de sauvegardes locales?
J’ai tout les fichiers en local, mais je ne peux plus faire de sauvegarde avec un plugin : c’est devenu trop lourd il ne charge pas . Par contre j’ai les sauvegardes automatiques qui datent toujours de quelques jours sur infomaniak
Donc les « vieilles » sauvegardes de base que j’ai c’était « avant » !
mon idée est la suivante : avoir les mêmes plugins sur un nouveau site, charger cette ancienne base, faire des sortes de copier de tout le nouveau (en particulier les commandes et les nouveaux produits… puis tout supprimer sur mon « vrai » site et tout réinjecter à l’aide de la nouvelle base, il peut y avoir un problème avec les liens ?
qu’en pensez-vous ?
parce que j’ai essayé différents plugins de transfert aucun (gratuit) ne fait bien le boulot ; ce n’est qu’avec Woocommerce qu’on peut tout transferrer correctement…
avoir les mêmes plugins sur un nouveau site, charger cette ancienne base, faire des sortes de copier de tout le nouveau (en particulier les commandes et les nouveaux produits…
Je pense que ce serait compliqué , le problème étant woocommerce qui crée de nombreuses tables tout en utilisant celles de wordpress. Je ne m’y risquerais pas en tout cas pas sur le vrai site et pas à partir de la base de données.
J’essaierais d’abord de nettoyer la base de données. Il y a des plugins pour ça et il y a des choses qu’on peut faire manuellement . Quelle est la taille de la base de données (et quelle est la taille maximum autorisée par l’hébergeur?) Quelle est la taille (ou les tailles) des plus grosses tables? Y-a-t’il des tables spéciales créées par post smtp ? (si oui, vous pouvez les supprimer).
parce que j’ai essayé différents plugins de transfert aucun (gratuit) ne fait bien le boulot
Si vous devez tester votre idée, il faut le faire en local . Comme vous avez filezilla, vous savez déjà comment transférer les dossiers . Pour la base de données il suffit de l’exporter (mais vous le saviez peut-être déjà). Avec ça vous pourrez vous créer une copie locale du site et là vous pourrez tout essayer sans risque. Pour ce genre de travail, il vaut mieux travailler sans plugin de sauvegarde.
Mais ce ne sera peut-être pas nécessaire. (je l’espère pour vous). 🙂
Pour les bases j’ai wp-optimize payant.
la table (d’après lui) est de 783.94 MB
je la nettoie régulièrement, à l’aide de cet excellent plugin.
parmi les 65 bases l’énorme est de 686.55 MB pour postmeta.
auparavant, d’après mes sauvegardes, le 19/09 le total en .gz est de 320 Mo
donc je vous raconte l’origine du problème : j’avais donc « post smtp ». J’envoie une newsletter, j’oublie de supprimer en temps les mails qui se sont enregistré sur ce plugin en double de newsletter (payant), ce que je faisais toujours auparavant, quand je m’en aperçois il est trop tard… et mon site etc.
pas de transient remarquable depuis…
en fait vous posez la bonne question : il faudrait supprimer tout le « en trop » dans postmeta… il faudrait que je m’y penche, quels sont les risques, qu’est-ce qui s’enregistre aussi dans cette base ??
(je crois que c’est ça la solution…)
Bonjour,
vue que mon sujet précédent(…) n’inspire personne je vais le poser d’une autre manière
Votre sujet n’a pas reçu de réponse en quelques heures, c’est tout à fait normal : ce forum est composé de bénévoles, et tous ne sont pas disponibles et au taquet pour vous répondre !
Par contre, les règles du forum demandent de ne pas ouvrir 2 sujet pour la même demande (ou presque) : @ferman ayant commencé à vous répondre ici, je clôture l’autre sujet.
Et pour vous répondre : si vous n’avez plus besoin de l’extension Post Smtp, supprimez-la simplement, puisque vous avez déjà fait cette manip’ :
j’ai donc supprimer les dossiers tant Include que admin et recharger d’après la dernière version de WP (qui est toujours à jour) c’est ainsi que j’ai retrouvé mon site, et bien sur supprimer l’extension en cause
(…)
Finalement j’ai découvert que je n’ai pas besoin d’extension smtpexcusez-moi, je sais tout ce que vous me dites… (sur WP depuis 2005) j’ai un sale caractère de plus j’ai bientôt 81 ans… alors pardonnez moi.
à Flobogo : ça fait un bail que j’ai supprimé cet extension et c’est là que l’histoire commence … soit vous suivez soit… ne prenez pas l’histoire en cours sans avoir lu ce dont il s’agit !
j’ai un sale caractère
C’est bien d’annoncer la couleur…
de plus j’ai bientôt 81 ans
…attention: ce ne sera pas considéré comme une excuse valable; il y a plein de nonagénaires sur le forum alors…:)
La table post_meta est embêtante à nettoyer: elle contient tellement de choses variées, en particulier plein de données en relation avec woocommerce . C’est un vrai fourre-tout. Pourriez-vous tester l’extension wp-sweep pour voir si vous gagnez quelque chose?
Dans php_myadmin essayez de voir (à peu près car vous devez avoir énormément de pages dans cette table) les meta_keys qui reviennent le plus souvent et qui pourraient donc être responsables de l’augmentation de l’embonpoint de la table. Quelle est la taille des tables alp_actionscheduler_actions et alp_actionscheduler_logs?
quelques mots en cours…
comme promis c’est l’enfer cette table (je me suis même relevée cette nuit, obsédée) :
- seopress
- produits : images, variations
- des factures de vente
- articles
- « woosea » dont je n’avais jamais entendu parlé qui fait de tout (brand, gender, size…)
- les menus
- les smush (alors qu’en fait je m’en sers jamais puisque je compresse « à domicile » « This image is marked as already compressed by another tool »
elle contient 127123 lignes
qui ne se chargent pas sur myphp s’arrêtant vers 8000
c’était pour vous donner quelques infos du suivi,
je vous dirai quand je suis arrivée au bout
- Cependant je ne sais comment utiliser « la » ligne de Lumière de Lune,
il y a les lignes (
meta_id,post_id,meta_key,meta_value)finalement je me décide à chercher par le titre de la dernière newsletter qui est la cause de tout… et je trouve
solution’, ‘All good, mail sent.’),
(2333205, 385023, ‘success’, ‘1’),
(2333206, 385023, ‘from_header’, ‘"Annie Stasse" <stasse.annie@,,,,.fr>’),
(2333207, 385023, ‘to_header’, ‘c,,,@,,,.com’),
(2333208, 385023, ‘reply_to_header’, ‘a,,,@,,,.com’),
(2333209, 385023, ‘transport_uri’, ‘smtp:tls:plain://smtp.orange.fr:587’),
(2333210, 385023, ‘original_to’, ‘c,,,@,,,,,.com’),
(2333211, 385023, ‘original_subject’, ‘Code Promo sur un grand choix de produits’)ponctué ici et là que je vais détruire
NB – le plugin wp-sweep a nettoyé un peu…
à suivre… et merci pour vos aides
une fois ce premier nettoyage peu de gain : 150 Mo
par contre je découvre toutes les lignes m’informant du bug :
Pour utiliser la ligne de Lumière de Lune vous sélectionnez la table wp_postmeta (votre préfixe est peut-être différent de wp) . Vous cliquez sur l’onglet SQL et copiez/collez la ligne dans cette fenêtre. Attention: on copie classiquement avec la souris mais pour coller la souris ne fonctionne pas, il faut faire « ctrl V ». Voir pièce jointe 1 pour le résultat.
Je vous passe une version modifiée du code de Lumière de Lune (auquel je n’avais pas pensé). A copier/coller dans les mêmes conditions. Il vous donne en plus le type de post correspondant aux métas trouvés (ça pourra être utile). Il permet aussi de sélectionner à partir d’une valeur (dans la pj 2, > 500). Cela vous permet de limiter le nombre de résultats aux plus importants. Dans votre cas ce sera sans doute nettement plus de 500. Vous pouvez augmenter à volonté, essayez puis augmenter à nouveau…etc jusqu’à n’avoir que les nombres les plus grands.
A la fin vous devriez savoir quels métas sont les plus fréquents, et à quel type de post ils correspondent. Et là on verra si ce type de post (et les métas associés ) peut être supprimé.
Vous savezque dans PHPMYADMIN vous pouvez trier selon la colonne que vous voulez, valeurs croissantes ou décroissantes. Enfin, avecle type de requête utilisé (« SELECT ») vous ne pouvez pas avoir de problème. Aucune fausse manœuvre fatale n’est à craindre.
- Vous devez être connecté pour répondre à ce sujet.