wp-config.php para WordPress multientorno

Cuando desarrollas un sitio web siempre vas a tener diferentes entornos para el mismo, el número de entornos que necesites dependerá del tamaño del proyecto y de cuánta gente esté involucrada en el proyecto.

Los principales entornos que encontrarás en cualquier proyecto web son:

• Servidor de desarrollo – La máquina local de los desarrolladores que crean la web.
• Servidor de pruebas – Una vez se haya terminado el desarrollo este será el lugar donde se harán todas las pruebas.
• Servidor de pruebas del cliente final – Donde el cliente revisará los cambios de la web.
• Servidor de producción – La web definitiva.

Los dos entornos que siempre has de tener son el entorno de desarrollo y el de producción. Lo normal es que solo necesites estos dos entornos si el cliente no necesita ver la web antes de ponerla en marcha. Esto implica que una vez que el desarrollador haya terminado de trabajar en la web solo le queda ponerla en el servidor de producción.

Esto suele ser así para los proyectos básicos, esos en los que el desarrollador hace las pruebas en su servidor de desarrollo local antes de hacer visible la web.

Si tienes un cliente que necesita revisar tu desarrollo antes de poner la web a la vista entonces tendrás que disponer de un servidor de pruebas del cliente final, este entorno debería parecerse lo más posible al servidor de producción. Cuando el desarrollador haya terminado de hacer las pruebas locales podrá subir la web al servidor de pruebas del cliente final para que lo revise. Una vez que el cliente acepte los cambios hechos por el desarrollador se podrá ya mover la web al sitio de producción.

En proyectos con varios desarrolladores será imprescindible que tengas un servidor de pruebas adicional además del de desarrollo y del de pruebas para el cliente final. Necesitas este servidor ya que cuando el desarrollador esté creando la web y probando el código lo estará probando solo en su propio entorno, y este entorno con seguridad no se adaptará a los entornos del resto de desarrolladores.

Una vez que el desarrollador haya probado su código debería subirlo al servidor de pruebas. Será ahí donde todos los desarrolladores harán los cambios para probarlos con los demás cambios del resto de desarrolladores. Una vez que este servidor sea estable y haya pasado las pruebas entones ya podrás subir esos cambios al servidor de pruebas del cliente final, donde este podrá revisar los cambios y, si los acepta, entonces se subirá todo al servidor de producción.

Multi entorno en WordPress

Si tienes un proyecto WordPress querrás que sea fácil cambiar entre distintos entornos, y el modo más fácil es que puedas subir todo lo que haya que hacer en el proyecto al mismo servidor. Esto implica que se subirán todos los cambios que hagas, no solo los cambios en los plugins o temas.

Pero si subes todo también cargarás el archivo wp-config.php, y este archivo le dice a WordPress cómo conectarse con la base de datos.

El archivo wp-config.php no es más que un fichero PHP que puedes cambiar, dependiendo del servidor desde el que se esté utilizando, usando la variable global $_SERVER para distinguir entre entornos.

Las variables que tienes que cambiar dependiendo del entorno son:

• DB_NAME – Nombre de la base de datos.
• DB_USER – Usuario para conectarse a la base de datos.
• DB_PASSWORD – Contraseña para conectarse a la base de datos.
• DB_HOST – Nombre del servidor donde está alojado la base de datos.
• WP_HOME – URL de la ubicación de la página principal donde está instalado WordPress.
• WP_SITEURL – URL de la ubicación del sitio WordPress, la mayoría de las veces la misma que en WP_HOME, pero puede cambiar si, por ejemplo, WordPress está instalado en un subdirectorio.
• WP_DEBUG – Mostrará cualquier error o aviso PHP.
• WP_CACHE – Cacheará WordPress.

Teniendo en cuenta todo lo anterior, un fichero wp-config.php para un WordPress multientorno sería así:

<?php

if( stristr( $_SERVER['SERVER_NAME'], "desarrollo" ) ) {
 
 	// Entorno de desarrollo
	define( 'DB_NAME', 'project_dev' );
	define( 'DB_USER', 'project_dev_user' );
	define( 'DB_PASSWORD', 'contraseña' );
	define( 'DB_HOST', 'localhost' );
	
	define( 'WP_HOME', 'http://proyecto.dev');
	define( 'WP_SITEURL', WP_HOME);
	
	// Para el desarrollo siempre querrás que el debug esté activo y la cache inactiva
	define( 'WP_DEBUG', true );
	define( 'WP_CACHE', false );
	 
} elseif( stristr( $_SERVER['SERVER_NAME'], "pruebas" ) ) {
 
	// Entorno de pruebas
	define( 'DB_NAME', 'project_test' );
	define( 'DB_USER', 'project_test_user' );
	define( 'DB_PASSWORD', 'contraseña' );
	define( 'DB_HOST', 'localhost' );
	
	define( 'WP_HOME', 'http://proyecto.pruebas'); 
	define( 'WP_SITEURL', WP_HOME);
	
	// Para las pruebas siempre querrás que el debug esté activo y la cache inactiva
	define( 'WP_DEBUG', true);
	define( 'WP_CACHE', false);
	
} elseif( stristr( $_SERVER['SERVER_NAME'], "cliente" ) ) {
 
	// Entorno de pruebas del cliente final
	define( 'DB_NAME', 'project_uat' );
	define( 'DB_USER', 'project_uat_user' );
	define( 'DB_PASSWORD', 'contraseña' );
	define( 'DB_HOST', 'localhost' );
	
	define( 'WP_HOME', 'http://proyecto.cliente'); 
	define( 'WP_SITEURL', WP_HOME);
	
	// El entorno de pruebas del cliente final siempre será el mismo que el de producción así que desactivamos el debug y activamos la cache
	define( 'WP_DEBUG', false );
	define( 'WP_CACHE', true );	
	 
} else {
 
	// Entorno de producción
	define( 'DB_NAME', 'project_live' );
	define( 'DB_USER', 'project_live_user' );
	define( 'DB_PASSWORD', 'contraseña' );
	define( 'DB_HOST', 'localhost' );
	
	define( 'WP_HOME', 'http://proyecto.es'); 
	define( 'WP_SITEURL', WP_HOME); 
	
	// El entorno visible siempre será el mismo que el de producción así que desactivamos el debug y activamos la cache
	define( 'WP_DEBUG', false );
	define( 'WP_CACHE', true );
		
}
 
define('DB_CHARSET', 'utf8');
define('DB_COLLATE', '');
?>

Con lo anterior, con un solo fichero wp-config.php puedes tener todos los entornos en un mismo alojamiento sin problemas, cada uno funcionando independientemente pero usando la misma base, algo que a la hora del desarrollo y las pruebas es fundamental.

Por supuesto, debes utilizar las URLs y la información de conexión a las bases de datos tuyas, no las del ejemplo.

Fuente: Paulund

¿Te gustó este artículo? ¡Ni te imaginas lo que te estás perdiendo en YouTube!

AVISO: Esta publicación es de hace 3 años o más. Si es un código o un plugin podría no funcionar en las últimas versiones de WordPress, y si es una noticia podría estar ya obsoleta. Luego no digas que no te hemos avisado.