Configurar el cache de objetos con Redis o Memcached
Primero: ¿qué puede tu PHP?
La cache de objetos habla con Redis o Memcached, y para eso PHP necesita la extensión correspondiente. Kakapo lo comprueba en tiempo de ejecución mirando si la clase Redis o Memcached está realmente cargada. Un servicio Redis en marcha no basta por sí solo: sin la extensión, PHP no puede hablar con él. Si falta, la entrada de la lista de selección aparece desactivada y al lado se indica qué paquete falta (por ejemplo «pecl install redis» o el paquete de la distribución php<version>-redis; después hay que reiniciar PHP). Si Kakapo solo encuentra la extensión más antigua «memcache», sin la d, lo dice expresamente — no se usa, porque le faltan la consulta agrupada getMulti y la transmisión binaria. Si no está ninguna de las dos extensiones, aquí no puedes avanzar; eso es cosa de tu proveedor de alojamiento, no del plugin.
Introducir los datos de conexión
El host suele ser 127.0.0.1. Un esquema como «http://» se rechaza, porque aquí solo va el nombre de host o la IP. Para un socket Unix introduces su ruta (p. ej. /var/run/redis/redis.sock) y pones el puerto a 0. El puerto en Redis suele ser 6379 y en Memcached 11211; se permite de 0 a 65535. Si cambias de conexión, Kakapo ajusta automáticamente el puerto estándar, siempre que el anterior siguiera siendo el estándar. El número de base de datos (de 0 a 255) solo existe en Redis y separa este sitio de otras aplicaciones en el mismo servidor. Usuario y contraseña solo los necesitas si tu Redis trabaja con ACL (a partir de Redis 6) o si Memcached exige SASL. El prefijo de claves separa entre sí dos instalaciones de WordPress en el mismo servidor de memoria — si el campo queda vacío, se deriva un prefijo de la dirección de tu sitio (kwpp más ocho caracteres). Se permiten letras, cifras y _ . : -, como máximo 40 caracteres. La validez por entrada está preajustada en 86400 segundos; se permite de 0 a 2592000. 0 significa «no caduca nunca» — eso tiene consecuencias para el vaciado, ver más abajo.
Probar la conexión antes de escribir nada
El botón «Probar la conexión» establece realmente una conexión, escribe una clave de prueba (con una validez de 30 segundos), la vuelve a leer, la compara carácter por carácter con el valor escrito y la borra de nuevo. Solo cuando el valor regresa sin cambios se considera superada la prueba — un simple «connect() no ha devuelto false» sería demasiado poco: Redis puede estar conectado y aun así ser de solo lectura (réplica), y Memcached acepta conexiones antes de tener memoria. Para todo el ciclo rige un límite de tiempo de un segundo. La duración medida y algunos datos del servidor (versión, memoria ocupada, número de entradas, duración) aparecen después en la tarjeta. Si la prueba falla, ahí figura el motivo concreto: no accesible, autenticación rechazada, base de datos no seleccionable. La prueba se ejecuta exclusivamente en el área de administración o por cron — durante la construcción de la página de un visitante nunca se establece una conexión de prueba.
Escribir el drop-in — y qué ocurre al hacerlo
La cache de objetos vive en el archivo wp-content/object-cache.php. WordPress lo carga muy pronto, antes que cualquier plugin. Antes de escribirlo, Kakapo muestra una vista previa: qué archivo se crea, qué datos de acceso contiene, qué queda después en el servidor de memoria y cómo es el camino de vuelta. Si algo lo impide — extensión ausente, un drop-in ajeno en ese lugar, wp-content sin permisos de escritura, plantilla ausente —, el botón está desactivado y el motivo aparece encima; la comprobación se repite en el servidor al escribir. Para confirmar, escribes INSTALLIEREN. Primero se escribe en un archivo vecino, cuya sintaxis comprueba el propio PHP (siempre que exec() esté permitido y haya un binario de PHP accesible), y solo después se renombra a su sitio y se le asignan los permisos 0644. El motivo del rodeo: un object-cache.php escrito a medias sería un error anterior a cualquier plugin — el sitio quedaría en blanco, también la página de administración desde la que querías deshacerlo. Además, cada escritura recibe su propia generación, para que las entradas de antes de una eliminación no vuelvan a valer de golpe (si no, reaparecería, por ejemplo, el nombre antiguo del blog y los administradores conectados perderían su sesión). Si en ese lugar ya hay un drop-in ajeno, no se sobrescribe ni se borra.
En funcionamiento: leer las cifras, vaciar, eliminar
En «Funcionamiento en curso» aparecen las cifras de esta única visita a la página: establecimiento de la conexión en milisegundos, aciertos y fallos, cuántos de ellos vinieron del servidor de memoria, cuántas peticiones fueron hacia allí y cuánto duraron. Una estadística a lo largo del tiempo no existe a propósito: llevarla costaría en cada visita más de lo que mide. «Vaciar la cache de objetos» cambia la sal de las claves en lugar de enviar FLUSHDB o flush_all: así ninguna clave antigua apunta ya a una entrada válida, pero los datos de otras aplicaciones en el mismo servidor quedan intactos. Las entradas huérfanas caducan según la validez ajustada — si está en 0, no caducan nunca y se van acumulando hasta que Redis o Memcached hagan limpieza por su cuenta. Si cambias la configuración, sigue valiendo lo que dice el archivo; Kakapo avisa de la diferencia y ofrece «Actualizar el drop-in». «Eliminar el drop-in» borra exactamente un archivo, sin dejar ninguna fila en la base de datos ni ningún calendario; al desactivar el plugin también desaparece. Si no quieres tener la contraseña en texto plano dentro del archivo, la defines como KWPP_OC_AUTH en el wp-config.php y dejas el campo vacío — la constante tiene preferencia. Lo mismo vale para host, puerto, usuario, base de datos y prefijo (KWPP_OC_HOST, KWPP_OC_PORT, KWPP_OC_USER, KWPP_OC_DB, KWPP_OC_PREFIX); así un cambio de servidor no exige reescribir el drop-in.