Media & Publishing: mavicon.pl

#mavicon.pl, um site que já sobreviveu a mais de uma década de manutenção

A maior parte do custo de um site empresarial não está na construção. Está nos anos seguintes, e o incidente típico não é o que a maioria imagina. Uma atualização de extensão raramente parte um site por si só. Parte-o quando o tema sobrescrevia o comportamento dessa extensão apoiando-se num pormenor de implementação que o autor nunca prometeu manter. O ficheiro atualizado é legítimo, o tema é legítimo, e a página de contactos deixa de funcionar na terça-feira de manhã sem que ninguém tenha tocado em nada.

Daí decorre a regra que governa a manutenção deste projeto: as atualizações passam primeiro por um ambiente de testes que é uma cópia da produção e não uma instalação limpa. Numa instalação nova, com tema predefinido e sem conteúdos, tudo funciona, e esse teste não diz absolutamente nada sobre o que vai acontecer no site real. A diferença aparece com o conteúdo acumulado, com as personalizações do tema e com a combinação concreta de extensões que só existe neste sítio.

A mesma lógica aplica-se às cópias de segurança. Uma cópia só vale alguma coisa depois de alguém ter restaurado o site a partir dela pelo menos uma vez. Uma cópia nunca restaurada é uma declaração e não uma proteção, e a diferença entre as duas descobre-se sempre no pior momento possível.

#O que este site tem de fazer pela empresa

Uma empresa que vende soluções técnicas tem no seu site o problema inverso ao de uma loja. A loja mostra produto e preço, e o visitante sabe em segundos se lhe interessa. Um fornecedor de serviços técnicos vende algo que não se fotografa, a um comprador que na maior parte das vezes ainda não consegue nomear o seu próprio problema. Chega com um sintoma, não com uma encomenda.

Disto saem decisões concretas de conteúdo. Primeiro, a oferta tem de ser legível a partir do sintoma e não apenas sob o nome do serviço, porque quem tem um sistema de armazém insuportavelmente lento não procura a tecnologia que devia ser substituída. Segundo, um estudo de caso trabalha aqui mais do que uma descrição de serviço, porque permite reconhecer a situação própria na de outra pessoa. Terceiro, e esta é a parte que costuma ficar de fora, o site tem de aguentar ser lido por alguém tecnicamente competente que está a verificar se o fornecedor sabe do que fala. Nessa prova as generalidades reprovam de imediato e de forma permanente.

O modelo de conteúdos separa por isso três coisas que num site empresarial comum vivem juntas: a descrição do serviço, a prova sob a forma de um projeto entregue e o material explicativo sobre o tema. Cada uma tem leitor diferente, ritmo de atualização diferente e posição diferente no caminho até ao contacto. Mantê-las num só tipo de conteúdo poupa uma semana na construção e custa durante anos, porque qualquer alteração a uma delas passa a exigir cautela com as outras duas.

O site foi construído para posicionar a empresa como especialista, apresentar os seus casos e captar clientes interessados em trabalho avançado de TI e marketing digital. A disposição e a colocação dos elementos vieram do cliente, pelo que o trabalho do nosso lado incidiu no modelo de conteúdos, nos templates e no que acontece ao site depois do arranque. A implementação demorou cerca de seis semanas.

#O que a lista de tecnologias não diz

A lista de ferramentas mais abaixo descreve o site no estado em que está depois de anos de manutenção, e não a base com que arrancou. A distinção merece ser dita em voz alta em vez de ficar ao cuidado do leitor.

O projeto entrou em funcionamento em 2012. Isso era WordPress sem REST API no núcleo, sem editor de blocos, com tipos de conteúdo personalizados com dois anos de idade e com um layout responsivo que mal tinha deixado de ser novidade. O React só foi publicado em 2013. A REST API chegou ao núcleo do WordPress na versão 4.7, no final de 2016. O Tailwind CSS nasceu em 2017 e o PHP 7 saiu em 2015, pelo que sair do ramo 5.x foi uma tarefa de manutenção autónoma anos depois do arranque e não uma decisão tomada durante a construção.

As descrições de projeto apresentam rotineiramente a camada técnica de hoje como se fosse a original, e o resultado é que ninguém consegue distinguir uma decisão de projeto de uma substituição posterior imposta pela passagem do tempo. Num projeto mantido há mais de uma década, as do segundo tipo são mais numerosas do que as do primeiro.

#Funcionalidades e as escolhas por trás delas

O WordPress com tipos de conteúdo próprios sustenta a separação descrita acima. É uma decisão que só se paga ao fim de uns dois anos. No primeiro mês parece complexidade desnecessária, porque as categorias fazem o mesmo serviço. Ao fim de duzentas entradas a diferença é que mudar o template dos casos não toca no blogue, e que quem introduz um serviço vê um formulário com os campos que um serviço realmente tem, em vez de um campo de texto universal com as instruções escritas num comentário.

O design responsivo em 2012 não consistia em acrescentar classes utilitárias a um template pronto. As grelhas e as regras responsivas escreviam-se à mão, e os pontos de rutura escolhiam-se em função do conteúdo e não de uma lista de resoluções populares. O segundo método parece mais sensato e envelhece pior, porque a lista de resoluções populares muda de dois em dois anos, ao passo que o ponto em que uma tabela de oferta deixa de caber é uma propriedade dessa tabela e não muda nunca.

Os módulos de apresentação carregam conteúdo sem recarregar a página. A contrapartida raramente se enuncia, por isso vale a pena enunciá-la: conteúdo obtido depois do facto é conteúdo que um motor de busca pode nunca ver, e numa página cuja única função é gerar contactos a partir da pesquisa isso é uma decisão comercial e não técnica. A resolução foi que a navegação, a filtragem e as páginas seguintes de listagem carregam de forma assíncrona, enquanto o corpo de texto de uma página de serviço nunca o faz. O primeiro ecrã está completo no código-fonte do documento.

O formulário de contacto valida do lado do cliente e do lado do servidor e encaminha os pedidos para o departamento certo. A duplicação não é desperdício. A validação no navegador existe para que ninguém espere por uma resposta do servidor só para descobrir uma gralha. A validação no servidor existe porque a primeira pode ser contornada, e um formulário sem ela é simplesmente uma porta aberta para robôs.

#Desafios de programação e soluções

A integração de conteúdos dinâmicos exigiu pontos de acesso próprios. Sem REST API no núcleo do WordPress, isso significou escrever uma camada de entrada própria, com verificação de permissões própria e formato de resposta próprio. É a parte do projeto que envelheceu mais depressa, e é isso que a torna interessante: código que nasce porque a plataforma não tinha algo é o primeiro candidato a ser removido no dia em que a plataforma passa a tê-lo. Manter a solução própria ao lado do núcleo custa depois a cada atualização.

A otimização de desempenho assentou em cache em várias camadas com Redis e Memcached, compressão de recursos e distribuição por CDN. Duas caches no mesmo projeto parecem excesso até se perceber que tratam de coisas diferentes: uma é cache de objetos para consultas à base de dados, a outra guarda sessões e fragmentos de vistas. Ainda assim, o ganho da cache de objetos num site de marketing é menor do que se costuma assumir, porque a maior parte do tráfego são visitantes anónimos em pouco mais de uma dezena de páginas, e essas servem-se mais barato devolvendo a página inteira a partir da cache, sem descer ao PHP.

A integração com sistemas externos abrangeu troca bidirecional com CRM e plataformas de analítica. A decisão determinante foi o comportamento em caso de falha. O padrão da maioria das extensões é mostrar um erro ou uma secção vazia, o que numa página comercial se lê como avaria do site inteiro. Aqui cada ligação tem valor de recurso: a última resposta conhecida e, quando nem essa existe, uma variante estática da secção. O visitante vê uma página sem um módulo e não uma mensagem de erro.

A migração de conteúdos das versões antigas do site recorreu a ferramentas de importação e exportação e a materiais do Web Archive. Transferir conteúdo a partir de um arquivo tem uma armadilha que só se vê depois da publicação: o arquivo preserva o texto, mas não preserva os endereços sob os quais esse texto estava indexado, nem as imagens que carregavam de domínios externos. Sem reconstruir os endereços antigos com redirecionamentos, a migração parece bem-sucedida e apaga ao mesmo tempo todo o histórico de posições na pesquisa.

#Ferramentas e tecnologias

O WordPress continua a ser a base, porque permite ao cliente editar conteúdo sem apoio de um programador, e num site de marketing esse é o critério decisivo. PHP e MySQL sustentam a camada de servidor. HTML5, CSS3, SASS e JavaScript formam a camada de apresentação, sendo que o valor real do SASS não está na escrita mais curta, mas em a cor da marca ter um sítio em vez de quarenta. O Bootstrap e, mais tarde, o Tailwind CSS aceleraram a construção de um layout coerente. Redis e Memcached tratam da cache e o Git do controlo de versões.

O controlo de versões num projeto desta dimensão é por vezes tido como formalidade, e é exatamente o contrário: é o único mecanismo graças ao qual uma correção feita à pressa se desfaz sem adivinhar o que foi alterado.

#Apoio e manutenção do site em WordPress

O acompanhamento inclui resposta a problemas técnicos e correção de erros após atualizações, atualizações regulares do núcleo, do tema e das extensões, monitorização de registos, cópias de segurança segundo calendário definido e pequenas alterações funcionais e gráficas.

Vale a pena separar uma coisa desta lista, porque é a origem da maioria dos incidentes em sites deste perfil, e é a mesma que abre este texto: o ambiente de testes tem de ser uma cópia da produção. É também a razão pela qual a manutenção não se resume a carregar num botão de atualização em massa. Entre a versão instalada e a mais recente há por vezes alterações de comportamento que só se manifestam em combinação com o que este site tem de particular, e descobri-las numa cópia custa uma hora, ao passo que descobri-las em produção custa a confiança de quem depende do formulário de contacto.

#Resumo e análise preliminar dos requisitos do cliente

A análise inicial fixou alguns pontos que se tornaram a base do projeto. O objetivo era construir a imagem da empresa como fornecedora de soluções avançadas e captar clientes interessados nesses serviços. Os requisitos incluíam apresentação dinâmica da oferta, integração com sistemas externos e um sistema de gestão de conteúdos flexível. O âmbito abrangeu a modernização da arquitetura do site, vistas responsivas e módulos de apresentação. O projeto foi dividido em fases, o que permitiu entregar funcionalidades de forma gradual. O cliente indicou como referência sites com apresentação clara da oferta, e isso influenciou a forma final.

Com a distância, o último ponto é o mais interessante. As referências indicadas por um cliente costumam ser tratadas como material para um painel de inspiração. Na prática dizem algo sobre outra coisa que não a estética: dizem por que ordem o cliente considera natural ler uma oferta, onde espera encontrar o preço e onde espera encontrar o contacto. Isso são decisões de modelo de conteúdos e não de aparência, e transferem-se para projetos seguintes muito melhor do que qualquer layout.

O site mavicon.pl foi preparado como ferramenta de marketing com uma estrutura de oferta clara, espaço para estudos de caso e base para continuar a atualizar conteúdos. O que se transfere daqui é o método de trabalho: o modelo de conteúdos antes do template, os testes contra uma cópia da produção e a separação explícita entre o que tem de estar no código-fonte e o que pode ser carregado depois. A pilha tecnológica não se transfere, porque a de 2012 é hoje metade diferente, e isso é o curso normal das coisas e não um defeito do projeto.