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. ¡Ah! ¿te funciona? pues entonces no he dicho nada :)
Hola Fernando, interpreto esto como que haces la instalación de todos los wordpress que necesites para tu proyecto, de forma independiente, con una base de datos para cada uno, ruta y carpeta de instalacion…. y luego en uno de ellos, el que decidas para poder acceder desde ese a cualquiera, modificas el archivo wp-config.php, añadiendo y personalizando con el codigo de esta entrada y asi podrias acceder al que quieras…. entiendo. Pero entonces si quieres que algo que tienes en el wordpress de prueba quieres ponerlo en algun otro, cualquier cambio, tienes que estar poniedolo de nuevo y asi con todo… es un lio total…. (asi que por eso supongo que no sera asi) por favor me lo puedes dejar claro. Gracias por tu esfuerzo y dedicación en tu página y en wordpress.
No, que va, con este fichero único accedes a todos los entornos sin tener que cambiar nada en cada ocasión, ya cada parte incluye la ruta de acceso
ummmm,… haber que me entere yo, si entro a un entorno (un wordpress en su base de datos) e instalo un plugin, o creo una entrada nueva…, o modifico algo, cambio un widget, pongo nueva plantilla… eso se hace en todos lo demas??… si yo trabajo en un wordpress prueba y algo queda bien y comforme como hago que eso pase a el wordpress digamos que seria el valido… (lo tengo que volver a hacer de nuevo en el otro, por eso mismo cuando cambio algo en uno, lo tendria que hacer de nuevo en otro)
…o es que toda en un solo wordpress…
Mis conocimientos llegan hasta ahi, y seguro que existe algo que no conozco… ¿entonces cómo seria?
Y cuando cambias algo de un plugin (que el cambio afecta a la bbdd) cómo pasas los cambios de un entorno a otro? ya que no son ficheros? con un sql de update de ésas tablas de ese plugin? no hay otra manera?
Saludos gracias por el aporte, una pregunta, el script del ejemplo es cuando se tiene configurado un host virtual en apache para el caso de , http://proyecto.pruebas…, en caso contrario, se debería usar http://localhost/proyectox/ ¿cierto?