Pages CMS: um CMS para sites estáticos que vive no seu repositório GitHub

Um site estático é rápido, barato de alojar e quase impossível de partir. O problema aparece no dia em que o cliente quer mudar o horário de funcionamento, trocar uma fotografia ou publicar uma novidade. Ou me liga a mim, ou lhe instalo um WordPress que ele não precisava. O Pages CMS resolve exatamente esse meio-termo, e é por isso que o tenho andado a testar.

O que é

O Pages CMS é um CMS open source (licença MIT) para repositórios GitHub. Não guarda o conteúdo numa base de dados própria: lê e escreve diretamente os ficheiros Markdown, YAML, JSON ou de imagem que já estão no repositório. Cada gravação no editor é um commit.

Não substitui o gerador do site nem o alojamento. É apenas a camada de edição por cima de um site feito com Astro, Hugo, Jekyll, Eleventy, Next.js, Nuxt, Docusaurus e afins. Quem constrói e publica continua a ser o seu pipeline de sempre.

Como funciona

Liga-se através de uma GitHub App com acesso aos repositórios que escolher. Depois basta um ficheiro .pages.yml na raiz do repositório a descrever o que é editável: onde ficam as imagens, que coleções existem e que campos tem cada entrada.

media: media

content:
  - name: posts
    label: Artigos
    type: collection
    path: content/posts
    fields:
      - name: title
        label: Título
        type: string
      - name: date
        label: Data
        type: date
      - name: cover
        label: Imagem
        type: image
      - name: body
        label: Texto
        type: rich-text

Com isto, o cliente vê uma lista de artigos, um formulário com título, data, imagem e um editor de texto rico, e um gestor de media com upload por arrastar e largar. Quando grava, o Pages CMS faz o commit; o seu Cloudflare, Vercel ou Netlify vê o push e volta a publicar o site.

O que traz de base

• Catorze tipos de campo: texto curto, texto longo, número, booleano, data, imagem, ficheiro, seleção, código, texto rico, UUID, objetos, blocos e referências a outras entradas.
• Coleções e ficheiros únicos: uma pasta de artigos ou um único ficheiro de definições do site, como contactos e horários.
• Colaboradores por email: convida-se o cliente pelo email e ele entra sem precisar de conta GitHub.
• Ações: botões no editor que disparam workflows de GitHub Actions, como um "Publicar em produção".
• Pesquisa e interface móvel: dá para corrigir um erro no telemóvel.

Para quem é, e para quem não é

Esta é a parte que mais importa, porque o Pages CMS é muito bom num caso concreto e fraco fora dele.

Os limites que convém conhecer

Nada disto é um defeito escondido. São consequências diretas de "o conteúdo vive no Git". Mas convém sabê-las antes de prometer algo a um cliente.

• Só GitHub. É o único fornecedor de repositórios suportado. Se o projeto está noutro lado, fica de fora.
• Não constrói nem publica o site. Cada gravação é um commit; a publicação depende de ter um deploy automático ligado a cada push. Sem isso, o cliente grava e nada muda online. Conte também com os segundos, ou minutos, que o build demora.
• As imagens vão para o repositório. Tudo o que o cliente carrega fica no Git para sempre, mesmo depois de apagado. Com o tempo o repositório cresce. O armazenamento externo em AWS S3 ou Cloudflare R2 aparece no site como "em breve" à data deste artigo.
• Sem fluxo editorial documentado. Não encontrei na documentação rascunhos com aprovação, trabalho por pull request nem pré-visualização ao vivo do site. Agendamento de publicações, permissões granulares por tipo de conteúdo, analytics e comentários estão todos marcados como "em breve".
• Os colaboradores têm poderes limitados, e os commits não são deles. Quem entra por email edita conteúdo e media, mas não mexe na configuração nem gere outros colaboradores. Por omissão, os commits saem com a identidade da GitHub App; para aparecer o nome de quem editou é preciso ativar commit.identity: user nas definições.
• Alguém tem de escrever o .pages.yml. O cliente não configura nada sozinho. Os campos, as coleções e os caminhos são trabalho de quem fez o site, e mudam sempre que a estrutura do conteúdo muda.
• Alojar por conta própria dá trabalho. A versão 2 precisa de PostgreSQL, de uma GitHub App criada por si, de segredos de autenticação e de um fornecedor de email (Resend ou SMTP) para os convites e o login. A base de dados guarda utilizadores, colaboradores e uma cache dos ficheiros do GitHub.

Versão alojada ou instalação própria

Há três caminhos, todos gratuitos: usar a versão alojada em app.pagescms.org, fazer deploy na Vercel com um clique, ou alojar em servidor próprio. Para a maioria dos sites de clientes, a versão alojada chega e não há nada para manter. A instalação própria faz sentido quando quer controlar o domínio do editor, a origem dos emails ou onde ficam os dados dos colaboradores. Nesse caso, lembre-se de que os colaboradores vivem na base de dados e não no repositório, por isso mudar de instância obriga a migrá-los.

Veredicto

Para o caso de "entreguei um site estático e o cliente quer atualizar o conteúdo sem me ligar", o Pages CMS é das opções mais simples que existem: um ficheiro de configuração, um convite por email, e o site continua estático, rápido e barato. Quando o projeto precisa de fluxo editorial, dados dinâmicos ou muito media, o problema já não é de CMS para sites estáticos, e vale mais escolher outra ferramenta desde o início.