10 erros comuns que iniciantes no CMS Joomla! cometem

Listo 10 erros que tendo a ver em sites de usuários iniciantes do CMS Joomla! ou até mesmo em antigos usuários que não conhecem as novidades de versões mais recentes do CMS. Certamente existem algumas dezenas de outros mais, e que em algum momento futuro posso vir a listá-los.

1 - Manter o /index.php/ na URL por não saber como remover

• O que afeta: SEO;
• Quanto é aceitável: Servidores em que não é possível trocar e/ou se é forçado a usá-lo.

Tanto o Apache HTTP Server (e outros servidores compatíveis) como o IIS permitem que, quer seja via renomear o htaccess.txt para .htaccess no primeiro grupo ou o web.config.txt para web.config no IIS, quer seja habilitado a remoção do /index.php/ da URL. Em situações extremamente específicas, em que o servidor realmente não dá suporte e não há como forçá-los a habilitarem é que isso vai ser necessário. Mas, para toda a imensa maioria dos demais, remover isso da URL é bem simples.

2 - Usar /site/, /ano/, /umapalavrainutilqualquer/ na URL, como meusite.com.br/site/

• O que afeta: SEO;
• Quanto é aceitável: Quando o termo usado é pertinente em SEO, ou em site principal que contém muitos sites próximo da raiz.

Evite deixar o site dentro de uma pasta não pertinente, ou pelo menos não faça isso de forma permanente. Você pode sim, deixar em algo como /novo/ enquanto estiver arrumando o seu novo site e o antigo precisar ser usado, mas não torne isso uma prática. E se cometeu essa gafe, leia a respeito de redirecionamentos via servidor e mova para a raiz seu site. Assim, você não terá problemas futuros.

Eventualmente, fazer tal manobra é mais complicado em sites antigos (como os de algumas universidades) que possuem muitos sites abaixo da raiz (e não como subdomínios) e você não tem a ajuda de um Sysadmin que faça uma rotina mais complexa pra você, permitindo-lhe manter o site direto na raiz.

3 - Deixar que uma biblioteca de javascript seja carregada na mesma página várias vezes

• O que afeta: Performance, acesso via dispositivos móveis (principalmente);
• Quanto é aceitável: Quando o termo usado é pertinente em SEO ou no site principal que contém muitos sites próximo da raiz.

Conforme o conjunto de extensões pretendido, é possível que elas carreguem mais de uma vez o mesmo arquivo externo ou arquivos que fazem a mesma coisa, porém de versões diferentes. Exemplos mais típicos são bibliotecas de javascript (como jQuery) de versões diferentes ou rotinas de javascript de mídias sociais, em que apenas uma chamada para estas é necessária porém, em listagens do tipo blog por exemplo, para cada artigo um arquivo é incluído novamente. É um fato que em situações específicas de navegador e de setup do provedor de arquivo externo o navegador pode cachear isso, mas não é uma boa ideia pressupor esse comportamento, em especial no caso de mais de uma versão de biblioteca javascript que força seu carregamento na DOM mais de uma vez.

4 - Aceitar hospedagens não amigáveis, em especial as que colocam a culpa de seu mal funcionamento em você

• O que afeta: Produtividade, Segurança;
• Quanto é aceitável: Quando você não tem opção.

Ainda que uma hospedagem que cobre mais por mês tenda a ser melhor, isso não é regra. Porém, é razoável imaginar que valores extremistas merecem maior atenção. Na dúvida, fique alguns meses para testar uma hospedagem antes de confiar a ela todos os seus sites ou os de seus clientes. Uma hospedagem boa não é só a que não dá problemas mas aquela em que quando eles acontecem, o suporte lhe ajudará a resolvê-los. Não entenda com isso que eles devem te ajudar a resolver o seu problema enquanto aprende a manusear o CMS e/ou as ferramentas do servidor mas sim que, sem motivo aparente algo pronto começa a dar errado (e você sabe que não é sua culpa). Fique de olho aberto para ver o que sua hospedagem irá dizer e fazer a respeito.

Se você está tendo problemas demais com uma opção de host, troque um de seus projetos e teste uma outra. E cuidado para não achar que tudo deve funcionar especificamente na hospedagem que você tem/contratou.

Vale a pena lembrar que mesmo em situações em que você tem controle mínimo sobre o servidor final, ter pelo menos acesso direto ao banco de dados e FTP nos primeiros meses é fundamental, pois é muito mais prático você mesmo resolver um erro do que enviar um email e pedir para alguém fazê-lo, se é que a pessoa vai saber fazer ou se vai fazer certo.

5 - Usar senhas de Super Administrador iguais em sites de clientes, e ainda por cima ter um link para eles do seu portfólio

• O que afeta: Segurança;
• Quanto é aceitável: Nunca.

123, 1234, 12345, admin, admin123, mesmo nome de usuário na senha, a senha do seu hotmail, a senha que usa há 5 anos, a senha que digita no computador do seu cliente ao fazer uma demonstração... Se além de senhas fáceis, você usa a mesma senha em todos os sites, muito cuidado: isso é um perigo. Nem vou dizer que jamais deveria usar admin como nome de usuário...

Qual o problema disso? Bem, além destas senhas tenderem a ser um vetor que pode ser explorado desde alguém que tem acesso a sua wireless descriptografada em um evento do CMS Joomla!, como um cliente seu, ou ex-funcionário depois de alguns meses pode lhe fazer uma surpresa. E levar um susto de uma só vez é uma coisa, agora ter TODOS os seus sites invadidos é uma dor de cabeça enorme, em especial se você nem souber de onde veio o problema.

6 - Usar uma mesma conta de SSH/FTP para gerenciar arquivos e outra conta de acesso ao banco de dados para gerenciar grupos de sites não análogos

• O que afeta: Segurança;
• Quanto é aceitável: Nunca.

Imagine a situação: um site seu, quer seja ao acaso ou porque é um vetor mais propício a ataques (como algo que lida com denúncias ou que é de cunho político) é invadido. Existem algumas dezenas de modos de impedir isso, mas se acontecer, poderá ser ainda pior se o mesmo usuário de acesso aos arquivos e os de acesso ao banco de dados forem de uso comum a outros sites não análogos. Ou seja, você pode ter uma quantidade muito maior de problemas, clientes reclamando, estresse olhando diretório por diretório em busca de um trojan colocado em alguma pasta perdida de seus sites, quiçá em todos eles.

Mesmo que uma hospedagem permita que você tenha vários sites em uma conta, procure permitir que cada site tenha modos de acesso completamente diferentes, com senhas diferentes.

Díspar das senhas de acesso ao painel administrativo, que precisam que você volta e meia digite as de acesso ao banco de dados e de conta FTP, com possibilidade de 30 caracteres e gerenciadas com algum software como o KeePass.

7 - Aprender a fazer algo e não mudar nunca mais, e reclamar de atualizações

• O que afeta: Produtividade (médio/longo prazo), Segurança (caso mantenha extensões antigas);
• Quanto é aceitável: caso converta seu site para HTML estático.

Algo positivo e aconselhável a quem está começando ou a quem está partindo de uma versão muito antiga para uma nova do CMS é, antes de fazer algo em Joomla, parar e testar extensões e ver com quais se adapta melhor. Custa tempo, dá trabalho, mas garante ao profissional que seu uso em situações reais se dêem sem surpresas. Não que isso represente que você vai ter que testar uma solução para cada tipo de nicho muito específico de mercado, mas pelo menos lhe proporcionará ter soluções usuais sempre a disposição. O problema está em fazer isso uma vez e nunca mais mudar.

Um tempo que eu pessoalmente acho razoável para parar e ver novidades é de 6 meses até, no máximo, o tempo de vida de uma versão LTS do Joomla! (em torno de um ano e meio).

8 - Achar que não precisa atualizar o CMS depois de um site feito

• O que afeta: Segurança;
• Quanto é aceitável: nunca, ou em situações em que você assume um compromisso de se responsabilizar por toda e qualquer brecha de segurança sem culpar o CMS.

O CMS Joomla! (na data em que este artigo é escrito, dispõe download na versão 3.0) tende a permitir atualizações mais frequentes, porém com uma dificuldade extremamente menor que suas versões anteriores. Nestas, isso era feito apenas com versões de atualização de segurança. Com o CMS "em dia", as atualizações disponibilizadas trarão além de correções de segurança, novas características back e/ou frontend. O real problema está em pessoas que vendem um site Joomla! sem levar em consideração que ele precisa ser atualizado (ainda que isto apenas requeira apertar um botão no painel administrativo). Nem sempre será tão simples quanto apertar esse botão e quando isso acontecer você terá que estar preparado para fazer uma cirurgia ou preparar seu cliente de que em algum momento, tal procedimento poderá acontecer.

Se você é novo no Joomla! e não gosta disso, troque de CMS. E se você vem de um ambiente em que "acha software livre inseguro em relação a algo que você faz sozinho com código fechado", faço um convite para fazer um scan em um site Joomla! e no seu CMS customizado e ver quais você consideraria mais fácil invadir.

9 - Subutilizar ou usar de modo errado o Nível de Acesso de Usuários (ACL) e associação de menus

• O que afeta: Produtividade, SEO, Segurança (no caso da ACL);
• Quanto é aceitável: usuário iniciante ou situações extremamente específicas feitas intencionalmente.

A associação de menus não é algo recente em Joomla! mas nem todos entendem o comportamento que ela pode ter quando a interação com o site ou a exibição pretendida em uma determinada área deste irá funcionar. A dificuldade se dá, em especial, nos casos em que não há uma relação direta com o elemento ou então que a relação não é obvia. Um sintoma típico disso é observado em sites que fazem um uso mais extensivo de módulos, templates ou estilos de templates diferentes entre páginas ao acessar ou um artigo em uma categoria específica, ou fazer uma pesquisa no componente de busca ou o de busca inteligente. Já o controle de nível de acesso detém uma complexidade que, se compreendida, permite manobras como exibir algo a um visitante, porém não a um usuário autenticado (comportamento que no passado eventualmente forçava gambiarras ou uso de extensões).

O modo de entender esta mecânica é levar a sério qualquer treinamento via facilitador(a) ou estudo sozinho que faça a respeito destes dois itens. Situações mais complexas tendem a não ser usadas de início, porém podem gerar uma boa dor de cabeça e corrida a fóruns e listas de discussões. Ter em mente não só o que parece óbvio mas procurar entender a lógica de como o CMS presupõe comportamentos. Lógicas como estas podem salvar um tempo enorme e seus projetos futuros! Se todos os artigos de um grupo devem ter um estilo parecido, organizá-los sob uma categoria e aplicar esses estilos a essa categoria é outro exemplo.

10 - Não entender o CMS e usar extensões demais ou mesmo passar ainda mais trabalho

• O que afeta: Produtividade (médio/longo prazo), Segurança (caso mantenha extensões antigas), Performance;
• Quanto é aceitável: quando você é iniciante (ou não domina um tópico específico) ou quando a extensão melhora a produtividade (não apenas a curto mas a longo prazo).

Tanto alguém que é iniciante em Joomla! ou quem usou o CMS em versões muito antigas, tende a querer usar extensões em demasia. E a lógica é simples: se existe uma extensão focada em algo, por que não usá-la? Eu diria que isso é questionável: boa parte das extensões existem porque ou no passado eram necessárias ou porque boa parte dos usuários não sabem como usar o CMS puro do modo certo. E o que leva a maioria das pessoas/profissionais a esse tipo de erro? Não saber razoavelmente bem sobre controle de nível de acesso (ACL), sobreposição de template e estilos, associação de menus, e claro, não conhecer as extensões "de fábrica" presentes no CMS.

Um usuário que não tem experiência consistente em desenvolvimento frontend, pode tender a usar CCKs em demasia, onde com alguma sobreposição de template o serviço estaria feito. Isso não é algo errado. Agora, esse exemplo específico a alguém que pelo menos saiba fazer templates, tende a ter um ganho de produtividade e performance.

A melhor solução é estudar o Joomla! puro. Mais do que isso, memorizar conceitos ao invés de armazenar via força bruta como as coisas funcionam. Reserve um tempo para ver como a instalação padrão com conteúdo de exemplo funciona tanto do ponto de vista do visitante como na administração de seu site, ou seja, como ela foi feita. Se estiver em dúvida sobre qual o jeito certo de fazer algo e ouvir/ler/for aconselhado com informações conflitantes, siga esse padrão.