Español
Română
РусскийErrore di connessione al database dopo aver copiato un'istanza WordPress Multisite in una seconda posizione
Ecco la mia configurazione. Ho un'istanza Multisite in esecuzione su http://example.com e voglio fare sviluppo e staging. Spostare un'istanza Multisite esistente di WP su localhost è un incubo, quindi farò lo sviluppo su un ambiente di staging.
Ho configurato http://staging.example.com per puntare alla directory /public_html/staging/ dell'account di hosting e ho copiato tutti i file WP dalla mia root nella directory /staging/. Ho anche copiato i file del database (dump SQL, importato le tabelle in un nuovo database) e modificato il file wp-config.php per puntare al nuovo database.
Dopo aver eseguito SQL per modificare i record del database, ho anche cambiato questa riga nel file wp-config.php:
/** Attivazione WordPress MU, novità in 3.0 */
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'example.com' ); // <- Modifico questa riga
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
Modificata in:
define( 'DOMAIN_CURRENT_SITE', 'staging.example.com' ); // <- ora modificata
Quando carico http://staging.example.com, ottengo... Error establishing database connection!
Ho controllato e ricontrollato username e password, mi sono assicurato che l'utente abbia tutti i privilegi sul nuovo database di staging e ho lasciato DBHOST come 'localhost' (anche se cambiarlo in staging.example.com non ha aiutato).
Perché la connessione al database dovrebbe fallire? Qualcuno può aiutare? (Grazie in anticipo per l'aiuto.)
NB: http://example.com funziona correttamente con impostazioni di connessione al database molto simili, solo con un database diverso, quindi non è un problema di server database non attivo.
Sfortunatamente non ha funzionato per me. Questo è un perfetto esempio della stupidità di usare percorsi assoluti nel database per WordPress.
Pegues
@Pegues ha funzionato per più di 10 persone qui :)
Pratik Joshi
Sono contento che abbia funzionato per altri. Questo non funziona per moltissime persone - e da quello che ho ricercato è perché c'è una differenza nei valori del database quando si passa da sottodominio a sottodirectory. E per tornare al mio commento iniziale, l'uso di percorsi assoluti non è saggio in WordPress. Non lo è mai stato, ed è la causa di così tanti problemi. E impostare un flusso di lavoro corretto con una pipeline CI/CD non è realmente possibile a livello enterprise.
Pegues
Funziona bene, tranne nel caso in cui si finisca per sostituire una stringa in dati serializzati, come un widget o un'opzione del tema, con una stringa di lunghezza diversa. I dati serializzati hanno questo aspetto - s:76:"hxxp://www-dev.example.com/wp-content/uploads/company_logo_swoosh.gif' 's:70:"hxxp://www.example.com/wp-content/uploads/company_logo_swoosh.gif' (nota: le lunghezze 76 e 70 non corrispondono più alle stringhe mostrate - ho modificato i dettagli del mio sito senza tenere traccia del nuovo conteggio di caratteri.) L'unica soluzione per questo è aggiornare manualmente i conteggi - oppure mantenere la stessa lunghezza del dominio di staging.
marfarma
Ho anche sostituito tt con xx in modo che gli URL non fossero oscurati -- non si poteva vedere la differenza tra di loro.
marfarma
È buono a sapersi. Questo significa che dovremmo almeno prendere il tempo per esaminare tutte le voci mentre vengono trovate e sostituite invece di sostituire tutto in una volta.
Jeff Sebring
Puoi utilizzare questo script per cercare/sostituire dati serializzati: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Costa