8
Em 2009, durante o CMS Brasil, uma das coisas que Matt Mullenweg (criador do WordPress) falou foi que o WordPress não é e não foi feito para ser um CMS completo, ele serve para fazer blogs e nisso o faz muito bem. Na época, a versão do WordPress era a 2.8.x, e o que ele disse realmente era verdade… Era totalmente otimizado para blogs. Mas isso nunca foi um impedimento para o pessoal usar a criatividade e inventar diversas maneiras de utilizar o wordpress para várias coisas que não são apenas blogs. Este artigo apresenta uma breve introdução (com idéias, sem configurações e detalhamento técnico) sobre um tema contraditório: como não criar um blog, e sim um portal web com WordPress!
Parte desses recursos que a galera cria deve-se ao incrível sistema de hooks e flexibilidade que o WordPress proporciona. Quem desenvolve para a ferramenta sabe que é possível criar plugins que podem atuar em qualquer uma das fases de processamento e ações. Isso tudo sem mexer no código núcleo da aplicação. Por exemplo, um plugin pode executar qualquer ação em código quando um post é criado, editado, excluído, o que for. E se o plugin for desenvolvido de forma correta utilizando estes hooks, um plugin tem chances mínimas de influenciar um outro plugin, ao menos que façam exatamente a mesma coisa.
Outro recurso é o incrível sistema de temas do WordPress. Com ele, de forma seletiva, você pode criar temas totalmente diferentes para cada post, categoria, tag, página, ou sejá lá o que for, por nome, por ID. Pode-se usar funções próprias de temas, widgets personalizados, tudo isso utilizando HTML e CSS puro ou se quiser, PHP embutido também.
Toda essa flexibilidade tem um preço: alto processamento. Se tem uma coisa em que o WordPress peca, é seu alto uso de recursos da máquina. Códigos PHP interpretados usam sempre CPU adicional e programação sem muita tipagem, sem muito tratamento de lixo de memória, acaba deixando o sistema muito pesado. Mas mesmo assim, não chega a ser um monstro… O WordPress geralmente se comporta muito bem, com suas configurações básicas. Só não aguenta muitos picos de conexões simultâneas.
Mas esse ponto fraco (em itálico porque não chega a ser muito preocupante) pode ser resolvido de diversas maneiras. Essas maneiras sempre lidam com um assunto que todo mundo já ouviu falar, mas quase ninguém sabe como funciona direito: cache. Com cache, ao invés do WordPress processar, por exemplo, 1.000 conexões em 1 minuto, utilizando CPU e memória a toda, ele gera a página uma única vez e serve para o resto das 999 conexões nesse minuto. Então no próximo minuto ele gera novamente para atualizar os dados. Há um pouco de atraso nesse mecanismo de cache, mas o atraso é mínimo em relação à todos as vantagens que um cache pode proporcionar.
Use the cache force, Luke
Não vou entrar em muitos detalhes sobre o que é exatamente um cache. Existem vários tipos. Mas vou tratar aqui da integração que acho a mais incrível de todas. Conhecem um software chamado Varnish? É o chamado proxy reverso, ou acelerador HTTP. Ele funciona como um intermediador entre o servidor Web e as conexões que vem do mundo. Para cada item buscado pelos navegadores, ele armazena em memória ou em disco e serve estaticamente para o usuário, muito mais rapidamente que se o WordPress tivesse que gerar toda a página, consultando banco de dados, utilizando interpretação de PHP, etc.
Além do mais, o Varnish é impecavelmente bem escrito e seu algoritmo é um dos mais eficientes da atualidade. Só que sua grande vantagem é justamente a flexibilidade e a capacidade de configuração dele. Você pode controlar como ele funciona de centenas de maneiras! Pode escolher fazer cache ou não por extensão de arquivo, por URL, por Cookie, por cabeçalhos HTTP, pode balancear entre servidores diferentes, configurar comportamento de tempo de vida (ttl), se ele é servido compactado ou não, entre muitas outras opções.
Com esse recurso bem configurado e integrado com o servidor web e sua aplicação, o cache elimina em 100% os problemas de alto uso de CPU e memória do servidor Web. 100% não, é pouco. 110%.
Desempenho: WordPress e Varnish trabalhando juntos
Pegue os hooks do WordPress e escreva um plugin que conversa com o Varnish. Assim você tem o WP-Varnish. Primeiro configure o Varnish para fazer cache de praticamente tudo do WordPress (menos administração, claro), por tempo indeterminado. Deixe que o Varnish encarregue-se de trabalhar com seu algoritmo para distribuir as páginas para os usuários. Então cada vez que algo é mudado no Blog, acione um hook que conecte-se ao Varnish e diga para ele invalidar a página. Ou seja, próxima vez que alguém acessar, o Varnish gera outro cache, agora atualizado. O plugin WP-Varnish faz exatamente isso.
Perceba que ele só fez isso quando foi mudado alguma coisa… Enquanto isso, é o Varnish que continua servindo as páginas, sem estouro de CPU e/ou memória. Pimba. Problema resolvido.
The cake is a lie, it’s a portal
Resolvido o problema do desempenho, utilize a flexibilidade do WordPress ao máximo! No quesito portal, o WordPress 3.0 veio aqui para ajudar. Com a possibilidade de criar múltiplos blogs em uma mesma instalação, imagine agora que, ao invés de você criar uma categoria para cada seção, pode criar blogs diferentes, com usuários diferentes e permissões diferentes. É uma forma simples, porém bem funcional de um sistema de ACLs (outra coisa que o WordPress não tem tanta flexibilidade para ser considerado um CMS completo).
Para cada seção do portal, pode-se criar temas completamente diferentes, com assuntos diferentes. Mas lembre-se que todos os dados estão na mesma instalação, então uma integração entre os blogs pode ser feita através de RSS ou plugins próprios que acessam a base MySQL. As funções de temas podem ser utilizadas para criar áreas de widgets que podem ser colocadas, editadas, removidas, movidas, tudo isso com bastante facilidade. Se tem algo que ninguém reclama do WordPress, é sua ótima e amiga interface de administração.
Auditoria
E quando se fala em portais, além da ACL, cobra-se muito auditoria. Com muitas pessoas utilizando a mesma ferramenta, a capacidade de fazer besteira é muito maior! E todo mundo sabe como é importante identificar quem fez a besteira ;)
Os hooks do WordPress podem cuidar do assunto. Com um bom plugin, vocẽ consegue executar escritas de logs para qualquer ação que você faça na administração. Aprovou algo? Logou. Escreveu um novo artigo? Logou. Apagou? Logou. Editou? Logou. Logou. Logou.
Quer um exemplo? Plugin Audit Trail.
Cache vs. Dinamismo
Se tudo feito da forma descrita até aqui, pode ser que exista vários itens das páginas que não funcionem. Como o Varnish faz cache dos elementos das páginas e deixa tudo estático, o dinamismo da página fica morto. Por exemplo, os contadores de visualizações aqui do Devin não seriam atualizados nunca…
Nesses casos, a melhor opção é utilizar os recursos de AJAX para buscar esses itens. Coloca-se uma excessão no Varnish, para em uma certa URL, nunca fazer cache. Então cria-se uma requisição AJAX dentro da página, que vai executar o código PHP. É mais difícil de fazer, mas o ganho de desempenho é também muito grande e o cache pode ser totalmente aproveitado.
Facilidade para criar
Aqui bato num ponto muito polêmico. Programar em PHP, assim como muitas outras linguagens interpretadas (ex.: Python, Ruby), é muito fácil. Muuuuuuuito fácil. É tão fácil que qualquer um programa e por isso é tão mais fácil criar porcarias. Num ambiente com muito desenvolvimento, mas com pessoas competentes, talvez programar em linguagem interpretada pode gerar mais produtividade.
Outros pontos interessantes
- Múltiplos bancos de dados e balanceamento
- Utilizando Proxy
- Social Networking com BuddyPress
- Verificação automática de posts relacionados
- E-Mails, Enquetes, Ratings, Versões de Impressão
- Um dos Anti-SPAM mais eficientes que já vi
- SEO, XML Sitemap
- e muito, muito mais…
