WordPress: sauvegarde et restauration sur un autre serveur

réparationLorsque mon site a été attaqué par des robots de commentaires-spam (cela ressemble à de la science-fiction, hein?) Cette semaine, j'ai été obligé de redémarrer mon serveur plusieurs fois avant de contrecarrer l'attaque. Je pense en fait que j'ai en quelque sorte corrompu la base de données ou un fichier dans WordPress car après l'événement, le site ne durerait pas plus de quelques heures environ sans tomber en panne.

J'ai profité de l'occasion pour déplacer mon site vers un nouveau compte sur mon compte revendeur à Jumpline.comimage 2260935 1169332. J'ai été extatique avec Jumpline au fil des ans. J'héberge une trentaine de sites Web et je ne reçois presque jamais d'appel des clients qui hébergent avec moi (sauf s'ils ont besoin d'aide). Le service est remarquable et leur équipe d'assistance est fantastique.

Leurs techniciens de support étaient en fait les gars qui ont identifié que c'étaient des spams qui tuaient mon site (merci!). Le passage au nouveau compte met maintenant ce site sur la dernière version de PHP / MySQL et dispose d'une application Ajax Webmail vraiment sympa.

Ce que je n'ai pas réalisé, c'est à quel point c'était une douleur incroyable d'essayer de faire un plus propre, installation de WordPress. De nombreux plugins ajoutent des champs et des tables à votre base de données WordPress. J'évalue constamment avec des plugins, donc ma base de données était un désastre. Exécuter une sauvegarde de WordPress ou de base de données et la restaurer sur le nouveau compte allait probablement simplement déplacer les problèmes avec elle. Au minimum, cela allait y jeter un tas de champs et de tables supplémentaires. J'aimerais voir les futures versions de WordPress mandater les modifications de la base de données lors de la désactivation d'un plugin afin que les déchets ne soient pas laissés pour compte.

J'ai même regardé quelques plugins supplémentaires qui généreraient votre blog WordPress au format XML pour une réimportation, mais vous perdez alors beaucoup de données. Douze heures plus tard (j'ai dormi) et je pense que j'ai en fait terminé le déplacement du compte et de toutes les données applicables. C'était un peu un cauchemar, mais voici ce que j'ai fait:

  1. Sauvegardé du site et de la base de données d'origine.
  2. WordPress installé à partir de zéro sur le nouveau compte.
  3. Installation des derniers plugins WordPress à partir de zéro sur le nouveau compte.
  4. Définissez toutes les options du plugin et les paramètres du site.
  5. A fait une comparaison de table de chaque table de la base de données source et de la base de données de destination.
  6. Suppression de tous les champs de la base de données source qui n'existaient pas dans la base de données de destination.
  7. Vider toutes les tables de la base de données de destination (vous débarrasser des messages de test WP standard.
  8. A fait une exportation de chaque table sans compromis. déposer et recréer. Cela écrira les enregistrements dans la nouvelle base de données avec les mêmes clés afin qu'aucune des relations ne soit rompue.
  9. Copié mon dossier wp-content \ upload du compte source vers le compte de destination. Depuis que j'ai également déplacé le nom de domaine, toutes les références d'image ont été conservées.
  10. J'ai dirigé le blog et l'ai testé! J'ai dû nettoyer certains permaliens de page, je ne sais pas pourquoi, mais ils allaient bien après.

Il est intéressant de noter que WordPress a des importations intégrées pour les plates-formes de blogs compétitives, mais aucune importation pour exécuter une importation WordPress vers WordPress qui ne tiendra pas compte des modifications du plugin.

Cela l'a fait à peu près. Vous remarquerez peut-être que je lance un nouveau thème. J'avais simplement trop de petits problèmes avec le thème bêta que j'utilisais. J'ai fait une personnalisation approfondie de ce thème mais je pense que je l'ai presque là où je le veux.

Mon seul reproche concernant le thème est que le auteur n'a pas implémenté de pied de page commun dans tout le thème qui résidait au-dessus de la balise bottom> body>, j'ai donc dû saisir manuellement mon script Google Analytics tout au long. J'aurais pu créer un pied de page personnalisé et y faire référence, mais je pense que plus tard, j'aurais été confus puisque l'auteur du thème a utilisé le nom de «pied de page» sur tout. C'est un très beau thème, cependant!

Je suppose que je suis de retour maintenant! Maintenant, je dois me mettre au travail!

3 Commentaires

  1. 1
  2. 2

    Juste une pensée…
    I always test back up and restore solutions, your post got my attention.
    Using the built in export and import built in to 2.1 , was a dream. I did have a problem with the displayed graphics.
    I’m about to wipe out and re-start the test blog, but this time I’ll edit the XML file to reflect the new location of the pictures.

  3. 3

    I too had the fine experience of rebuilding my WordPress site from the ground up. All went pretty well as I was sure to backup everything via multiple means.

    The main problems I ran into were my category post assignments were lost due to importing via the XML file. Plus, a few posts weren’t fully restored. It seems like it was due to some problems with the use of single quotes in paragraphs. For some reason, the backup file didn’t properly escape the quotes and WordPress thought it had come to the end of a post.

    Oh well, it took some time but I was able to pull this info from the .SQL file I backed up before deleting the database.

    Thanks for sharing your experiences.

Que pensez-vous?

Ce site utilise Akismet pour réduire les spams. Découvrez comment sont traitées les données de vos commentaires..