CSS bloqueado (SRI)

Se a interface admin de repente renderiza como texto sem estilo, ou o editor perde sua barra de formatação, a causa habitual é um hash de Subresource Integrity (SRI) obsoleto: o checksum embutido na página não corresponde mais ao arquivo em disco após uma atualização. Esta página explica por que isso acontece e como corrigir em uma etapa.

O que está acontecendo

A interface admin protege suas próprias folhas de estilo, fontes e scripts com SRI: cada página voltada para a equipe embute o checksum do arquivo exato que ela carrega. Se o navegador recebe um arquivo cujo checksum não corresponde ao que a página promete, ele se recusa a executá-lo ou carregá-lo. Essa é a proteção funcionando; aqui o checksum em si está desatualizado.

Os checksums são calculados uma vez, quando a aplicação inicia. Se um dos arquivos protegidos é substituído em disco enquanto a aplicação continua rodando (um hotfix copiado no lugar, um asset atualizado entre etapas de um deploy manual), o servidor continua dizendo aos navegadores o checksum antigo enquanto serve o arquivo novo. A discrepância bloqueia o asset.

Os assets protegidos são a própria folha de estilo do admin, suas definições de fonte, a folha de estilo e o script do editor, e o script de settings: os arquivos de core empacotados da UI admin. Qualquer um deles saindo de sincronia produz o mesmo sintoma: a área admin renderiza sem estilo, com funcionalidades que dependem desses arquivos (notavelmente o editor de rich-text) falhando silenciosamente.

A correção: reinicie a aplicação

Reiniciar recalcula cada hash a partir dos arquivos como realmente estão, e o sintoma desaparece. Esta é a correção completa; nada mais é preciso.

• Sob systemd:

systemctl restart chinaski@<instance>

• Sob hypnotoad:

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

Depois faça um hard-refresh da página admin (Ctrl/Cmd-Shift-R) uma vez, já que o navegador pode ter algumas falhas em cache. Tudo deve renderizar com estilo de novo imediatamente.

Em deploys padrão o script de deploy reinicia o serviço como parte de seu fluxo normal, então esse problema fica na prática limitado à substituição manual de arquivos enquanto o processo está rodando.

Confirmando que era SRI

1. Abra a página admin quebrada e as devtools do navegador → aba Console/Network.
2. Um asset bloqueado aparece com um erro de integridade no console ("Failed to find a valid digest in the 'integrity' attribute…").
3. Ele nomeia um dos cinco arquivos protegidos: a folha de estilo do admin, fonts.css, o CSS/JS do editor ou o script de settings.
4. Verificação opcional: calcule o SHA-256 do arquivo e confirme que difere do checksum embutido na página (essa discrepância é a definição do problema).

Sintoma relacionado: hash ausente (assets carregam sem verificação)

O caso inverso também existe. Se um arquivo protegido está ausente ou ilegível quando a aplicação inicia, nenhum hash é calculado para ele: o log de inicialização o nomeia (SRI hash failed for <file>), e as páginas carregam aquele asset sem verificação de integridade. A correção, neste caso, é restaurar o arquivo e reiniciar. Enquanto persistir, o admin carrega o asset sem a proteção de integridade, o que vale notar em vez de ignorar.

Como prevenir

• Faça o deploy como uma unidade. Copiar arquivos sobre uma instância rodando sem reiniciar é o único gatilho realista. O fluxo padrão de deploy reinicia o serviço como sua última etapa; mantenha esse hábito também para hotfixes manuais.
• Observe a linha de inicialização. No boot a aplicação registra "SRI hashes computed for 5 admin assets." Essa linha confirma hashes ao vivo; sua ausência, ou um aviso individual SRI hash failed, nomeia exatamente qual arquivo está ausente.
• Lembre-se do escopo. Isso cobre apenas os cinco arquivos do bundle do admin. Arquivos de tema e do site público não têm ciclo de vida de SRI e não precisam de reinícios.