«La caché Opcode no está activada»: cómo saber si el aviso de Salud del sitio es real

Si entraste hace poco a Herramientas → Salud del sitio, quizás viste una recomendación nueva: «La caché Opcode no está activada», con una etiqueta de rendimiento y un enlace a la documentación de PHP que no aclara mucho si no trabajas con servidores.

La pregunta lógica es: ¿tengo que hacer algo? En la mayoría de los casos, no. La caché ya funciona y es WordPress el que no logra verla. Pero «la mayoría» no es «siempre», así que vamos a comprobarlo.

Qué es OPcache, en simple

WordPress está escrito en PHP. Cada vez que alguien visita tu sitio, el servidor tiene que «traducir» ese código a instrucciones que entiende la máquina. OPcache guarda esa traducción ya hecha para no repetirla en cada visita. Es como tener la receta memorizada en vez de leerla desde cero cada vez que cocinas. Es de las cachés que más se notan.

Por qué aparece el aviso ahora

La comprobación llegó con WordPress 7.0. Para hacerla, WordPress le pregunta a PHP por el estado de OPcache con la función opcache_get_status(). Si no recibe una respuesta clara de que está activo, muestra el aviso.

El problema es que hay dos configuraciones muy comunes en las que esa función no confirma nada, aunque OPcache esté trabajando a full:

• Caché solo en disco. Algunos servidores guardan OPcache en archivos en vez de en memoria compartida (opcache.file_cache_only). En ese modo la función responde que la caché en memoria no está activa, aunque la de disco sí lo esté.
• Consulta bloqueada por el hosting. En hostings compartidos es habitual restringir esa función (con opcache.restrict_api), porque podría mostrar información de archivos de otros clientes del mismo servidor.

El aviso no dice «OPcache está apagado». Dice «WordPress no pudo comprobar que esté encendido». No es lo mismo.

Cómo comprobarlo sin dejar tu servidor a la vista

La receta típica es subir un archivo info.php con phpinfo(). Funciona, pero tiene un riesgo: mientras exista, cualquiera puede ver la configuración completa de tu servidor. Y es fácil olvidarse de borrarlo.

Una alternativa más segura: un pequeño mu-plugin que muestra solo los datos de OPcache, y solo a administradores. Guárdalo como wp-content/mu-plugins/cwp-ver-opcache.php:

<?php
/**
 * Plugin Name: Ver estado de OPcache (Curso WordPress)
 * Description: Visita /wp-admin/?cwp_opcache=1 siendo administrador.
 */

add_action( 'admin_notices', function () {
	if ( ! isset( $_GET['cwp_opcache'] ) || ! current_user_can( 'manage_options' ) ) {
		return;
	}
	$datos = array(
		'Extensión cargada'       => extension_loaded( 'Zend OPcache' ) ? 'sí' : 'no',
		'opcache.enable'          => ini_get( 'opcache.enable' ),
		'opcache.file_cache_only' => ini_get( 'opcache.file_cache_only' ),
		'opcache.file_cache'      => ini_get( 'opcache.file_cache' ),
		'opcache.restrict_api'    => ini_get( 'opcache.restrict_api' ),
	);
	echo '<div class="notice notice-info"><p><strong>OPcache en este servidor:</strong></p><ul>';
	foreach ( $datos as $clave => $valor ) {
		if ( false === $valor ) {
			$valor = '(no existe)';
		} elseif ( '' === $valor ) {
			$valor = '(vacío)';
		}
		echo '<li><code>' . esc_html( $clave ) . '</code>: ' . esc_html( $valor ) . '</li>';
	}
	echo '</ul></div>';
} );

Entra a tudominio.cl/wp-admin/?cwp_opcache=1 y verás el resumen arriba. ini_get() lee la configuración aunque el hosting haya bloqueado la función de estado, por eso aquí sí ves la verdad. Cuando termines, puedes borrar el archivo o dejarlo: no muestra nada a nadie más.

No uses la consola para esto. Si tienes SSH, es tentador escribir php -i | grep opcache, pero la consola usa su propia configuración (opcache.enable_cli, que suele estar apagada). Te diría «apagado» aunque la web lo tenga encendido. Lo que importa es lo que ve PHP desde la web.

Los tres escenarios

1. **Extensión cargada: sí, y opcache.enable en 1.** OPcache funciona; el aviso es un falso positivo. Si además file_cache_only está en 1 o restrict_api tiene una ruta, ya sabes por qué WordPress no lo ve. No tienes que hacer nada.
2. **Extensión cargada: sí, pero opcache.enable en 0 o vacío. Está disponible pero apagado. En cPanel revisa Seleccionar versión de PHP → Opciones o el MultiPHP INI Editor**; si no lo encuentras, pídeselo al soporte. Aquí sí vas a ganar velocidad.
3. Extensión cargada: no. Tu PHP no tiene OPcache. Si tu servidor es un VPS con cPanel, instálalo desde WHM → EasyApache 4 (la extensión se llama opcache dentro de cada versión de PHP) o por SSH con dnf install ea-php83-php-opcache (cambia 83 por tu versión) y reinicia PHP-FPM. Si es un hosting compartido que no lo ofrece, es una buena razón para pensar en cambiarte.

Cómo quitar el aviso (solo si es falso)

Si confirmaste que estás en el escenario 1 y el aviso te molesta, puedes quitar solo esa prueba de Salud del sitio. Este código busca la prueba por su nombre, sin depender de cómo se llame exactamente en tu versión de WordPress:

<?php
/**
 * Plugin Name: Ocultar falso positivo de OPcache (Curso WordPress)
 */

add_filter( 'site_status_tests', function ( $tests ) {
	foreach ( array( 'direct', 'async' ) as $tipo ) {
		foreach ( array_keys( $tests[ $tipo ] ?? array() ) as $clave ) {
			if ( false !== stripos( $clave, 'opcode' ) || false !== stripos( $clave, 'opcache' ) ) {
				unset( $tests[ $tipo ][ $clave ] );
			}
		}
	}
	return $tests;
} );

Úsalo con criterio. Si algún día te cambias de hosting, borra este archivo para que WordPress vuelva a avisarte si el servidor nuevo no tiene OPcache.

¿Te salió algo distinto a los tres escenarios? Comparte en el foro lo que mostró el resumen del mu-plugin y tu tipo de hosting, y te decimos si hay algo que activar.