Feito com Chinaski

Favicon

O favicon do site é gerado uma vez, a partir de uma única imagem-fonte enviada, e implantado automaticamente a cada build. Envie-o em Settings (o controle de upload de favicon); a aplicação gera todos os tamanhos que navegadores e web apps instaláveis esperam.

Upload

O controle de favicon das Settings aceita arquivos PNG, JPEG, SVG ou ICO de até 5 MB. Ao salvar:

  • A fonte passa por uma verificação de tamanho (“roughly square”: uma proporção não mais larga que ~1,25:1, porque escalar uma wordmark larga em um ícone produz uma fatia inutilizável). Uploads não quadrados são rejeitados com uma mensagem clara em vez de mutilados.
  • Um conjunto de ícones gerado é produzido: favicon-96x96.png, apple-touch-icon.png (180×180), web-app-manifest-192x192.png, web-app-manifest-512x512.png, um wrapper SVG incorporando a renderização de 96×96 (favicon.svg) e um favicon.ico (tomado verbatim quando você enviou um ICO, caso contrário derivado do PNG de 96×96).
  • Os arquivos vão para dois lugares: o diretório assets/ (a fonte da verdade para o próximo build estático) e public/ (para que o CMS possa servi-los imediatamente).
  • O salvamento dispara um rebuild, e a ação é auditada (“Favicon updated by <username>”).

Instalações novas vêm com um conjunto padrão de fábrica (a marca do Chinaski), que o upload substitui.

Onde os favicons aparecem

No build, o conjunto completo de favicons é copiado para a raiz do site da saída (não sob nenhum prefixo de idioma) e incluído no manifest de build assinado. O partial padrão _head.tt então emite as tags <link> de favicon para os sites habilitados: favicon PNG, apple-touch-icon e o atalho .ico.

Removendo

O controle de exclusão de favicon das Settings remove a fonte enviada e todas as derivadas dos dois diretórios, limpa a configuração e dispara um rebuild. O estado restaurado é o conjunto padrão de fábrica (ou nenhuma tag de favicon no <head> se o conjunto padrão de fábrica estiver ausente).

Modos de falha que vale conhecer

  • O favicon não está funcionando? O conjunto gerado vive em assets/; se o build estático acontece em outro lugar, uma entrada no log de build avisa. Falha na geração do favicon.svg é registrada como aviso (não fatal), enquanto o conjunto PNG/ICO é o que o <head> referencia.
  • Sobras com dono root: os arquivos gerados e copiados substituem em vez de modificar; um favicon solto com dono root deixado por uma ação de ferramenta de deploy não consegue travar o salvamento, pois o caminho de escrita exige gravabilidade em nível de diretório em vez de propriedade em nível de arquivo.
  • Se o processo não consegue escrever no diretório de assets de forma alguma, o erro flash nomeia o diretório e aponta para propriedade/permissões: essa é a sua correção, não tentar de novo.
Leia este site em