Italiano
Español
РусскийEroare de conexiune la baza de date după copierea unei instanțe WordPress Multisite într-o a doua locație
Iată configurația mea. Am o instanță Multisite care rulează la http://example.com și vreau să fac dezvoltare și staging. Mutarea unei instanțe Multisite WP existente pe localhost este un coșmar, așa că voi face dezvoltarea pe o locație de staging.
Am configurat http://staging.example.com să indice către directorul /public_html/staging/ al contului de hosting și am copiat toate fișierele WP din rădăcina site-ului în directorul /staging/. De asemenea, am copiat fișierele bazei de date (dump SQL, am importat tabelele într-o nouă bază de date) și am modificat fișierul wp-config.php pentru a indica către noua bază de date.
După executarea SQL pentru modificarea înregistrărilor din baza de date, am modificat și această linie din fișierul wp-config.php:
/** Activarea WordPress MU, nou în 3.0 */
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'example.com' ); // <- Modific această linie
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
Modificată în:
define( 'DOMAIN_CURRENT_SITE', 'staging.example.com' ); // <- acum modificată
Când încarc http://staging.example.com, primesc... Error establishing database connection!
Am verificat și răsverificat numele de utilizator și parola, m-am asigurat că utilizatorul are toate privilegiile pe noua bază de date de staging și am lăsat DBHOST ca 'localhost' (deși schimbarea acestuia în staging.example.com nu a ajutat).
De ce ar eșua conexiunea la baza de date? Poate cineva să ajute? (Mulțumesc în avans pentru ajutor.)
NB: http://example.com funcționează bine cu setări foarte similare de conexiune la baza de date, doar cu o bază de date diferită, deci nu este o problemă cu serverul bazei de date fiind oprit.
Din păcate, nu a funcționat pentru mine. Acesta este un exemplu perfect al prostiei de a folosi căi absolute în baza de date pentru WordPress.
Pegues
@Pegues a funcționat pentru peste 10 persoane aici :)
Pratik Joshi
Mă bucur că a funcționat pentru alții. Acest lucru nu funcționează pentru foarte mulți oameni - și din ceea ce am cercetat, se datorează unei diferențe în valorile bazei de date la trecerea de la subdomeniu la subdirector. Și pentru a reveni la comentariul meu inițial, utilizarea căilor absolute nu este înțeleaptă din partea WordPress. Niciodată nu a fost și este cauza atâtor probleme. Și configurarea unui flux de lucru adecvat cu pipeline CI/CD nu este cu adevărat posibilă la nivel de întreprindere.
Pegues
Aceasta funcționează bine, cu excepția cazului în care înlocuiți un șir de caractere în date serializate, cum ar fi un widget sau o opțiune de temă, cu un șir de caractere de lungime diferită. Datele serializate arată astfel - 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' (notă: lungimile 76 și 70 nu mai corespund cu șirurile prezentate - am editat detaliile site-ului meu și nu am ținut evidența noului număr de caractere.) Singura soluție pentru aceasta este să actualizați manual numărul de caractere - sau să păstrați aceeași lungime pentru domeniul de staging.
marfarma
De asemenea, am înlocuit tt cu xx astfel încât URL-urile să nu fie obscure - nu puteți vedea diferența dintre ele.
marfarma
Acest lucru este bine de știut. Aceasta înseamnă că ar trebui să ne luăm timp să parcurgem toate intrările pe măsură ce sunt găsite și înlocuite, în loc să înlocuim totul deodată.
Jeff Sebring
Poți folosi acest script pentru a căuta/înlocui date serializate: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Costa