Ainda usa WordPress?

Declaração de interesses: Sou tendencioso. Adoro o ProcessWire e odeio o Wordpress. E estou numa missão de tornar o ProcessWire tão popular como acredito que merece ser. Neste artigo vou comparar ambas as plataformas. Mas prometo não mentir.

Dito isso, ontem recebi uma newsletter do CMS Critic a pedir votos para os prémios deste ano.

Se não sabe o que é, o CMS Critic é um site dedicado a plataformas de gestão de conteúdos. Ali encontram-se análises, dicas e notícias dedicadas basicamente a todos os CMS que há por aí. E todos os anos têm o CMS Critic Awards. Como eles dizem:

“Os prémios CMS tiveram início há três anos para preencher uma lacuna que faltava na indústria do software empresaria. Embora já tenham surgido prémios similares no passado, nunca nenhum se focou realmente em garantir uma exposição justa e a oportunidade igual para todos os players do mercado. Foi por isso que criamos os CMS Critic Awards.”

Inicialmente fiquei surpreso ao não ver o Wordpress nomeado para NENHUMA das 20 categorias. Estas incluem "Melhor CMS Open Source", "Melhor CMS Gratuito", "Melhor Software de Blog". Ironicamente, existe uma categoria dedicada ao "Melhor Hosting para Wordpress".

Isto para mim é indicativo de que o Wordpress, apesar de ser o CMS mais popular hoje em dia, já não é a melhor solução. Já o sei há anos, mas agora parece que há gente suficiente a concordar comigo.

Para que raio serve o Wordpress?

Inicialmente, para quem se lembra do nascimento do WP, era uma plataforma de blog. Adorei-ol quando saíu. Era limpo, bonito, organizado, e muito melhor que a solução proprietária que usava na altura. Era tão bom que começaram a tentar fazer mais do que blogs com ele.

E é aqui que o Wordpress começa a azedar. Desenha-se uma plataforma especificamente direcionada a blogs, e depois tenta-se fazer algo diferente com ela e para isso começa-se a martelar, a adicionar plugins, widgets, e fica-se com uma confusão de CMS que põe o utilizador a coçar a cabeça enquanto se interroga como fazer uma determinada tarefa.

Ao longo dos anos o Wordpress tornou-se uma confusão. É complicado de implementar e perdeu a usabilidade.

Examplos

Um examplo — nota, isto foi há alguns anos e já existe algo melhor – a forma como tive a certa altura que implementar um site multi-idioma em WP. Depois de instalar um plugin de idiomas, literalmente tive que escrever ambas as versões do mesmo texto num único campo e separá-lo por um código especial tipo {//english//}, algo que tinha que ser escrito à mão no campo de texto. Não me lembro do código exato nem quero. O que quero dizer é que a solução para contornar o problema era tão suga que tive que explicar ao meu cliente que quando quisesse criar uma página nova, mais valia duplicar uma existente e substituir conteudo.

Evidência dois é um site em que estou a trabalhar agora. O cliente comprou um tema do ThemeForest. Era barato e tinha bom aspeto. Agora paga-me para descobrir como trabalha com o CMS. Estou a ser pago literalmente para dar voltas pela administração do site, descobrir como fazer tarefas específicas, e escrever um manual.

Evidência três. Memso site. Tive que reprogramar parcialmente um dos templates para apresentar outros artigos escritos pelo mesmo autor. Ao fazê-lo, fiquei tão chocado com a confusão do código que me dei ao trabalho de re-escrever o mesmo em ProcessWire. Aqui vai a comparação lado a lado:

Vê como o código da direita é muito mais limpo? Nem é preciso ser programador para ter ter uma ideia do que aquilo faz. No código da esquerda, tiro o chapéu a quem o conseguir escrever de cabeça sem googlar nada.

Evidência quatro. Este screenshot:

Isto é o ecrã de edição de uma página, no site de que estou a falar. Duas coisas me ocorrem:

1. What the fuck?
2. Que trapalhada! Por onde começo?
3. Boa sorte a descobrir como funciona aquele visual composer. O cliente não sabe o que é um query? É aprender, para isso serve o Google.

Ok, são três. As duas primeiras são uma só, mas separei-as pelo drama.

Porque sou tendencioso com o ProcessWire?

Porque experiência!

À data que escrevo este artigo já o uso há um ano e tive um daqueles momentos eureka em que pensei "Isto é EXATAMENTE como um CMS deve ser."

Ali estava um CMS que fazia zero suposições sobre o que eu queria construir. Apresenta com uma tela em branco, começa-se por delinear os campos necessários para o conteúdo que se quer. Uma notícia por exemplo. Penses nisso como um tipo de página, ou template. Cria-se um template para artigos e acrescenta-se os campos: título, data, texto, foto. Precisa que as fotos sejam mais que uma? Define-se o número como ilimitado. Precisa de um campo adicional para resumo? Adicione. Coloca-se exatamente os campos necessários e nada mais. E quando se cria uma página nova do tipo notícia, aparece um formulário que se explica a si mesmo:

E depois é fazer o mesmo para produtos, páginas básicas, página de contactos. Adicione um campo para a imagem de header, adione uma checkbox para definir se aparece um call-to-action no final. O que quiser.

E depois no código, o ProcessWire oferece uma forma incrivelmente simples de carregar o conteúdo. Para cada template que se crie, há um ficheiro correspondente com o mesmo nome. Cola-se o HTML e onde está o título substitui-se por $page->title. Onde está a data coloca $page->date. O texto, substitui por $page->body. A imagem substitui por $page->image->url. É o mesmo princípio de uma ponta à outra. Chama-se um campo pelo nome, recebe-se o conteúdo.

O ProcessWire não tem funções que geram um link completamente formado a um artigo. Em vez disso lê-se o URL e título da página e coloca-se node for preciso no HTML. Acaba-se com A) mais controlo, e B) neurónios livres para pensar no que se quer construir em vez de como se constrói. Sabendo o básico de PHP e HTML, faz-se disto o que se quiser.

Simples != básico

• Se precisa de uma imagem num tamanho específico, escreve $page->image->size(200,100)->url. O ProcessWire gera a imagem, guarda-a para poupar processamento da próxima vez, e devolve o url.
• Pode-se definir que páginas com o template X só permite ter abaixo páginas do template Y. Ou não ter sequer descendentes. Abaixo da página de notícias, só se pode criar páginas do tipo artigo, e abaixo dessas não se pode criar sub-páginas.
• O método $pages->find() é uma pesquisa em esteróides. Pesquisa qualquer coisa, filtra por qualquer campo, ordena por qualquer campo, super simples.
• Pode usar o controlo de utilizadores do ProcessWire para fazer autenticação no site. Utilizadores também são páginas, e os seus campos também podem ser modificados. Podemos criar um tipo de utilizador que se consegue autenticar no site, mas não no CMS. Clientes de uma loja, por exemplo.
• É interentemente seguro. De facto, neste post Reddit, um utilizador pergunta porque é que ainda não foram detetadas qualquer falhas de segurança no ProcessWire. Talvez porque a arqutetura é fechada por defeito e os developers só abrem o que preciusam. Os módulos ProcessWire, na sua maioria, são apenas novos tipos de campo e capacidades de output, nunca fazem demasiado sozinhos, e assim não se abrem buracos.
• É extremamente rápido. Já construí todo o tipo de sites com isto, incluindo um portal de classificados com milhares de entradas e pesquisas complexas que levam milisegundos.
• Inicialmente, fazer tudo na árvore do site parece estranho. Estamos habituados a ter sítios diferentes para gerir notícias, produtos, etc. Mas habituamo-nos rapidamente à árvore. Editores de conteúdo acabam por ter a vida simplificada, basta pensar que a estrutura de menus é igual à estrutura de conteúdo.
• E fico-me por aqui.

Está feito

Ainda tenho trabalho para fazer e o almoço está pronto, por isso fico-me por aqui. Se é um developer, sugiro mesmo que dê uma espreitadela ao ProcessWire para tirar as dúvidas. Se é um cliente, acredito mesmo que estará melhor servido com ProcessWire no seu próximo site porque ficará com uma plataforma muito mais limpa, organizada, fácil e à prova de futuro. Mas isto digo-o eu, que como já disse sou tendencioso como o raio.