Italiano
Română
РусскийError de conexión a la base de datos después de copiar una instancia de WordPress Multisite a una segunda ubicación
Esta es mi configuración. Tengo una instancia Multisite ejecutándose en http://example.com, y quiero hacer desarrollo y staging. Mover una instancia existente de Multisite de WP a localhost es una pesadilla, así que voy a hacer el desarrollo en una ubicación de staging.
Configuré http://staging.example.com para que apunte al directorio /public_html/staging/ de la cuenta de hosting, y copié todos los archivos de WP desde mi raíz al directorio /staging/. También copié los archivos de la base de datos (volcado SQL, importé las tablas a una nueva base de datos) y cambié el archivo wp-config.php para que apunte a la nueva base de datos.
Después de ejecutar SQL para cambiar los registros de la base de datos, también cambié esta línea en el archivo wp-config.php:
/** Activando WordPress MU, nuevo en 3.0 */
define( 'MULTISITE', true );
define( 'SUBDOMAIN_INSTALL', false );
$base = '/';
define( 'DOMAIN_CURRENT_SITE', 'example.com' ); // <- Cambio esta línea
define( 'PATH_CURRENT_SITE', '/' );
define( 'SITE_ID_CURRENT_SITE', 1 );
define( 'BLOG_ID_CURRENT_SITE', 1 );
Cambiado a:
define( 'DOMAIN_CURRENT_SITE', 'staging.example.com' ); // <- ahora cambiado
Cuando cargo http://staging.example.com, obtengo... Error estableciendo la conexión con la base de datos!
He revisado y comprobado tres veces el nombre de usuario y la contraseña, me aseguré de que el usuario tiene todos los privilegios en la nueva base de datos de staging, y he dejado el DBHOST como 'localhost' (aunque cambiarlo a staging.example.com tampoco ayudó).
¿Por qué fallaría la conexión a la base de datos? ¿Alguien? (Gracias por su ayuda de antemano.)
Nota: http://example.com está funcionando bien con configuraciones de conexión a la base de datos muy similares, solo que con una base de datos diferente, así que no es un problema de que el servidor de base de datos esté caído.
Desafortunadamente no funcionó para mí. Este es un ejemplo perfecto de lo estúpido que es usar rutas absolutas en la base de datos para WP.
Pegues
@Pegues funcionó para más de 10 personas aquí :)
Pratik Joshi
Me alegra que haya funcionado para otros. Esto no funciona para mucha gente, y según lo que he investigado es porque hay una diferencia en los valores de la base de datos al cambiar de subdominio a subdirectorio. Y respecto a mi comentario inicial, el uso de rutas absolutas no es sabio por parte de WP. Nunca lo ha sido, y es la causa de tantos problemas. Además, configurar un flujo de trabajo adecuado con una canalización de CI/CD no es realmente posible a nivel empresarial.
Pegues
Eso funciona bien, excepto si terminas reemplazando una cadena en datos serializados, como un widget o una opción del tema, con una cadena de diferente longitud. Los datos serializados se ven así - 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: las longitudes 76 y 70 ya no corresponden a las cadenas mostradas - edité los detalles de mi sitio y no llevé un registro del nuevo conteo de caracteres.) La única solución para eso es actualizar manualmente los conteos - o mantener la misma longitud del dominio de staging.
marfarma
También reemplacé tt con xx para que las URLs no se obscurecieran -- no podías ver la diferencia entre ellas.
marfarma
Es bueno saberlo. Esto significa que al menos deberíamos tomarnos el tiempo para revisar todas las entradas a medida que se encuentran y reemplazan en lugar de reemplazar todo de una vez.
Jeff Sebring
Puedes usar este script para buscar/reemplazar datos serializados: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/
Costa