WP Super Cache

Descrição

Este plugin gera arquivos html estáticos do seu blog dinâmico do WordPress. Depois que um arquivo html é gerado, o seu servidor servirá esse arquivo em vez de processar os scripts PHP do WordPress, que são comparativamente mais pesados e mais custosos.

Os arquivos estáticos em HTML serão exibidos para a grande maioria dos seus usuários:

  • Usuários que não estão conectados.
  • Usuários que não deixaram um comentário no seu blog.
  • Ou usuários que não visualizaram um post protegido por senha.

99% de seus visitantes receberão arquivos html estáticos. Um arquivo em cache pode ser servido milhares de vezes. Outros visitantes receberão arquivos em cache personalizados, adaptados à sua visita. Se estiverem conectados ou tiverem deixado comentários, esses detalhes serão exibidos e armazenados em cache para eles.

O plugin serve arquivos em cache de 3 maneiras (classificadas por velocidade):

  1. Avançado. O método mais rápido é usar o Apache mod_rewrite (ou qualquer outro módulo semelhante suportado pelo servidor web) para servir arquivos html estáticos “supercached”. Isso ignora completamente o PHP e é extremamente rápido. Se o seu servidor for atingido por um dilúvio de tráfego, é mais provável que ele atenda, pois as solicitações são “mais leves”. Isso requer o módulo mod_rewrite do Apache (que provavelmente está instalado se você tiver links permanentes personalizados) e uma modificação do seu arquivo .htaccess que é arriscado e pode derrubar o seu site se modificado incorretamente.
  2. Simples. Arquivos estáticos do supercache podem ser servidos pelo PHP e esta é a maneira recomendada de usar o plugin. O plugin servirá um arquivo em supercache se existir e é quase tão rápido quanto o método mod_rewrite. É mais fácil de configurar, pois o arquivo .htaccess não precisa ser alterado. Você ainda precisa de um link permanente personalizado. Você pode manter partes dinâmicas da sua página neste modo de cache.
  3. Cache pelo WP-Cache. Usado principalmente para armazenar em cache páginas de usuários conhecidos, URLs com parâmetros e feeds. Usuários conhecidos são usuários logados, visitantes que deixam comentários ou aqueles que devem receber dados personalizados por usuário. É o método de cache mais flexível e um pouco mais lento. Ele também armazenará em cache as visitas de usuários desconhecidos se o supercache estiver desativado. Você também pode ter partes dinâmicas em sua página neste modo. Esse modo está sempre ativado, mas você pode desativar o cache de usuários conhecidos, URLs com parâmetros ou feeds separadamente. Defina a constante “DISABLE_SUPERCACHE” como 1 no seu wp-config.php se você quiser usar apenas o cache do WP-Cache.

Se você não está confortável com a edição de arquivos PHP, use o modo simples. É fácil de configurar e muito rápido.

Configurações recomendadas

  1. Cache simples.
  2. Compactar páginas.
  3. Não fazer cache de páginas para usuários conhecidos.
  4. Reconstrução de cache.
  5. Suporte a CDN.
  6. Verificações extras na página inicial.

Coleta de lixo é o ato de limpar arquivos de cache que estão desatualizados e obsoletos. Não há valor correto para o tempo de expiração, mas um bom ponto de partida é de 1800 segundos.

Considere a exclusão do conteúdo da caixa de texto “Agentes de usuário rejeitados” e permita que os mecanismos de pesquisa armazenem arquivos em cache para você.

Pré-carregue o máximo de posts possível e ative o “Modo de pré-carregamento”. A coleta de lixo de arquivos antigos em cache será desativada. Se você não se importa com a atualizações frequentes de widgets da barra lateral, defina o intervalo de pré-carregamento para 2880 minutos (2 dias), assim todos os seus posts não são recarregadas com muita frequência. Quando o pré-carregamento ocorre, os arquivos de cache do post que está sendo atualizado são excluídos e depois regenerados. Depois, é realizada uma coleta de lixo com o objetivo de limpar os arquivos obsoletos ainda em cache.
Mesmo com o modo de pré-carregamento ativado, os arquivos em cache ainda serão excluídos quando posts forem modificados ou forem feitos comentários.

Desenvolvimento

Documentação

Se você precisar de mais informações além das seguintes, pode consultar a documentação do desenvolvedor.

Pré-carregamento

Você pode gerar arquivos em cache para os posts, categorias e tags do seu site através de pré-carregamento. O pré-carregamento visitará cada página do seu site, gerando uma página em cache à medida que avança, como qualquer outro visitante do site. Devido à natureza sequencial dessa função, pode levar algum tempo para pré-carregar um site completo, se houver muitos posts.
Para tornar o pré-carregamento mais eficaz, pode ser útil desativar a coleta de lixo para que os arquivos de cache mais antigos não sejam excluídos. Isso é feito ativando o “Modo de pré-carregamento” nas configurações. No entanto, esteja ciente de que as páginas ficarão eventualmente desatualizadas, mas que as atualizações enviando comentários ou editando posts limparão partes do cache.

Coleta de lixo

Com o passar do tempo, seu diretório de cache é preenchido, o que ocupa espaço no seu servidor. Se o espaço for limitado ou cobrado por capacidade ou se você se preocupar de que as páginas em cache do seu site fiquem obsoletas, a coleta de lixo deverá ser realizada. A coleta de lixo ocorre regularmente e exclui arquivos antigos no diretório de cache. Na página de configurações avançadas, você pode especificar:
1. Tempo limite do cache. Por quanto tempo os arquivos de cache são considerados atualizados. Após esse período, eles ficam obsoletos e podem ser excluídos.
2. Agendador. Configure com que frequência a coleta de lixo deve ser feita.
3. E-mails de notificação. Você pode ser informado sobre o andamento do trabalho de coleta de lixo.
Não há configurações certas ou erradas para a coleta de lixo. Depende do seu próprio site.
Se o seu site receber atualizações ou comentários regulares, defina o tempo limite para 1800 segundos e o temporizador para 600 segundos.
Se o seu site é principalmente estático, você pode desativar a coleta de lixo digitando 0 como tempo limite ou usar um valor de tempo limite muito grande.

O diretório de cache, geralmente wp-content/cache/, é apenas para arquivos temporários. Nunca coloque arquivos importantes ou links simbólicos pra arquivos ou diretórios importantes nesse diretório. Eles serão excluídos se o plugin tiver acesso de gravação a eles.

CDN

Uma rede de entrega de conteúdo (CDN) é geralmente uma rede de computadores localizados em todo o mundo que servirá o conteúdo do seu site mais rapidamente usando servidores próximos a você. Arquivos estáticos, como imagens, arquivos JavaScript e CSS, podem ser veiculados por essas redes para acelerar a velocidade de carregamento do site. Você também pode criar uma “CDN mais simples” usando um subdomínio do seu domínio para servir também arquivos estáticos.

OSSDL CDN off-linker foi integrado ao WP Super Cache para fornecer suporte básico à CDN. Ele funciona reescrevendo os URLs dos arquivos (exceto arquivos .php) em wp-content e wp-includes no servidor, para que eles apontem para um nome de host diferente. Muitos CDNs suportam origin pull. Isso significa que a CDN baixará automaticamente o arquivo do seu servidor quando for solicitado pela primeira vez e continuará a servi-lo por um período configurável antes de baixá-lo novamente do seu servidor.

Configure isso na aba “CDN” da página de configurações do plugin. Essa é uma técnica avançada e requer um entendimento básico de como seu servidor web ou CDNs funcionam. Certifique-se de limpar o cache de arquivos depois de configurar o CDN.

API REST

Agora, existem endpoints da API REST para acessar as configurações deste plugin. Para fazer uso, você precisará ser autenticado como um usuário administrador com permissão para visualizar a página de configurações. Isso ainda não foi documentado, mas você pode encontrar todo o código que lida com isso no diretório “rest”.

Cache personalizado

Agora é possível conectar-se ao processo de armazenamento em cache usando a função add_cacheaction().

Três ganchos estão disponíveis:

  1. ‘wp_cache_get_cookies_values’ – modifica a chave usada pelo WP Cache.
  2. ‘add_cacheaction’ – é executado na fase2. Permite que um plugin adicione ganchos do WordPress.
  3. ‘cache_admin_page’ – é executado na página de administrador. Use-o para modificar essa página, talvez adicionando novas opções de configuração.

Também existe um filtro comum do WordPress. Use o filtro “do_createsupercache”
para personalizar as verificações feitas antes do armazenamento em cache. O filtro aceita um parâmetro.
A saída da função wp_cache_get_cookies_values() do WP-Cache.

O WP Super Cache possui seu próprio sistema de plugins. Este código é carregado quando o WP Super Cache é carregado e pode ser usado para alterar a forma como o cache é feito. Isso ocorre antes que a maior parte do WordPress seja carregada, portanto, algumas funcionalidades não estarão disponíveis. Plugins podem estar localizados em qualquer lugar que o PHP possa carregá-los. Adicione seu próprio plugin chamando wpsc_add_plugin ($name) onde $name é o nome completo do arquivo e o caminho para o plugin. Você só precisa chamar essa função uma vez para adicioná-lo. Use wpsc_delete_plugin ($name) para removê-lo da lista de plugins carregados.

Os cookies que o WP Super Cache usa para identificar “usuários conhecidos” podem agora ser modificados, adicionando os nomes desses cookies a uma lista na configuração do plugin. Use wpsc_add_cookie ($name) para adicionar um novo cookie e wpsc_delete_cookie ($name) para removê-lo. Os nomes dos cookies também modificam as regras do mod_rewrite usadas pelo plugin, mas recomendamos usar o cache no modo simples para evitar complicações com a atualização do arquivo .htaccess.
O nome e valor do cookie são usados ​​para diferenciar os usuários para que você possa ter um cookie, mas valores diferentes para cada tipo de usuário em seu site, por exemplo. Eles receberão arquivos de cache diferentes.

Veja plugins/searchengine.php como um exemplo que eu uso para o meu plugin No Adverts for Friends.

Resolução de problemas

Se as coisas não funcionam quando você instalou o plugin, aqui estão algumas coisas para verificar:

  1. O wp-content é gravável pelo servidor web?
  2. Existe um wp-content/wp-cache-config.php? Caso contrário, copie o arquivo wp-super-cache/wp-cache-config-sample.php para wp-content/wp-cache-config.php e verificar se WPCACHEHOME aponta pro lugar certo.
  3. Existe um wp-content/advanced-cache.php? Caso contrário, você deve copiar wp-super-cache/advanced-cache.php para wp-content/. Você deve editar o arquivo e alterar o caminho para que ele aponte para a pasta wp-super-cache.
  4. Se as páginas não estiverem em cache, remova wp-content/advanced-cache.php e recrie-o, seguindo os conselhos acima.
  5. Certifique-se de que a seguinte linha existe em seu arquivo wp-config.php e que ela está ACIMA da linha “require_once(ABSPATH.’wp-settings.php’);”:

    define( 'WP_CACHE', true );
    
  6. Tente a página Configurações->WP Super Cache novamente e ative o cache.
  7. Olhe em wp-content/cache/supercache/. Existem diretórios e arquivos lá?
  8. Algo em seu error_log do php?
  9. Se o seu navegador continuar pedindo que você salve o arquivo após a instalação do super cache, desative a compactação do Super Cache. Vá para a página Configurações->WP Super Cache e desative-a lá.
  10. O plugin não funciona muito bem quando o modo de segurança do PHP está ativo. Isso deve ser desativado pelo seu administrador.
  11. Se as páginas são armazenadas em supercache aleatoriamente e às vezes não, seu blog provavelmente pode ser visualizado com e sem o prefixo “www” no URL. Você deve escolher uma maneira e instalar o plugin Enforce www preference se você estiver usando uma instalação antiga do WordPress. As últimas versões já se redirecionam corretamente (você sempre deve executar a versão mais recente do WordPress de qualquer maneira!).
  12. Usuários de servidor privado no DreamHost devem editar wp-content/wp-cache-config.php e definir o diretório de cache como “/tmp/” se estiverem recebendo erros sobre o aumento do uso da CPU. Consulte esta discussão para obter mais informações.
  13. Erros de bloqueio de arquivo como “falha ao adquirir a chave 0x152b: permissão negada em …” ou “Página não armazenada em cache pelo WP Super Cache. Não foi possível obter o bloqueio mutex”. são um sinal de que talvez você precise usar o bloqueio de arquivos. Edite wp-content/wp-cache-config.php e remova o comentário de “$use_flock = true” ou defina $sem_id com um valor diferente. Como último recurso, você também pode desativar o bloqueio de arquivos na tela administrativa.
  14. Se estiver usando bloqueio grosseiro de arquivos, certifique-se de que o arquivo cache/wp_cache_mutex.lock seja gravável pelo servidor web.
  15. A pasta de cache não pode ser colocada em um compartilhamento NFS, Samba ou NAS. Tem que estar em um disco local. O bloqueio e a exclusão de arquivos expirados não funcionarão corretamente, a menos que a pasta de cache esteja na máquina local.
  16. A coleta de lixo de arquivos antigos em cache não funcionará se o WordPress não conseguir encontrar o wp-cron.php. Se o seu nome de host for resolvido para 127.0.0.1, isso poderá impedir a coleta de lixo de funcionar. Verifique as entradas do wp-cron.php em seus access_logs. Eles retornam um código 404 (arquivo não encontrado) ou 200? Se for 404 ou você não encontrar o wp-cron.php em qualquer lugar, o WordPress pode estar procurando esse script no lugar errado. Você deve falar com o administrador do servidor para corrigir isso ou editar o arquivo /etc/hosts nos servidores Unix e remover a seguinte linha. Seu nome de host deve resolver para o endereço IP externo usado por outros servidores na rede/Internet. Veja http://yoast.com/wp-cron-issues/ para mais informações. Uma linha como “127.0.0.1 localhost localhost.localdomain” está ok.

    127.0.0.1 example.com
    
  17. Se páginas antigas estiverem sendo servidas a seus visitantes por meio do supercache, você poderá estar perdendo os módulos do Apache (ou seus equivalentes, se você não usar o Apache). São necessários 3 módulos: mod_mime, mod_headers e mod_expires. Os dois últimos são especialmente importantes para garantir que os navegadores carreguem novas versões das páginas existentes no seu site.
  18. A mensagem de erro “WP Super Cache está instalado, mas está quebrado. O caminho para wp-cache-phase1.php em wp-content/advanced-cache.php deve ser corrigido!” aparece no final de cada página. Abra o arquivo wp-content/advanced-cache.php no seu editor favorito. O caminho para wp-cache-phase1.php está correto? Este arquivo normalmente estará em wp-content/plugins/wp-super-cache/. Se não estiver correto, o mecanismo de armazenamento em cache não será carregado.
  19. O armazenamento em cache não funciona. A impressão de horário no meu blog continua mudando quando eu recarrego. Verifique se o caminho nas regras .htaccess corresponde ao local do diretório supercache. Pode ser necessário codificá-lo. Tente desativar o modo supercache.
  20. Se os arquivos do supercache forem gerados, mas não servidos, verifique as permissões em todas as suas pastas wp-content/cache/supercache (e em cada uma das pastas cache, supercache e wp-content) e wp-content/cache/.htaccess. Se o seu PHP for executado como um usuário diferente do Apache e as permissões forem estritas, o Apache poderá não conseguir ler os arquivos de cache gerados pelo PHP. Para corrigir, você deve adicionar a seguinte linha ao seu wp-config.php (adicione-a acima da definição WP_CACHE.) Em seguida, limpe seu cache.

    umask( 0022 );
    
  21. Caso veja lixo no navegador após ativar a compactação no plugin, talvez a compactação já esteja ativada no seu servidor web. No Apache, você deve desativar o mod_deflate ou, no PHP, a compactação zlib pode estar ativada. Você pode desativar isso de três maneiras. Se você tiver acesso root, edite seu php.ini e localize a configuração zlib.output_compression e verifique se está “Off” ou adicione esta linha ao seu .htaccess:

    php_flag zlib.output_compression off
    

    Se isso não funcionar, adicione esta linha ao seu arquivo wp-config.php:

    ini_set('zlib.output_compression', 0);
    
  22. A “tela branca da morte” ou uma página em branco quando você visita seu site quase sempre é causada por um erro de PHP, mas também pode ser causado pela APC. Desative essa extensão do PHP se tiver problemas e substitua pelo eAccelerator ou Xcache.
  23. Após a desinstalação, seus links permanentes podem quebrar se você remover as regras mod_rewrite do WordPress também. Regenere essas regras, visitando a página Configurações->Link permanente e salvando esse formulário novamente.
  24. Se o seu blog se recusar a carregar, verifique se o seu wp-config.php está correto. Será que não está faltando uma tag de abertura ou fechamento do PHP?
  25. Sua página inicial está ok, mas as postagens e páginas retornam 404? Acesse Configurações->links permanentes e clique em “Salvar” depois de selecionar uma estrutura de link permanente personalizada. Pode ser necessário atualizar manualmente o arquivo .htaccess.
  26. Se determinados caracteres não aparecerem corretamente no seu site, seu servidor pode não estar configurado corretamente. Você precisa informar aos visitantes qual conjunto de caracteres é usado. Acesse Configurações->Leitura e copie o valor de ‘Codificação para páginas e feeds’. Edite o arquivo .htaccess com todas as suas regras de reescrita do Supercache e WordPress e adicione isso na parte superior, substituindo CHARSET pelo valor copiado. (por exemplo, ‘UTF-8’)

    AddDefaultCharset CHARSET
    
  27. Use o Cron View para ajudar a diagnosticar problemas de coleta de lixo e pré-carregamento. Use o plugin para garantir que os trabalhos sejam agendados e a que horas. Procure pelos trabalhos wp_cache_gc e wp_cache_full_preload_hook.
  28. A mensagem de erro “WP Super Cache está instalado, mas está quebrado. A constante WPCACHEHOME deve ser definida no arquivo wp-config.php e apontar para o diretório do plugin WP Super Cache.” aparece no final de cada página. Você pode excluir o wp-content/advanced-cache.php e recarregar a página de configurações do plugin ou editar o wp-config.php, procurar WPCACHEHOME e garantir que ela aponte para a pasta wp-super-cache. Normalmente, será wp-content/plugins/wp-super-cache/ mas provavelmente você precisará do caminho completo para esse arquivo (por isso é mais fácil deixar a página de configurações corrigi-lo). Se não estiver correto, o mecanismo de armazenamento em cache não será carregado.
  29. Se o seu servidor estiver com problemas devido ao número de semáforos usados pelo plugin, é porque seus usuários estão usando o bloqueio de arquivos, o que não é recomendado (mas é necessário para poucos usuários). Você pode desativar globalmente o bloqueio de arquivo definindo a constante WPSC_DISABLE_LOCKING ou definindo a constante WPSC_REMOVE_SEMAPHORE para que a função sem_remove() seja chamada após cada página ser armazenada em cache, mas isso parece causar problemas para outros processos que solicitam o mesmo semáforo. Melhor desativá-lo.
  30. Defina a variável $htaccess_path em wp-config.php ou wp-cache-config.php como o caminho do seu .htaccess global caso o plugin esteja procurando esse arquivo no diretório errado. Isso pode acontecer se você tiver o WordPress instalado de alguma maneira incomum.

Instalação

Instale como qualquer outro plugin, diretamente da sua página de plugins, mas certifique-se de ter os links permanentes personalizados ativados. Vá para a página de configurações do plugin em Configurações->WP Super Cache e ative o armazenamento em cache.

Como desinstalar o WP Super Cache

Praticamente tudo que você precisa fazer é desativar o plugin na página de plugins. O plugin deve limpar a maioria dos arquivos que criou e modificou, mas ainda não remove as regras do mod_rewrite do arquivo .htaccess. Procure a seção nesse arquivo marcada pelas tags SuperCache BEGIN e END. O plugin não as remove porque algumas pessoas adicionam as regras do WordPress nesse bloco também.

Para desinstalar manualmente:

  1. Desative o armazenamento em cache na página de configurações do plugin e limpe o cache.
  2. Desative o plugin na página de plugins.
  3. Remova a definição WP_CACHE do arquivo wp-config.php. Se parece com define( 'WP_CACHE', true );
  4. Remova as regras do mod_rewrite do Super Cache do seu arquivo .htaccess.
  5. Remova os arquivos wp-content/advanced-cache.php e wp-content/wp-cache-config.php
  6. Remova o diretório wp-content/cache/
  7. Remova o diretório wp-super-cache do seu diretório de plugins.

Se tudo mais falhar e seu site estiver corrompido

  1. Remova a definição WP_CACHE do arquivo wp-config.php. Se parece com define( 'WP_CACHE', true );
  2. Remova as regras (veja acima) que o plugin escreveu no arquivo .htaccess em seu diretório raiz.
  3. Exclua a pasta wp-super-cache na pasta plugins.
  4. Opcionalmente, exclua o advanced-cache.php, wp-cache-config.php e a pasta cache em wp-content/.

FAQ

Como saber se meu blog está sendo armazenado em cache?

Acesse Configurações->WP Super Cache e procure o formulário “Testar cache” na página de configurações fáceis. Clique em “Testar cache” e o plugin solicitará a primeira página do site duas vezes, comparando a impressão de horário em cada uma para garantir que correspondam.

Se você quiser fazer isso manualmente, ative a depuração na página de configurações do plugin e carregue o arquivo de registro em uma nova guia do navegador. Em seguida, visualize seu blog enquanto estiver conectado e desconectado. Você deve ver a atividade no registro. Veja a fonte de qualquer página do seu site. Quando uma página é criada, você verá o texto “Página dinâmica gerada em XXXX segundos.” e “Página em cache gerada pelo WP-Super-Cache em AAAA-MM-DD HH: MM: SS” no final do código-fonte. Ao recarregar, uma página em cache mostrará o mesmo registro de data e hora; portanto, aguarde alguns segundos antes de verificar.
Se o Supercaching estiver desativado e a compactação ativada, o texto “Compactação = gzip” será adicionado. Se a compactação estiver desativada e a página for exibida como um arquivo html estático, o texto “super cache” será adicionado. A única outra maneira de verificar se o arquivo em cache foi servido pelo script PHP ou pelo cache estático é observando os cabeçalhos HTTP. As páginas em cache do PHP terão o cabeçalho “WP-Super-Cache: arquivo supercache servido pelo PHP”. Os arquivos em cache do WPCache terão o cabeçalho “WP-Super-Cache: arquivo de cache do WPCache servido”. Você também deve verificar seu diretório de cache em wp-content/cache/supercache/hostname/ por arquivos de cache estáticos.
Se as regras do plugin estiverem ausentes no seu arquivo .htaccess, o plugin tentará servir a página em supercache, se for encontrada. O cabeçalho será “WP-Super-Cache: arquivo supercache servido pelo PHP” se isso acontecer.
O módulo de velocidade da página do Apache pode causar problemas durante o teste. Desative-o se notar algum problema ao executar o testador de cache.

Como faço para desativar o Supercaching?

Se você quiser apenas usar o mecanismo WP-Cache, edite seu wp-config.php ou crie um mu-plugin que defina a constante ‘DISABLE_SUPERCACHE’ como 1.

Arquivos WP-Cache vs Supercache

Todos os arquivos de cache são armazenados em wp-content/cache/supercache/HOSTNAME/ onde HOSTNANE é o seu nome de domínio. Os arquivos são armazenados em diretórios correspondentes à estrutura de link permanente do seu site. Os arquivos Supercache são index.html ou alguma variante disso, dependendo do tipo de visitante que acessa no blog. Outros arquivos são nomeados wp-cache-XXXXXXXXXXXXXXXXX.php. Os nomes de arquivos meta associados começam com “meta”. Esses arquivos contêm informações sobre o arquivo em cache, e são gerados pelo mecanismo “WPCache caching” do plugin.

Os comentários e outras partes dinâmicas do meu blog serão atualizados imediatamente?

Os comentários serão exibidos assim que forem moderados, dependendo da política de comentários do proprietário do blog. Outros elementos dinâmicos em uma página podem não ser atualizados, a menos que sejam escritos em JavaScript, Flash, Java ou outra linguagem do navegador do cliente. O plugin realmente produz páginas estáticas em html. Nenhum PHP é executado quando essas páginas são exibidas. O plugin “Popularity Contest” é um exemplo de plugin que não funcionaria.

A compactação do Super Cache causará lentidão em meu servidor?

Não, fará o contrário. Os arquivos do Super Cache são compactados e armazenados de modo que a compactação pesada seja feita apenas uma vez. Esses arquivos geralmente são muito menores e são enviados ao navegador do visitante muito mais rapidamente do que o html descompactado. Como resultado, seu servidor gasta menos tempo conversando na rede, economizando tempo de CPU e largura de banda e também pode atender à próxima solicitação muito mais rapidamente.

Como faço para que certas partes da página permaneçam dinâmicas?

Nota: esta funcionalidade está desativada por padrão. Você terá que ativá-la na página de configurações avançadas.

Existem 2 maneiras de fazer isso. Você pode usar o JavaScript para manipular a parte da página que deseja manter dinâmica. É isso que o Google AdSense e muitos widgets de sites externos fazem e é a maneira recomendada. Ou você pode usar um filtro WP Super Cache para fazer o trabalho, mas não poderá usar o cache do modo mod_rewrite. Você precisa usar o método de entrega “simples” ou desativar o supercaching.

O WP Super Cache 1.4 introduziu um filtro de ação de cache chamado wpsc_cachedata. A página em cache a ser exibida passa por esse filtro e permite a modificação da página. Se a página contiver uma tag de espaço reservado, o filtro poderá ser usado para substituir essa tag pelo seu html gerado dinamicamente.
A função conectada ao filtro wpsc_cachedata deve ser colocada em um arquivo na pasta de plugins do WP Super Cache, a menos que você use o recurso late_init. Um plugin de exemplo está incluído. Edite dynamic-cache-test.php para ver o código de exemplo.
Existem duas funções de exemplo lá. Há uma função simples que substitui uma string (ou tag) que você define quando a página em cache é servida. A outra função de exemplo usa um buffer de saída para gerar o conteúdo dinâmico. Devido a uma limitação no funcionamento do PHP, o código do buffer de saída DEVE ser executado antes de chegar no filtro wpsc_cachedata, ao menos quando uma página é armazenada em cache. Ele não interfere a exibição de páginas em cache. Veja este post para obter uma explicação mais técnica e mais longa.
Para executar as funções do WordPress, você deve ativar o recurso ‘Início tardio’ na página de configurações avançadas.

Como faço para atrasar a exibição do cache até que a ação “init” seja acionada?

Os arquivos em cache são servidos antes que praticamente todo o WordPress seja carregado. Embora isso seja ótimo para o desempenho, é uma dor quando você deseja estender o plugin usando uma parte central do WordPress. Nesse caso basta ativar o modo ‘Início tardio’ na página de configurações avançadas e os arquivos em cache serão exibidos quando a função “init” for acionada. WordPress e seus plugins serão carregados agora.

Por que os plugins WP UserOnline, o Popularity Contest, o WP Postratings ou o plugin X não funcionam ou não atualizam no meu blog agora?

Este plugin armazena páginas inteiras em cache, mas alguns plugins acham que podem executar o código PHP toda vez que uma página é carregada. Para corrigir isso, o plugin precisa usar os métodos JavaScript/AJAX ou o filtro wpsc_cachedata descrito na resposta anterior para atualizar ou exibir informações dinâmicas.

Por que meus plugins WP Super Cache desaparecem quando eu atualizo o plugin?

O WordPress exclui a pasta do plugin quando atualiza um plugin. É assim também com o WP Super Cache, então todos os arquivos modificados no wp-super-cache/plugins/ serão excluídos. Você pode colocar seus plugins personalizados em um diretório diferente de várias maneiras. Você pode definir a variável $wp_cache_plugins_dir em wp-config.php ou wp-content/wp-cache-config.php e apontá-la para um diretório fora da pasta wp-super-cache. O plugin procurará lá por seus plugins. Ou, se você distribuir um plugin que precisa ser carregado com antecedência, use a função wpsc_add_plugin($filename) para adicionar um novo plugin onde quer que esteja. Use wpsc_delete_plugin($filename) para remover o arquivo de plugin. Consulte #574 ou este post sobre como escrever plugins WP Super Cache.

O que o recurso de reconstrução de cache faz?

Quando um visitante deixa um comentário, o arquivo em cache dessa página é excluído e o próximo visitante recria a página em cache. Quando uma página demora para carregar, o que acontece se receber 100 visitantes durante esse período? Não haverá uma página em cache; portanto, o WordPress exibirá uma nova página para cada usuário e o plugin tentará criar uma página em cache para cada um desses 100 visitantes, causando uma enorme carga no servidor. Esse recurso impede que isso aconteça. A página em cache não é renovada quando um comentário é deixado, mas sim é marcada para reconstrução. O próximo visitante nos 10 segundos seguintes vai regenerar a página em cache enquanto a página antiga é veiculada para os outros 99 visitantes. Eventualmente, a página é carregada pelo primeiro visitante e a página em cache é atualizada. Consulte este post para obter mais informações.

Por que o plugin não faz por padrão o cache das solicitações de robôs dos mecanismos de pesquisa?

Esses bots normalmente só visitam cada página uma vez e, se a página não é popular, não faz sentido criar um arquivo de cache que ficará inativo em seu servidor. No entanto, você pode permitir que essas visitas sejam armazenadas em cache, removendo a lista de bots de “Agentes de usuário rejeitados” na página de configurações avançadas.

Uma página de categoria está sendo exibida em vez da minha página inicial

Uma pequena proporção de sites terá problemas com a seguinte configuração:

  1. Usa uma página estática para a página inicial.
  2. Usa a estrutura de link permanente /%category%/%postname%/.

Às vezes, uma página de categoria é armazenada em cache como a página inicial do site em vez da página estática. Não posso replicar o problema, mas uma solução simples é usar o modo “Simples”. Você também pode ativar “Verificações extras da página inicial” na página Configurações avançadas.

Por que recebo avisos sobre o armazenamento em cache de http://ismyblogworking.com/

“O seu blog não suporta o cache do cliente (sem resposta a 304 if-modified-since).”
“O seu feed não suporta armazenamento em cache (sem resposta a 304 if-modified-since)”

O supercache não suporta verificações de cabeçalho 304 no modo avançado, mas suporta no modo simples. Esse cache é feito pelo seu navegador, não pelo servidor. É uma verificação em que navegador pergunta ao servidor se uma versão atualizada da página atual está disponível. Caso contrário, ele não fará o download da versão antiga novamente. A página ainda é armazenada em cache pelo servidor, mas não pelos navegadores dos visitantes.
Experimente o Cacheability Engine em http://www.ircache.net/cgi-bin/cacheability.py ou https://redbot.org/ para obter mais análises.

Como devo usar melhor as ferramentas de acompanhamento utm_source no Google Analytics com este plugin?

Esse rastreamento adiciona uma string de consulta a cada URL vinculado de várias fontes, como Twitter e leitores de feed. Infelizmente, isso impede que as páginas sejam supercacheadas. Veja o comentário do Joost aqui para saber como transformá-lo em uma tag de âncora que pode ser armazenada no cache do supercache.

O plugin reclama que wp-content é gravável! O htdocs é gravável!

Não é bom quando o servidor web pode gravar nesses diretórios, mas às vezes as contas de hospedagem compartilhada são configuradas dessa maneira para facilitar a administração. Use o chmod 755 diretório para corrigir as permissões ou use a seção de permissões do seu cliente ftp. Esta pesquisa no Google tem mais informações sobre este tópico e esta página do codex também. Infelizmente, alguns hosts exigem que esses diretórios sejam graváveis. Se for esse o caso, ignore este aviso.

Como excluo a definição de WP_CACHE do wp-config.php?

Carregue seu cliente ftp preferido e conecte-se ao seu site. Navegue até a raiz (ou o diretório abaixo) do seu site, onde você encontrará wp-config.php. Faça o download desse arquivo e edite-o em um editor de texto. Exclua a linha define ('WP_CACHE', true); e salve o arquivo. Agora faça o upload, substituindo o wp-config.php no seu servidor.

Como excluo as regras do Super Cache do arquivo .htaccess?

Execute seu cliente ftp preferido e conecte-se ao seu site. Pode ser necessário ativar “Mostrar arquivos ocultos” nas preferências do cliente ftp. Navegue até a raiz do seu site, onde encontrará o arquivo .htaccess. Faça o download desse arquivo e edite-o em um editor de texto. Exclua as linhas entre “# BEGIN WPSuperCache” e “# END WPSuperCache” e salve o arquivo. Agora faça o upload, substituindo o arquivo .htaccess no seu servidor.

Como eu altero as permissões de arquivo?

Esta página no WordPress Codex explica tudo o que você precisa saber sobre permissões de arquivo em seu servidor e várias maneiras de alterá-las.

Por que tenho picos de carga quando novos posts são feitos?

Você pode ter a opção “limpar todos os arquivos em cache ao criar novos posts”. A limpeza desses arquivos pode demorar, e seus visitantes agora visitarão páginas não armazenadas em cache. Você está usando o acompanhamento de campanhas do Google Analytics com utm_source no URL? Essas páginas não são armazenadas em cache. Consulte a pergunta “Como devo usar melhor as ferramentas de rastreamento utm_source no Google Analytics com este plugin” acima para saber como usá-las corretamente.
As páginas em cache precisam ser atualizadas ao criar posts. Talvez seu servidor não esteja preparado para atender à quantidade de tráfego que você recebe. Ative o recurso “reconstruir cache”, pois isso pode ajudar.

Quantas páginas posso armazenar em cache?

O único limite real são os limites definidos pelo seu servidor. Por exemplo, EXT2 e EXT3 permitem um máximo de 31.999 subdiretórios, portanto, se você tiver uma estrutura de permalink plana (como /%POSTNAME%/) e mais de 32.000 posts, poderá encontrar problemas. Da mesma forma, se você executar uma rede multisite e tiver mais de 31.999 sites (blogs), não poderá armazenar todos eles em cache. Se você realmente tivesse tantos sites ativos, não estaria executando em um único servidor.

Percebo que a versão www do meu site está em cache separadamente. Como eu paro isso?

O WordPress deve redirecionar para o URL canônico do seu site, mas se isso não acontecer, adicione isso ao seu .htaccess acima das regras do Supercache e do WordPress. Mude example.com para o seu próprio domínio.
RewriteCond %{HTTP_HOST} www.example.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

Como faço para exibir páginas em cache para dispositivo móvel aos clientes que usam telas pequenas, como telefones e tablets?

Seu tema provavelmente é responsivo, o que significa que ele redimensiona a página para se adequar ao dispositivo que está exibindo a página. Se não for responsivo, você precisará usar um plugin para dispositivo móvel em separado para renderizar uma página formatada para esses visitantes. Os seguintes plugins foram testados, mas podem ter um comportamento diferente de acordo com o dispositivo móvel do cliente. Você também precisará ativar o suporte ao navegador de dispositivo móvel na página Configurações avançadas.

Avaliações

27 de setembro de 2019
You can also disable cache for requests with GET parameters and logged in users, which makes it great for dynamic sites.
5 de setembro de 2019
Все минусы связаны с самой идеей кэширования. А плагин фантастический!
22 de agosto de 2019
I used the plugin in some sites. It was good. But at some point (2019 ?) all the updates created major problems. Now it even changes the wp-config.php permissions from whatever you have it (644) to 600. Without any warning or ask for permission. That is unacceptable, WPSC is just a cache plugin. Not a security script.
14 de agosto de 2019
It’s a simple good solution on caching, we use it now on 6 completely different setup of WordPress sites, together with a some of async and optimizer plugins, and some caching instructions in .htaccess, tried other cache-plugins before but this is good enough, no problems, stable, flexible and nice results in speed test
25 de julho de 2019
NON ho notato nessuna velocizzazione nella fornitura delle pagine web. Ho notato invece, che il caricamento delle immagini, nell'archivio Media, si conclude quasi sempre con un Errore HTTP, dopo minuti di attesa. Anche il Salvataggio Bozza risulta MOLTO rallentato. In conclusione: il risultato ottenuto con questo plugin è esattamente l'opposto di quello che promette. Disinstallato!
Leia todas as 1.231 avaliações

Contribuidores e desenvolvedores

“WP Super Cache” é um software com código aberto. As seguintes pessoas contribuíram para este plugin.

Contribuidores

“WP Super Cache” foi traduzido para 18 localidades. Obrigado aos tradutores por suas contribuições.

Traduzir “WP Super Cache” para o seu idioma.

Interessado no desenvolvimento?

Navegue pelo código, dê uma olhada no repositório SVN ou assine o registro de desenvolvimento via RSS.

Registro de alterações

1.7.0

  • Added “wpsc_cdn_urls” filter to modify the URLs used to rewrite URLs. #697
  • Fixed CDN functionality for logged in users. #698
  • Disable settings that don’t work in Expert mode. #699
  • Don’t enable mobile support by default, but it can still be enabled manually. #700
  • Change “admin bar” to “Toolbar”. Props @garrett-eclipse. #701
  • Show settings enabled by “easy” settings page. #703

1.6.9

  • Improve the variables and messaging used by advanced-cache.php code. #687
  • Add a warning message to the debug log viewer. #688
  • Disable raw viewing of the debug log. #691
  • Clean up the debug log. #692 #694
  • Added wpsc_update_check() in 9659af156344a77ae247dc582d52053d95c79b93.

1.6.8

  • Added new constants, WPSC_SERVE_DISABLED (disable serving of cached files) and WPSC_SUPERCACHE_ONLY (only serve supercache cache files). #682 and #672
  • Hide get_post() warning on some sites. #684
  • Check if WPCACHEHOME is set correctly before maybe updating it. #683
  • Remove object cache support as it never worked properly. #681
  • Add “logged in users” to the “do not cache for users” setting and rename that setting to “Cache Restrictions” #657

1.6.7

  • wp_cache_setting() can now save boolean values since many of the settings are bools. #676
  • Check if $super_cache_enabled is true in a less strict way because it might be ‘1’ rather than true. #677

1.6.6

  • Fix problems with saving settings. Returns false ONLY when there’s an issue with the config file, not when the setting isn’t changed. Change other code to cope with that, including updating WPCACHEHOME (#670)
  • When saving settings rename the temporary config file correctly, and delete wp-admin/.php if it exists. (#673)
  • Fix adding WPCACHEHOME to wp-config.php when advanced-cache.php is not found and wp-config.php is RO. (#674)

1.6.5

  • Check advanced-cache.php was created by the plugin before modifying/deleting it. (#666)
  • When saving settings, save blank lines. Fixes problems with WP_CACHE and WPCACHEHOME in wp-config.php. Related to #652. (#667)
  • Update outdated code and use is_multisite() (#600)
  • Fix the delete cache button in the Toolbar. (#603)
  • Code cleanup in #602
  • Use get_post_status instead of post_status (#623)
  • Fixes button – Update Direct Pages (#622)
  • Removes apache_response_headers and uses only headers_list (#618)
  • Function is_site_admin has been deprecated (#611)
  • Fixes action urls in wp_cache_manager (#610)
  • Remove the link to the HibbsLupusTrust tweet. (#635)
  • Don’t load wp-cache-config.php if it’s already loaded (#605)
  • PHPCS fixes and optimization for plugins/domain-mapping.php (#615)
  • Introduces PHP_VERSION_ID for faster checking (#604)
  • Fixes regex and optimizes ossdl-cdn.php (#596)
  • Only update new settings and use a temporary file to avoid corruption. (#652)
  • Serve cached files to rejected user agents, don’t cache them. (#658)
  • Combine multiple headers with the same name (#641)
  • Open ‘Delete Cache’ link in same window (#656)
  • Promote the Jetpack Site Accelerator on the CDN page. (#636)

1.6.4

  • Changes between 1.6.3 and 1.6.4
  • Fixes for WP-CLI (#587) (#592)
  • Bumped the minimum WordPress version to 3.1 to use functions introduced then. (#591)
  • Correção no wpsc_post_transition para evitar erro fatal quando usando get_sample_permalink.
  • Corrigido link de “Excluir Cache” na barra de ferramentas.(#589)
  • Corrigido cabeçalhos usados na página de configurações.

1.6.3

  • Changes between 1.6.2 and 1.6.3
  • Added cookie helper functions (#580)
  • Added plugin helper functions (#574)
  • Added actions to modify cookie and plugin lists. (#582)
  • Really disable garbage collection when timeout = 0 (#571)
  • Added warnings about DISABLE_WP_CRON (#575)
  • Don’t clean expired cache files after preload if garbage collection is disabled (#572)
  • On preload, if deleting a post don’t delete the sub directories if it’s the homepage. (#573)
  • Fix generation of semaphores when using WP CLI (#576)
  • Fix deleting from the Toolbar (#578)
  • Avoid a strpos() warning. (#579)
  • Improve deleting of cache in edit/delete/publish actions (#577)
  • Fixes to headers code (#496)

1.6.2

  • Fixed serving expired supercache files (#562)
  • Write directly to the config file to avoid permission problems with wp-content. (#563)
  • Correctly set the .htaccess rules on the main site of a multisite. (#557)
  • Check if set_transient() exists before using it. (#565)
  • Removed searchengine.php example plugin as it sets a cookie to track users. Still available here. (#567)
  • For advanced users only. Change the vary and cache control headers. See https://github.com/Automattic/wp-super-cache/pull/555 (#555)

1.6.1

  • Fix the name of the WP Crontrol plugin. (#549)
  • Handle errors during deactivation/uninstall by email rather than exiting. (#551)
  • Add a notice when settings can’t be updated. (#552 and #553)

1.6.0

  • Fix issues in multisite plugin (#501)
  • Fixes wp-cli plugin deactivate/activate (#499)
  • Cleanup – change quotes. (#495)
  • $htaccess_path defines the path to the global .htacess file. (#507)
  • Fix ‘cannot redeclare gzip_accepted()’ (#511)
  • Correct the renaming of tmp_wpcache_filename (removed unnecessary slash in path) which caused renaming to fail. (#516)
  • Add check for Jetpack mobile theme cookie (#515)
  • Optimize wp_cache_phase2 and create wpsc_register_post_hooks (#508)
  • WPCACHEHOME has a trailing slash (#513)
  • Cleanup cache enable/disable and update_mod_rewrite_rules (#500)
  • Post Update now clears category cache (#519)
  • Various fixes for saving the debug page form (#542)
  • Expert-caching and empty parameters, like ?amp, should not serve cached page (#533)
  • Tiny Yslow description fix (#527)
  • Add ipad to mobile list (#525)
  • Hide opcache_invalidate() warnings since it’s disabled some places. (#543)
  • Check that HTTP_REFERER exists before checking it. (#544)
  • Replace Cron View” with WP Crontrol because it’s still updated. (#546)
  • adding hook (wp_cache_cleared) for full cache purges (#537)

1.5.9

  • Fixed fatal error if the debug log was deleted while debugging was enabled and a visitor came to the site.
  • Fixed the dynamic caching test plugin because of PHP7 changes. Dynamic cache mode must be enabled now.
  • Lots of WordPress coding style formatting fixes to the code.
  • All changes: https://github.com/Automattic/wp-super-cache/compare/1.5.8…1.5.9

1.5.8

  • PHP 7 fixes. (#429)
  • Fix debug comments checkbox. (#433)
  • Only register uninstall function in admin pages to save queries. (#430)
  • Check that wp-cache-phase1.php is loaded before saving settings page. (#428)
  • If a url has a “?” in it then don’t delete the associated cache. It’ll delete the whole cache after stripping out ?… part. (#427 & #420)
  • Allow static functions in classes to be used in cacheactions. (#425)
  • Don’t make AJAX requests anonymous. (#423)
  • Fixed link to chmod explanation. (#421)
  • Add more escaping to the CDN settings page. (#416)
  • Use SERVER_PROTOCOL to determine http protocol. (#412 & #413)
  • If preload stalls only send one email per day, but do display an admin notice. (#432)
  • Fixed more PHP warnings in #438 and #437
  • Hide mod_rewrite warnings for Nginx users. #434

1.5.7.1

  • If the HTTP HOST is empty then don’t use it in strpos to avoid a PHP warning. (#408)
  • Don’t preload posts with permalinks that contain rejected strings. (#407)
  • Generate a list of archive feeds that can be deleted when the site is updated. Also fixes corrupted config file issue and fatal error with older versions of WordPress. (#403)

1.5.7

  • Fix fatal error in plugins/searchengine.php (#398)

1.5.6

  • REST API: Added /plugins endpoint to handle the plugins settings page. (#382)
  • Minor changes to indentaion and spaces to tabs conversion (#371) (#395)
  • Don’t set $wp_super_cache_comments here as it’s not saved. (#379)
  • realpath() only works on directories. The cache_file wasn’t set correctly. (#377)
  • Fix problem deleting cache from Toolbar because of realpath() (#381)
  • Use trigger_error() instead of echoing to the screen if a config file isn’t writeable. (#394)
  • Added the “wpsc_enable_wp_config_edit” filter to disable editing the wp-config.php (#392)
  • Fix some PHP notices when comments are edited/published/maintained. (#386)
  • Minor changes to description on plugins page. (#393)

1.5.5

  • Catch fatal errors so they’re not cached, improve code that catches unknown page types. (#367)
  • Fix caching on older WP installs, and if the plugin is inactive on a blog, but still caching, give feeds a short TTL to ensure they’re fresh. (#366)
  • When preloading don’t delete sub-directories, or child pages, when caching pages. (#363)
  • Avoid PHP warnings from the REST API for settings that are not yet defined. (#361)
  • Added missing settings to the config file. (#360)

1.5.4

  • Fix messages related to creating advanced-cache.php (#355, #354)
  • Deleting the plugin doesn’t need to delete the cache directory as it’s already done on deactivation. (#323)
  • Disable Jetpack mobile detection if Jetpack Beta is detected. (#298)
  • Add more checks on directories to make sure they exist before deleting them. (#324)
  • Add siteurl setting to CDN page for users who have WordPress in it’s own directory. (#332)
  • Don’t enable and then not save debug comments when toggling logging. (#334)
  • Show plugin activity html comments to users who disable caching for logged in users. (#335)
  • Better notifications on Preload page, and redo sql to fetch posts. Added “wpsc_preload_post_types_args” filter on post visibility, and wpsc_preload_post_types filter on post types used. (#336)
  • Use a cached feed if it is newer than the last time a post was updated. (#337)
  • Better define a sitemap (#340) but when the content type is unknown add more checks to find out what it is. (#346)
  • Save cache location correctly on the advanced settings page. (#345)
  • Make sure the debug log exists before toggling it on/off to ensure the http auth code is added to it.
  • Return the correct cache type to the REST API. Ignore supercache enabled status. (#352)
  • Fix cache contents in REST API showing double count of supercache files. (#353)
  • Move the nonce in the CDN page back into a function. (#346)
  • Use realpath to compare directories when loading the sample config file to account for symlinked directories. (#342)
  • Other minor changes to html or typos
    (Numbers are pull requests on Github.)

1.5.3

  • Fix a critical bug that caused unlink to be run on null while deleting the plugin.

1.5.2

  • Add a trailing slash to home path. Fixes problems with finding the .htaccess file.
  • Delete WPCACHEHOME and WP_CACHE from wp-config.php when plugin deactivated.
  • Check that WPCACHEHOME is the right path on each load of the settings page.
  • Load the REST API code without using WPCACHEHOME.
  • Fixed mobile browser caching when using WP-Cache caching.
  • Fixed directory checks on Windows machines.
  • Reverted CDN changes in 1.5.0 as they caused problems in older “WordPress in a separate directory” installs.
  • Added note to CDN page when site url != home url. Site owners can use a filter to adjust the URL used.
  • Stop preload quicker when requested while preloading taxonomies.
  • Added more information for when updating the .htaccess file fails.
  • “Served by” header is now optional. Enable it by setting $wpsc_served_header to true in the config file.

1.5.1

  • Don’t use anonymous functions in REST API
  • Check that REST API Controller is available before loading the REST API.
  • Don’t use multibyte string functions because some sites don’t have it enabled.

1.5.0

  • REST API settings endpoints.
  • Simplified settings page.
  • WP-Cache files reorganised.
  • Caching of more http headers.
  • Lots of bug fixes.

1.4.9

  • Fixed bug when not running sem_remove after sem_release. See https://github.com/Automattic/wp-super-cache/issues/85
  • Fixed a PHP error impacting PHP 7.1.
  • Fixed a bug where we cached PUT and DELETE requests. We’re treating them like POST requests now.
  • Delete supercache cache files, even when supercache is disabled, because mod_rewrite rules might still be active.
  • Updated the settings page, moving things around. #173
  • Make file locking less attractive on the settings page and fixed the WPSC_DISABLE_LOCKING constant so it really disables file locking even if the user has enabled it already.
  • Added a WPSC_REMOVE_SEMAPHORE constant that must be defined if sem_remove() is to be used as it may cause problems. #174
  • Added a “wpsc_delete_related_pages_on_edit” filter that on returning 0 will disable deletion of pages outside of page being edited. #175
  • Fixed plugin deleting all cached pages when a site had a static homepage. #175
  • Make sure $cache_path has a trailing slash #177
  • Remove flush() #127 but also check if headers are empty and flush and get headers again. #179
  • Add fix for customizer #161 and don’t cache PUT AND DELETE requests #178
  • Check for superglobals before using them. #131

1.4.8

  • Removed malware URL in a code comment. (harmless to operation of plugin but gets flagged by A/V software)
  • Updated translation file.

1.4.7

  • Update the settings page for WordPress 4.4. layout changes.

1.4.6

  • Generate the file cache/.htaccess even when one exists so gzip rules are created and gzipped pages are served correctly. Props Tigertech. https://wordpress.org/support/topic/all-website-pages-downloading-gz-file-after-latest-update?replies=36#post-7494087

1.4.5

  • Enhancement: Only preload public post types. Props webaware.
  • Added an uninstall function that deletes the config file. Deactivate function doesn’t delete it any more.
  • Possible to deactivate the plugin without visiting the settings page now.
  • Fixed the cache rebuild system. Rebuild files now survive longer than the request that generate them.
  • Minor optimisations: prune_super_cache() exits immediately if the file doesn’t exist. The output of wp_cache_get_cookies_values() is now cached.
  • Added PHP pid to the debug log to aid debugging.
  • Various small bug fixes.
  • Fixed reset of expiry time and GC settings when updating advanced settings.
  • Removed CacheMeta class to avoid APC errors. It’s not used any more.
  • Fixed reset of advanced settings when using “easy” settings page.
  • Fixed XSS in settings page.
  • Hide cache files when servers display directory indexes.
  • Prevent PHP object injection through use of serialize().

1.4.4

  • Fixed fatal error in output handler if GET parameters present in query. Props webaware.
  • Fixed debug log. It wasn’t logging the right message.

1.4.3

  • Security release fixing an XSS bug in the settings page. Props Marc Montpas from Sucuri.
  • Added wp_debug_log(). Props Jen Heilemann.
  • Minor fixes.

1.4.2

  • Fixed “acceptable file list”.
  • Fixed “Don’t cache GET requests” feature.
  • Maybe fixed “304 not modified” problem for some users.
  • Fixed some PHP warnings.

1.4.1

  • Fixed XSS in settings page. Props Simon Waters, Surevine Limited.
  • Fix to object cache so entries may now be deleted when posts updated. (object cache still experimental)
  • Documentation updates and cleanup of settings page.

1.4

  • Replace legacy mfunc/mnclude/dynamic-cached-content functionality with a “wpsc_cachedata” cacheaction filter.
  • Added dynamic-cache-test.php plugin example wpsc_cachedata filter plugin.
  • Delete post, tag and category cache when a post changes from draft to publish or vice versa. Props @Biranit.
  • Update advanced-cache.php and wp-config.php if wp-cache-phase1.php doesn’t load, usually happening after migrating to a new hosting service.
  • Misc bugfixes.

1.3.2

  • Any mfunc/mclude/dynamic-cached-content tags in comments are now removed.
  • Dynamic cached content feature disabled by default and must be enabled on the Advanced Settings page.
  • Support for the mobile theme in Jetpack via helper plugin on script’s Plugins tab.

1.3.1

  • Minor updates to documentation
  • Fixed XSS in settings page.

1.3

  • mfunc tags could be executed in comments. Fixed.
  • More support for sites that use the LOGGED_IN_COOKIE constant and custom cookies.

1.2

  • Garbage collection of old cache files is significantly improved. I added a scheduled job that keeps an eye on things and restarts the job if necessary. Also, if you enable caching from the Easy page garbage collection will be enabled too.
  • Editors can delete single cached files from the Toolbar now.
  • Fixed the cached page counter on the settings page.
  • Some sites that updated to 1.0 experienced too much garbage collection. There are still stragglers out there who haven’t upgraded but that’s fixed now!
  • Supercached mobile files are now used as there was a tiny little typo that needed fixing.
  • If your site is in a directory and you saw problems updating a page then that should be fixed now.
  • The deactivate hook has been changed so your configuration isn.t hosed when you upgrade. Unfortunately this will only happen after you do this upgrade.
  • Some sites use custom cookies with the LOGGED_IN_COOKIE constant. Added support for that.
  • Added support for WPTouch Pro, but it appears to be flaky still. Anyone have time to work on that? I don.t.
  • Some sites had problems with scheduled posts. For some reason the plugin thought the post was in draft mode and then because it only checked the same post once, when the post magically became published the cache wasn.t cleared. That.s fixed, thanks to the debug logging of several patient users.
  • And more bug fixes and translation updates.

1.1

  • Use $_SERVER[ ‘SERVER_NAME’ ] to create cache directories.
  • Only create blogs cached directories if valid requests and blogs exist.
  • Only clear current blog’s cache files if navigation menu is modified
  • Added clean_post_cache action to clear cache on post actions
  • Removed garbage collection details on Contents tab
  • Added wp_cache_check_mobile cacheaction filter to shortcircuit mobile device check.
  • Don’t delete cache files for draft posts
  • Added action on wp_trash_post to clear the cache when trashed posts are deleted
  • Show a warning when 304 browser caching is disabled (because mod_rewrite caching is on)
  • New check for safe mode if using less that PHP 5.3.0
  • Added wp_supercache_remove_cookies filter to disable anonymous browsing mode.
  • Fixed garbage collection schedule dropdown
  • Fixed preload problem clearing site’s cache on “page on front” sites.
  • Fix for PHP variable not defined warnings
  • Fixed problem refreshing cache when comments made as siteurl() sometimes didn’t work
  • Preloading of taxonomies is now optional
  • Domain mapping fixes.
  • Better support for https sites. Remove https:// to get cache paths.
  • Added AddDefaultCharset .htaccess rule back in and added an option to remove it if required.
  • Added multisite plugin that adds a “Cached” column to Network->Sites to disable caching on a per site basis.
  • Added WPTouch plugin to modify browser and prefix list in mobile detection code. Added support for that plugin’s exclude list.
  • Fixed cache tester
  • Filter the tags that are used to detect end-of-page using the wp_cache_eof_tags filter.
  • Removed debug level from logging as it wasn’t helpful.
  • Removed mention of wp-minify.

1.0

  • Removed AddDefaultCharset .htaccess rule
  • Fixed problem with blogs in a folder and don’t have a trailing slash
  • New scheduling of garbage collection
  • Added a “Delete cache” link to Toolbar to delete cache of current page.
  • Updated documentation
  • Sorry Digg, Stephen Fry power now!
  • Updated translations
  • Preload taxonomies and all post types except revisionsand nav menu items
  • Fixed previews by logged in users.
  • Added option to make logged in users anonymous
  • Use WP 3.0 variables to detect multisite installs
  • Hash filenames so files are served from the same CDNs

0.9.9.9

  • Fixed typo, is_front_page.
  • Serve repeated static files from the same CDN hostname.
  • Updated translations.
  • Make supercache dir lowercase to avoid problems with unicode URLs.
  • Add option to skip https loaded static content.
  • Remove 5 second check on age of existing cache files. Should help with posts that get lots of comments and traffic.
  • Lots of bugs fixed.

0.9.9.8

  • CDN updates: can be switched off, multiple CNAMEs.
  • Uninstall process improved. It removes generated files and fixes edited files.
  • Cached dynamic pages can now be stored in Supercache files and compressed.
  • 1and1 Webhosting fix (/kunden/)
  • Remove log by email functionality as it caused problems for users who were inundated by email
  • Many more minor fixes and changes.

0.9.9.6

  • Fixed problem serving cached files with PHP
  • Added support for 304 “file not modified” header to help browser caching. (PHP caching only)
  • Added French & German translations, updated Italian translation and fixed translation strings.
  • Sleep 4 seconds between preload urls to reduce load on the server
  • Updated docs and FAQs.

0.9.9.5

  • Disable compression on on easy setup page. Still causes problems on some hosts.
  • Remove footerlink on easy setup page.
  • Don’t delete mod_rewrite rules when caching is disabled.
  • Don’t stop users using settings page when in safe mode.

0.9.9.4

  • Settings page split into tabbed pages.
  • Added new “Easy” settings page for new users.
  • New PHP caching mode to serve supercached files.
  • Mobile support fixes.
  • Added Domain mapping support plugin.
  • Added “awaiting moderation” plugin that removes that text from posts.
  • Terminology change. Changed “half on” to “legacy caching”.
  • Fixed cache tester on some installs of WordPress.
  • Updated documentation
  • Added $wp_super_cache_lock_down config variable to hide lockdown and directly cached pages admin items.
  • Preloaded checks if it has stalled and reschedules the job to continue.
  • Serve the gzipped page when first cached if the client supports compression.
  • Lots more bug fixes..

0.9.9.3

  • Fixed division by zero error in half on mode.
  • Always show “delete cache” button.
  • Fixed “Update mod_rewrite rules” button.
  • Minor text changes to admin page.

0.9.9.2

  • Forgot to change version number in wp-cache.php

0.9.9.1

  • Added preloading of static cache.
  • Better mobile plugin support
  • .htaccess rules can be updated now. Added wpsc_update_htaccess().
  • Fixed “page on front” cache clearing bug.
  • Check for wordpress_logged_in cookie so test cookie isn’t detected.
  • Added clear_post_supercache() to clear supercache for a single post.
  • Put quotes around rewrite rules in case paths have spaces.

0.9.9

  • Added experimental object cache support.
  • Added Chinese(Traditional) translation by Pseric.
  • Added FAQ on WP-Cache vs Supercache files.
  • Use Supercache file if WP-Cache file not found. Useful if mod_rewrite rules are broken or not working.
  • Get mobile browser list from WP Mobile Edition if found. Warn user if .htaccess out of date.
  • Make sure writer lock is unlocked after writing cache files.
  • Added link to developer docs in readme.
  • Added Ukranian translation by Vitaly Mylo.
  • Added Upgrade Notice section to readme.
  • Warn if zlib compression in PHP is enabled.
  • Added compression troubleshooting answer. Props Vladimir (http://blog.sjinks.pro/)
  • Added Japanese translation by Tai (http://tekapo.com/)
  • Updated Italian translation.
  • Link to WP Mobile Edition from admin page for mobile support.

0.9.8

  • Added Spanish translation by Omi.
  • Added Italian translation by Gianni Diurno.
  • Addded advanced debug code to check front page for category problem. Enable by setting $wp_super_cache_advanced_debug to 1 in the config file.
  • Fixed wordpress vs wordpress_logged_in cookie mismatch in cookie checking function.
  • Correctly check if WP_CACHE is set or not. PHP is weird.
  • Added wp_cache_clear_cache() to clear out cache directory.
  • Only show logged in message when debugging enabled.
  • Added troubleshooting point 20. PHP vs Apache user.
  • Fixed problem deleting cache file.
  • Don’t delete cache files when moderated comments are deleted.

0.9.7

  • Fixed problem with blogs in folders.
  • Added cache file listing and delete links to admin page.
  • Added “Newest Cached Pages” listing in sidebox.
  • Made admin page translatable.
  • Added “How do I make certain parts of the page stay dynamic?” to FAQ.
  • Advanced: added “late init” feature so that plugin activates on “init”. Set $wp_super_cache_late_init to true in config file to use.
  • Disable supercaching when GET parameters present instead of disabling all caching. Disable on POST (as normal) and preview.
  • Fixed problem with cron job and mutex filename.
  • Warn users they must enable mobile device support if rewrite rules detected. Better detection of when to warn that .htaccess rules must be updated (no need when rewrite rules not present)
  • Advanced: Added “wpsupercache_404” filter. Return true to cache 404 error pages.
  • Use the wordpress_test_cookie in the cache key.
  • Show correct number of cache files when compression off.
  • Fixed problem with PHP safe_mode detection.
  • Various bugfixes and documentation updates. See Changelog.txt

0.9.6.1

  • Move “not logged in” message init below check for POST.
  • Add is_admin() check so plugin definitely can’t cache the backend.
  • Add “do not cache” page type to admin page.

0.9.6

  • Add uninstall.php uninstall script.
  • Updated cache/.htaccess rules (option to upgrade that)
  • Added FAQ about category and static homepage problem.
  • Add wp_cache_user_agent_is_rejected() back to wp-cache-phase2.php
  • Show message for logged in users when caching disable for them.
  • Check filemtime on correct supercache file

0.9.5

  • Show next and last GC times in minutes, not local time.
  • Don’t serve wp_cache cache files to rejected user agents. Supercache files are still served to them.
  • If enabled, mobile support now serves php cached files to mobile clients and static cached files to everyone else.
  • Added checks for “WPSC_DISABLE_COMPRESSION” and “WPSC_DISABLE_LOCKING” constants to disable compression and file locking. For hosting companies primarily.
  • Added check for DONOTCACHEPAGE constant to avoid caching a page.
  • Use PHP_DOCUMENT_ROOT when creating .htaccess if necessary.

0.9.4.3

  1. Added “Don’t cache for logged in users” option.
  2. Display file size stats on admin page.
  3. Clear the cache when profile page is updated.
  4. Don’t cache post previews.
  5. Added backslashes to rejected URI regex list.
  6. Fixed problems with posts and comments not refreshing.