Cambio del sito principale in WordPress Multisite

12 lug 2016, 09:40:55
Visualizzazioni: 29.5K
Voti: 10

Stiamo gestendo diversi siti su sottodomini in un ambiente WordPress Multisite e vogliamo spostare il sito principale dalla root a un sottodominio in questo modo:

Il sito attuale è example.com con ID 1 (non può essere rinominato perché il campo è impostato e non modificabile)

Il nuovo sito è new.example.com con ID 15 (ho provato a rinominarlo in example.com)

Ho seguito alcune istruzioni per il cambio che prevedevano la ridenominazione dei siti e l'aggiornamento del file wp-config.php per assegnare il nuovo ID 15 a SITE_ID_CURRENT_SITE e Blog_ID_CURRENT_SITE. Il risultato è stato che il sito principale non è cambiato e l'area amministrativa si è danneggiata.

Esiste un modo diretto per sostituire il sito principale con il contenuto del sito in sottodominio senza dover importare post/pagine e plugin?


AGGIORNAMENTO:

Grazie per questi suggerimenti. La mia conclusione, basata su quanto ho visto nel database, letto e appreso da voi, è che il nuovo sito in sottodominio che deve sostituire il sito principale deve avere i nomi delle tabelle base e l'ID 1, con i percorsi aggiornati ecc. La mia unica preoccupazione è che dopo aver effettuato questi cambiamenti l'amministrazione della rete possa avere problemi -- quindi fondamentalmente devo confrontare le tabelle base (wp_options ecc) con quelle equivalenti (wp_x_options ecc) per verificare se ci sono elementi unici relativi all'amministrazione della rete in queste tabelle base.

2
Commenti

Per sicurezza, nel caso non fosse un errore di battitura sopra, dovrebbe essere in maiuscolo BLOG_ID_CURRENT_SITE, e penso che SITE_ID_CURRENT_SITE probabilmente debba rimanere 1 (per corrispondere alla tabella wp_site). Vedi il codice in wp-includes/ms-settings.php che usa queste costanti per impostare $current_site->blog_id - ovviamente hai bisogno che DOMAIN_CURRENT_SITE, PATH_CURRENT_SITE siano impostati ecc. Non so però se sistemare questo risolverà il problema. Non ho un multisite con sottodomini per verificare: potrebbero esserci anche percorsi in wp_X_options che dovresti modificare: potresti aver bisogno di fare debug dello stato errato per capire cosa non funziona.

Rup Rup
12 lug 2016 12:19:17
Tutte le risposte alla domanda 2
6
14

Quattro anni e nessuna risposta? Ecco qui la soluzione…-

Prendiamo come esempio la seguente configurazione di rete (sto usando il comando site list di 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 |
+---------+--------------------+---------------------+---------------------+

L'elenco dei siti della rete apparirebbe così:

elenco siti della rete

Vogliamo usare il sito con ID 2 come nuovo sito root con l'URL http://wp.tmp/. Questo è essenzialmente lo stesso problema descritto nella domanda, solo con valori diversi per ID e URL.

La parte relativa al multisite del file wp-config.php probabilmente appare così:

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;

Aggiornamento delle impostazioni del sito nel database

WordPress utilizza le tabelle wp_*_option e wp_blogs per trovare il blog corrispondente a un determinato URL richiesto e per costruire permalink corretti per questo blog. Dobbiamo quindi modificare i valori nelle seguenti tre tabelle (per questo esempio):

  • In wp_options le chiavi home e siteurl
  • In wp_2_options le chiavi home e siteurl (nel tuo caso sarebbe wp_15_options)
  • In wp_blogs la colonna domain per entrambi i siti con ID 1 e 2 (rispettivamente 15)

Sto usando Adminer per questo, ma qualsiasi altro strumento di gestione del database (PhpMyAdmin) va bene. (Gli screenshot mostrano l'interfaccia in tedesco ma credo che il concetto sia chiaro.)

adminer modifica wp_options

In wp_options (la tabella delle opzioni per il sito ID 1) ho cambiato i valori di entrambe le chiavi home e siteurl da http://wp.tmp a http://foo.wp.tmp. (Lo screenshot sopra mostra lo stato prima dell'aggiornamento.)

Ho fatto esattamente lo stesso con la tabella wp_2_options ma qui ho cambiato il valore da http://foo.wp.tmp a http://wp.tmp.

Il prossimo passo è aggiornare la tabella wp_blogs:

adminer modifica wp_blogs (Anche qui, lo screenshot mostra la tabella prima delle modifiche.) Qui devi semplicemente scambiare i valori di entrambi i siti nella colonna domain:

  • wp.tmp diventa foo.wp.tmp e
  • foo.wp.tmp diventa wp.tmp

Ora devi aggiornare il file wp-config.php per gestire correttamente i nuovi dati delle impostazioni:

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; // Questo è il nuovo ID del sito root
const SUBDOMAIN_INSTALL    = TRUE;

A questo punto hai di nuovo una rete WordPress multisite funzionante ma con un nuovo sito root:

$ 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 |
+---------+--------------------+---------------------+---------------------+

elenco siti della rete aggiornato

Ricorda: durante questo processo, il tuo sito non sarà disponibile e le richieste potrebbero terminare con errori, quindi potresti voler configurare una risposta 503 Service Unavailable davanti alla tua installazione WordPress. Questo può essere fatto usando .htaccess.

Aggiornamento del contenuto del database

Ora arriva la parte complicata. Al momento, tutti gli URL nelle tabelle dei contenuti puntano ancora alle risorse dei vecchi siti. Ma sostituirli non è così semplice: sostituire ogni http://foo.wp.tmp con http://wp.tmp nel primo passaggio e ogni http://wp.tmp con http://foo.wp.tmp nel passaggio successivo porterà a far sì che tutti i vecchi URL puntino al sito ID 1 (http://foo.wp.tmp).

Il modo migliore sarebbe inserire un passaggio intermedio:

  • Cerca http://foo.wp.tmp e sostituiscilo con uno slug preferibilmente univoco: http://3a4b522a.wp.tmp
  • Cerca http://wp.tmp e sostituiscilo con http://foo.wp.tmp
  • Cerca http://3a4b522a.wp.tmp e sostituiscilo con http://wp.tmp

Tutti questi comandi di ricerca e sostituzione dovrebbero ignorare le tre tabelle (*_options *_blogs) che abbiamo aggiornato prima, altrimenti romperebbero la configurazione. Potresti anche controllare manualmente la presenza di URL nella tabella wp_*_options al di fuori delle chiavi home e siteurl.

Suggerisco di usare il comando search-replace di WP-CLI per questo, in quanto può gestire dati serializzati e non ha le limitazioni che HTTP potrebbe avere.

10 ago 2016 21:07:11
Commenti

+1 per una panoramica buona e dettagliata. Sarebbe utile avere un comando personalizzato wp-cli per questo ;-) Ti riferisci a una domanda di "4 anni fa", ma la domanda è stata posta il 12/07/2016. PS: Ho notato ieri che Adminer non è più disponibile nella directory dei plugin su wordpress.org.

birgire birgire
10 ago 2016 22:35:24

Ah, dovrei leggere queste date due volte. Adminer è infatti un'applicazione standalone che viene in un singolo file PHP. Non c'è bisogno di usare il plugin qui. Ho scritto un plugin che almeno ti permette di cambiare l'URL del sito via WP-CLI: https://github.com/inpsyde/wp-cli-site-url

David David
11 ago 2016 01:41:13

sì, ne sono consapevole, mi è capitato qualche volta di dover estrarre dati da siti abbandonati senza alcun accesso ssh/ftp/cpanel ecc. In quel caso una versione plugin diventa utile ;-) Grazie per il link, sembra un plugin utile anche quello che hai creato.

birgire birgire
11 ago 2016 01:53:01

Ottima risposta, sono solo scioccato che nessuno abbia scritto un plugin per questo... Esiste un plugin per questa cosa? 3 semplici passaggi! Abbastanza deterministico, inoltre. Come ti è venuta in mente? :D

Gyuri Gyuri
9 ott 2018 10:41:05

Potrebbe essere deterministico ma in WordPress quasi nulla è prevedibile. In diversi anni di WordPress professionale ho trovato un motivo solo una o due volte per cambiare il sito principale in un ambiente esistente. Penso sia un caso limite piuttosto raro ed è per questo che non esiste un plugin per questo.

David David
10 ott 2018 18:02:56

Grazie, questo mi ha aiutato con una messa online particolarmente complicata.

martinedwards martinedwards
14 nov 2018 10:53:12
Mostra i restanti 1 commenti
3

Un'alternativa più semplice (che non richiede di modificare alcuna riga di codice) è utilizzare il plugin all-in-one-migration:

  1. esporta new.example.com con ID 15 e
  2. reimportalo in example.com con ID 1
25 nov 2018 16:43:45
Commenti

Concordo. Avevamo un sotto-sito che doveva sostituire il sito principale. L'abbiamo importato direttamente sul sito principale con All-in-one-Migration con l'add-on multisito.

Matt Beckman Matt Beckman
4 ott 2019 00:55:46

Anche se questo migra i dati del sito, non cambia il sito principale - ID1 è dove si trovano tutte le funzioni di amministrazione core e multisito, non è chiaro se l'OP volesse migrare i dati del sito o cambiare quale sia il sito principale.

Alex Balcanquall Alex Balcanquall
15 gen 2022 21:15:05

È importante notare che il plugin All-in-one-migration non include questa funzionalità senza pagare per l'Estensione Multisito che "parte da 199$"

Peter Højlund Andersen Peter Højlund Andersen
27 gen 2022 20:03:26