Introdução

O WordPress surgiu para facilitar a vida de quem fazia sites em HTML. A “Linguagem de Marcação de HiperTexto” (HyperText Markup Language) dava muito trabalho de edição. O WordPress integrava editores WYSIWYG (What You See Is What You Get) com um sistema automatizado de publicação de artigos de modo dinâmico, aproveitando a linguagem PHP.

Deixo claro, desde logo, que o meu propósito não é o de criticar ou depreciar o WordPress. É, sem dúvida um CMS - Content Management System - muito robusto e que entrega, com código aberto, um sistema muito útil para milhares de pessoas e empresas.

Eu mesmo o usei por vários anos e, em vários cenários, é uma ótima opção de site dinâmico.

O meu objetivo é apenas descrever as dificuldades que enfrentei e o que funcionou melhor para mim. Espero que essa leitura seja útil para orientar quem tem dúvidas, de acordo com a realidade de cada um.

Advertência

Também já adianto que não vou entrar em detalhes técnicos da instalação. Se esse é o seu objetivo, já pode parar por aqui. O que vou tratar são das escolhas estratégicas, que muitos somente vão descobrir depois de muito trabalho.

Um CMS, duas formas de usar

Há, essencialmente, dois modos de criar o seu site no WordPress.

A primeira, mais prática, é usando o próprio serviço, disponível em https://wordpress.com. Lá você faz o seu cadastro e já consegue criar o seu site de modo rápido e gratuito. Em troca da gratuidade, eles podem colocar anúncios no ‘seu’ site.

Então, para aproveitar todos os recursos, ter o seu próprio domínio, escolher temas e plugins, você acabará tendo que optar pelo pagamento de uma mensalidade. Considero, sinceramente, um bom começo. Você já pode testar muita coisa e os planos têm preços muito competitivos.

A segunda, é usar o CMS auto-hospedado na sua própria infra-estrutura ou em um VPS (Virtual Private Server). Aí você tem muita liberdade, tanto para usar o seu próprio domínio, quanto para instalar quantos plugins e temas que quiser.

As vantagens e desvantagens são extensas e também não vou tratar delas nesta oportunidade, para não perder o foco.

As minhas escolhas

Eu preferi instalar no meu próprio VPS, porque me garantia maior controle e livre instalação de temas e plugins, além de permitir criar páginas e subdomínios com outras características, fora do WordPress.

Com mais liberdade, veio mais responsabilidade. Ter que administrar o servidor, cuidar da segurança contra ataques, fazer o backup do site. E aí começaram a surgir grandes problemas e dificuldades.

Primeiro problema: segurança em um sistema complexo

O WordPress é um sistema que foi ganhando cada vez mais complexidade ao longo do tempo. E, quanto mais complexo, mais pontos que exigem atenção, em termos de segurança.

E um site pode ficar exposto a ataques o tempo todo, de qualquer parte do mundo.

Em 2011, percebi que algumas pessoas conseguiam usar os comentários do meu site mesmo sem prévia aprovação do administrador. Na primeira vez, não parecia um grande problema; eu simplesmente deletava, mas os comentários começaram a ficar frequentes e, com o tempo, fui percebendo que já existiam ‘rachaduras’ na segurança e eu ainda não tinha conhecimento para corrigir isso.

Claro que atualizações de segurança foram feitas por desenvolvedores e inúmeros bugs foram corrigidos ao longo do tempo.

Até que, em 2011, meu servidor (VPS) foi invadido por um grupo que assinava seu ataques como “TeaM HITMAN HaCkEr”.

A partir daí, procurei transformar minha frustração em estímulo para estudar mais segurança de redes e computadores.

Percebi que: ou você mesmo entende todo o sistema ou acaba terceirizando a administração da segurança do site. O problema da segunda abordagem, é que existem inúmeros programas, plugins, empresas e estratégias que podem ser contratadas e, sem conhecimento, você pode pagar muito por um serviço que, mesmo sendo prestado, não resolverá o seu problema.

Então, pelo menos um conhecimento mínimo é necessário, até para que você saiba selecionar as suas reais necessidades.

Uma das estratégias que garantem a longevidade do site são backups consistentes.

Segundo problema: os backups

O WordPress fez uma escolha na sua arquitetura. Armazenar os posts em um banco de dados. Inicialmente, por padrão, usava o MySQL. Após a sua aquisição pela Oracle, em 2010, passou a usar o MariaDB, um fork. Mas também é possível usar o SQLite, com suporte oficial.

Então os posts, no WordPress, são uma combinação de dados armazenados no Banco de Dados com códigos em PHP e Javascript, que montam as páginas HTML dinamicamente, formatado com CSS.

Isso traz uma complexidade para o backup. É preciso armazenar o conjunto todo do site em um determinado instante para que ele possa ser integralmente recuperado.

Recuperar somente uma parte é um desafio.

No meu caso, apesar de ter feito backups, passei por frustrantes experiências ao tentar recuperar o site. Somente quando precisei deles, verifiquei que não eram consistentes.

Mesmo existindo soluções comerciais, eu não queria ficar preso a uma empresa fazendo o backup de um modo que eu não pudesse guardar por um longo prazo.

Cheguei a pensar em salvar em PDFs. Isso traria, pelo menos, alguma maneira de recuperar as informações, mas recuperar inúmeros artigos seria um enorme trabalho.

A solução atual: Markdown + Hugo

Depois de anos insistindo e tropeçando, resolvi que faria meus artigos em Markdown, porque a facilidade de usar um editor do próprio WordPress tinha um preço escondido: as dificuldades de fazer um backup.

E esse, na verdade, não é um problema só do WordPress, mas de outros editores de texto com código proprietário. Você fica preso à plataforma.

Quem usava o WordStar, por exemplo, precisaria guardar não somente os arquivos, mas também o programa que permitia consultá-los. E, se não o fez, teve dificuldades para recuperar seus arquivos depois que a MicroPro foi incorporada pela SoftKey e posteriormente extinta pela Mattel.

A própria Microsoft migrou os arquivos que eram, por padrão, gravados em .doc, um formato binário proprietário, para .docx, que adota o Office Open XML.

Talvez você se pergunte: mas qual o problema de guardar um arquivo em .doc? Documentos digitais que precisam ser armazenados com confiabilidade por um longo prazo devem evitar essa dependência de uma empresa ou plataforma. Diversos órgãos públicos tinham interesse nisso.

Para evitar esse problema, muitos preferiam armazenar suas anotações em um editor de texto “puro”, como o notepad, no windows, Vim e Emacs, muito usados em programação.

Mas o texto ‘puro’ tem as suas desvantagens. Não permite um negrito, um itálico e vários sinais que enriquecem o texto.

Nesse contexto, é que surgiu o Markdown, reunindo a vantagem de usar texto ‘puro’ com uma marcação bem mais simples do que a do HTML, o padrão até hoje usado nas páginas da internet.

A ideia foi a de que a marcação do texto não dificultasse a sua leitura, mesmo que o texto não fosse renderizado.

Também não pretendo me aprofundar nos detalhes de como usar o Markdown nesse artigo. Caso tenha interesse, mais informações no site do criador, John Gruber: daringfireball.net. Ele foi desenvolvido com a colaboração de Aaron Swartz, que desenvolveu a implementação em Perl.

Só quero deixar claro que a ideia básica é a seguinte: você escreve uma única vez e pode exportar para qualquer outro formato, como HTML, MS-Word, RTF, ODT, PDF, epub etc.

Foi assim que escrevi esse texto. A simplicidade permite maior concentração no principal, na produção do texto.

Uma vez preparado o artigo, usei o Hugo, implementado na linguagem Go, que cria, a partir do texto em Markdown, um site.