El archivo de configuración es uno de los más importantes en la instalación de WordPress. Es conocido como wp-config.php y, a pesar de su gran relevancia, suele usarse sólo para ingresar la información de conexión a la base de datos; para después quedar completamente en el olvido. Sin embargo, debemos tomar en cuenta que este archivo es nuestra navaja suiza al momento de optimizar y mejorar nuestra instalación de WordPress.
De acuerdo con el Codex de WordPress:
Es uno de los más importantes en la instalación de WordPress. Y está localizado en el directorio raíz; conteniendo información importante como la conexión a la base de datos y varios ajustes.
Por defecto, el archivo wp-config.php no viene incluido en la distribución oficial de WordPress. Es cierto, al descargar el paquete de WordPress no lo encontrarás por ningún lado. En su lugar, se distribuye otro bajo el nombre wp-config-sample.php.
Si eres un usuario experimentado, querrás crear tu archivo de forma manual. Para ello necesitas renombrar el archivo _wp-config-sample-php _a wp-config.php y comenzar a editar los valores correspondientes. En un inicio, sólo basta editar los valores de conexión a la base de datos.
La alternativa mas común es dejar que el mismo WordPress cree el archivo wp-config.php de manera automática. Esto se logra siguiendo la famosa instalación de 5 minutos de WordPress, simplemente introduciendo los valores que se nos piden.
Después de concluir con la instalación y configuración inicial; deberíamos tener una instalación limpia de WordPress. Y es en este punto donde inicia nuestra configuración personalizada.
La mayoría de los ajustes se configuran por medio de Constantes de PHP; que son definidas en la documentación de PHP de la siguiente manera:
Una constante es un identificador (nombre) para expresar un valor simple. Como el nombre sugiere, este valor no puede variar durante la ejecución del script.
Sabiendo esto, vamos a revisar los ajustes iniciales del archivo wp-config.php
Sin duda los ajustes más importantes son los de la conexión a la base de datos. WordPress almacena toda su información ahí y es por eso que necesita acceso. Para hacer una conexión correcta, se necesita contar con el host, el nombre de usuario, la contraseña y el nombre de la base de datos. En el siguiente código se muestran las 4 constantes que definen los datos de conexión: define(‘DB_NAME’, ‘database_name_here’); define(‘DB_USER’, ‘username_here’); define(‘DB_PASSWORD’, ‘password_here’); define(‘DB_HOST’, ‘localhost’);
Las llaves de seguridad o Security Keys son una serie de constantes que se usan para mejorar la encriptación de datos sensibles. Por otro lado, las llaves de autenticación se usan como controles de seguridad; mientras que las llaves salts son usadas en las contraseñas.
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');
Es importante mencionar que el uso de estas llaves no es necesario; pero es una práctica altamente recomendada para aumentar la seguridad de la instalación de WordPress. Visita el generador oficial de llaves de WordPress para obtener llaves seguras y únicas.
Este parámetro es usado por WordPress para saber qué prefijo añadir a las tablas de la instalación. Por defecto se usa wp._ De esta manera, las tablas generadas por el sistema serán nombradas como wp_post, wp_users, etc.
Al cambiar este parámetro, nos estamos protegiendo de ataques automatizados. Por lo general, estos ataques tratan de acceder a las tablas wp_users y wp_posts. Si cambiamos este valor como se ve a continuación, estarás previniendo el 99% de los ataques automatizados. Ya que no es lo mismo intentar acceder a wp_users que a uJshEjd54S_users. $table_prefix = ‘uJshEjd54S_’;
Sabemos que nunca debemos confiar 100% en un lenguaje de programación; ya que estos son ingratos y siempre fallarán, sin importar lo bien hechos que estén. No importa que seas desarrollador o un usuario de WordPress. Estoy seguro que alguna vez has entrado a tu sitio y te has encontrado con la pantalla blanca de la muerte. Es evidente que hay algo mal, pero no tienes idea de qué. Y aquí es donde la siguiente constante nos salva la vida: define(‘WP_DEBUG’, true); WordPress, por defecto, no muestra los errores de PHP. Es por esta razón que vemos esa pantalla blanca de la muerte cuando algo falla en nuestra instalación. Al cambiar el valor de esta constante a true, veremos la luz al final del camino; o mínimo sabremos qué está sucediendo. El error será visible en el navegador y tendremos un punto inicial para comenzar a indagar en el problema.
Una vez que entendimos los parámetros básicos del archivo wp-config.php es hora de comenzar con nuestra configuración avanzada.
El lenguaje por default de WordPress es el inglés. Pero esta opción se puede cambiar fácilmente usando la siguiente constante: define(‘WPLANG’, ‘es_MX’); Con esto, nuestra instalación será traducida automáticamente al Español de México. Al momento de escribir este artículo, existen 43 traducciones completas de WordPress disponibles para descarga.
En la versión 2.6 de WordPress se introdujeron las revisiones de posts. Consisten en guardar una copia del post cada vez que es editado. WordPress guarda las últimas 25 copias de cada post. Si tenemos un sitio con cientos de posts y cada post con una veintena de revisiones, nuestra base de datos comenzará tomar tamaños no deseados; ya que cada revisión es una entrada completa en la base de datos. 
Si agregamos la siguiente constante podemos limitar e incluso deshabilitar que WordPress guarde revisiones:
Al estar editando o creando un post, por seguridad del usuario, WordPress auto salva los contenidos cada 60 segundos. Esto significa que guarda una copia del post cada minuto. Aunado a las revisiones, esto puede generar una base de datos grande. Para aumentar el tiempo de auto salvado basta con usar la constante: AUTOSAVE_INTERVAL Usa define(‘AUTOSAVE_INTERVAL’, 120); para cambiar el tiempo en segundos.
Cuando un usuario elimina un post, página, custom post o cometario; WordPress mueve el post a la “basura” en lugar de eliminarlo por completo. De esta manera, si en el futuro decides restaurar una entrada, podrás hacerlo. Esta “basura” es eliminada cada 30 días. Pero si deseas que este proceso se ejecute con mayor frecuencia, puedes especificar cada cuántos días quieres que lo haga. Por ejemplo, siete: define(‘EMPTY_TRASH_DAYS’, 7 ); Para deshabilitar completamente esta opción debes usar la siguiente definición define(‘EMPTY_TRASH_DAYS’, 0 ); De esta forma, WordPress eliminará de una vez por todas el contenido; en lugar de moverlo a la basura.
Además del ya mencionado WP_DEBUG, WordPress ofrece un par de opciones más que son útiles al momento de desarrollar un tema o un plugin. define( ‘SCRIPT_DEBUG’, true );define( ‘CONCATENATE_SCRIPTS’, false ); WordPress usa tanto librerías como archivos propios de JavaScript; y los unifica y concatena por defecto para servir un único archivo. Con la constante SCRIPT_DEBUG definimos que WordPress use las versiones descomprimidas de los archivos de JavaScript y CSS en lugar de .min.js y min.css. Así, la tarea de depuración será más sencilla. CONCATENATE_SCRIPTS indica si los archivos de JavaScript deben ser contatenados en un solo archivo o no.
Al momento de desarrollar, algunas veces queremos saber cuál es la consulta exacta que WordPress está ejecutando en la base de datos. Si usamos la constante SAVEQUERIES WordPress almacenará las consultas en un array para que podamos imprimirlas y analizarlas. define( ‘SAVEQUERIES’, true ); Una vez definida la constante solo debemos imprimir su valor de la siguiente forma: "; print_r( $wpdb->queries ); echo “”; } ?> Esto imprime todas las consultas hechas usando la instancia de la clase $wpdb. Es recomendable imprimir estos valores al final de la ejecución de WordPress. Por lo regular, se hace usando el hook wp_footer.
Es bien sabido que los hospedajes compartidos tienen serias limitantes al momento de asignar memoria a nuestras cuentas para ejecutar nuestros scripts. Para aumentar esta cantidad debemos usar la constante _WP_MEMORY_LIMIT. _Por ejemplo, si queremos incrementarla a 64M, lo haríamos de la siguiente manera: define( ‘WP_MEMORY_LIMIT’, ‘64M’ ); Es importante mencionar que algunos servicios de hospedaje no permiten que se manipule este valor; y si necesitas incrementar la memoria, deberás contactar a tu soporte técnico.
Las actualizaciones automáticas del core de WordPress son tan odiadas como bendecidas por los usuarios. Hay quienes no quieren preocuparse por estar actualizando su sitio cada vez que hay una nueva actualización; y también hay quienes desean total control de qué se instala y cuándo se actualiza su sitio. Por defecto, las actualizaciones del core están activadas. Pero si quieres desactivarlas hay un par de modos de hacerlo. Para desactivar todas las actualizaciones automáticas de una vez por todas, debes usar: define( ‘AUTOMATIC_UPDATER_DISABLED’, true ); Si no quieres ser tan drástico y sólo quieres permitir actualizaciones menores, lo consigues de la siguiente forma: define( ‘WP_AUTO_UPDATE_CORE’, ‘minor’ );
Una buena práctica es usar conexiones encriptadas al momento de ingresar a tu administrador, o al momento en el que tus usuarios usen la forma de acceso. WordPress permite forzar el uso de SSL en estos dos sitios sensibles define( ‘FORCE_SSL_LOGIN’, true );define( ‘FORCE_SSL_ADMIN’, true ); Obviamente deberas contar con un certificado SSL válido para tu domino.
En lo personal, me he topado con un par de clientes que se sienten muy listos como para modificar el tema o algún plugin usando el editor por defecto de WordPress. Y esto sólo ha resultado inevitablemente en un caos total. Sin embargo, WordPress nos da la oportunidad de deshabilitar esta opción y dejar lejos de nuestros clientes el código de nuestros temas y plugins. define( ‘DISALLOW_FILE_EDIT’, true );
Siguiendo con las malas costumbres de los clientes; en una ocasión, un cliente me reclamó que su sitio estaba extremadamente lento y que por favor revisara qué estaba pasando. Al ingresar al sitio en cuestión, veo con horror que el cliente había instalado más de 50 plugins y todos estaban activos. Para evitar que esto suceda, podemos deshabilitar por completo la instalación y activación de plugins. Basta con agregar la siguiente constante: define( ‘DISALLOW_FILE_MODS’, true );
Por defecto, WordPress crea un conjunto nuevo de imágenes cada vez que subes una. Es decir, supongamos que inicialmente quieres hacer uso de la imagen background.png. Subes la imagen usando la librería multimedia de WordPress y una vez arriba, te das cuenta que tiene un error. Editas tu imagen y subes la nueva versión. En este momento, WordPress detecta que ya existe una imagen con el mismo nombre y renombra la nueva versión como background-1.png. Ahora tienes 2 imágenes y sólo ocuparás una. Para evitar este comportamiento, y reemplazar las imágenes en lugar de renombrarlas, usamos la constante IMAGE_EDIT_OVERWRITEdefine( ‘IMAGE_EDIT_OVERWRITE’, true );
Como pudiste notar, WordPress nos da manga ancha al momento de configurar cada aspecto de nuestra instalación de acuerdo a nuestras necesidades. Estos son sólo algunos ejemplos de lo que podemos lograr usando nuestro archivo wp-confing.php. Aún queda mucho que aprender sobre este tema, y qué mejor lugar para hacerlo que el Curso Profesional de WordPress de Platzi. Pero, cuéntanos, ¿cuáles son tus opciones favoritas o más usadas en el archivo wp-config.php?
