Como limpar o cache do WordPress por linha de comando

Estou trabalhando em alguns projeto utilizando o WordPress como CMS e em situações específicas eu precisava limpar o cache de todo o site. Não sou fã da plataforma, acho que a performance deixa muito a desejar, mas não posso negar que ela é cheia de facilidades.

Sei que posso fazer apagar o cache por dentro do wp-admin, mas no ambiente de desenvolvimento ou se meu “trigger” para a limpeza de cache é externo, um caminho muito fácil é apagar fisicamente todos os arquivos de cache do WordPress.

Os arquivos de cache ficam em wp-content/cache e podem ter extensões .html, .gz e também .meta. Então com um simples find na linha de comando (unix) você consegue limpar o cache do WordPress com a linha abaixo:

find /var/www/wordpress.gssolutions.com.br/public/wp-content/cache/ \( -name '*.html' -or -name '*.html.gz' -or -name '*.meta' \) -delete

Lembre-se de substituir o caminho (/var/www/wordpress.gssolutions.com.br/public) pelo caminho da instalação do WP no seu servidor.

Tem uma solução melhor para lidar com estas situações? Deixe nos comentários 🙂

Dicas: jQuery performance

Duas coisas que todo o bom desenvolvedor deve se preocupar: segurança e performance.

Comecei a me preocupar e estudar mais a fundo performance em PHP quando passei a ter problemas com o crescimento do And After, para isso desenvolvi um sistema de cache inteligente utilizando o cache do Code Igniter, que aumentou muito a performance de entrega das páginas – e mesmo assim tem muito que pode melhorar.

Performance no front-end

Com a reduação dos custos computacionais (cloud, balance e servidores mais acessíveis) os problemas de processamento do backend muitas vezes são resolvidos com o "liga mais máquina", mas os problemas de performance no front-end são sentidos pelo usuário – e não temos controle sobre o computador do usuário.

A redução do custo do acesso a internet banda larga (internet 1Mb a R$35,00) permite que carreguemos mais código e imagens com mais qualidade sem prejudicar muito a entrega, mas ainda temos dois pontos principais de otimização de sites front-end que independem de banda ou do servidor:

  1. Renderização do código
  2. Performance do javascript

A forma e ordenação de como o HTML é escrito definem como ele será renderizado – e cada browser fará isso de uma forma, por isso é muito importante seguir as boas práticas e recomendações da W3C para estar preparado para o futuro, e não preso aos navegadores do passado.

Assim como o html, cada navegador tem a sua forma (ou engine) para lidar com javascript, o que diferencia muito a performance de algumas funções em um navegador ou outro – achar a forma que atende melhor seus usuários (sem ficar preso a navegadores velhacos) é o que eu vejo como melhor opção.

Se você quer entender um pouco mais sobre javascript recomendo a leitura dos slides sobre performance em javascript que postei anteriormente, os slides deste post tratam exclusivamente da biblioteca jQuery.

jQuery performance

Os slides abaixo apresentam diversos testes de performance com a biblioteca jQuery, em diversos navegadores. 

 

Uma boa forma de mensurar e testar seu código é criando uma rotina de testes de performance, que pode ser usando alguma biblioteca (ainda não usei para teste de performance) e o "modo macho", criando um cronômetro em javascript e marcando o tempo de execução de loops com cada função que você quer testar.