MEP WP Cache: Perguntas frequentes e tutorial (em português)

Conhece a Digital Ocean? Tenha VPS em cloud pagando a partir de US$ 5 por mês! Cadastre-se pelo meu link de afiliado aqui e ganhe US$ 10! Dá para testar o plano mais básico por 2 meses, ou o segundo por um... Existem várias distros Linux pré-configuradas, muitos tutoriais de instalação dos serviços web e um excelente suporte. O serviço é rápido e estável, tenho gostado muito! Vale a pena conferir e resgatar os seus 10 dólares de crédito ao ativar sua conta. Eles aceitam PayPal ;)

Esta página traz perguntas frequentes referentes ao uso do MEP WP Cache, plugin para WordPress focado em entregar conteúdo estático (HTML) sempre que possível, levando a carga do PHP e MySQL próxima a zero na maioria dos servidores.

IMPORTANTE! MESMO SE VOCÊ NÃO USAR ESTE PLUGIN DE CACHE, leia as dicas no tutorial no final, especialmente sobre rewrite no Apache ou Nginx… Isso irá te ajudar com vários outros plugins de cache! As regras são bem parecidas para todos, o que vai mudar em geral é o caminho da pasta do cache, e só! Eu fiz uma explicação bem detalhada sobre isso.

Para que mais um plugin de cache?

Sendo direto: nenhum dos que existiam me atendiam plenamente, já que tinham muitas opções, bem além das que eu precisava. Quero um plugin com código leve e pequeno, simples e rápido. E o principal: QUE NUNCA APAGUE O CACHE, só ao postar novos conteúdos mesmo. A maioria dos outros plugins trabalham com expiração, agendam tarefas no cron, ficam fazendo verificações que causam um peso maior no servidor dependendo das circunstâncias. O MEP WP Cache não: ele é bem mais direto, apenas cacheia as páginas conforme são acessadas e depois você esquece que ele existe. Se você cachear o site todo, pode fechar ou desinstalar o MySQL (vilão de recursos) que as páginas em cache continuarão funcionando.

Qual é a configuração do servidor necessária?

Preferencialmente servidores Linux com Nginx ou Apache, mas é provável que rode em vários outros.

Funciona com hospedagem compartilhada?

Sim, claro! Aliás é super recomendado para hosts compartilhados ou VPS baratos: o MEP WP Cache não usa tarefas do cron, não faz cache excessivo de uma vez e nem fica apagando os arquivos do cache, somente quando necessário. Você só precisa carregar os arquivos e configurar permissões de gravação na pasta /wp-content/cache (não recomendo deixar as permissões de gravação na pasta wp-content inteira, somente na cache!).

Qual a diferença do cache PHP e rewrtite?

No modo PHP ainda há um certo trabalho do cabeçalho do WordPress: os códigos e bancos de dados são carregados pois o WordPress é incializado. O plugin detecta se a página já está em cache, e se não estiver ele cria o cache na hora. Se a página estiver no cache, ele lê o conteúdo do arquivo HTML que está na pasta (é basicamente um TXT) e embute na resposta ao navegador. É mais rápido do que fazer diversas consultas ao banco de dados como o WordPress faria, mas o banco de dados ainda é acessado. Se o MySQL estiver ocupado ou caído, o site ficará fora do ar (Erro ao estabelecer conexão com o banco de dados…).

No modo rewrite, o mais recomendado, o cache é feito diretamente pelo servidor web. O WordPress não é carregado, o PHP e o MySQL sequer são chamados!!! Isto é extremamente rápido. O servidor web basicamente vai ler o arquivo da pasta e entregar ao visitante. Se você usar um servidor de baixo consumo de recursos, como o Nginx, seu site voará! Vai dar para atender muito mais usuários simultâneos do que antes.

Para ativar o modo rewrite você precisa configurar o servidor. Há exemplos prontos para usar no Apache e Nginx, é só copiar e colar! Veja na pasta help do plugin, deixei alguns arquivos .txt com o código para usar no .htaccess e também para o arquivo de configuração do Nginx.

O cache funciona para páginas com parâmetros na URL (GET/POST)?

Este é um diferencial recomendado do MEP WP Cache! Sim, com o método rewrite isso funciona! Muitos plugins pulam o cache se um comando GET ou POST for enviado… Isso é ruim, pois há parâmetros que não têm nada a ver com o servidor, como ?utm… para trackear a origem dos acessos no Google Analytics. O MEP WP Cache irá cachear as páginas normalmente, entregando o arquivo HTML salvo da pasta mesmo nesse casos!

Para a maioria dos usuários isso JAMAIS será um problema, pois as requisições do WordPress são feitas a arquivos que já ficam fora do cache por padrão: wp-login.php, index.php, wp-comments-post.php, etc. Estes arquivos não geram o cache, continuarão funcionando normalmente.

Isso só traria problemas caso você use algum plugin que de fato precisa que uma página do blog receba parâmetros GET ou dados via POST. De qualquer forma nestes casos você pode desativar ou ativar conforme a necessidade, diretamente nas regras de rewrite do seu servidor web.

Como posso saber se a página que vi veio do cache ou foi gerada dinamicamente?

Você pode ver o código fonte da página no navegador: o plugin adiciona um comentário em HTML no final da página. Este comentário não aparece no site, somente ao ver o código fonte. Se ele não estiver presente, é sinal de que a página foi gerada dinamicamente (pesando nas costas do PHP + MySQL).
Se você quiser saber se o cache foi entregue diretamente (rewrite) ou via PHP, será necessário analisar o cabeçalho da página com ferramentas específicas (ou mesmo sites da web). Por exemplo, entre em http://www.webconfs.com/http-header-check.php e coloque a URL da sua página. Se aparecer “X-Cache-Handler: php” então a página foi entregue pelo PHP (usando um mínimo de PHP + MySQL). É recomendável utilizar o rewrite sempre que possível, o desempenho é muito superior.

Funciona com temas mobile?

O ideal hoje em dia é que você use um tema responsivo, que se adapta à tela do aparelho. Desta forma os mesmos arquivos do cache são entregues a todos os visitantes, sem distinção de sistema operacional, browser nem tamanho de tela. Os temas responsivos podem ser listados no código do plugin para ignorar o cache (caso do WPtouch), mas este código vem desativado e futuramente provavelmente será removido deste plugin para otimizar ainda mais o processamento (eles continuam no Cache Enabler, no entanto). O maior objetivo do MEP WP Cache é entregar conteúdo estático em 99%+ do tempo. Hoje em dia uma parcela significante dos acessos vêm de dispositivos móveis (varia de site para site, mas comigo anda entre 20 a 60% dependendo do site). Sendo assim, não é vantagem entregar o site mobile sem cache, iria pesar no servidor de forma significante… E não estou disposto a programar dois caches, um desktop e um mobile. Isso tornaria o uso do rewrite e as mesmas URLs impraticável, forçando a usar o PHP para verificar qual versão entregar… Ando mudando todos os meus sites para temas responsivos, sugiro que faça o mesmo ;-)

Há plugins incompatíveis?

Não é ideal usar este plugin junto com plugins como WPtouch, Carrington, Jetpack e Handheld, entre outros. Plugins que entregam um tema diferente dependendo da tela ou aparelho prejudicam o cache. Faz uma força aí e use um tema responsivo, vai fazer bem ao seu site ;)

Funciona com instalação multisite?

Em tese sim, mas pode ser necessário testar melhor antes para ter certeza de que tudo está OK.

Funciona com permalinks personalizados?

Sim, aliás ele só funciona bem com estes permalinks personalizados! Caso use o formato padrão “?p=id…” não dará certo, já que a página sempre será processada pelo PHP do WordPress. Você deve usar permalinks personalizados, podem incluir a data ou o nome do post.

Funciona com comentários do Disqus, ou Facebook, entre outros?

Sim! Aliás é até ideal em alguns aspectos: isso vai tirar o peso do seu servidor no que toca aos comentários, de forma que você pode apagar ou bloquear o acesso ao wp-comments-post.php, acabando com boa parte da carga causada por bots de spam. Mas cada caso é um caso. O MEP WP Cache funciona tanto com o sistema de comentários padrão do WordPress como com comentários externos. Alguns plugins de captcha e proteção anti-SPAM poderão não funcionar se forem baseados em cookies; se não forem baseados em cookies mas sim num código publicado diretamente no HTML, então devem funcionar sem problemas (atualmente uso o Stop Spam Comments).

Meu site ainda precisará do MySQL e PHP?

Se você desativar os comentários do WordPress e fizer um esquema para cachear todas as páginas, poderia até mesmo desinstalar o MySQL que o site continuaria funcionando para sempre (desde que esteja no modo rewrite, claro, o mais recomendado). Desta forma daria para usar um VPS com pouca memória (256, quem sabe 128 MB?). Por exemplo, você ativaria o MySQL para usar o painel de administração e publicar posts… Ao sair, desativa o MySQL e o site continua no ar com desempenho excelente.

Quem tem servidores com pouca memória normalmente não usa ferramentas avançadas de cache como Varnish… Ele beneficia mais sistemas com muita memória, já que costuma guardar um cache dos arquivos na RAM. Mesmo usando o Varnish seria bom um cache estático no WordPress, já que o conteúdo dos posts não muda depois de publicados, na grande maioria dos sites mesmo… Para que depender de PHP + MySQL quando o texto pode ser entregue a partir do HTML puro?

A maioria das hospedagens compartilhadas opta pelo uso do Apache, situação onde o cache do MEP WP Cache fará muito bem! Se você tem um VPS, cloud ou dedicado com controle total (root), recomendo fortemente o uso do Nginx. Ele entrega arquivos estáticos com uma velocidade magnífica. Ao usar o modo rewrite, os arquivos do cache são apenas arquivos HTML, JS, CSS, imagens… O desempenho é muito bom e o consumo de memória é bem baixo, mesmo com vários acessos simultâneos. O MySQL é um vilão de recursos no que toca ao WordPress.

A geração do site todo estático ainda não foi implementada nativamente, mas basta acessar todas as páginas ao menos uma vez… Algo como gerar uma lista de URLs e acessar todas com o wget ou curl.

Quando o cache será apagado automaticamente?

O MEP WP Cache evita ao máximo apagar o cache pelos motivos expostos. O objetivo é entregar conteúdo estático em 99,9% ou mais do tempo. Diferente de outros plugins, a proposta é manter o cache o maior tempo possível. O cache deve ser limpo apenas quando algo de fato mudar em todas as suas páginas, como o tema, links nos menus, listas de coisas recentes (posts ou comentários), etc. Pode ser bom limpar o cache de tempos em tempos caso você use vários widgets de RSS, por exemplo – nesse caso, sinceramente eu recomendaria o uso de algum outro plugin. Como quero forçar o uso do modo rewrite e não depender em nada de tarefas agendadas para otimizar ao máximo o processamento, o MEP WP Cache nunca vai ficar verificando por datas e horas para ver se deve ou não apagar um arquivo. Ele é mais leve, roda menos código no servidor. Menos se (isso), se (aquilo)… Mais {ações}!

Atualmente o cache é apagado automaticamente em algumas situações. Você pode editar o código do plugin para remover alguma indesejada. No arquivo principal dele (main class), procure por public function __construct() e comente as ações do WordPress que chamam a função clear_total_cache.

No momento em que escrevo para a versão 1.0, o cache será limpo automaticamente numa destas ações:

  • Publicação ou edição de post (nas opções do plugin você configura se deve ser limpo o cache todo ou somente da página em questão)
  • Publicação ou edição de comentários (idem, você altera se quer limpar todo o cache, ou só do post em questão)
  • Atualizações do WordPress (_core_updated_successfully)
  • Troca de tema (switch_theme)
  • Exclusão de post, para atualizar as páginas com menus para ele (wp_trash_post)
  • Ao ativar ou desativar o plugin
  • E na limpeza do cache feita pelo Autoptimize, caso você o utilize (autoptimize_action_cachepurged)
  • (particularmente recomendo mais usar o módulo PageSpeed no servidor do que esses plugins, seria uma compressão mais otimizada a nível de código)


Tutorial rápido de instalação do plugin de cache para WordPress

Não esqueça de ativar o modo rewrite, ele é bem eficiente.

Primeiramente desative todos os outros plugins de cache estático que porventura você possa estar utilizando (WP Super Cache, W3, Cache Enabler, etc). O MEP WP Cache foi projetado para funcionar sozinho, dois plugins de cache que geram as páginas estáticas certamente daria conflito. Você precisará remover as regras do plugin antigo no .htaccess ou arquivo do servidor web, caso tenha colocado (dê uma olhada no seu .htaccess na pasta do WordPress). Se você nunca usou plugin de cache antes, não precisa se preocupar com isso.

No MEP WP Cache não é necessário alterar o wp-config.php para adicionar o comando de cache, nem usar o arquivo wp-advanced-cache.php. Nada disso ;-) Basta ativar o plugin, liberar permissão de escrita na pasta wp-content/cache e configurar as regras de rewrite, seja via .htaccess no Apache ou no arquivo de configuração do servidor, no caso do Nginx.

Passo 1: Instale o plugin normalmente

Coloque a pasta dele na pasta wp-content/plugins, vá até a seção de Plugins do WordPress e o ative. Procedimento padrão para qualquer plugin.

ativar plugin de cache no wordpress

Passo 2: Como ativar a pasta do cache

Dentro da sua pasta wp-content, crie uma pasta chamada cache. Atribua a ela permissões de escrita/gravação para seu usuário, seguindo as orientações da sua hospedagem (normalmente ative a permissão chmod 755, ou 777 em último caso – 755 é o recomendado).

Exemplo: Filezilla

liberar permissao de escrita na pasta cache

salvar permissoes de pasta no filezilla

É bom marcar para aplicar também às subpastas, e aproveite para excluir as pastas de cache de outros plugins, caso tenham ficado por ali. Dentro da pasta cache este plugin criará uma pasta própria.

Exemplo: Terminal

No terminal (local ou SSH) bastaria dar o comando chmod -R 755 /caminho/da/pasta/cache. Caso não funcione, alguns usam o 777, mas não é legal usar o 777 em hospedagem compartilhada não. Se você usa um VPS, cloud ou dedicado só seu, não há tanto problema em usar 777 já que todos os usuários estão sob seu controle. Mas no caso de hosts compartilhados é ruim, já que pessoas com outras contas no mesmo servidor também poderiam alterar os arquivos do seu site, caso saibam o caminho da sua pasta. Nesses casos quando um site é invadido, muitas vezes vários outros são… Em hosts de hospedagem compartilhada com milhares de contas por servidor isso é bem ruim.

Pronto! O cache passará a funcionar com a configuração padrão, mas ainda não estará no modo “turbo”: ele vai usar PHP + MySQL no carregamento das páginas, mas não na montagem do conteúdo do blog. Você deve ativar o modo rewrite para máxima performance.

Passo 3: Vá em Configurações > MEP WP Cache

Revise as opções e marque as apropriadas. São bem poucas! É um dos plugins mais práticos e diretos. Detalhes sobre o que cada opção faz estão logo mais abaixo, nesta página.

Ele exibe o tamanho do cache na entrada do painel do WordPress e também na página do plugin. Há um link para limpar todo o cache na barra do WordPress, à direita (próximo ao seu nome). Esse link permite limpar o cache rapidamente, útil quando você alterar os widgets ou alguns elementos do tema.

Passo extra 3.5: o MEP WP Cache só funciona com os permalinks personalizados do WordPress. Como praticamente todo mundo usa isso, não inclui como um passo necessário. Se seus posts são exibidos na forma blog.com.etc/?p=123, não dará certo! É necessário alterar os links permanentes em Configurações > Links permanentes para alguma estrutura diferente da padrão. Eu gosto de usar o nome do post (%postname%), mas não há problema em usar as datas ou as categorias não.

links permanentes do wordpress para o plugin de cache

Passo 4: Ative o modo rewrite, que dará um turbo danado no seu site!

Ativar o modo rewrite pode parecer complicado, mas não é tão difícil. Você precisa adicionar um trecho de código no seu arquivo .htaccess, caso use o Apache, ou no arquivo de configuração do site, caso use o Nginx. O código é parecido com o de vários outros plugins de cache: basicamente ele vai redirecionar internamente as chamadas aos arquivos para os que existirem na pasta do cache. Se o arquivo HTML existir para a página solicitada, ele é entregue diretamente, sem passar pelo WordPress, portanto, sem consumir nada nada de PHP + MySQL! Caso não exista, ele será entregue pelo WordPress e em seguida armazenado no cache, assim todas as próximas requisições ao mesmo arquivo virão do cache, sem chamar o PHP + MySQL de novo.

Na pasta “help” do plugin tem o código que você precisa colar.

Como ativar o rewrite no .htaccess do Apache

Primeiro, certifique-se de que o mod_rewrite existe e está ativo no seu servidor, caso use um VPS… Se não estiver ativado, ative-o primeiro (geralmente com a2enmod rewrite seguido de service apache2 restart, caso do Ubuntu). A maioria das hospedagens compartilhadas já têm este módulo ativado por padrão.

Para ativar o rewrite deste plugin no Apache abra o arquivo .htaccess em um editor de textos, e antes da linha # BEGIN WordPress, cole o código de rewrite do MEP WP Cache a seguir:

# BEGIN MEP WP Cache

RewriteEngine On
RewriteBase /

# set blog sub path
SetEnvIf Request_URI "^(.*)$" SUB_PATH=/wp-content/cache/mep-wp-cache/

# set path
SetEnvIf Request_URI "^(.*)$" CE_PATH=$1
SetEnvIf Request_URI "^(/)index.php$" CE_PATH=$1

# default HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html [L]

# wp override
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [END]

# END MEP WP Cache

No final dele vai ficar o que já estava, o dos links permanentes do WordPress.

Se já havia algum código de outro plugin de cache, remova ele primeiro. O do WordPress não é bom remover não, caso contrário você poderá ter problemas com os permalinks.

IMPORTANTE: O código acima funciona nas versões atuais do Apache, mas pode dar problemas com as versões antigas (anteriores ao 2.3.9). Se for o caso, use este outro código:

# BEGIN MEP WP Cache

RewriteEngine On
RewriteBase /

# set blog sub path
SetEnvIf Request_URI "^(.*)$" SUB_PATH=/wp-content/cache/mep-wp-cache/

# set path
SetEnvIf Request_URI "^(.*)$" CE_PATH=$1

# default HTML file
RewriteCond %{ENV:CE_PATH} /$
RewriteCond %{ENV:CE_PATH} !^/wp-admin/.*
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""
RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_
RewriteCond %{DOCUMENT_ROOT}%{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html -f
RewriteRule ^(.*) %{ENV:SUB_PATH}%{HTTP_HOST}%{ENV:CE_PATH}index.html [L]

# END MEP WP Cache

Ele vai fazer exatamente a mesma coisa, mas tem algumas diretivas diferentes apenas.

Como ativar o rewrite do plugin de cache no Nginx

Se você usa o Nginx, que aliás eu super recomendo (geralmente consome bem menos memória que o Apache, ideal para VPS baratos ou sites com alto tráfego), edite o arquivo de configuração do seu domínio (/etc/nginx/sites-available/seusite…) e adicione este código dentro da seção {server} correspondente:


### START MEP WP CACHE

set $cache_uri $request_uri;

### POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
set $cache_uri 'null cache';
}

if ($query_string != "") {
set $cache_uri 'null cache';
}

# Don't cache uris containing the following segments
if ($request_uri ~* "(/wp-admin/|/xmlrpc.php|/wp-(app|cron|login|register|mail).php|wp-.*.php|/feed/|index.php|wp-comments-popup.php|wp-links-opml.php|wp-locations.php|sitemap(_index)?.xml|[a-z0-9_-]+-sitemap([0-9]+)?.xml)") {
set $cache_uri 'null cache';
}

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
set $cache_uri 'null cache';
}

# Use cached or actual file if they exists, otherwise pass request to WordPress
location / {
try_files /wp-content/cache/mep-wp-cache/$http_host/$cache_uri/index.html $uri $uri/ /index.php ;
}

### END MEP WP CACHE

Obrigado pessoal do Easy Engine pelo código ;)

A seguir reinicie o Nginx com service nginx restart (ou reload em vez de restart, mas costumo usar o restart).

Se seu código já tiver uma seção de arquivos “location / {…”, será necessário removê-la ou mesclar o conteúdo da seção com ela. Caso contrário o serviço não irá ser iniciado. Deixo abaixo um print de como está o meu nesse momento, para referência de onde colar:

O começo do código:

parte 1 do codigo do rewrite no nginx

E o final:

parte 2 do nginx

Observe que logo abaixo estava a seção location / {…, eu comentei toda ela colocando # antes, para desativá-la. A versão colada para uso com o plugin já fará o que ela faria, que é passar o controle das requisições para o index.php do WordPress caso não encontre os arquivos no cache.

Plugin de cache instalado, agora vamos aos testes! Como saber se está tudo OK?

Para ver se o plugin está gerando o cache dos arquivos corretamente, basta dar uma olhada na pasta do cache. Ele vai criar pastas e subpastas com a estrutura do site lá dentro.

Por padrão o cache não será visível aos usuários logados, nem a quem postou um comentário. E também será ignorado em requisições POST ou GET (no próximo tópico mostro como contornar isso, forçando o cache para todo mundo).

A melhor forma de ver é usando outro navegador deslogado, ou o modo anônimo que os navegadores atuais fornecem. Abra uma guia anônima (CTRL + SHIFT + N no Chrome, ou pelo menu… O Firefox e o Edge também têm) e acesse alguma página do seu site. Verifique o código fonte dela. No final terá um comentário adicionado pelo plugin informando a data e hora em que o cache foi gerado. Se aparecer este comentário, feito! Você acessou a versão em cache da página.

O cache é gerado aos poucos, conforme as páginas são acessadas. Sendo assim, no primeiro acesso de uma página ela ainda não está no cache. Ele é gerado ali, e todas as demais requisições receberão a página em cache. Seja uma pessoa ou dezenas, centenas, milhares acessando o seu site… Então se o comentário com o código não aparecer, experimente recarregar a página e olhar de novo – na segunda vez ela deverá ser carregada do cache.

Se tudo deu certo, é isso!

Se você não aplicar as regras de rewrite no seu servidor web, o index.php do WordPress vai continuar responsável pelas requisições, que não serão entregues a partir dos arquivos HTML do cache… Isso é ruim, pois apesar de consumir menos recursos do que um site sem cache nenhum, o PHP + MySQL ainda serão acionados. Se o servidor MySQL cair o site ficará fora do ar, por exemplo. Com o rewrite, não! As páginas que já estiverem no cache ficarão no ar por tempo indefinido (vai depender das suas configurações; o cache NUNCA será apagado por completo automaticamente pelo plugin, somente ao trocar tema ou caso você tenha configurado ou clique no botão para apagar).

Como saber qual modo está ativo? PHP ou rewrite?

Para saber isso será um pouco mais complicado: você precisa ver o cabeçalho http. Você pode fazer isso usando ferramentas de linha de comando ou mesmo sites online. Por exemplo, entre em http://www.webconfs.com/http-header-check.php e teste alguma página (seja a inicial ou link de algum post). Se aparecer “X-Cache-Handler: php” então o cache está sendo servido de forma não tão otimizada, pelo PHP. Depois de configurar o rewrite isto deve sumir do cabeçalho http.

Eu acho que isso é ESSENCIAL: usar o cache para requisições POST e GET

A grande maioria dos plugins de cache não servem a versão estática ao encontrarem pedidos POST ou GET, o que pode complicar dependendo da situação. Eu recomendo cachear também as páginas para posts assim. Isso só vai ser ruim se você precisar de plugins que dependam de requisições GET ou POST para funcionar, como aqueles que adicionam parâmetros na URL (algo como seusite.com.etc/?coisa1=teste&coisa2=blablabla). Estas páginas não existem na maioria dos casos, visto que usamos os blogs para servir conteúdo! Elas são comuns em lojas virtuais e sites de membros logados.

Você pode ativar ou desativar o redirecionamento ao cache para este tipo de página diretamente nas regras de rewrite, alterando alguns parâmetros por lá. Você pode comentar as linhas colocando um # (hashtag ou jogo da velha), assim não precisa apagar e fica fácil reverter ao mudar de ideia.

Particularmente gosto de forçar o cache também para páginas com GET ou POST por causa do parâmetro ?utm… que é bem comum em links de rastreamento, como os do Google Analytics. Se você recebe tráfego no seu site com estes links, o ideal é cachear as páginas também!

Normalmente você não vai ter problema nenhum em ativar o cache para isso, já que a funcionalidade básica do WordPress será preservada: o painel de administração e os arquivos wp-algumacoisa.php nunca passarão pelo cache.

Como ativar ou desativar o cache para páginas com GET ou POST no Apache

No código que você adiciona ao .htaccess, observe estas duas partes:

RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} =""

A primeira coloca uma condição para a reescrita, que basicamente quer dizer isso: se o método de requisição (request method) for diferente de POST (usado no envio de formulários, saca aquele <form method=”post”…?), beleza, pode entregar o cache. A segunda é parecida: se os parâmetros de URL (query string) forem vazios (“”), ou seja, não existirem (aquelas coisas site.com.etc/?parametro=valor), então entregue o cache. A entrega do cache é feita pela RewriteRule, que vem após estas linhas.

O que você precisa fazer é remover estas linhas, ou melhor, comentá-las. Basta adicionar um # antes (ou retirar, se o que você quiser for o oposto). Ficaria assim:

#RewriteCond %{REQUEST_METHOD} !=POST
#RewriteCond %{QUERY_STRING} =""

Para experimentar, acesse o navegador no modo anônimo tendo certeza que sua página foi cacheada. Verifique o código fonte e observe a última linha. Tem o comentário do plugin? Então você recebeu o arquivo do cache.

Agora entre no site colocando qualquer parâmetro depois da URL, por exemplo, /?teste=1. Ficaria assim, só um exemplo: seusite.com/post-de-teste/?teste=1

Observe o código fonte desta página. Tem o comentário do cache? Se não tiver, ela foi servida pelo PHP + MySQL, ou seja: consome mais recursos do servidor.

Vale a pena experimentar e ver se seu site funciona bem com estas duas linhas no arquivo comentadas. Com elas comentadas ou apagadas o desempenho será melhor, mas alguns plugins de lojas virtuais e coisas que exigem parâmetros ou formulários talvez não funcionem.

Como ativar ou desativar o cache para páginas com GET ou POST no Nginx

Primeiramente, leia a seção acima sobre o Apache. É basicamente a mesma coisa, só vai mudar o lugar em que você fará isso ;)

No arquivo de configuração do seu site, onde colou os comandos de rewrite… Procure por estas linhas:

### POST requests and urls with a query string should always go to PHP
if ($request_method = POST) {
set $cache_uri 'null cache';
}

if ($query_string != "") {
set $cache_uri 'null cache';
}

Veja que a lógica é a mesma! Se (o método de requisição for POST) então (configure para não usar o cache). A mesma coisa na parte de baixo referente ao GET: se (o texto da consulta for diferente de nada, ou seja, se tiver qualquer caractere) então (configure para não usar o cache).

O que você precisa fazer é comentar estes campos, colocando # no início das linhas:

### POST requests and urls with a query string should always go to PHP
#if ($request_method = POST) {
#set $cache_uri 'null cache';
#}

#if ($query_string != "") {
#set $cache_uri 'null cache';
#}

Dica boba, mas válida: não precisa ser os dois!

Você pode fazer isso isoladamente, só para o POST ou para o GET. Por exemplo, se você quer usar o parâmetro ?utm… para rastrear os acessos no Google Analytics, bastará comentar ou remover as linhas do método GET, podendo deixar o post.

Para melhor desempenho recomendo desativar nos dois casos, comentando todas elas.

Note que o preview de post talvez não funcione se você mandar cachear as requisições GET!

Como forçar o cache para os usuários logados?

Por padrão os usuários logados sempre verão as páginas dinâmicas: elas são geradas em tempo real, consumindo poder de processamento do PHP, MySQL… Em geral vai ser menos pesado do que se você não usasse plugin de cache, afinal somente os administradores e editores são os usuários na maioria dos casos. Assim eles sempre acessam as páginas mais recentes ao visualizá-las. É bom para testar plugins, temas, ver alterações do post e previews…

Mas se o seu site tem muitos usuários logados, seja uma lojinha, rede social, página de membros etc… A coisa pode complicar um pouco, né? Talvez valha a pena ativar o cache também para os usuários logados.

Eu não inclui opção para isto direto no plugin pois prefiro que ela seja alterada nas regras do rewrite, será bem mais eficiente – caso contrário o plugin teria um trabalho a mais, além de entregar o cache em PHP e não o estático 100%…

Nas regras do rewrite basta alterar a linha referente aos cookies dos usuários logados. Vamos por partes, primeiro o Apache, mais popular, depois o Nginx, mais eficiente ;)

Como forçar o cache para usuários logados no Apache

No código do MEP WP Cache adicionado ao .htaccess, localize esta linha:

RewriteCond %{HTTP_COOKIE} !(wp-postpass|wordpress_logged_in|comment_author)_

Ela faz ignorar a regra do rewrite caso tenha um cookie… No exemplo acima, em três situações:

  • Se tiver o cookie wp-postpass, referente a um post protegido por senha… Estas páginas não podem ser cachedas desta forma! Afinal de contas elas são dinâmicas: a exibição do formulário de senha ou do conteúdo é diretamente dependente do cookie de autorização…
  • Ou se tiver o cookie wordpress_logged_in, que existe quando um usuário está logado (rá! é esse que temos que tirar!)
  • Ou o cookie comment_author, que existe quando alguém posta um comentário. O WordPress usa isso para mostrar aquela mensagem “Seu comentário foi enviado e está aguardando moderação” somente para quem comentou, não para todos os visitantes… Esta página não pode ir pro cache por razões óbvias: se ela for pro cache todo mundo vai ver esta mensagem, mesmo quem não deixou comentário nenhum.

Como você deve ter imaginado, você precisará remover o wordpress_logged_in dali, e uma barra. A barra ali indica “ou” (“or”). Traduzindo ela:

Condição pra reescrita: se tiver um cookie que não seja nenhuma destas opções: post com senha OU usuário logado OU alguém que acabou de comentar.

Você deve deixar esta linha assim, então:

RewriteCond %{HTTP_COOKIE} !(wp-postpass|comment_author)_

Prontinho! ;-)

Se você usa comentários de terceiros (como Disqus, Facebook etc) e não usa nenhum post protegido com senha (muita gente não usa este recurso), pode comentar ou remover esta linha inteira, adicionando o jogo da velha # no começo dela. Assim pode dar uma otimizada extra nas checagens, já que o servidor não vai precisar comparar os textos dos cookies, indo direto para a entrega do cache.

Como forçar o cache para usuários logados no Nginx

O esquema será o mesmo: leia a seção acima, caso a tenha pulado. No código para o Nginx a parada está nesta linha:

# Don't use the cache for logged in users or recent commenters
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_logged_in") {
set $cache_uri 'null cache';
}

Vale a mesma recomendação para o Apache: remova o que lhe for conveniente. Se você quer desativar o cache somente para os usuários logados, remova o texto wordpress_logged_in (e a barra que vem antes dele). Se não usa posts com senha, remova o wp-postpass (e jamais se esqueça disso, se um dia vier a usar!). E se usa comentários externos, remova o comment_author. O wordpress_[a… é um cookie extra que eu nem sei direito o que faz, no código que vi para o Nginx já vinha assim então preferi mantê-lo.

Se você for remover todas as verificações de cookies, comente as linhas usando o # no início delas! Assim o desempenho (que já é espetacular) ficará melhor ainda, ganhando alguns milissegundos no processamento do Nginx.

publicidade
comments powered by Disqus