Configuración limpia de wp-config en tu WordPress

WordPress es uno de los CMS que más se instala con un one click, lo que significa que habitualmente nadie se preocupa por el fichero de configuración, pero este fichero tiene muchos más secretos y trucos de los que en un principio puede parecer.

Cuando monto un WordPress nuevo intento preocuparme de dejar al menos la casa recogida, ya no porque el propio WordPress funcione correctamente, sino porque uno nunca sabe lo que puede pasar y aunque ese sitio deje de estar bajo mi control, lo principal es que funcione correctamente.

El primer bloque del wp-config hace referencia a la conexión con la base de datos. Si es un sitio nuevo, podéis configurar como prefiráis, si es uno que ya existe y está en funcionamiento, es mejor no tocar nada de ahí.

define( 'DB_NAME', 'sitio_abc123' );
define( 'DB_USER', 'sitio_def456' );
define( 'DB_PASSWORD', 'abcDEF#123ghiJKL$456mnoPQR%789' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', 'utf8mb4_general_ci' );

El usuario, contraseña y demás, poco a comentar; recomiendo una contraseña de al mínimo 16 caracteres, aunque yo intento usar al menos 32 caracteres alfanuméricos y con símbolos.

Quizá lo interesante aquí es el juego de caracteres. Por defecto suele estar en blanco, aunque, si quieres tenerlo al 100% bien, lo mejor es ponerle el sistema de UTF-8 MB4. Este sistema permite, entre otras cosas, guardar prácticamente cualquier carácter de cualquier alfabeto de forma nativa.

El siguiente bloque hace referencia a la seguridad en las cookies y otros elementos alternativos.

Lo normal es directamente irse a la API y copiar los códigos que te genera, y nunca dejar lo que hay por defecto. Incluso, es muy recomendable ir cambiado estos códigos con cierta frecuencia (cada 3-6 meses).

define( 'AUTH_KEY', 'lu~c7DpP+I97R>2:7}fhODTYBOo1-HBLqu~3F5+ivWsyhJ>+-q+_paO*S|sT>gqs' );
define( 'SECURE_AUTH_KEY', 'xD]**8_T7fJFiHpw8ICYh/8a]b{}pc,boqK9;+`w8tgp4$L94O:+24(JNV@uE#$S' );
define( 'LOGGED_IN_KEY', '`Hch}Oba:?eX94c.EkU7Cxq5^g3_{ry]({aeiVn#Po~*$|v#eSIMjo0_M,u+}{2_' );
define( 'NONCE_KEY', 'i?M1fAF-bSaHK!S2G zX<%MpOLT$b,k,bIRZk(,VW}y+NP7X|W-fRRDGDYo~()U;' );
define( 'AUTH_SALT', 'q|ckP/*P34x7Hhf n`$epyLOU4v7U[)j.dobf-dSrQNFC :a-<-zJoc./bl@5TOF' );
define( 'SECURE_AUTH_SALT', '  OZ4-%y2|B/.^(t-#v2XR4Ea{M/^?n0{`/bi+u5=Tq*]Z/~M.` T+9LzKlFO2[E' );
define( 'LOGGED_IN_SALT', '#+q~6011Q|Ek|p%9pjHw+QiBLi|1RU2hH-tzk7x0b/urxN0WHxtL}4~{RtP{Amy,' );
define( 'NONCE_SALT', 'vy|v}qNjycpt|IY98A{%AA%c~dEM~=X3y7By+]+HoO8:-:shKq0=~H|?3k;.bqt-' );

El siguiente bloque es otro clásico muy comentado por temas de seguridad, y es el prefijo de la base de datos. Al igual que la base de datos, si hablamos de un sitio web existente, es mejor no tocar nada, pero si va a ser un sitio web nuevo, mi recomendación es usar un prefijo de letras minúsculas (ASCII) de la a A la Z, sin letras «raras» como la Ñ o la Ç, y números. En general usar un prefijo del al menos 6 caracteres y que empiecen por letra y no número. Al final, añadir un underscore (también conocido como guión bajo).

$table_prefix = 'a1b2c3_';

¿Pasa algo si dejo el wp_ por defecto? No.

El siguiente bloque a añadir es el del debug, para analizar posibles errores. Esto es muy para programadores y gente de sistemas, pero está bien dejar todas las opciones disponibles por si alguna vez hacen falta.

define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );
define( 'SCRIPT_DEBUG', false );

Por defecto lo mejor es dejarlo todo a false, y activar solo lo necesario cuando sea necesario.

otro bloque a gestionar es el de la memoria máxima a usar. Este bloque es un poco complejo y depende de muchos factores. En caso de no saber qué hacer o poner, lo mejor es no poner nada. Pero hay que tener presente que dependiendo de tu alojamiento web deberás poder configurar con más o menos suerte esto.

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

Mi recomendación es la de dejar un máximo de 128MB para el frontal, y de 256MB para el panel de administración. Con esto y una máquina «normalita» debería haber suficiente para que todo funcione correctamente.

A partir de aquí las configuraciones son bastante variadas. Teniendo en cuenta que voy a comentar sobre un sitio «normal» (y no un WordPress MultiSite), podemos revisar los siguientes elementos:

Lo primero es la activación del uso de la caché.

define( 'WP_CACHE', true );

Esto, personalmente, creo que debería venir por defecto así, pero como no viene así, pues lo activamos. Así, si el usuario intenta configurar cualquier cosa relacionada con caché, le funcionará.

Lo siguiente son las URL del sitio

define( 'WP_SITEURL', 'https://www.example.com' );
define( 'WP_HOME', 'https://www.example.com' );

Configurar la URL en el fichero de configuración evita que los manazas toquen o cambien algo y la web deje de funcionar por completo. No será la primera vez que, por un descuido, dejas el ratón en el cajetín de las URL, pulsas en la Ñ antes del Intro y la web deja de ir. O un usuario al que le han dicho que ha de tener su web con HTTP le pone la S sin haber configurado el certificado, y la historia deja de funcionar.

Lo siguiente que hago es no configurar los crones. WordPress por defecto ejecuta los crones cada vez que alguien entra en la web o en el panel de administración. No digo que sea una mala idea, pero si tu sitio consume muchos recursos, no tiene sentido hacerlo así.

define( 'DISABLE_WP_CRON', true );

Obviamente, esto implica que haya que configurar el cron directamente en el sistema de tareas del propio servidor. Hay que ejecutarlo cada minuto si no queremos que se quede nada colgado.

Ahora toca un poco de configuración para los editores.

define( 'AUTOSAVE_INTERVAL', 30 );
define( 'EMPTY_TRASH_DAYS', 7 );
define( 'WP_POST_REVISIONS', 3 );

Lo primero sirve para definir cada cuánto tiempo se auto guarda la información del editor… así, si se te cierra la ventana o algo, al menos que no hayas perdido todo. Yo lo pongo a 30 segundos.

Lo siguiente es cada cuánto tiempo se elimina la papelera. A veces nos da por eliminar comentarios, entradas o lo que sea pero nadie las vacía. Con esto se va haciendo un poco de mantenimiento. 7 días creo que es suficiente.

Y para acabar, aunque personalmente me gusta más dejarlo en false, creo que dejar un historial de 3 versiones de un contenido es también suficiente. Si alguien guarda algo y la ha liado, podrá recuperarlo si no lo tenía previamente en otro soporte.

Siguiendo con lo de que los usuarios son unos manazas, tenemos la posibilidad de que modifiquen los ficheros del sistema, de un plugin o de vete a saber qué. Para ello les bloqueamos la edición desde el panel.

define( 'DISALLOW_FILE_EDIT', true );

Puede que sea algo muy radical, pero es que ni siquiera yo suelo editar nada por el panel… no me gusta (aunque la funcionalidad es excelente) y creo que puede generar ciertos riesgos si la gente no saber lo que hace.

Para seguir con la seguridad, el acceso al panel exclusivamente por HTTPS.

define( 'FORCE_SSL_LOGIN', true );
define( 'FORCE_SSL_ADMIN', true );

Hoy en día navegamos sin pensar mucho a través de qué red, ya sea la del móvil, la de casa o una WiFi que hemos encontrado por la calle. Para evitar los riesgos de que alguien se quede con nuestro usuario y contraseña, sin duda esta opción es muy simple y necesaria.

Otra opción es la de las actualizaciones de WordPress. Y hablo de las del núcleo, no las de plugins o themes.

define( 'WP_AUTO_UPDATE_CORE', 'minor' );

En este caso lo que vamos a configurar es que WordPress se actualice automáticamente en sus versiones menores. ¿Qué significa esto? Pues el ejemplo más claro es lo que hemos vivido estos días atrás. Teníamos la versión 4.9.8, y apareció la versión 5.0, que era, para algunas instalaciones, muy complejo a nivel de compatibilidad. Pero en posteriores días han aparecido las versiones 5.0.1 y 4.9.9, que son versiones de seguridad. Si eres de los que se había quedado en la 4.9.8, el sistema no te hacía nada, y lo mejor era que, al menos, actualice automáticamente a la 4.9.9. Pues nada, con esta línea funciona así.

Depende de lo que hacemos con las imágenes y media, se nos pueden acumular un montón de versiones de una imagen.

define( 'IMAGE_EDIT_OVERWRITE', true );

Con este sistema lo que hacemos es (entre otras cosas) que al eliminar una imagen también se eliminen sus versiones de tamaños, o que al sobre escribir una imagen, también lo hagan las otras que se generan automáticamente. Simplemente mantiene el orden en la galería multimedia.

Y para acabar, la plantilla por defecto.

define( 'WP_DEFAULT_THEME', 'twentysixteen' );

Esto no significa que esa sea la plantilla que el sistema vaya a usar, sino que es la plantilla a usar en los momentos de «no sé qué hacer». Estos casos son muy de backup cuando por lo que sea una plantilla se estropea o pasa algo. A mi personalmente me gusta usar una de las Twenty que vienen con el sistema, que habitualmente es la TwentySixteen, y el resto las elimino.

Para ir acabando tenemos la concatenación de elementos.

define( 'CONCATENATE_SCRIPTS', false );
define( 'COMPRESS_CSS', false );
define( 'COMPRESS_SCRIPTS', false );

Aquí tengo mis pros y contras con la forma de hacerlo. Lo que está claro es que la primer, por temas de seguridad y ataques, es mejor dejarla a false. Las otras dos se podrían dejar a true si no usamos ningún plugin que gestione la optimización de CSS y scripts. Pero, sino, por defecto apagado todo y ya haré que un plugin de optimización se encargue de ello.

Y ya sí, para acabar, lo necesario para que WordPress funcione, la carga de los settings.

if ( ! defined( 'ABSPATH' ) )
 define( 'ABSPATH', dirname( __FILE__ ) . '/' );
require_once ABSPATH . 'wp-settings.php';

Como bien dice el propio fichero de configuración: eso no se toca.

Y así quedaría el resultado final:

<?php
define( 'DB_NAME', 'sitio_abc123' );
define( 'DB_USER', 'sitio_def456' );
define( 'DB_PASSWORD', 'abcDEF#123ghiJKL$456mnoPQR%789' );
define( 'DB_HOST', 'localhost' );
define( 'DB_CHARSET', 'utf8mb4' );
define( 'DB_COLLATE', 'utf8mb4_general_ci' );
//
define( 'AUTH_KEY', 'lu~c7DpP+I97R>2:7}fhODTYBOo1-HBLqu~3F5+ivWsyhJ>+-q+_paO*S|sT>gqs' );
define( 'SECURE_AUTH_KEY', 'xD]**8_T7fJFiHpw8ICYh/8a]b{}pc,boqK9;+`w8tgp4$L94O:+24(JNV@uE#$S' );
define( 'LOGGED_IN_KEY', '`Hch}Oba:?eX94c.EkU7Cxq5^g3_{ry]({aeiVn#Po~*$|v#eSIMjo0_M,u+}{2_' );
define( 'NONCE_KEY', 'i?M1fAF-bSaHK!S2G zX<%MpOLT$b,k,bIRZk(,VW}y+NP7X|W-fRRDGDYo~()U;' );
define( 'AUTH_SALT', 'q|ckP/*P34x7Hhf n`$epyLOU4v7U[)j.dobf-dSrQNFC :a-<-zJoc./bl@5TOF' );
define( 'SECURE_AUTH_SALT', '  OZ4-%y2|B/.^(t-#v2XR4Ea{M/^?n0{`/bi+u5=Tq*]Z/~M.` T+9LzKlFO2[E' );
define( 'LOGGED_IN_SALT', '#+q~6011Q|Ek|p%9pjHw+QiBLi|1RU2hH-tzk7x0b/urxN0WHxtL}4~{RtP{Amy,' );
define( 'NONCE_SALT', 'vy|v}qNjycpt|IY98A{%AA%c~dEM~=X3y7By+]+HoO8:-:shKq0=~H|?3k;.bqt-' );
//
$table_prefix = 'a1b2c3_';
//
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', false );
define( 'SCRIPT_DEBUG', false );
//
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );
//
define( 'WP_CACHE', true );
define( 'WP_SITEURL', 'https://www.example.com' );
define( 'WP_HOME', 'https://www.example.com' );
//
define( 'DISABLE_WP_CRON', true );
define( 'AUTOSAVE_INTERVAL', 30 );
define( 'EMPTY_TRASH_DAYS', 7 );
define( 'WP_POST_REVISIONS', false );
define( 'DISALLOW_FILE_EDIT', true );
define( 'FORCE_SSL_LOGIN', true );
define( 'FORCE_SSL_ADMIN', true );
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
define( 'IMAGE_EDIT_OVERWRITE', true );
define( 'WP_DEFAULT_THEME', 'twentysixteen' );
//
define( 'CONCATENATE_SCRIPTS', false );
define( 'COMPRESS_CSS', false );
define( 'COMPRESS_SCRIPTS', false );
//
if ( ! defined( 'ABSPATH' ) )
 define( 'ABSPATH', dirname( __FILE__ ) . '/' );
require_once ABSPATH . 'wp-settings.php';

Obviamente, este código no es de copiar y pegar, pero sí que quiero que sirva como plantilla base. Existen una cantidad ingente de parámetros más que se pueden configurar, así que si realmente te interesa mantener WordPress correctamente configurado, te invito a que le des una ojeada.