Restaurer une sauvegarde WordPress sans perdre les paramètres du thème

Restaurer une sauvegarde WordPress sans perdre les paramètres du thème

Restaurer une sauvegarde WordPress n’est pas compliqué. Cependant, si vous changez d’environnement, que vous restaurez la base MySQL avec une nouvelle URL, vous pouvez perdre tout le paramétrage de votre thème. Cela arrive fréquemment lorsque l’on utilise un thème enfant. 

Wordpress et le changement d'URL
Wordpress et le changement d'URL

Je restaure souvent des bases de données WordPress dans différents contextes. J’utilise beaucoup un environnement de test en local sous Windows. Par exemple, lors de la création d’un nouveau site WordPress  pour le migrer du test vers la production. Un autre cas de figure est restaurer une sauvegarde de la base de données WordPress pour tester les mises à jour de thème, de WordPress, voir d’une extension particulière avant de le faire en production.

Un pratique classique quand on travaille au niveau base de données consiste à faire un export de la base puis un import. Comme il y a changement d’URL, ce qui semble le plus logique consisterait à modifier celle-ci dans le script avant de l’importer par un simple chercher/remplacer. Remplacer par exemple https://sitetestNG.com par https://localhost/sitetest.

Souvent, lorsque l’on fait cette manipulation, pourtant simple et rapide, on perd le paramétrage du thème. Cela dépend des thèmes et aussi si on utilise la technologie thème parent et thème enfant. Dans ce dernier cas, l’extension Customizer Export/Import qui permet d’exporter les paramètres d’un thème et de les importer ne fonctionne pas.

Pourquoi les paramètres du thème WordPress sont perdus si on restaure la base avec une URL différente de celle d’origine ?

Dans la base de données WordPress, la table wp_options contient les valeurs de différents paramètres et en général vous trouvez dans la valeur theme_mods_{theme-name} le paramétrage du  thème.

Vous pouvez passer avec phpmyadmin la requête SELECT * FROM ‘wp_options’ WHERE ‘option_name` like ‘theme_mods%’ 

Elle renvoie un résultat de ce type :

Wordpress - Base MySQL - Paramètre du thème
Wordpress - Base MySQL - Paramètre du thème

Dans le cas de figure ci-dessus, 3 lignes :

  • Le paramétrage du thème Spacious
  • Le paramétrage du thème enfant Spacious Child
  • Le paramétrage d’un thème de base WordPress Twenty Twenty

Lors d’une restauration, avec modification d’URL par script, la ligne de Spacious Child, le thème actif, alors que c’est une ligne de parfois plus de 10000 caractères, est remplacée par 

a:1:{s:18: »custom_css_post_id »;i:-1;}

Une recherche internet m’a permis de comprendre d’où cela vient. Tout cela est expliqué dans l’article de stack overflow WP Customizer theme settings disapearing after wp database restore/migrate.

Pour résumé, WordPress encode les paramètres dans les chaines de caractères avec un code définissant type:longeur:valeur.

Dans si, dans la valeur, vous avez l’URL d’origine et que la nouvelle URL ne fait pas la même longueur, le paramètre est considéré comme invalide et remplacé par chaine de caractère standard. Puissant mais bien ennuyeux !

Comment restaurer la sauvegarde WordPress et garder le paramétrage du thème

Voici la méthode que j’utilise. Elle est simple mais pas toujours rapide:

  • Sauvegarde (exporter) de la base MySQL sur le site d’origine;
  • Restauration dans le nouvel environnement sans rien modifier dans la base;
  • Avec phpmyadmin, modifier dans wp_options les champs siteurl et home avec la nouvelle url, par exemple https://localhost/sitetest si vous travaillez en local;
  • Vous pouvez alors vous connecter avec la console wordpress sur le nouvel environnement;
  • Aller dans Réglages/Général : vous retrouvez dans Adresse Web de WordPress et Adresse Web du site la valeur https://localhost/sitetest

 

Wordpress - Paramètres des URL
Wordpress - Paramètres des URL
Data - MySQL et Wordpress - Un univers parfois complexe
Data - MySQL et Wordpress - Un univers parfois complexe

Finaliser le changement d’URL dans WordPress

Lorsque vous changer en base de données l’URL du site dans la table wp_options, cela a comme impact de pouvoir vous connecter à la console WordPress du site. Mais tous les objets où l’URL d’origine est déclarée ne sont pas impactés (menu, image, liens entre articles …)

Deux solutions sont alors possibles:

  • Vous remontez le site pour un test rapide, par exemple pour valider la mise à jour du thème, d’une extension. Dans ce cas, vous n’avez pas besoin d’un site de test 100% opérationnel.  Il suffit alors de modifier l’URL de l’adresse Web du site paramétrée dans WordPress. Par exemple, changer https://localhost/sitetest en http://localhost/sitetest et remettre immédiatement la bonne URL https://localhost/sitetest.
    Dans ce cas, de nombreux liens présents dans le site sont modifiés (menu, url des pages et articles …). Il peut cependant rester d’anciens liens du site d’origine (liens personnalisés dans le menu,  positionnés dans le texte d’article …)
    Mais, souvent le site fonctionne assez bien pour travailler dessus sans avoir besoin d’aller plus loin, pour un test de mise à jour, par exemple.
  • Vous remontez le site pour faire des tests approfondis. Voir vous migrez la base vers un environnement de production.
    Dans ce cas, j’utilise l’extension Better Search Replace
    Cette extension fonctionne bien, même si elle n’a pas été mise à jour depuis un an, un check de sécurité montre qu’il n’y a pas de problèmes pour celle-ci.
    Son gros défaut est la lenteur. Comme je maintiens un site en WordPress multisite avec près de 370 tables et 8 URL à changer, j’avoue que cela prend du temps. Cependant, pour un site plus petit, c’est extrêmement rapide.

 

Conclusion

Changer une URL dans un site WordPress n’est pas si simple.

Lorsque je travaillais sur des sites construits directement en PHP ou technologie Java, il n’y avait pas en base de données de cryptages, excepté pour les mots de passe, ni de contrôles de la cohérence des paramètres. Du coup, la méthode de modification par script était celle appliquée couramment en développement, pour corriger des bugs dans les programmes ou les bases, problèmes habituels.

La méthode proposée ci-dessus peut certainement être améliorée. Il est tout à fait possible que je refasse des recherches dans quelques temps pour la modifier. L’utilisation d’une extension pour faire un travail technique n’est pas une solution que j’apprécie particulièrement. 

N’hésitez pas à mettre en commentaire si vous avez une autre technique que je me ferais un plaisir de tester !

No Comments

Post A Comment