Uno de los archivos más importantes de la instalación de WordPress es el archivo de configuración. Reside en la raíz del directorio y contiene definiciones constantes e instrucciones PHP que hacen funcionar a WordPress de la forma que usted desea. El archivo wp-config.php almacena datos como como los detalles de la conexión a la base de datos, tablas de prefijos, vías a directorios específicos y muchas opciones relacionadas a características específicas de las cuales hablaremos en este artículo.

El archivo básico wp-config.php

Cuando usted instala por primera vez WordPress, le pedirán ingresar información requerida como detalles de la base de datos y la tabla de prefijos. Algunas veces su host configurará WordPress por usted, y no tendrá que hacerlo manualmente. Pero cuando se encuentra corriendo de forma manual el proceso de instalación de 5 minutos, se le pedirá que agregue algunos de los datos más relevantes almacenados dentro del wp-config.

Cuando ejecute la configuración, se requerirá que usted ingrese los datos que se encuentran almacenados en el archivo wp-config-php

Cuando ejecute la configuración, se requerirá que usted ingrese los datos que se encuentran almacenados en el archivo wp-config-php

Aquí tenemos un archivo básico wp-config.php:

// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'database_name_here');

/** MySQL database username */
define('DB_USER', 'username_here');

/** MySQL database password */
define('DB_PASSWORD', 'password_here');

/** MySQL hostname */
define('DB_HOST', 'localhost');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

define('AUTH_KEY',		'put your unique phrase here');
define('SECURE_AUTH_KEY',	'put your unique phrase here');
define('LOGGED_IN_KEY',		'put your unique phrase here');
define('NONCE_KEY',		'put your unique phrase here');
define('AUTH_SALT',		'put your unique phrase here');
define('SECURE_AUTH_SALT',	'put your unique phrase here');
define('LOGGED_IN_SALT',	'put your unique phrase here');
define('NONCE_SALT',		'put your unique phrase here');

$table_prefix  = 'wp_';

/* That's all, stop editing! Happy blogging. */

Usualmente, este archivo se genera automáticamente al momento de configurarlo, pero ocasionalmente WordPress no tendrá los privilegios para escribir sobre el folder de instalación. En esta situación, usted deberá crear un archivo vacío de wp-config.php, copiar y pegar el contenido del wp-config-sample.php, y establecer los valores propios a todas las constantes definidas. Cuando esté listo, suba su archivo a la raíz del folder y use WordPress.

Nota: las definiciones constantes y las instrucciones de PHP vienen en un orden específico el cual jamás deberá ser cambiado. Y nunca debemos agregar contenido bajo la siguiente línea de comentario:

/* That's all, stop editing! Happy blogging. */

Primero, vienen las definiciones de las constantes de la base de datos que usted debió haber recibido de su host:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST
  • DB_CHARSET
  • DB_COLLATE

Siguiendo los detalles de la base de datos, ocho llaves de seguridad harán de este sitio un lugar mucho más seguro en contra los hackers. Cuando usted haga la instalación de WordPress, este generará de forma automática llaves de seguridad y de salt, pero puede cambiarlas en cualquier momento, con tan solo añadir una cadena arbitraria. Para una mejor seguridad, considere usar el generador en línea.

La variable $table_prefix  almacena el prefijo de todas las tablas de WordPress. Desafortunadamente, todos conocen su valor por defecto y esto puede abrir la base de datos de WordPress y le deja vulnerable, que puede ser arreglada fácilmente al someter un valor personalizado para $table_prefix  al ejecutar la configuración.

Para cambiar el prefijo de tabla en un sitio web funcional, usted deberá correr varias consultas en contra de la base de datos, luego de forma manual, editar el archivo wp-config.php. Si no tiene acceso a la base de datos o no tiene el conocimiento necesario para construir consultas personalizadas, entonces usted puede instalar un plugin como Change Table Prefix que cambiará el nombre de las tablas de base de datos y los nombres de campo, y actualizará el archivo de configuración sin riesgo alguno.

Nota: es una buena práctica hacer un backup de los archivos y base de datos de WordPress incluso si usted va a cambiar el prefijo de tabla con un plugin.

Así que, hasta ahora, el análisis ha sido limitado a la configuración más básica. Pero tenemos a nuestra disposición muchas constantes que podemos definir para permitir características, personalizar y asegurar la instalación.

Configuración muy básica: editando el sistema de archivos

El sistema de archivos de WordPress es muy bien conocido por usuarios y hackers. Por esta razón, usted puede considerar cambiar la estructura de archivo integrada con tan solo mover los folders específicos en ubicaciones arbitrarias y establecer la URL correspondiente y la ruta al archivo wp-config. Primero, podemos mover el folder de contenido definiendo dos constantes. La primera establece el camino del directorio completo:

define( 'WP_CONTENT_DIR', dirname(__FILE__) . '/site/wp-content' );

La segunda establece la nueva URL del directorio:

define( 'WP_CONTENT_URL', 'http://example.com/site/wp-content' );

Podemos mover el folder del plugin definiendo las siguientes constantes:

define( 'WP_PLUGIN_DIR', dirname(__FILE__) . '/wp-content/mydir/plugins' );
define( 'WP_PLUGIN_URL', 'http://example.com/wp-content/mydir/plugins' );

De la misma forma, podemos mover el folder de los archivos subidos, al establecer la ruta del nuevo directorio:

define( 'UPLOADS', 'wp-content/mydir/uploads' );

Nota: Todas las rutas son relativas a ABSPATH, y estos no deberán contener una barra diagonal.

Una vez hecho, acomode los folders y recargue WordPress.

La imagen muestra la estructura integrada comparada a una estructura personalizada

La imagen muestra la estructura integrada comparada a una estructura personalizada

No es posible mover el folder de /wp-content/themes del archivo de wp-config, pero podemos registrar un nuevo directorio de tema en un plugin o a un archivo de funciones de tema.

Características para desarrolladores: modo debug y guardando consultas

Si usted es un desarrollador, puede forzar a WordPress para mostrar errores y advertencias que le ayudarán en la depuración de temas y plugins. Para habilitar el modo debug necesita establecer el valor WP_DEBUG a verdadero, como se muestra a continuación:

define( 'WP_DEBUG', true );

WP_DEBUG es establecido como falso por defecto. Si necesita deshabilitar el modo debug, puede tan solo remover la definición, o establecer el valor de la constante a falso.

Cuando se encuentra trabajando en un sitio en vivo, deberá deshabilitar el modo debug. Los errores y advertencias nunca deberán aparecer frente a los visitantes porque ofrece información valiosa a los hackers. ¿Pero qué tal si tiene que hacer debug de todas formas? 

En estas situaciones, usted puede forzar a WordPress para que mantenga su memoria de los errores y advertencias en un archivo debug.log, colocado en el folder /wp-content. Para habilitar esta opción, copie y pegue el siguiente código en el archivo wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Para lograr que esta opción funcione, primero necesitamos habilitar el modo de debug. Luego, al establecer WP_DEBUG_LOG a verdadero forzamos a que WordPress almacene los mensajes en un archivo debug.log, mientras, define WP_DEBUG_DISPLAY a falso, escondemos la información de la pantalla. Finalmente configuramos el valor de PHP variable DISPLAY_ERRORS a 0 y las advertencias no se mostrarán en la pantalla. wp-config jamás se cargará de la cache. Por esta razón, es un buen lugar para invalidar las opciones php.ini.

Nota: esta es una gran opción de la cual puede tomar ventaja para registrar mensajes que WordPress no podría mostrar en la pantalla. Como un ejemplo, cuando se activa la acción publish_post, WordPress carga un script que guarda datos, luego redirige al usuario a la página de edición del post. En esta situación, usted podrá registrar los mensajes, pero no podrá mostrarlos en la pantalla.

Otra constante del debugging determina las versiones de los scripts y estilo a cargarse. Establezca SCRIPT_DEBUG a verdadero si desea cargar las versiones sin comprimir:

define( 'SCRIPT_DEBUG', true );

Si su tema o plugin muestra datos extraídos de la base de datos, usted podrá querer almacenar los detalles de las consultas para subsecuentes revisiones. La constante SAVEQUERIES forza a WordPRess a almacenar información dentro de la formación $wpdb->queries. Estos detalles serán impresos agregando el siguiente código a la plantilla de pie de página:

if ( current_user_can( 'administrator' ) ) {
        global $wpdb;
        echo '
';
        print_r( $wpdb->queries );
        echo '

‘;
}

Para un análisis más profundo de esta opción, consulte a Cómo Construir Consultas Eficientes en WordPress.

Cuando su sitio empiece a crecer, podría querer reducir el número de posts de revisión. Por defecto, WordPress automáticamente guarda revisiones cada 60 segundos. Podemos cambiar este valor estableciendo un intervalo personalizado en wp-config de la siguiente forma:

define( 'AUTOSAVE_INTERVAL', 160 );

Por supuesto, puede reducir el intervalo de autoguardado también:

Cada vez que salvamos nuestras ediciones, WordPress agrega una fila a la tabla de posts, para que podamos restaurar revisiones de posts y páginas anteriores. Esto es una funcionalidad bastante útil que puede convertirse en problema cuando nuestro sitio crezca más. Afortunadamente, podemos reducir el número máximo de revisiones de posts a guardarse, o deshabilitar la función por completo.

Si desea desactivar la revisión de posts, defina la siguiente constante:

define( 'WP_POST_REVISIONS', false );

Si desea limitar el número máximo de revisiones, en su lugar, agregue la siguiente línea:

define( 'WP_POST_REVISIONS', 10 );

Por defecto, WordPress almacena posts descartados, páginas, archivos adjuntos y comentarios por 30 días, luego los borra de forma permanente. Podemos cambiar este valor con la siguiente constante:

define( 'EMPTY_TRASH_DAYS', 10 );

Incluso, podemos desactivar la basura, dejando el valor en 0, pero considere que WordPress no le permitirá restaurar contenido de nuevo.

Tamaño de memoria permitido

Ocasionalmente usted podrá recibir un mensaje como el siguiente:

Error fatal: El tamaño permitido de memoria de xxx bytes ha sido agotado….

El tamaño de memoria máximo depende de la configuración del servidor. En caso que no tenga acceso al archivo php.ini, puede incrementar el límite de la memoria solo para WordPress al establecer la constante WP_MEMORY_LIMIT en el archivo de wp-config. Por defecto, WordPress tratará de alocar 40Mb a PHP por sitios únicos y 64MB por múltiples instalaciones. Por su puesto, si la memoria alocada de PHP es mayor a 40Mb (o 64Mb), WordPress adoptará el valor máximo.

Habiendo dicho esto, usted puede establecer un valor personalizado con la siguiente línea:

define( 'WP_MEMORY_LIMIT', '128M' );

Si es necesario, puede establecer un límite de memoria máxima, también, con lo siguiente:

define( 'WP_MAX_MEMORY_LIMIT', '256M' );

Actualizaciones automáticas

Empezando desde la versión 3.7, WordPress soporta actualizaciones automáticas para lanzamientos de seguridad. Esto es una característica importante que le permite a los admins del sitio seguir manteniendo seguro al sitio, todo el tiempo.

Puede desactivar todas las actualizaciones automáticas con tan solo definir la siguiente constante:

define( 'AUTOMATIC_UPDATER_DISABLED', true );

Quizás no sea una buena idea deshabilitar las actualizaciones de seguridad, pero es su decisión.

Por defecto, las actualizaciones automáticas no funcionan con lanzamientos mayores, pero puede permitir cualquier actualización importante definiendo WP_AUTO_UPDATE_CORE de la siguiente forma:

¿Luchando con el tiempo de inactividad y los problemas de WordPress? Kinsta es la solución de alojamiento diseñada para ahorrarle tiempo! Vea nuestras características
# Disables all core updates:
define( 'WP_AUTO_UPDATE_CORE', false );

# Enables all core updates, including minor and major:
define( 'WP_AUTO_UPDATE_CORE', true );

El valor por defecto es minor:

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Una constante adicional deshabilita las auto-actualizaciones (y cualquier actualización o cambio a cualquier archivo) Si usted establece DISALLOW_FILE_MODS a verdadero, todas las ediciones de archivos serán deshabilitadas, incluso instalaciones de temas, plugins y actualizaciones. Por esta razón, su uso no es recomendado.

Opciones de seguridad

Nota: considere que algunos plugins podrían no funcionar de forma correcta si está constante es definida como verdadera.

define( 'DISALLOW_FILE_EDIT', true );

Note: consider that some plugins could not work properly if this constant is defined to true.

Disallow_file_edit

Disallow_file_edit

Una característica de seguridad es la Administración de SSL. Si usted compró un certificado de SSL y está propiamente configurada, usted puede forzar a WordPress a transferir datos sobre SSL en cualquier sesión login y de admin. Use la siguiente constante:

define( 'FORCE_SSL_ADMIN', true );

Revise el Codex si necesita más información sobre la Administración de SSL.

Otras dos constantes permiten bloquear consultas externas y listar los hosts admitidos.

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'example.com,*.anotherexample.com' );

En este ejemplo, hemos deshabilitado todos los accesos de hosts externos, luego listamos los hosts permitidos, separados por comas (se permiten los wildcards).

Otras opciones avanzadas

WP_CACHE establecido como verdadero incluye un script wp-content/advanced-cache.php. Esta constante tiene sólo efecto si usted instala un plugin de cache persistente.

CUSTOM_USER_TABLE y CUSTOM_USER_META_TABLE son usados para establecer tablas personalizadas además de las tablas por defecto wp_users y wp_usermeta. Estas constantes permiten una opción muy útil  que permite a los usuario de los sitios acceder a varios sitios web con una sola cuenta. Para que esta opción funcione, todas las instalaciones deberán ser compartidas desde la misma base de datos.

Empezando desde la versión 2.9, WordPress soporta la Optimización Automática de Base de Datos. Gracias a esta opción, al establecer WP_ALLOW_REPAIR a verdadero, WordPress automáticamente repara cualquier base de datos corrupta.

WordPress crea un nuevo grupo de imágenes cada vez que usted edita una imagen. Si usted restaura la imagen original, todos los grupos generados se mantendrán en el servidor. Usted puede reescribir este comportamiento al establecer IMAGE_EDIT_OVERWRITE a verdadero, para que, cuando restaure la imagen original, todas las ediciones se borren del servidor.

Bloquear wp-config.php

Ahora sabemos porque wp-config.php es uno de los archivos más importantes de WordPress. Así que, ¿Por qué no esconderlo de los hackers? Antes que nada, podemos mover wp-config a un nivel arriba del folder raíz de WordPress (sólo un nivel). Sin embargo, esta técnica es un poco controversial, así que yo sugiero adoptar otras soluciones para proteger el archivo. Si su sitio funciona con el Servidor Web Apache, puede agregar las siguientes directivas al archivo htaccess:


order allow,deny
deny from all

Si el sitio web funciona con Nginx, puede agregar la siguiente directiva al archivo de configuración:

location ~* wp-config.php { deny all; }

Nota: estas instrucciones deberán ser agregadas solo después de que la configuración se haya completado.

Si su sitio web ha pasado por varias migraciones o usted se la compró recomiendo que ú cree un nuevo grupo de llaves de seguridad de WordPress. Estas llaves son establecidas de forma aleatoria como variables que mejoran la encriptación de la información almacenada en las cookies del usuario. A partir de WordPress 2.7 han habido 4 diferentes llaves:  AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, y NONCE_KEY.

Por defecto, estas son generadas de forma aleatoria para usted. Pero WordPress realmente tiene una herramienta gratuita que usted usar para generar nuevas llaves aleatorias. Luego puede simplemente actualizar las llaves actuales que se encuentran almacenadas en su archivo de wp-config.php.

Llaves de seguridad de WordPress

Llaves de seguridad de WordPress

Lea un poco más acerca de las llaves de seguridad de WordPress.

Y finalmente, usted deberá verificar dos veces y asegurarse que sus permisos se establezcan en su archivo wp-config.php. Típicamente los archivos en el directorio raíz de un sitio WordPress se establecen a 644, queriendo decir que los archivos son legibles y grabables por el dueño del archivo y legible por usuarios en el grupo del dueño del archivo y legible para cualquier otra persona. De acuerdo a la documentación de WordPress, los permisos en wp-config.php deberán establecerse a 440 o 400 para prevenir que otros usuarios en el servidor lo lean. Usted puede fácilmente cambiar esto con su cliente FTP.

Permisos de wp-config.php

Permisos de wp-config.php

Resumen

En este artículo, enumeré muchas constantes de WordPress las cuales podemos definir dentro de un archivo wp-config. Algunas de estas son muy comunes, y sus funciones son fáciles de entender. Otras constantes permiten opciones avanzadas que requieren un conocimiento profundo de WordPress y administración de sitios.

He listado las características más comunes, dejando aparte algunas opciones avanzadas que podremos discutir en próximos artículos. Si usted desea explorar las opciones y constantes que no mencionamos aquí, tómese la libertad de iniciar una conversación en la sección de comentarios que encontrará abajo y adentrémonos a eso.