Show HN: Pages CMS – Um CMS para GitHub

Artigo original ↗ Discussão no Hacker News ↗

Um novo projeto open source, Pages CMS, oferece um sistema de gerenciamento de conteúdo baseado em GitHub que se apoia em geradores de sites estáticos existentes como Jekyll, Hugo, Eleventy, Astro e Next.js, com o objetivo de recriar uma experiência de edição no estilo WordPress sem prender os usuários a um provedor de hospedagem específico. Comentadores elogiam sua UX mais simples em comparação com ferramentas como Decap/Netlify CMS e TinaCMS, apreciam a auto-hospedagem fácil em serviços como Cloudflare Pages e destacam recursos como suporte a múltiplos repositórios, tipos de conteúdo configuráveis e edição rich-text. Os principais desafios e itens do roadmap incluem melhor onboarding por meio de configurações geradas automaticamente, suporte aprimorado a coleções MDX e HTML, opções de armazenamento de mídia (S3/R2) e compatibilidade mais ampla com provedores Git além do GitHub.

Recepção Geral e Casos de Uso Alvo

  • Muitos comentaristas estão entusiasmados, especialmente os que sentem falta do Forestry ou estão insatisfeitos com Decap/Netlify CMS e Tina.
  • Casos de uso populares: blogs e sites de documentação construídos com Hugo, Jekyll, Eleventy, Astro, Next.js e outros SSGs, facilitando para usuários não técnicos editarem conteúdo em repositórios Git.
  • Alguns veem isso exatamente como a “camada fina de CMS em cima do GitHub” que vinham desejando.

Configuração, Definição e UX

  • As pessoas elogiam a UI/UX e relatam tê-lo colocado para rodar na Cloudflare em minutos.
  • Outros observam que a integração ainda não é totalmente “clicar e pronto”; descobrir a configuração das páginas e os esquemas de conteúdo ainda exige esforço.
  • Vários pedem um assistente de configuração que infira tipos de conteúdo e campos a partir de pastas e front matter existentes; o autor indica que isso está planejado.

Formatos de Conteúdo e Integração com SSG

  • Funciona bem com front matter em Markdown para SSGs comuns.
  • Limitações atuais: o suporte a MDX é parcial (arquivos únicos via modo “code” funcionam; coleções e editor rico ainda não estão sólidos).
  • Alguns usuários de Jekyll não entendem como o “body” é mapeado quando ele é apenas implícito após o front matter.
  • Há demanda por melhor suporte a HTML e coleções MDX, data a partir do nome do arquivo para Jekyll, e coleções YAML planas em vez de um arquivo por entrada.

Autenticação, Hospedagem e Provedores Git

  • Apenas GitHub é suportado no momento; o código pode ser hospedado em qualquer lugar (por exemplo, Cloudflare Pages), e o CMS é puramente frontend mais pequenas funções de autenticação.
  • O OAuth do GitHub exige amplo acesso ao repositório; comentaristas ficam desconfortáveis, mas tokens de acesso pessoal com permissões granulares e auto-hospedagem ajudam a mitigar isso.
  • Alguns querem fortemente suporte para GitLab, Bitbucket, Gitea ou uma API Git genérica; Git genérico está atualmente fora do escopo.

Tratamento de Mídia e Armazenamento

  • O editor de rich text inicialmente quebrou quando media não estava configurado; correções rápidas foram lançadas.
  • Usuários pedem S3/R2 e serviços de upload de terceiros; o suporte a S3/R2 está sendo trabalhado ativamente.
  • A mídia pode ser colocada junto das publicações configurando filtros nas extensões de arquivo.

Comparações, Preço e Filosofia

  • Comparado com frequência com Decap, Static CMS, Keystatic, Tina, Statamic, Lektor, Publii e CloudCannon.
  • Os principais diferenciais discutidos: UX mais simples que Decap, roda totalmente online ao contrário do modo desktop do Keystatic e não exige hospedagem com um provedor específico.
  • O projeto é licenciado sob MIT e pode ser auto-hospedado; menciona-se uma futura camada “Pro” para recursos avançados, o que gera algum ceticismo sobre o status gratuito de longo prazo.