Configurar WordPress con la máxima potencia

Una de las razones de la popularidad de WordPress es su conocida instalación de 5 minutos. Pero para que ella sea posible el archivo wp-config.php tiene que ser breve. La conexión a la base de datos, el dominio o el idioma suelen cubrir la mayoría de las necesidades. Sin embargo, y tal como lo documenta el Códex, configurar WordPress en detalle permite tener un control más preciso sobre la eficiencia, el reporte de errores y la seguridad.

Configurar WordPress con la máxima potencia

 

 

Las directivas más prácticas

wp-config-sample.php es el modelo para la primer instalación (deberá ser renombrado a  wp-config.php).

Además de los parámetros de conexión a la base de datos, este fichero define los llamados salts (usados para la encriptación de las contraseñas) y claves (chequeos de seguridad internos) para los que WordPress ofrece el servicio de generación automático.

Hay sólo dos datos más. El más importante es el prefijo de las tablas, que por defecto es “wp_”.

Hasta hace poco, hubiese recomendado cambiarlo a cualquier otra cosa. Era para anticipar eventuales ataques de inyección SQL. Pero esto no es en realidad necesario. Existe solamente para permitir dos instancias en una misma base de datos.

$table_prefix = 'wp_';

La constante WP_DEBUG, desactivada por defecto, es la que dice a WordPress que muestre errores durante la carga de la página. (La “pantalla blanca de la muerte” es un error fatal invisible).

De nuevo, es necesaria para la etapa de desarrollo. No debería seguir activa en línea.

define ('WP_DEBUG', false);

 

Configurar WordPress, recargado

Lo más importante a tener en cuenta con wp-config.php es el contexto: desarrollo o producción. Si se trata del primer caso, la eficiencia no es un problema. En cambio, es un factor determinante al estar en línea.

El inconveniente planteado por esto es la necesidad de mantener dos wp-config.php distintos, uno en la terminal y otro en el servidor.

Por eso un desarrollador llamado Alexandre Plennevaux ideó una nueva sintaxis que permite guardar simultáneamente ambos grupos de definiciones en un solo fichero. La llamó SUPERCHARGED WP-CONFIG.PHP.

Configurar WordPress vía Supercharged
Configurar WordPress vía Supercharged

La manera en que él mismo la define es:

“Todas las globales de WordPress en un wp-config.php, listas para un nuevo proyecto.”

El concepto es sencillo y funcional: se define una variable principal para establecer el caso actual, y a partir de ella se ejecuta un switch que elige una variante.

Además, por fuera de esta última, se dejan muchas otras opciones muy potentes que sirven independientemente del contexto. Y que por lo general permanecen desaprovechadas.
 

Diseccionando las opciones de desarrollo

Así es como SUPERCHARGED… introduce ambos grupos de constantes (se omiten las relativas a la database).

Puede que la cantidad de directivas resulten excesivas de momento. Pero, a continuación, las desmenuzaré una por una con la mayor claridad posible:

define ( 'CURRENT_SERVER', 'dev' );

switch (CURRENT_SERVER) {

    /***************************************
    DEVELOPMENT SERVER. OPTIMIZED FOR DEBUGGING
    ****************************************/
    case 'dev':
        define ( 'WP_CACHE', false ); // (1)
        define ( 'WP_DEBUG', true ); // (2)
        define ( 'SAVEQUERIES', false ); // (3)
        define ( 'WP_DEBUG_LOG', false ); // (4)
        define ( 'WP_DEBUG_DISPLAY', true ); // (5)
        define ( 'SCRIPT_DEBUG', true ); // (6)
        define ( 'CONCATENATE_SCRIPTS', false ); // (7)
        // DATABASE
        define ( 'DB_NAME'..., etc... ),
        // DOMAIN & URL
        define ( 'PROTOCOL', 'http://' );
        define ( 'DOMAIN_NAME', 'localhost' );
        define ( 'WP_SITEURL', PROTOCOL . DOMAIN_NAME );
        define ( 'PATH_TO_WP', '/wp/' ); // if your WP is in subdir
        define ( 'WP_HOME', WP_SITEURL . PATH_TO_WP ); // WP root
        break;

    case 'live':
    /***************************************
    PRODUCTION SERVER. OPTIMIZED FOR SPEED.
    ****************************************/
        define ( 'WP_CACHE', true ); 
        define ( 'WP_DEBUG', false );
        define ( 'SAVEQUERIES', false );
        define ( 'SCRIPT_DEBUG', false );
        define ( 'CONCATENATE_SCRIPTS', true );
        // log errors in a file (wp-content/debug.log), don't show
        define ( 'WP_DEBUG_LOG', true );
        define ( 'WP_DEBUG_DISPLAY', false );
        define ( 'ENFORCE_GZIP', true );
        // DATABASE
        define ( 'DB_NAME', etc... ),
        // DOMAIN & URL
        define ( 'PROTOCOL', 'http://' );
        define ( 'DOMAIN_NAME', 'dominio.com' );
        define ( 'WP_SITEURL', PROTOCOL . DOMAIN_NAME );
        define ( 'PATH_TO_WP', '/' ); // if your WP is in subdir
        define ( 'WP_HOME', WP_SITEURL . PATH_TO_WP ); // WP root
        break;
    }

Al establecer valores de tipo booleano (verdadero/falso) no es necesario incluir comillas.

Diferencias entre configurar WordPress para desarrollo y producción
Breve infografía sobre las diferencias entre configurar WordPress para desarrollo y producción

 

Las diferencias entre configuraciones de desarrollo y producción, una por una

  1. WP_CACHE sirve para activar el sistema integrado de caching, lo que permitirá una mayor eficiencia sin necesidad de plugins adicionales. Según la explicación del Códex:

    “si su valor es true, incluye el script wp-content/advanced-cache.php al ejecutar wp-settings.php.”

  2. WP_DEBUG ya fue explicado, y aunque algunas referencias dicen que debe estar activo para poder encender a su vez WP_DEBUG_LOG y WP_DEBUG_DISPLAY, según mi experiencia esto no es necesario. Puede estar en falso y permitir escribir la salida de errores a un log de todas maneras, aunque teniendo la precaución de negar WP_DEBUG_DISPLAY.
  3. SAVEQUERIES sirve para examinar las consultas a la base de datos. Toda la información recolectada es almacenada en un array ($wpdb->queries).
  4. WP_DEBUG_LOG permite enviar la salida de errores a un fichero de texto plano, cuya ubicación por defecto es /wp-content/debug.log. Combinada con…
  5. WP_DEBUG_DISPLAY, que localmente puede ser true, pero más bien false en línea, posibilita ver problemas de ejecución de PHP. En el mismo navegador, o bien sólo accediendo al archivo de texto, respectivamente. (Lo más práctico es simplemente activar sólo WP_DEBUG localmente).
  6. SCRIPT_DEBUG sirve para rastrear problemas en el front-end. Según el Códex provoca que:

    “…sean servidas las versiones sin comprimir de scripts y hojas de estilo en wp-includes/js, wp-includes/css, wp-admin/js y wp-admin/css, en vez de las minificadas con extensiones .min.css y .min.js.”

  7. CONCATENATE_SCRIPTS está relacionada con la anterior. Provoca la fragmentación (en false) de todos los scripts utilizados por separado dentro del Dashboard. WordPress hace uno solo de todos los ficheros .js.

 
 

La velocidad de carga y el registro de errores

En general,  las diferencias están pensadas en función de la eficienciaWP_CACHE estará activo en línea y desactivado localmente mientras que WP_DEBUGWP_DEBUG_DISPLAY estarán como false en producción, aunque combinados con un WP_DEBUG_LOG en true.

Al tiempo de desarrollar también se puede recurrir a esta opción si por una cuestión de diseño es preferible no interferir con el flujo de la página. O, simplemente, se puede encender WP_DEBUG para ver los errores inmediatamente.

Es de notar que el log de PHP puede ser indicado a gusto incluyendo un condicional. Como, por ejemplo (el valor del path es genérico):

if (WP_DEBUG_LOG) {  
@ini_set ( 'log_errors', 'On' );   
@ini_set ( 'error_log', '/dominio/logs/php-errors.log'); 
}
La salida de depuración por defecto de WordPress
La salida de depuración por defecto de WordPress bajo el directorio /wp-content/

 
 

Una forma más larga, pero más clara de configurar la dirección web

Otra de las virtudes de SUPERCHARGED… es cómo maneja las direcciones URL. Usa hasta cinco parámetros. Podrían resultar excesivos si no fuera porque con ellos se controla la instalación local tanto como la remota con mayor precisión.

Es útil la aclaración de que, a pesar de que pueden fijarse desde la administración, wp-config.php tiene precedencia.

En el Dashboard, a través de Ajustes Principales, pueden escribirse tanto la Dirección del sitio (WP_SITEURL), que es el dominio principal de la web, como la Dirección de WordPress (WP_HOME), pensada para permitir la instalación en un subdirectorio. (Es decir que aquí se escribiría el nombre de una subcarpeta bajo la raíz www).

Configurar el Site URL de WordPress vía Supercharged
Configurar el Site URL de WordPress vía Supercharged

SUPERCHARGED…, en cambio  (a partir del comentario “DOMAIN & URL”), compone la directiva WP_SITEURL previamente concatenando PROTOCOL y DOMAIN_NAME para obtener la dirección principal, dejando la opción de incluir una barra simplemente (/) como PATH_TO_WP, y agregándola a su vez.

Toda la cadena así compuesta se asigna finalmente a WP_HOME. En más pasos de los que podrían esperarse, pero evitando contradicciones entre los valores.

 
 

Más allá de la configuración usual

Muchos plugins pueden usar constantes especiales para integrarse con WordPress. Pero la verdad es que ya es posible usar una gran cantidad de ellas sin necesidad de instalar nada más.

Pueden controlar el número de revisiones de un post dentro de la base de datos o cuánto tiempo quedará en la Papelera, hasta el hecho de bloquear cualquier pedido HTTP que no provenga del propio dominio.

SUPERCHARGED… incluye varias directivas luego del comentario titulado “SETTINGS COMMON TO ALL SERVERS(“CONFIGURACIONES COMUNES A TODOS LOS SERVIDORES”).

Son éstas en un orden ligeramente diferente:
 

Configurar WordPress con constantes avanzadas relativas al contenido

// Idioma de WordPress: el defecto es 'en_EN'
define ( 'WPLANG', 'es_AR' ); // español de Argentina

// Num. de revisiones, FALSE para quitarlas
define ( 'WP_POST_REVISIONS', 3 ); 

// Intervalo de autoguardado en segundos
define ( 'AUTOSAVE_INTERVAL', 120 ); 

// Días en la Papelera (0 para deshabilitarla)
define ( 'EMPTY_TRASH_DAYS', 7 );
// Si no se publicará via email, 
// decrementar este valor en segundos.
// Ej.: 1 día (en vez de 5 minutos)
define ( 'WP_MAIL_INTERVAL', 86400 );

Este grupo de definiciones ayuda a reducir el tamaño de la base de datos, limitando el número de revisiones. Así como también permite aumentar el tiempo de espera para autoguardar el texto, o incluso desactivar permanentemente la Papelera.
 

Configurar WordPress con constantes avanzadas relativas a la seguridad

Estas medidas son críticas y por eso vienen comentadas inicialmente, aunque entre ellas haya algunas que se recomiendan como buenas prácticas:

// Quita "add new plugins" del Dashboard 
// (no recomendado)
define ( 'DISALLOW_FILE_MODS', false );
// Deshabilita la edición de themes y plugins 
// en el Dashboard (recomendado)
define ( 'DISALLOW_FILE_EDIT', true );
// Deshabilita wp_cron. 
// Recomendado sólo si se crea un cronjob real para /wp-cron.php
define ( 'DISABLE_WP_CRON', true ); 

// SSL: fuerza una conexión segura al Dashboard 
if ( PROTOCOL === 'https://' ) { 
    define ( 'FORCE_SSL_LOGIN', true ); 
    define ( 'FORCE_SSL_ADMIN', true ); 
}

FORCE_SSL_LOGIN fuerza una conexión segura sólo para el login, mientras que FORCE_SSL_ADMIN la mantiene a través de toda la sesión en el Dashboard.

Edición de plugins en línea
¿Para qué editar plugins en línea cuando ni siquiera deberían ser modificados?

 

Configurar WordPress con constantes avanzadas relativas a directorios personalizados

WordPress tiene una estructura específica de directorios. Algunos usuarios notan que esto es un riesgo de seguridad. Pero cambiarla podría generar complicaciones con las plantillas o con determinados plugins.

Hay una serie de medidas más efectivas a este respecto, como la serie de permisos de las carpetas. O el borrado de ciertos scripts (por ejemplo el de upgrade).

Aún así es posible cambiar los valores por defecto con las siguientes constantes (desactivadas inicialmente):

// renombrar la carpeta wp-content
define ( 'WP_CONTENT_DIR', dirname(__FILE__) . '/mi-contenido' );
define ( 'WP_CONTENT_URL', WP_SITEURL . '/mi-contenido' );
// renombrar la carpeta de plugins
define ( 'WP_PLUGIN_DIR', WP_CONTENT_DIR . '/mis-plugins' ); 
define ( 'WP_PLUGIN_URL', WP_CONTENT_URL . '/mis-plugins' ); 
// renombrar la carpeta uploads 
define ( 'UPLOADS', '/mis-subidas' );

La locación de wp-content requiere direcciones absolutas y URIs completos. SUPERCHARGED… la integra con la configuración del host ya establecida, es decir con WP_SITEURL.

Cambié cómo se compone la dirección de WP_PLUGIN_DIR y WP_PLUGIN_URL añadiendo la constante ya rellenada para wp-content…, es decir, la carpeta que conceptualmente aloja todas las extensiones del usuario de WordPress.

El destino de los uploads se comporta de manera diferente. Es siempre relativo a ABSPATH, es decir el root del servidor. En este caso quedaría separada de wp-content, por fuera de ésta y a su mismo nivel jerárquico.

El path de las plantillas no se puede cambiar, pero aparentemente se puede registrar un directorio adicional para ellas utilizando:

register_theme_directory ( WP_CONTENT_DIR . '/mis-themes' );

Algo así resultaría del código superior:

/dominio.com/mi-contenido/
/dominio.com/mi-contenido/mis-plugins/
/dominio.com/mi-contenido/themes/
/dominio.com/mi-contenido/mis-themes/
/dominio.com/mis-subidas/

 

Configurar WordPress con constantes avanzadas relativas a memoria, crons y actualizaciones automáticas

Este tipo de recursos sólo son necesarios en casos excepcionales, pero es bueno conocerlos.

// Asignación de memoria
define ( 'WP_MEMORY_LIMIT', '32M' );
// Admin area específicamente
define ( 'WP_MAX_MEMORY_LIMIT', '32M' );
// Cambiar el tema por defecto Twenty-***
define ( 'WP_DEFAULT_THEME', 'mi-tema' );
// Tabla personalizada para Usuarios
define ( 'CUSTOM_USER_TABLE', $table_prefix . 'usuarios' );
define ( 'CUSTOM_USER_META_TABLE', $table_prefix . 'usuarios_meta' );

De nuevo, un nombre personalizado para las tablas de usuario no sería útil si alguien obtuviera acceso a la base de datos.

// Más de Cron
// Intervalo de repetición del cron
define( 'WP_CRON_LOCK_TIMEOUT', 120 ); 
// Problemas con el cron? 
// Probar esto como último recurso.
define( 'ALTERNATE_WP_CRON', true );

Aunque las siguientes constantes dictan el comportamiento de WordPress respecto a las actualizaciones automáticas, según mi experiencia es preferible utilizar Easy Updates Manager. Es un añadido poderoso al Dashboard con una interfaz visual agradable y práctica para regular los diferentes niveles de automatic upgrades.

Vista principal de Easy Updates Manager
Vista principal de Easy Updates Manager

De todas maneras, existen las directivas siguientes para poder configurar sin requerir ningún plugin. Si WordPress está bajo control de versiones, algunas de ellas podrían no llegar a activarse:

// Auto-updates
// Deshabilitar todas las actualizaciones 
// (no recomendado)
define ( 'AUTOMATIC_UPDATER_DISABLED', true );
  
// Deshabilitar todas las actualizaciones 
// del Core (no recomendado)
define ( 'WP_AUTO_UPDATE_CORE', false ); 
// Habilitar actualizaciones del Core,
// menores y mayores (no recomendado)
define ( 'WP_AUTO_UPDATE_CORE', true ); 
// Habilitar act. menores del Core
// (por defecto) (recomendado)
define ( 'WP_AUTO_UPDATE_CORE', 'minor' );
// Deshabilitar actualizaciones de tablas 
// de la DB (no recomendado)
define ( 'DO_NOT_UPGRADE_GLOBAL_TABLES', true ); 

Esta última variable evita operaciones automáticas en la base de datos. Es para sitios con una gran cantidad de usuarios, que necesiten elegir el momento de un pesado ajuste en tal caso.

La diferencia entre “mayor” y “menor” se explica por la distancia en la numeración de versiones. De un 4.3 a un 4.4 sería el primer caso; el segundo, de un 4.3.1 a 4.3.2, por ejemplo.

 
 

Bonus track: configurar WordPress para bloquear pedidos HTTP que no provengan del propio dominio

En casos de extrema urgencia, esta poderosa variable puede bloquear todo pedido HTTP que no provenga de localhost o el propio dominio.

Activándola no funcionarían ni siquiera las actualizaciones de plugins desde el Dashboard (sin agregar el dominio “wordpress.org” a la lista de exclusiones).

Según el Códex:

Bloquea pedidos de URLs externos definiendo WP_HTTP_BLOCK_EXTERNAL como true. WP_ACCESSIBLE_HOSTS permitirá el acceso a hosts adicionales. El formato de la constante WP_ACCESSIBLE_HOSTS es una lista separada por comas de hostnames a aprobar. Hay soporte para dominios con wildcards, por ejemplo: *.wordpress.org agrega todos los subdominios de wordpress.org

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', '*.wordpress.org,*.github.com' );

¡Si esta información te resulta útil, tus comentarios y sugerencias son bienvenidos!

12.01.2018 (23.08.2018)

Suscribite para recibir lo último en Design & WordPress

Dejá un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Do NOT follow this link or you will be banned from the site!