CSS Bloqueado (SRI)

Si la interfaz de administración de pronto se renderiza como texto sin estilos, o el editor pierde su barra de formato, la causa usual es un hash de Subresource Integrity (SRI) obsoleto: el checksum incrustado de la página ya no coincide con el archivo en disco tras una actualización. Esta página explica por qué sucede y cómo arreglarlo en un paso.

Qué está pasando

La interfaz de administración protege sus propios stylesheets, fuentes y scripts con SRI; cada página orientada al staff incrusta el checksum del archivo exacto que carga. Si el navegador recibe un archivo cuyo checksum no coincide con lo que la página promete, se niega a ejecutarlo o cargarlo. Esa es la protección funcionando; aquí el checksum mismo está desactualizado.

Los checksums se computan una vez, cuando la app arranca. Si uno de los archivos protegidos se reemplaza en disco mientras la app sigue corriendo (un hotfix copiado en el lugar, un asset actualizado entre pasos de un deploy manual), el servidor le sigue diciendo a los navegadores el checksum viejo mientras sirve el archivo nuevo. El desajuste bloquea el asset.

Los assets protegidos son el stylesheet propio del admin, sus definiciones de fuentes, el stylesheet y script del editor, y el script de settings: los archivos core incluidos en el bundle del admin UI. Cualquiera de ellos saliéndose de sincronía produce el mismo síntoma: el área de admin se renderiza sin estilos, con las features que dependen de esos archivos (notablemente el rich-text editor) fallando en silencio.

La corrección: reiniciar la app

Reiniciar re-computa cada hash a partir de los archivos tal como realmente son, y el síntoma desaparece. Esta es la corrección completa: nada más hace falta.

• Bajo systemd:

systemctl restart chinaski@<instance>

• Bajo hypnotoad:

hypnotoad cms.pl          # hot reload also restarts workers with fresh hashes

Luego haz un hard-refresh de la página de admin (Ctrl/Cmd-Shift-R) una vez, ya que el navegador puede tener unos fallos cacheados. Todo debería renderizarse con estilos de nuevo inmediatamente.

En despliegues estándar el script de deploy reinicia el servicio como parte de su flujo normal, así que este problema está prácticamente limitado al reemplazo manual de archivos mientras el proceso corre.

Confirmar que era SRI

1. Abre la página de admin rota y las devtools del navegador → pestaña Console/Network.
2. Un asset bloqueado aparece con un error de integridad en la consola ("Failed to find a valid digest in the 'integrity' attribute…").
3. Nombra uno de los cinco archivos protegidos: el stylesheet del admin, fonts.css, el CSS/JS del editor, o el script de settings.
4. Chequeo opcional: computa el SHA-256 del archivo y confirma que difiere del checksum incrustado en la página (ese desajuste es la definición del problema).

Síntoma relacionado: hash faltante (assets cargan sin verificación)

El caso inverso también existe. Si un archivo protegido falta o no es legible cuando la app arranca, no se computa hash para él; el log de arranque lo nombra (SRI hash failed for <file>), y las páginas cargan ese asset sin chequeo de integridad. La corrección en este caso es restaurar el archivo y reiniciar. Mientras persiste, el admin carga el asset sin la protección de integridad, algo que vale la pena notar en lugar de ignorar.

Preventivo

• Haz deploy como una unidad. Copiar archivos sobre una instancia corriendo sin reiniciar es el único disparador realista. El flujo estándar de deploy reinicia el servicio como su último paso; conserva ese hábito para los hotfixes manuales también.
• Ojo con la línea de arranque. Al boot la app registra "SRI hashes computed for 5 admin assets." Esa línea confirma los hashes vivos; su ausencia, o una advertencia individual SRI hash failed, nombra exactamente qué archivo falta.
• Recuerda el alcance. Esto cubre solo los cinco archivos del bundle de admin. Los archivos de temas y del site público no tienen ciclo de vida de SRI y no necesitan reinicios.