O WordPress não é uma tecnologia: é um ecossistema

Imaginemos três projetos web que utilizam WordPress.

O primeiro é um site institucional construído com um tema comercial, um editor visual e vários plugins. A sua equipa pode atualizar conteúdos sem conhecimentos de programação. O segundo utiliza um tema próprio e funcionalidades desenvolvidas à medida para responder a necessidades específicas. No terceiro, o WordPress funciona apenas como gestor de conteúdos: o site visível é desenvolvido em separado, talvez com React, e obtém a informação através de uma API.

Os três projetos partilham o mesmo CMS. No entanto, a sua arquitetura, a sua experiência de administração e as suas necessidades de manutenção podem ser muito diferentes.

Por isso, afirmações como «o WordPress é lento», «o WordPress é flexível» ou «o WordPress é difícil de manter» são incompletas. Podem descrever determinados projetos, mas não necessariamente a plataforma em todas as suas formas.

O WordPress não funciona de forma isolada. Aquilo que vemos como um único site é o resultado de decisões sobre componentes, desenvolvimento, infraestrutura e serviços. O WordPress é o ponto de partida, não uma descrição completa daquilo que construímos.

Para compreender as suas vantagens e limitações, precisamos de olhar para além do seu núcleo.

O núcleo é apenas uma parte daquilo que utilizamos

O núcleo do WordPress, ou core, fornece as funções fundamentais para gerir utilizadores, conteúdos e publicações. Mas raramente constitui, por si só, tudo aquilo de que um projeto necessita.

À sua volta, incorporamos temas que definem a apresentação, plugins que alargam funcionalidades, fornecedores de alojamento que gerem a infraestrutura, integrações com serviços externos e, por vezes, desenvolvimentos personalizados. Numa mesma instalação podem coexistir código mantido pela comunidade WordPress, produtos comerciais e soluções desenvolvidas por uma agência.

Esta combinação coloca uma questão que nem sempre é visível a partir do painel de administração: nem todos os componentes evoluem ao mesmo ritmo, nem estão sob a responsabilidade das mesmas pessoas.

A equipa que mantém o núcleo define as suas prioridades. Cada fabricante de plugins ou temas decide como e quando atualiza os seus produtos. Um fornecedor de alojamento controla parte do ambiente técnico, enquanto uma agência pode ficar responsável pelas personalizações. Cada parte tem o seu próprio calendário, as suas condições e os seus limites de responsabilidade.

Isto não torna o WordPress uma exceção. O software moderno costuma ser construído com peças de múltiplas origens. O que é singular no seu ecossistema é a facilidade com que essas peças podem ser incorporadas e combinadas, mesmo quando quem administra o site mal se apercebe das relações que se criam entre elas.

Utilizar uma única plataforma de gestão não significa depender de um único fornecedor. E essa diversidade, embora exija algumas precauções, é também uma das suas maiores forças.

A grande vantagem de não ter de construir tudo

Nem todas as organizações precisam de desenvolver o seu próprio gestor de conteúdos, programar um formulário ou criar de raiz uma integração com uma plataforma de comércio eletrónico. Uma das razões da permanência do WordPress é permitir tirar partido de soluções que outros já construíram.

Uma pequena empresa pode lançar um site profissional sem financiar um desenvolvimento totalmente personalizado. Uma organização sem fins lucrativos pode gerir donativos ou inscrições. E um projeto mais complexo pode ligar o seu site a ferramentas de marketing ou sistemas empresariais sem ter de desenvolver toda a integração desde o início.

A vantagem também não é apenas económica. Existe uma ampla disponibilidade de profissionais, documentação e conhecimentos especializados. É possível encontrar equipas com experiência em desempenho, acessibilidade, comércio eletrónico ou gestão editorial, e dar continuidade a projetos desenvolvidos inicialmente por outras pessoas.

Reutilizar soluções permite dedicar mais recursos àquilo que realmente diferencia cada projeto. Não ter de inventar tudo é uma vantagem importante.

Mas dispor de uma ferramenta para quase qualquer necessidade também pode mudar a nossa forma de decidir. Quando surge um requisito, é tentador procurar um plugin e instalá-lo antes de nos perguntarmos como deverá essa funcionalidade enquadrar-se no conjunto.

O facto de uma solução existir e funcionar não significa que seja a mais adequada. Pode utilizar estruturas de dados difíceis de migrar, introduzir processos pouco compatíveis com outras ferramentas ou condicionar futuras ampliações. Desenvolver algo à medida também não garante um resultado melhor: ambas as opções exigem critério.

A força do ecossistema está em oferecer alternativas. A responsabilidade de as escolher continua a ser nossa.

Quando cada solução introduz uma nova dependência

A complexidade de um site nem sempre pode ser medida contando plugins ou calculando quanto código contém. O decisivo costuma estar nas relações entre os seus componentes.

Um plugin necessita de uma determinada versão de PHP. Um tema inclui uma biblioteca de JavaScript que outra extensão também utiliza. Uma personalização consulta dados armazenados por um fornecedor externo. Uma integração depende de uma API continuar a funcionar.

Durante meses, tudo pode funcionar corretamente. Depois chega uma atualização, muda uma API ou uma biblioteca deixa de ser mantida. Nenhum componente tem de estar mal desenvolvido para que o conjunto comece a apresentar problemas: basta que as suas alterações não sejam compatíveis entre si.

Podemos chamar-lhe complexidade acumulada: à medida que aumentam as relações entre componentes, torna-se mais difícil antecipar como uma alteração afetará o restante sistema.

Por isso, dez plugins relativamente independentes podem ser mais simples de manter do que três estreitamente relacionados. E um site com poucas extensões pode ser frágil se uma delas suportar processos essenciais que nenhuma outra ferramenta consegue substituir facilmente.

Ter muitas funcionalidades não equivale a manter o controlo sobre elas. Esse controlo não exige programar tudo de raiz nem rejeitar dependências externas. Significa saber que elementos são críticos, como se relacionam, quem os mantém e que alternativas temos se precisarmos de os modificar ou substituir.

Uma arquitetura com responsabilidades bem delimitadas, documentação suficiente e testes antes de atualizar não elimina todos os riscos, mas facilita a sua gestão. O objetivo não é evitar a evolução do sistema, mas fazer com que cada alteração seja o mais previsível possível.

No WordPress, onde ampliar funcionalidades pode ser tão fácil como instalar uma extensão, esta distinção é especialmente importante: a rapidez de implementação e a sustentabilidade de uma decisão técnica não são a mesma coisa.

Um ecossistema também é uma economia

Por detrás do WordPress existe uma indústria de empresas de alojamento, fabricantes de plugins e temas, desenvolvedores independentes, agências e fornecedores de suporte. Parte desta atividade contribui diretamente para o projeto de código aberto; outra parte constrói produtos e serviços à sua volta.

Não existe uma contradição automática entre software livre e atividade comercial. Desenvolver, atualizar e prestar suporte a uma ferramenta requer recursos. Os modelos de negócio permitem sustentar muitas soluções que, de outro modo, dificilmente existiriam.

No entanto, os interesses dos fornecedores e dos clientes nem sempre coincidem. Uma empresa pode alterar o preço de uma subscrição, reorganizar os seus planos ou deixar de manter um produto por razões comerciais legítimas. Para quem o utiliza como peça central do seu site, essas decisões podem ter consequências importantes.

Imaginemos uma organização que gere as suas vendas através de uma extensão específica. Mesmo que tenha acesso aos seus dados e a parte do código, mudar de ferramenta poderá implicar migrar informação, refazer processos e formar novamente a sua equipa. O custo de saída pode ser muito superior ao preço da licença.

Aqui surge uma distinção fundamental: ter acesso ao código nem sempre significa ter capacidade prática para substituir uma solução. Uma licença livre oferece direitos importantes, mas manter por conta própria uma ferramenta abandonada também pode exigir conhecimentos e recursos que a organização não possui.

Antes de adotar um componente, convém considerar quem o desenvolve, como é financiado, que suporte oferece e o que aconteceria se desaparecesse. Isto não significa desconfiar do software comercial nem assumir que uma ferramenta gratuita será menos fiável. Significa incorporar a continuidade do fornecedor e o custo da mudança na análise técnica.

As agências também devem analisar as suas próprias decisões. A ferramenta que permite entregar um site mais depressa nem sempre será a mais conveniente para quem terá de o manter durante anos.

Escolher tecnologia implica, em parte, escolher relações económicas. O importante é compreendê-las antes de se tornarem dependências difíceis de gerir.

A comunidade não é um departamento de suporte

O WordPress também conta com algo que não pode ser reduzido aos seus produtos comerciais: uma comunidade internacional que contribui para o núcleo, corrige erros, traduz, documenta, organiza encontros e partilha conhecimento.

Esta rede facilita encontrar respostas, aprender com experiências alheias e manter viva uma plataforma que não depende de uma única equipa de desenvolvimento. É um dos grandes ativos do projeto.

Mas uma comunidade que contribui para o desenvolvimento de uma tecnologia não é o mesmo que uma equipa contratada para manter o nosso site.

O facto de um plugin ter um repositório público ou um fórum de suporte não significa que o seu autor seja obrigado a responder a todas as questões. O facto de o núcleo receber atualizações não garante a compatibilidade de qualquer combinação de temas, extensões e código personalizado. E o facto de um fornecedor prestar suporte ao seu produto não implica que tenha de resolver qualquer conflito causado por terceiros.

Pensemos numa incidência após uma atualização. O alojamento funciona corretamente; o fornecedor do plugin aponta uma incompatibilidade com o tema; e quem mantém o tema atribui a falha a uma personalização. É possível que cada um tenha razão no âmbito das suas responsabilidades. No entanto, o site continua sem funcionar.

O exemplo revela uma diferença essencial: o facto de cada peça ter um responsável não garante que alguém responda pelo conjunto.

É aí que entra a responsabilidade profissional de quem concebe, integra e mantém o projeto. Não significa que uma agência tenha de prestar suporte indefinidamente, nem que a manutenção esteja automaticamente incluída no desenvolvimento inicial. Significa que convém estabelecer quem supervisiona as atualizações, quem investiga as incidências e ao abrigo de que acordos essas tarefas são realizadas.

O WordPress pode ser utilizado sem pagar uma licença pelo seu núcleo, mas isso não torna a sua manutenção gratuita. É necessário dedicar tempo a acompanhar alterações, realizar testes e resolver problemas. A comunidade pode disponibilizar ferramentas e conhecimento; não pode assumir responsabilidades que nunca lhe foram atribuídas.

Reconhecer esse limite também é uma forma de respeitar o trabalho de quem contribui para o software livre. O seu contributo tem um enorme valor precisamente porque não devemos confundi-lo com uma obrigação de suporte permanente.

Conclusão

Voltemos aos três projetos do início. Partilham o WordPress, mas as suas decisões de arquitetura, dependências e necessidades de manutenção são diferentes. Por isso, perguntar se «o WordPress é uma boa solução» sem conhecer o projeto contribui menos do que parece.

Escolher o WordPress não consiste apenas em selecionar um CMS. Implica também decidir que componentes utilizar, em que fornecedores confiar, como organizar o desenvolvimento e quem ficará responsável pela sua evolução.

A solução não é instalar menos plugins por princípio nem evitar serviços externos. É compreender o que incorporámos e conservar capacidade suficiente para intervir quando as circunstâncias mudarem.

A qualidade de um projeto WordPress depende tanto da plataforma como do critério com que os seus componentes foram escolhidos, integrados e mantidos. Talvez a pergunta mais útil não seja o que podemos construir com o WordPress, mas quanto compreendemos realmente daquilo que construímos.

Mas há algo mais. Enquanto este ecossistema crescia, a web também se transformava profundamente: os dispositivos, as expectativas de desempenho, a segurança, as arquiteturas e a forma de criar e consumir conteúdos.

Isto leva-nos ao próximo artigo da série, A web que o WordPress ajudou a construir já não existe, e a uma nova pergunta: até que ponto o WordPress continua a responder às necessidades de uma web que já não se parece com aquela para a qual foi criado?