Nous exploitons plusieurs sites de sous-domaines dans un environnement WordPress multisite et souhaitons faire basculer le site principal de la racine vers un sous-domaine, comme suit:
Le site actuel est example.com
avec ID 1
(impossible de renommer car le champ est défini et non modifiable)
Le nouveau site est new.example.com
avec ID 15
(essayé de renommer en example.com
)
J'ai suivi certaines instructions pour changer qui impliquait de renommer les sites et de mettre à jour le fichier wp-config.php
pour donner le nouvel ID de 15 pour le SITE_ID_CURRENT_SITE
et le Blog_ID_CURRENT_SITE
. Le résultat est que le site principal n'a pas changé et que l'administrateur s'est fait avoir.
Existe-t-il un moyen simple de basculer le site principal vers l'extérieur et de le remplacer par le contenu du site de sous-domaine sans importer les publications/pages et les plug-ins?
METTRE À JOUR:
Merci de donner ces conseils. Ma conclusion avec ce que j'ai vu dans la base de données, lu et obtenu de votre part, est que le nouveau site de sous-domaine remplaçant le site principal doit avoir les noms de table de base et l'ID de 1, les chemins d'accès mis à jour, etc. Mon seul souci est que après la commutation, l'administrateur réseau aura un problème - il me faut donc fondamentalement comparer les tables de base (wp_options, etc.) à leurs équivalents (wp_x_options, etc.) pour voir s'il existe quelque chose d'unique concernant l'administrateur réseau dans ces tables.
Quatre ans et pas de réponse? Alors on y va ... -
Prenons comme exemple la configuration réseau suivante (j'utilise la commande de la liste de sites de WP-CLI ):
$ wp site list
+---------+--------------------+---------------------+---------------------+
| blog_id | url | last_updated | registered |
+---------+--------------------+---------------------+---------------------+
| 1 | http://wp.tmp/ | 2016-08-04 08:39:35 | 2016-07-22 09:25:42 |
| 2 | http://foo.wp.tmp/ | 2016-07-22 09:28:16 | 2016-07-22 09:28:16 |
+---------+--------------------+---------------------+---------------------+
La liste de sites réseau ressemblerait à ceci:
Nous voulons utiliser le site avec l'ID 2
comme nouveau site racine avec l'URL http://wp.tmp/
. En réalité, il s’agit du même problème que celui décrit dans la question, mais avec quelques autres valeurs pour l’ID et les URL.
La partie pertinente multisite du wp-config.php
ressemble probablement à ceci:
const MULTISITE = TRUE;
const DOMAIN_CURRENT_SITE = 'wp.tmp';
const PATH_CURRENT_SITE = '/';
const SITE_ID_CURRENT_SITE = 1;
const BLOG_ID_CURRENT_SITE = 1;
const SUBDOMAIN_INSTALL = TRUE;
WordPress utilise les tables wp_*_option
et wp_blogs
pour trouver le blog correspondant à une URL de demande donnée et pour créer les liens permanents appropriés pour ce blog. Nous devons donc modifier les valeurs dans les trois tableaux suivants (pour cet exemple):
wp_options
les clés home
et siteurl
wp_2_options
les clés home
et siteurl
(dans votre cas, ce serait wp_15_options
)wp_blogs
la colonne domain
pour les deux sites avec l'ID 1
et 2
(respectivement 15
)J'utilise Adminer pour cela, mais tout autre outil de gestion de base de données (PhpMyAdmin) fait également l'affaire. (Les captures d'écran montrent l'interface graphique en allemand mais je suppose que l'idée est claire.)
Dans wp_options
(la table d'options pour l'ID de site 1
), je modifie les valeurs des deux clés home
et siteurl
de http://wp.tmp
à http://foo.tmp
. (La capture d'écran ci-dessus montre l'état avant la mise à jour.)
Je fais exactement la même chose avec la table wp_2_options
mais ici je change la valeur de http://foo.wp.tmp
à http://wp.tmp
.
La prochaine étape consiste à mettre à jour la table wp_blogs
:
(Encore une fois, la capture d'écran montre le tableau avant que je modifie.) Ici, il vous suffit de changer les valeurs des deux sites dans la colonne domain
:
wp.tmp
devient foo.wp.tmp
etfoo.wp.tmp
devient wp.tmp
Maintenant, vous devez mettre à jour le wp-config.php
pour traiter correctement les nouvelles données de paramètres:
const MULTISITE = TRUE;
const DOMAIN_CURRENT_SITE = 'wp.tmp';
const PATH_CURRENT_SITE = '/';
const SITE_ID_CURRENT_SITE = 1;
const BLOG_ID_CURRENT_SITE = 2; // This is the new root site ID
const SUBDOMAIN_INSTALL = TRUE;
À ce stade, vous avez à nouveau un site WordPress multisite fonctionnel, mais avec un nouveau site racine:
$ wp site list
+---------+--------------------+---------------------+---------------------+
| blog_id | url | last_updated | registered |
+---------+--------------------+---------------------+---------------------+
| 1 | http://foo.wp.tmp/ | 2016-08-04 08:39:35 | 2016-07-22 09:25:42 |
| 2 | http://wp.tmp/ | 2016-07-22 09:28:16 | 2016-07-22 09:28:16 |
+---------+--------------------+---------------------+---------------------+
Rappelez-vous: pendant ce processus, votre site ne sera pas disponible et les demandes engendreront de vilaines erreurs. Vous voudrez peut-être organiser une réponse 503 Service Unavailable
devant votre installation WordPress. Cela pourrait être fait en utilisant .htaccess
.
Maintenant vient la partie la plus délicate. Pour le moment, toutes les URL dans les tables de contenu pointent toujours sur les ressources des anciens sites. Mais les remplacer n'est pas si facile: remplacer chaque http://foo.wp.tmp
par http://wp.tmp
dans la première étape et chaque http://wp.tmp
par http://foo.wp.tmp
à l'étape suivante aura pour résultat que toutes les anciennes URL pointant vers l'ID de site 1 (http://foo.wp.tmp
).
Le meilleur moyen serait d'insérer une étape intermédiaire:
http://foo.wp.tmp
et remplacez-le par un slug de préférence unique: http://3a4b522a.wp.tmp
http://wp.tmp
et remplacez-le par http://foo.wp.tmp
http://3a4b522a.wp.tmp
et remplacez-le par http://wp.tmp
Toutes ces commandes de recherche et de remplacement doivent ignorer les trois tables (*_options
*_blogs
) déjà mises à jour, sinon elles casseraient la configuration. Vous pouvez également effectuer une recherche manuelle des URL dans la table wp_*_options
en dehors des clés home
et siteurl
.
Je suggérerais d'utiliser la commande search-replace de WP-CLI pour cela, car elle peut traiter des données sérialisées et n'a aucune limitation que HTTP pourrait avoir.
Une alternative plus simple (qui ne concerne aucune ligne de code) consiste à utiliser le plug-in tout-en-un-migration :
new.example.com
avec ID 15
etexample.com
avec ID 1