Nuno Nebeker

Como Eu Uso o Github Como Um CMS

Publicado em

Há por aí muitas soluções para blogs e wikis e há muitos factores envolvidos na escolha de uma em vez de outra. Já usei WordPress, tanto a versão open source como o serviço completo, e já escrevi HTML e CSS à mão, quando isso era o melhor para o projecto. Não vou fazer declarações absolutas sobre qual é a melhor solução de blogging , porque acho que isso não existe.

A Minha Solução Tecnológica

Aquilo que procuro é:

  • Fonte em Markdown;
  • Um gerador de sites estáticos;
  • Uma pipeline simples;
  • Alojamento não-comercial sem preocupações.

Consigo isso combinando Obsidian, VS Code, Hugo e GitHub Pages. Também quero o meu próprio domínio, mas isso não é necessário para muitos casos, em particular para projectos FOSS, portanto não o vou abordar aqui.

Escrever em Markdown

Markdown é uma linguagem de markup aberta, simples, legível por humanos em texto puro. Usando sintaxe simples como cardinal, asteriscos e parênteses, podemos formatar documentos de modo muito leve. O formato em texto pura também a torna portátil.

Este formato é popular para documentação técnica e em redes sociais. É suportado por GitHub, GitLab, Pandoc (que já usei para um projecto), Reddit, Discord, Lemmy, Matrix, etc. É provável que já o tenha usado, mesmo sem saber.

Como é um formato de texto puro pode-se usar qualquer editor, mas eu gosto de ou Obsidian, uma aplicação de apontamentos completa e extensível, ou Visual Studio Code, um editor de texto orientado a código que se transforma em IDE. Usando uma ou outra destas ferramentas posso partilhar os meus apontamentos e ficheiros fonte de artigos entre aparelhos.

Gerar Páginas Com Hugo

Hugo é tão fixe e está de tal maneira na moda que justifica um emoji de foguetão. Aqui está: 🚀

Vamos só fazer marcha-atrás. Estou a escrever um blogs , não a desenvolver uma loja. Não quero comentários, likes , votos, carrinhos de compras, favoritos, contas de utilizador ou qualquer coisa desse tipo. Isso quer dizer que isto é um site estático - apenas mostra conteúdo como ele é e não espera nem precisa de acção do utilizador. Isso significa que não é precisa uma base de dados ou qualquer importante lógica de fundo. Tudo de que preciso é um conjunto de ficheiros HTML, CSS, JavaScript e talvez imagens, portanto uso um gerador de sites estáticos.

Hugo é escrito em Go, o que o torna fixe, and e suporta um grande conjunto de temas, porque está na moda. Ao correr o programa na linha de comandos posso criar ficheiros de conteúdo com folha de rosto básica e depois gerar as páginas e lançar num servidor local.

A sua tradução de Markdown, configuração, extensibilidade e temas são tão simples de usar como complexos o suficiente pra criar sites agradáveis, bonitos, funcionais e acessíveis - incluindo suporte para o meu requisito adicional de conteúdo miltilingue.

Alojamento Com GitHub Pages

OK, vamos dar inicio ao espectáculo.

git checkout -b cms
git add content/posts/how-i-use-github-as-a-cms.md
git commit -m "First draft about GitHub."
git push

Enviar a fonte deste artigo para um repositório remoto

GitHub Pages é um serviço de alojamento de páginas oferecido pelo GitHub. Nomes com bom senso à parte, para uso não comercial e com algumas limitações técnicas, o GitHub aloja o conteúdo de uma repositório público como um website estático. É mesmo assim tão simples. O GitLab e Codeberg fazem o mesmo, e dão-lhe nomes igualmente simples. O GitLab não parece ter uma página de introdução particularmente amigável, saltando directamente para documentação séria, mas isso não tem nada que ver com nada - o mais provável é escolher o serviço onde já se tem código, acontece que eu uso mais o GitHub.

Quando faço push do conteúdo para main, é quase instantaneamente servido pelo GitHub com as actualizações. Tendo o conteúdo lá, ganho portabilidade, fiabilidade, acesso a partir de diferentes dispositivos e do mundo todo e até opções de colaboração, porque é para isso mesmo que serve o Git.

A Parte do CMS

Mas eu prometi um Sistema de Gestão de Conteúdo, não foi? Uma página na Internet, uma aplicação, alguma coisa assim, não ferramentas de linha de comandos.

Bem aqui está:

uma captura de ecrã do parágrafo anterior em Inglês na aplicação para iOS do GitHub

Aplicação para iOS do GitHub

E aqui:

uma captura de ecrã das diferenças dos parágrafos anteriores e o código para estas capturas de ecrã em Inglês no computador em GitHub.com

GitHub no computador

É claro que uma aplicação e acesso na Internet não são os únicos aspecots de um CMS. Se é preciso acesso a ferramentas de linha de comandos para gerar páginas estáticas, e for preciso puxar do computador portátil para qualquer edição rápida, não provámos nada, pois não?

Aqui é que entra em cena a pipeline . Sou avesso a reinventar rodas, por isso fui à procura daquilo de que precisava e adaptei-o às minhas necessidades. A equipa do Hugo tem a sua própria documentação, mas como estou a usar o serviço gratuito do GitHub e não quero expor os ficheiros de fonte ao público - só os ficheiros estáticos gerados - e achei este artigo de Finisky Garden muito útil. Note-se o .github.io que sugere que está alojado em GitHub Pages.

Como isto como ponto de partida, este é o meu processo:

  1. Criar um ficheiro novo para o artigo em qualquer aparelho que esteja a usar na altura;
  2. Fazer push disso para um novo branch no meu repositório privado;
  3. A certa altura, gerar a página localmente to confirmar que está tudo a funcionar como esperava;
  4. Continuar a escrever e editar;
  5. Traduzir o artigo original em Inglês para Português;
  6. Fazer merge pra ‘main’;
  7. A pipeline gera a nova versão e envia para o repositório público;
  8. Partilhar o meu novo artigo ligeiramente interessante;
  9. Fazer correções pós-publicação e enviar para ‘main’. and push to main again to update.

OK, não consigo mesmo competir com o WordPress, mas gosto assim.

Recomendaria Isto?

Esta solução e processo não correspondem a todos os requisitos de um CMS. Nem sequer abordei imagens, apesar de não ser uma questão demasiado complicada com Hugo. Acho que justifiquei bem algumas das vantagens e fui aberto em relação à maior desvantagem: para quem quer algo dinâmico, isto não vai funcionar.

Talvez a pergunta mais importante seja “este processo é fácil de usar para a maioria das pessoas”? Não, é claro que não. Como programador, posso celebrar a superioridade de texto puro o dia todo, mas não é por acaso que What You See Is What You Get é tão popular. Posto isto, quando só se precisa de fazer alterações ocasionais a uma página simples, a maioria das pessoas leigas seria capaz de se familiarizar com a utilização básica do GitHub. Estando a infraestrutura montada, até parece WordPress.

Esta abordagem funciona para mim, porque considero o processo técnico divertido. É por isso que estou a escrever um artigo sobre isso? Para quem “divertido” tem o mesmo significado, espero que acompanhar-me nesta viagem tenha sido agradável. Independentemente disso, que haja diversão.

captura de ecrã do pull request deste artigo

Fazer merge deste artigo para o publicar