Descargar

WP Super Cache

Por Automattic

Descripción

Este plugin crea archivos html estáticos de tu sitio WordPress dinámico. Una vez se haya creado el archivo html tu servidor servirá ese archivo en vez de procesar los scripts PHP de WordPress, en comparación mucho más pesados y consumidores de recursos.

Los archivos estáticos html se servirán a la gran mayoría de sus usuarios:

  • Usuarios que no están conectados.
  • Usuarios que no han comentado en tu sitio.
  • O usuarios que no han visto una entrada protegida por contraseña.

El 99% de tus visitantes recibirán archivos html estáticos. Un archivo en caché se puede servir miles de veces. Otros visitantes recibirán archivos en caché personalizados a la medida de su visita. Si están conectados, o han dejado comentarios, esa información se mostrará y almacenará en caché para ellos.

El plugin sirve los archivos en caché en 3 maneras (ordenados por velocidad):

  1. Experto. El modo más rápido es usar el módulo de Apache mod_rewrite (o cualquier módulo similar que tenga tu servidor web) para servir archivos html estáticos “supercacheados”. Esto omite completamente PHP y es extremadamente rápido. Si tu servidor recibe un aluvión de tráfico le será más fácil afrontarlo ya que las peticiones son más “livianas”. Esto requiere el módulo de Apache mod_rewrite (que seguramente esté instalado si tienes enlaces permanentes personalizados) y una modificaci´n de tu archivo .htaccess. Las visitas a los usuarios anónimos o desconocidos se sirven de este modo.
  2. Fácil. Los archivos estáticos supercacheados pueden servirse por PHP y esta es la forma recomendada de usar el plugin. El plugin servirá un archivo “supercacheado” si existe y es casi tan rápido como el método mod_rewrite. Es más fácil de configurar ya que no necesita cambiar el archivo .htaccess. Sin embargo necesita un enlace permanente personalizado. Puedes mantener partes de tu página dinámica en este modo de almacenamiento en caché.
  3. Caché de WP-Cache. Esto se usa principalmente para almacenar en caché las páginas para usuarios conocidos, URL con parámetros y feeds. Los usuarios conocidos son usuarios registrados, visitantes que dejan comentarios o aquellos a quienes deben mostrarse datos personalizados por usuario. Es el método de almacenamiento en caché más flexible y un poco más lento. El almacenamiento en memoria caché de WP-Cache también almacenará en caché las visitas de usuarios desconocidos si supercache está desactivado. Puedes tener partes dinámicas en tu página en este modo también. Este modo siempre está activado pero puedes desactivar el almacenamiento en caché para usuarios conocidos, URL con parámetros o feeds por separado. Establece la constante “DISABLE_SUPERCACHE” en 1 en tu wp-config.php si solo deseas usar el almacenamiento en caché de WP-Cache.

Si no te sientes cómodo editando archivos PHP, utiliza el modo fácil. Es fácil y muy rápido de configurar.

Ajustes recomendados

  1. Almacenamiento en caché fácil.
  2. Comprimir páginas.
  3. No cachear páginas a los usuarios conocidos.
  4. Reconstrucción de caché.
  5. Compatibilidad con CDN.
  6. Comprobaciones adicionales de portada.

La recogida de basura es el acto de limpiar los archivos de caché que están desactualizados y obsoletos. No hay un valor correcto para el tiempo de caducidad, pero un buen punto de inicio es 1800 segundos.

Considera eliminar el contenido de la caja de texto “Agentes de usuario rechazados” y permite que los motores de búsqueda guarden los archivos en caché para tí.

A ser posible precarga tantas entradas como puedas y activa el “Modo de precarga”. La recogida de residuos todavía funcionará pero no afectará a los archivos precargados. Si no te importa que los widgets de barra lateral no se actualicen muy a menudo pon el intervalo de precarga a 2880 minutos (2 días) para que tus entradas no se vuelvan a cachear muy a menudo. Cuando se realiza la precarga los archivos en caché de la entrada se actualizan y se borran, y luego se regeneran. Después se realiza una recogida de residuos de todos los archivos antiguos para limpiar los archivos en caché anticuados.
Con la precarga de archivos de caché se siguen borrando cuando creas o editas entradas o cuando se hacen comentarios.

Desarrollo

Documentación

Si necesitas más información que la actual, puedes visitar la documentación del desarrollador.

Precarga

Puedes generar archivos almacenados en caché para las publicaciones, categorías y etiquetas de tu sitio mediante precarga. La precarga visitará cada página de tu sitio y generará una página en caché a medida que avance, al igual que cualquier otro visitante del sitio. Debido a la naturaleza secuencial de esta función, precargar un sitio completo puede llevar algún tiempo si hay muchas publicaciones.
Para que la precarga sea más efectiva, puede ser útil desactivar la recogida de basura para que no se eliminen los archivos de caché más antiguos. Esto se hace activando el “Modo de precarga” en los ajustes. Ten en cuenta, sin embargo, que las páginas quedarán desactualizadas eventualmente, pero que las actualizaciones al enviar comentarios o editar publicaciones borrarán partes de la caché.

Recogida de basura

El directorio de caché se llena con el tiempo, y eso ocupa espacio en el servidor. Si el espacio es limitado o te pasa factura o si te preocupa que las páginas en caché se vuelvan obsoletas, entonces debes realizarse la recogida de basura. La recolección de basura se hace regularmente y borra archivos viejos en el directorio de caché. En la página de ajustes avanzados puedes especificar:
1. Tiempo de caducidad. Cuánto tiempo se consideran válidos los archivos de caché. Después de este tiempo, están obsoletos y se pueden eliminar.
2. Programador. Configura la frecuencia con la que se debe realizar la recogida de basura.
3. Mensajes de notificación por correo electrónico. Puedes recibir información sobre la evolución del proceso de recogida de basura. No hay configuraciones correctas o incorrectas para la recolección de basura. Depende de tu propio sitio.
Si tu sitio recibe actualizaciones periódicas o comentarios, establece el tiempo de caducidad en 1800 segundos y configura el temporizador en 600 segundos.
Si tu sitio es principalmente estático, puedes desactivar la recogida de basura escribiendo 0 como tiempo de caducidad o usando un valor de tiempo de caducidad francamente grande.

El directorio de caché, generalmente wp-content/cache/ es solo para archivos temporales. Nunca coloques en ese directorio archivos importantes o enlaces simbólicos a archivos o directorios importantes. Se eliminarán si el plugin tiene acceso de escritura a ellos.

CDN

Una red de distribución de contenido (CDN) generalmente es una red de computadoras ubicadas en todo el mundo que sirven el contenido del sitio web más rápidamente mediante el uso de servidores cercanos a tí. Los archivos estáticos como imágenes, Javascript y CSS se pueden servir a través de estas redes para acelerar la carga del sitio. También puedes crear una “CDN de pobre” utilizando un subdominio de tu dominio para servir archivos estáticos.

OSSDL CDN off-linker se ha integrado en WP Super Cache para proporcionar compatibilidad básica con CDN. Funciona reescribiendo las URLs de los archivos (excepto los archivos.php) en wp-content y wp-includes de tu servidor, por lo que apuntan a un hostname diferente. Muchos CDN admiten extracción de origen. Esto significa que el CDN descargará el archivo automáticamente de tu servidor cuando se le solicite por primera vez, y lo continuará sirviendo durante un período de tiempo configurable antes de volver a descargarlo de tu servidor.

Configura esto en la pestaña “CDN” de la página de ajustes del plugin. Esta es una técnica avanzada y requiere una comprensión básica de cómo funciona tu servidor web o CDN. Asegúrate de borrar los archivos en caché después de configurar el CDN.

REST API

Ahora hay endpoints en la REST API para acceder a la configuración de este plugin. Deberá ser autenticado como usuario administrador con permiso para ver la página de configuración y poder usarla. Esto aún no se ha documentado, pero puede encontrar todo el código de esto en el directorio “rest”.

Caché personalizada

Ahora es posible conectar el proceso de almacenamiento en caché utilizando la función add_cacheaction().

Hay tres ganchos disponibles:

  1. ‘wp_cache_get_cookies_values’ – modifica la clave utilizada por WP Cache.
  2. ‘add_cacheaction’ – se ejecuta en fase2. Permite que un plugin agregue ganchos de WordPress.
  3. ‘cache_admin_page’ – se ejecuta en la página de administración. Úsalo para modificar esa página, quizás agregando nuevas opciones de configuración.

Hay un filtro regular de WordPress también. Usa el filtro the “do_createsupercache”
para personalizar los controles realizados antes del almacenamiento en caché. El filtro acepta un parámetro.
La función de salida de WP-Cache wp_cache_get_cookies_values().

WP Super Cache has it’s own plugin system. This code is loaded when WP Super Cache loads and can be used to change how caching is done. This is before most of WordPress loads so some functionality will not be available. Plugins can be located anywhere that PHP can load them. Add your own plugin by calling wpsc_add_plugin( $name ) where $name is the full filename and path to the plugin. You only need to call that function once to add it. Use wpsc_delete_plugin( $name ) to remove it from the list of loaded plugins.

The cookies WP Super Cache uses to identify “known users” can be modified now by adding the names of those cookies to a list in the plugin configuration. Use wpsc_add_cookie( $name ) to add a new cookie, and wpsc_delete_cookie( $name ) to remove it. The cookie names also modify the mod_rewrite rules used by the plugin but I recommend using Simple mode caching to avoid complications with updating the .htaccess file.
The cookie name and value are used to differenciate users so you can have one cookie, but different values for each type of user on your site for example. They’ll be served different cache files.

See plugins/searchengine.php as an example I use for my No Adverts for Friends plugin.

Solución de problemas

Si algunas cosas no funcionan desde que instalaste el plugin, hay algunas cosas que debes comprobar:

  1. ¿Tiene wp-content permisos de escritura para el servidor?
  2. ¿Existe un wp-content/wp-cache-config.php? Si no existe, debes copiar el archivo wp-super-cache/wp-cache-config-sample.php en wp-content/wp-cache-config.php y asegurarte de que WPCACHEHOME apunte al lugar correcto.
  3. ¿Existe un wp-content/advanced-cache.php? Si no existe, debes copiar wp-super-cache/advanced-cache.php en wp-content/. Debes editar el archivo y cambiar la ruta para que apunte a la carpeta wp-super-cache.
  4. Si no hay páginas en la memoria caché, elimina wp-content/advanced-cache.php y vuelve a crearlo, siguiendo los consejos anteriores.

  5. Asegúrate de que la siguiente línea esté en wp-config.php y esté ENCIMA de la línea “require_once(ABSPATH.’wp-settings.php’);”:

    define( 'WP_CACHE', true );
  6. Prueba de nuevo en página Ajustes->WP Super Cache y activa la caché.
  7. Pasa a ver wp-content/cache/supercache/. ¿Hay directorios y archivos allí?
  8. ¿Hay algo en el error_log de php?
  9. Si el navegador sigue pidiéndote que guardes el archivo después de instalar supercaché, debes desactivar la compresión de Super Cache. Ve a la página Ajustes->WP Super Cache y desactívala ahí.
  10. El plugin no funciona muy bien con el modo seguro de PHP activo. Debe ser desactivado por tu administrador.
  11. Si las páginas se supercachean aleatoriamente y a veces no, probablemente tu blog se puede ver con y sin el prefijo “www” en la URL. Debes elegir una forma e instalar el plugin Enforce www preference si estás usando una instalación antigua de WordPress. Las últimas versiones se redireccionan (de todos modos ¡siempre deberías usar la última versión de WordPress!)
  12. Los usuarios de servidores privados en Dreamhost deberían editar wp-content/wp-cache-config.php y apuntar el directorio de caché a “/tmp/” si reciben errores sobre el aumento del uso de la CPU. Consulta este debate para saber más.
  13. Errores de bloqueo de archivos como “no se pudo obtener la clave 0x152b: Permiso denegado en …” o “Página no almacenada en caché por WP Super Cache. No se pudo obtener el bloqueo de exclusión mutua.” son una señal de que debes usar el bloqueo de archivos. Edita wp-content/wp-cache-config.php y descomenta “$use_flock = true” o define un valor diferente para $sem_id. También puedes desactivar el bloqueo de archivos desde la pantalla de administración como último recurso.
  14. Asegúrate de que el servidor web pueda escribir en la memoria cache/wp_cache_mutex.lock si utilizas el bloqueo basto de archivos.
  15. La carpeta de caché no se puede colocar en un compartimiento NFS o Samba o NAS. Tiene que estar en un disco local. El bloqueo de archivos y la eliminación de archivos caducados no funcionarán correctamente a menos que la carpeta de caché esté en la máquina local.

  16. La recogida de basura de archivos antiguos de caché no funcionará si WordPress no puede encontrar wp-cron.php. Si stu hostname se resuelve en 127.0.0.1, podría estar impidiendo que funcione la recogida de elementos no utilizados. Verifica los access_logs de las entradas de wp-cron.php. ¿Devuelven un código 404 (archivo no encontrado) o 200? Si es 404 o no ves wp-cron.php en cualquier lugar, WordPress puede estar buscando esa secuencia de comandos en el lugar equivocado. Debes hablar con el administrador de tu servidor para corregir esto o editar /etc/hosts en servidores Unix y eliminar la siguiente línea. Tu hostname debe resolverse en la dirección IP externa de otros servidores en el uso de la red/Internet. Ver http://yoast.com/wp-cron-issues/ para más info. Una línea como “127.0.0.1 localhost localhost.localdomain” está bien.

    127.0.0.1 example.com
  17. Si se están sirviendo páginas anticuadas a tus visitantes a través de la supercaché, es posible que te falten módulos Apache (o sus equivalentes si no usas Apache). Se requieren 3 módulos: mod_mime, mod_headers y mod_expires. Los dos últimos son especialmente importantes para garantizar que los navegadores carguen las nuevas versiones de páginas existentes en tu sitio.
  18. El mensaje de error “WP Super Cache está instalado pero roto. La ruta a wp-cache-phase1.php in wp-content/advanced-cache.php debe corregirse!” aparece al final de cada página. Abre el archivo wp-content/advanced-cache.php en su editor favorito. ¿Es correcta la ruta a wp-cache-phase1.php? Este archivo estará normalmente en wp-content/plugins/wp-super-cache/. Si no es correcto, el motor de almacenamiento en caché no se cargará.
  19. El almacenamiento en caché no funciona. La marca de tiempo en mi blog cambia constantemente cuando recargo. Comprueba en las reglas .htaccess que la ruta coincide con el lugar donde está el directorio supercache. Puede que tengas que codificarlo. Intenta desactivar el modo supercaché.

  20. Si se generan archivos de caché de supercaché pero no se sirven, comprueba los permisos en todas las carpetas de wp-content/cache/supercache (y en cada una de las carpetas de memoria caché y supercaché de wp-content) y wp-content/cache/.htaccess. Si tu PHP se ejecuta como un usuario diferente a Apache y los permisos son estrictos, es posible que Apache no pueda leer los archivos de caché generados por PHP. Para solucionarlo, debes agregar la siguiente línea a tu wp-config.php (agrégala encima de WP_CACHE define). Después borra la caché.

    umask( 0022 );

  21. Si ves basura en tu navegador después de activar la compresión en el plugin, es posible que la compresión ya esté activada en el servidor web. En Apache debes desactivar mod_deflate, o en PHP la compresión zlib puede estar activada. Puedes desactivarla de tres maneras. Si tienes acceso de administrador, edita el php.ini y encuentra la configuración de zlib.output_compression y asegúrate de que esté “Desactivada” o agrega esta línea al .htaccess:

    php_flag zlib.output_compression off

    Si eso no funciona, añade esta línea a tu wp-config.php:

    ini_set('zlib.output_compression', 0);
  22. La “pantalla blanca de la muerte” o una página en blanco cuando visitas tu sitio casi siempre es causada por un error de PHP, pero también puede ser causado por APC. Desactiva esa extensión de PHP si tienes problemas y reemplázala con eAccelerator o Xcache.
  23. Después de desinstalar, los enlaces permanentes pueden romperse si eliminas también las reglas de mod_rewrite de WordPress. Vuelve a generar esas reglas visitando la página Ajustes->Enlaces permanentes y guarda ese formulario de nuevo.
  24. Si tu blog se niega a cargar, asegúrate de que tu wp-config.php sea correcto. ¿Has perdido una etiqueta PHP de apertura o cierre?
  25. ¿Tu página principal está bien, pero las entradas y las páginas dan un 404? Ve a Ajustes-> enlaces permanentes y haz clic en “Guardar” una vez hayas seleccionado una estructura personalizada de enlaces permanentes. Es posible que debas actualizar manualmente el archivo .htaccess.

  26. Si algunos caracteres no aparecen correctamente en tu sitio web, es posible que tu servidor no esté configurado correctamente. Debes decirle a los visitantes qué conjunto de caracteres usas. Ve a Ajustes->Lectura y copia el valor ‘Codificación de páginas y feeds’. Edita el archivo .htaccess con todas las reglas de reescritura de Supercache y WordPress y añade esto en la parte superior, reemplazando CHARSET con el valor copiado. (por ejemplo, ‘UTF-8’)

    AddDefaultCharset CHARSET
  27. Usa Cron View para ayudar a diagnosticar problemas de recogida de basura y precarga. Usa el plugin para asegurarte de que las tareas estén programadas y para qué hora. Busca las tareas wp_cache_gc y wp_cache_full_preload_hook.
  28. El mensaje de error “WP Super Cache está instalado pero roto. La constante WPCACHEHOME se debe establecer en el archivo wp-config.php y apuntar al directorio del plugin WP Super Cache.” aparece al final de cada página. Puedes eliminar wp-content/advanced-cache.php y recargar la página de configuración del plugin o editar wp-config.php y buscar WPCACHEHOME y asegurarte de que apunte a la carpeta wp-super-cache. Normalmente será wp-content/plugins/wp-super-cache/ pero es probable que necesites la ruta completa a ese archivo (por lo que es más fácil dejar que la página de ajustes lo solucione). Si no es correcto, el motor de almacenamiento en caché no se cargará.
  29. Si tu servidor está teniendo problemas debido a la cantidad de semáforos que utiliza el plugin, es porque tus usuarios están utilizando el bloqueo de archivos, que no es recomendable (pero lo necesitan un reducido número de usuarios). Puedes desactivar globalmente el bloqueo de archivos definiendo la constante WPSC_DISABLE_LOCKING, o definiendo la constante WPSC_REMOVE_SEMAPHORE para que llame a sem_remove() después de almacenar cada página en caché, pero eso parece causar problemas en otros procesos que solicitan el mismo semáforo. Lo mejor es desactivarlo.
  30. Set the variable $htaccess_path in wp-config.php or wp-cache-config.php to the path of your global .htaccess if the plugin is looking for that file in the wrong directory. This might happen if you have WordPress installed in an unusual way.

Instalación

Instalar como cualquier otro plugin, directamente desde tu página de plugins, pero asegúrate de tener activos los enlaces permanentes personalizados. Ve a la página de ajustes del plugin en Ajustes->WP Super Cache y activa el almacenamiento en caché.

Cómo desinstalar WP Super Cache

Prácticamente todo lo que tienes que hacer es desactivar el plugin en la página de plugins. El plugin debería limpiar la mayoría de archivos creados y modificados, pero aún no borra las reglas de mod_rewrite del archivo .htaccess. Busca la sección de ese archivo marcada con las etiquetas SuperCache BEGIN y END. El plugin no borra eso debido a que algunas personas añaden también reglas de WordPress en ese bloque.

Para desinstalarlo manualmente:

  1. Desactiva la caché en la página de ajustes del plugin y vacía la caché.
  2. Desactiva el plugin en la página de plugins.
  3. Borra la variable WP_CACHE de tu wp-config.php. Será algo como define( 'WP_CACHE', true );
  4. Borra las reglas mod_rewrite de Super Cache de tu archivo .htaccess.
  5. Borra los archivos wp-content/advanced-cache.php y wp-content/wp-cache-config.php
  6. Borra el directorio wp-content/cache/
  7. Borra el directorio wp-super-cache de tu directorio de plugins.

Si todo falla y tu sitio está roto

  1. Borra la variable WP_CACHE de tu wp-config.php. Será algo como define( 'WP_CACHE', true );
  2. Borra las reglas (ver arriba) que el plugin escribió en el archivo .htaccess de tu directorio raíz.
  3. Borra la carpeta wp-super-cache de la carpeta de plugins.
  4. Opcionalmente borra advanced-cache.php, wp-cache-config.php la la carpeta de caché en wp-content/.

Preguntas frecuentes

Instrucciones de instalación

Instalar como cualquier otro plugin, directamente desde tu página de plugins, pero asegúrate de tener activos los enlaces permanentes personalizados. Ve a la página de ajustes del plugin en Ajustes->WP Super Cache y activa el almacenamiento en caché.

Cómo desinstalar WP Super Cache

Prácticamente todo lo que tienes que hacer es desactivar el plugin en la página de plugins. El plugin debería limpiar la mayoría de archivos creados y modificados, pero aún no borra las reglas de mod_rewrite del archivo .htaccess. Busca la sección de ese archivo marcada con las etiquetas SuperCache BEGIN y END. El plugin no borra eso debido a que algunas personas añaden también reglas de WordPress en ese bloque.

Para desinstalarlo manualmente:

  1. Desactiva la caché en la página de ajustes del plugin y vacía la caché.
  2. Desactiva el plugin en la página de plugins.
  3. Borra la variable WP_CACHE de tu wp-config.php. Será algo como define( 'WP_CACHE', true );
  4. Borra las reglas mod_rewrite de Super Cache de tu archivo .htaccess.
  5. Borra los archivos wp-content/advanced-cache.php y wp-content/wp-cache-config.php
  6. Borra el directorio wp-content/cache/
  7. Borra el directorio wp-super-cache de tu directorio de plugins.

Si todo falla y tu sitio está roto

  1. Borra la variable WP_CACHE de tu wp-config.php. Será algo como define( 'WP_CACHE', true );
  2. Borra las reglas (ver arriba) que el plugin escribió en el archivo .htaccess de tu directorio raíz.
  3. Borra la carpeta wp-super-cache de la carpeta de plugins.
  4. Opcionalmente borra advanced-cache.php, wp-cache-config.php la la carpeta de caché en wp-content/.
¿Cómo sé que mi blog se está cacheando?

Ve a Ajustes->WP Super Cache y busca el formulario “Probar caché” en la página de ajustes fáciles. Haz clic en “Probar Cache” y el plugin solicitará la página principal del sitio dos veces, comparando una marca de tiempo en cada una para asegurarse de que coincidan.

Si deseas hacerlo manualmente, activa la depuración en la página de ajustes del plugin y carga el archivo de registro en una nueva pestaña del navegador. Luego, mira tu blog mientras estás conectado y tras haber cerrado sesión. Deberías ver actividad en el registro. Mira el código fuente de cualquier página de tu sitio. Cuando se crea una página por primera vez, verás el texto “Página dinámica generada en XXXX segundos”. y “Página en caché generada por WP-Super-Cache en YYYY-MM-DD HH: MM: SS” al final del código fuente. Al volver a cargar, una página almacenada en caché mostrará la misma marca de tiempo, así que espera unos segundos antes de verificar.
Si el Supercaching está desactivado y tienes activada la compresión, se agregará el texto “Compression = gzip”. Si la compresión está desactivada y la página se sirve como un archivo html estático, se agregará el texto “super cache”. La única forma de comprobar si el archivo en caché es servido por el script PHP o desde la caché estática es mirando los encabezados HTTP. Las páginas en caché de PHP tendrán el encabezado “WP-Super-Cache: archivo de super cache servido desde PHP”. Los archivos en caché de WPCache tendrán el encabezado, “WP-Super-Cache: servido archivo de caché WPCache”. También debes verificar el directorio de caché en wp-content/cache/supercache/hostname/ para archivos de caché estáticos.
Si las reglas del plugin no aparecen en tu archivo .htaccess, el plugin intentará mostrar la página super cache si la encuentra. Si esto sucede el encabezado será “WP-Super-Cache: archivo de supercache servido desde PHP”.

¿Cómo desactivo Supercache?

Si solo quieres usar el motor WP-Cache, entonces edita tu wp-config.php o crea un mu-plugin que establezca la constante ‘DISABLE_SUPERCACHE’ en 1.

WP-Cache vs archivos Supercache

Todos los archivos de caché se almacenan en wp-content/cache/supercache/HOSTNAME/ donde HOSTNANE es tu nombre de dominio. Los archivos se almacenan en directorios que coinciden con la estructura de enlaces permanentes de tu sitio. Los archivos de Supercache son index.html o alguna variante de eso, dependiendo del tipo de visitante que llegue al blog. Otros archivos se llaman wp-cache-XXXXXXXXXXXXXXXXX.php. Los metaarchivos asociados comienzan con “meta”. Esos archivos contienen información sobre el archivo en caché. Estos archivos son generados por el motor “WPCache caching” del plugin.

¿Se actualizarán de inmediato los comentarios y otras partes dinámicas de mi blog?

Los comentarios se mostrarán tan pronto como se moderen, según la política de comentarios del propietario del blog. Es posible que otros elementos dinámicos de una página no se actualicen a menos que estén escritos en JavaScript, Flash, Java u otro lenguaje de navegador del lado del cliente. El plugin realmente produce páginas html estáticas. Cuando esas páginas se sirven no se ejecuta PHP. “Popularity Contest” es uno de esos plugins que no funcionarán.

¿Reducirá la velocidad de mi servidor la compresión de Super Cache?

No, hará lo contrario. Los archivos de Super Cache se comprimen y almacenan de esa forma, por lo que la compresión intensa se realiza solo una vez. Generalmente estos archivos son mucho más pequeños y se envían al navegador de un visitante mucho más rápido que los html sin comprimir. Como resultado, el servidor pasa menos tiempo hablando por la red, lo que ahorra tiempo de CPU y ancho de banda, y también puede atender la próxima solicitud mucho más rápidamente.

¿Cómo hago para que ciertas partes de la página se mantengan dinámicas?

Nota: esta funcionalidad está desactivada por defecto. Deberás activarla en la página de ajustes avanzados.

Hay 2 formas de hacer esto. Puedes usar Javascript para dibujar la parte de la página que deseas mantener dinámica. Eso es lo que Google Adsense y muchos widgets de sitios externos hacen y es la forma recomendada. O puedes usar un filtro de WP Super Cache para hacer el trabajo pero no puedes usar el caché de modo mod_rewrite. Has de usar el método de entrega “fácil” o desactivar supercache.

WP Super Cache 1.4 introdujo un filtro de caché llamado wpsc_cachedata. La página en caché a mostrar pasa por este filtro y permite la modificación de la página. Si la página contiene una etiqueta de marcador de posición, el filtro se puede usar para reemplazar esa etiqueta con tu html generado dinámicamente.
La función que se engancha al filtro wpsc_cachedata debe colocarse en un archivo en la carpeta de plugins de WP Super Cache si no usas la función late_init feature. Hay un plugin de ejemplo incluido. Edita dynamic-cache-test.php para ver el código de ejemplo.
Hay dos ejemplos de funciones allí. Hay una función simple que reemplaza una cadena (o etiqueta) que define cuando se sirve la página en caché. La otra función de ejemplo usa un buffer de salida para generar el contenido dinámico. Debido a una limitación en la forma en que PHP funciona, el código del buffer de salida DEBE ejecutarse antes que el filtro wpsc_cachedata, al menos para cuando se almacena en la memoria caché de una página. No importa cuando se publican páginas en caché. Consulta esta entrada para obtener una explicación más técnica y extensa.
Para ejecutar funciones de WordPress debes activar la característica ‘Late init’ en la página de ajustes avanzados.

¿Cómo puedo retrasar la entrega de caché hasta que se active la acción “init”?

Los archivos cacheados se sirven antes de que cargue casi todo WordPress. Si bien es genial para el rendimiento, es un dolor cuando quieres ampliar el plugin usando una parte del core de WordPress. Activa el modo ‘Retrasar init’ en la página de ajustes avanzados y los archivos en caché se servirán cuando se active “init”. WordPress y sus plugins se cargarán ahora.

¿Por qué ahora no funcionan o no se actualizan en mi blog WP UserOnline, Popularity Contest, WP Postratings o el plugin X?

Este plugin almacena en caché páginas enteras, pero algunos plugins piensan que pueden ejecutar código PHP cada vez que se carga una página. Para solucionarlo, el plugin necesita usar los métodos de Javascript/AJAX o el filtro wpsc_cachedata descrito en la respuesta anterior para actualizar o mostrar información dinámica.

¿Por qué desaparecen mis plugins de WP Super Cache cuando actualizo el plugin?

WordPress deletes the plugin folder when it updates a plugin. This is the same with WP Super Cache so any modified files in wp-super-cache/plugins/ will be deleted. You can put your custom plugins in a different directory in a number of ways. You can define the variable $wp_cache_plugins_dir in wp-config.php or wp-content/wp-cache-config.php and point it at a directory outside of the wp-super-cache folder. The plugin will look there for it’s plugins. Or if you distribute a plugin that needs to load early you can use the function wpsc_add_plugin( $filename ) to add a new plugin wherever it may be. Use wpsc_delete_plugin( $filename ) to remove the plugin file. See #574 or this post on writing WP Super Cache plugins.

¿Qué hace la característica reconstruir caché?

Cuando una visita deja un comentario, el archivo en caché de esa página se elimina y la siguiente visita vuelve a crear la página en caché. Una página emplea tiempo en cargarse, entonces ¿qué sucede si recibes 100 visitantes en ese momento? No habrá una página almacenada en caché para que WordPress sirva una página actualizada para cada usuario y el plugin intentará crear una página en caché para cada uno de esos 100 visitantes, causando una gran carga en el servidor. Esta característica evita que esto ocurra. La página almacenada en caché no se borra cuando dejan un comentario. Está marcada para que en lugar de eso se reconstruya. La siguiente visita dentro de los siguientes 10 segundos regenerará la página en caché mientras se sirve la página antigua a las otras 99 visitas. La página es eventualmente cargada por la primera visita y la página en caché se actualiza. Consulta esta entrada para saber más.

¿Por qué el plugin no cachea por defecto las solicitudes de los robots del motor de búsqueda?

Esos bots normalmente solo visitan cada página una vez y si la página no es popular no tiene sentido crear un archivo de caché que permanezca inactivo en el servidor. Sin embargo, puedes permitir que estas visitas se almacenen en caché eliminando la lista de bots de “Agentes de usuario rechazados” en la página de configuración avanzada.

Se está mostrando una página de categoría en lugar de mi página de inicio

Una pequeña proporción de sitios web tendrán problemas con la siguiente configuración:

  1. Utiliza una página estática para la página principal.
  2. Usa la estructura de enlaces permanentes /%category%/%postname%/.

A veces, una página de categoría se almacena en caché como la página de inicio del sitio en lugar de la página estática. No puedo replicar el problema pero una solución simple es usar el modo “Fácil”. También puedes habilitar los “Comprobaciones adicionales de página de inicio” en la página de ajustes avanzados.

¿Por qué recibo advertencias sobre el almacenamiento en caché desde http://ismyblogworking.com/ ?

“Tu blog no admite el almacenamiento en memoria caché del cliente (no hay respuesta 304 a If-modified-since).”
“Tu feed no admite cacheo (no hay respuesta 304 a If-modified-since)”

Supercache no es compatible con control de encabezado 304 en el modo Avanzado, pero sí lo es en modo Fácil. Esto es el almacenamiento en caché realizado por el navegador, no el servidor. Es un control que hace el navegador para preguntarle al servidor si hay disponible una versión actualizada de la página actual. Si no, no descarga la versión anterior de nuevo. El servidor aún almacena la página en caché, pero no en los navegadores de los visitantes.
Prueba el motor de Cacheability en http://www.ircache.net/cgi-bin/cacheability.py o https://redbot.org/ para un análisis más detallado.

¿Cómo debo usar las herramientas de seguimiento utm_source en Google Analytics con este plugin?

Ese seguimiento agrega una cadena de consulta a cada URL vinculada desde varias fuentes como Twitter y lectores de noticias. Desafortunadamente, evita que las páginas se supercacheen. Consulta el comentario de Joost aquí sobre cómo convertirlo en una etiqueta de anclaje que pueda supercachearse.

¡El plugin se queja de que wp-content tiene permisos de escritura! ¡htdocs tiene permisos de escritura!

No es bueno quw el servidor web pueda escribir en estos directorios, pero a veces las cuentas de hosting compartido se configuran así para facilitar la administración. Usa chmod 755 directory para corregir los permisos o busca la sección de permisos en tu cliente ftp. Este búsqueda en Google te guiará para obtener más información sobre este tema y también hay esta página del codex page. Lamentablemente, algunos hosts requieren que esos directorios sean escribibles. Si ese es el caso, simplemente ignora esta advertencia.

¿Cómo borro WP_CACHE define de wp-config.php?

Carga tu cliente ftp de escritorio y conéctate a tu sitio. Navega hasta la raíz (o el directorio debajo de ella) del sitio donde encontrarás wp-config.php. Descarga ese archivo y edítalo en un editor de texto. Borra la línea define( 'WP_CACHE', true ); y guarda el archivo. Ahora súbelo, sobrescribiendo el wp-config.php en tu servidor.

¿Cómo elimino las reglas de Super Cache del archivo .htaccess?

Carga tu cliente ftp de escritorio y conéctate a tu sitio. Es posible que debas activar “Mostrar archivos ocultos” en las preferencias de tu cliente ftp. Navegua a la raíz del sitio donde encontrarás el archivo .htaccess. Descarga ese archivo y edítalo en un editor de texto. Elimina las líneas entre “# BEGIN WPSuperCache” y “# END WPSuperCache” y guarda el archivo. Ahora cárgalo y sobrescribe el archivo .htaccess en tu servidor.

¿Cómo cambio los permisos de archivos?

Esta página del Codex de WordPress explica todo lo que necesitas saber sobre los permisos de archivos en el servidor y varias formas de cambiarlos.

¿Por qué obtengo picos de carga cuando se hacen nuevas publicaciones?

Puedes permitir la opción “borrar todos los archivos almacenados en caché cuando se realicen nuevas publicaciones”. Limpiar esos archivos puede llevar tiempo, y tus visitantes ahora visitarán las páginas que no están en caché. ¿Estás usando el seguimiento de campañas de Google Analytics con utm_source en la url? Esas páginas no están en caché. Consulta la pregunta “¿Cómo debo usar las herramientas de seguimiento de utm_source en Google Analytics con este plugin?” para saber cómo usarlas correctamente.
Las páginas en caché deben actualizarse cuando se realizan las publicaciones. Tal vez tu servidor simplemente no está a la altura de la cantidad de tráfico que recibes. Activa la función “reconstrucción de caché” ya que puede ser útil.

¿Cuántas páginas puedo cachear?

El único límite real son los límites definidos por tu servidor. Por ejemplo, EXT2 y EXT3 permiten un máximo de 31,999 subdirectorios, así que si tienes una estructura plana de enlaces permanentes (como /%POSTNAME%/) y tienes más de 32.000 entradas puede que te metas en problemas. Igualmente, si es una red multisitio y tienes más de 31.999 sitios (blogs) no podrás cachearlos todos. Siendo realistas, si tienes tantos sitios activos no deberías estar ejecutándolos en un mismo servidor.

La versión www de mi sitio es cacheada aparte. ¿Cómo puedo evitarlo?

WordPress should redirect to the canonical URL of your site but if it doesn’t, add this to your .htaccess above the Supercache and WordPress rules. Change example.com to your own hostname.
RewriteCond %{HTTP_HOST} www.example.com$ [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

¿Cómo sirvo páginas móviles en caché a clientes con pantallas pequeñas como teléfonos y tabletas?

Tu tema es probablemente adaptable, lo que significa que cambia el tamaño de la página para adaptarse a cualquier dispositivo en el que se muestre. Si no es adaptable, tendrás que usar un complemento independiente para móvil para procesar una página formateada para esos visitantes. Se han probado los siguientes complementos pero YMMV depende del cliente móvil. Tendrás que habilitar el soporte para navegador móvil también en la página de ajustes avanzada.

Reseñas

Best for basic sites

Works great for basic sites that just need a full page cache, also good in combination with Autoptimize

Great Plugin BUT need some changes

Great plugin. Moreover, one of the few that allows caching pages of categories and not caching posts. BUT I spent a lot of time checking pages caching entering and leaving the admin account. The plugin verifies user through the cookie, hence simply quitting the record is not enough. It is necessary to check pages through anonymous mode of the browser or clean cookies. Please indicate this, or do not check through cookies.

Very fast – and reliable

There are many good Caching plugins available, and all help impriving Paeg loading speed. However, this one here is also very reliable and works flawless with lots of other Plugins, Page translation plugins for example. Many thanks to the Developers!

Leer todas las 1.192 reseñas

Colaboradores y desarrolladores

“WP Super Cache” es un software de código abierto. Las siguientes personas han colaborado con este plugin.

Colaboradores

“WP Super Cache” ha sido traducido a 16 idiomas. Gracias a los traductores por sus contribuciones.

Traduce “WP Super Cache” a tu idioma.

¿Interesado en el desarrollo?

Revisa el código , echa un vistazo al repositorio SVN , o suscríbete al log de desarrollo por RSS .

Registro de cambios

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)
  • Fixes to wpsc_post_transition to avoid a fatal error using get_sample_permalink. (#595)
  • Fixed the admin bar “Delete Cache” link. (#589)
  • Fixed the headings used in the settings page. (#597)

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 admin bar (#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)
  • Comprueba si set_transient() existe antes de usarlo. (#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

  • Arregla el nombre del plugin WP Crontrol. (#549)
  • Handle errors during deactivation/uninstall by email rather than exiting. (#551)
  • Añade un aviso cuando los ajustes no se pueden actualizar. (#552 y #553)

1.6.0

  • Soluciona problemas en el plugin multisitio (#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)
  • Añadido el iPad a la lista de móviles (#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.
  • Cambios: https://github.com/Automattic/wp-super-cache/compare/1.5.8…1.5.9

1.5.8

  • Correcciones de PHP 7. (#429)
  • Arreglada casilla de verificación de comentarios de depuración. (#433)
  • Solo registra la función de desinstalación en las páginas de administración para guardar consultas. (#430)
  • Comprueba que wp-cache-phase1.php está cargado antes de guardar la página de ajustes. (#428)
  • Si una url contiene un “?” entonces no elimina la caché asociada. ¿Eliminará toda la caché después de eliminar?… parte. (#427 & #420)
  • Permite funciones estáticas en clases para ser utilizadas en acciones de caché. (#425)
  • No hace anónimas las solicitudes AJAX. (#423)
  • Corregido enlace a la explicación de chmod. (#421)
  • Agregados más escapes a la página de ajustes de CDN. (#416)
  • Usa SERVER_PROTOCOL para determinar el protocolo http. (#412 & #413)
  • Si la precarga se detiene solo envía un correo electrónico por día, pero muestra un aviso al administrador. (#432)
  • Corregidas más advertencias de PHP en #438 y #437
  • Oculta las advertencias de mod_rewrite para los usuarios de Nginx. #434

1.5.7.1

  • Si HTTP HOST está vacío, no lo usa en strpos para evitar una advertencia de PHP. (#408)
  • No precarga las publicaciones con enlaces permanentes que contengan cadenas rechazadas. (#407)
  • Genera una lista de feeds de archivos que se pueden eliminar al actualizar el sitio. También corrige el problema de archivo de configuración dañado y el error fatal con versiones anteriores de WordPress. (#403)

1.5.7

  • Arreglado error fatal error en plugins/searchengine.php (#398)

1.5.6

  • REST API: Added /plugins endpoint to handle the plugins settings page. (#382)
  • Cambios menores en sangría y espacios para la conversión de pestañas (#371) (#395)
  • Don’t set $wp_super_cache_comments here as it’s not saved. (#379)
  • realpath() solo funciona en directorios. cache_file no estaba cofigurado correctamente. (#377)
  • Arreglado problema debido a realpath() al eliminar la caché de la barra de administración (#381)
  • Use trigger_error() instead of echoing to the screen if a config file isn’t writeable. (#394)
  • Agregado el filtro “wpsc_enable_wp_config_edit” para desactivar la edición de wp-config.php (#392)
  • Repara algunos avisos de PHP cuando los comentarios se editan/publican/mantienen. (#386)
  • Cambios menores en la descripción en la página de plugins. (#393)

1.5.5

  • Captura errores fatales para que no se almacenen en la memoria caché, mejora el código que capta tipos de página desconocidos.(#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)
  • Al precargar, no elimina subdirectorios ni páginas secundarias mientras cachea páginas. (#363)
  • Evitar advertencias de PHP de REST API en configuraciones que aún no están definidas. (#361)
  • Agregados ajustes que faltaban al archivo de configuración.(#360)

1.5.4

  • Reparados mensajes relacionados con la creación de advanced-cache.php (#355, #354)
  • Al eliminar el plugin no es necesario eliminar el directorio de caché, ya se hizo al desactivarlo.(#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)
  • Usa un feed almacenado en caché si es más reciente que el último cambio de una publicación. (#337)
  • Better define a sitemap (#340) but when the content type is unknown add more checks to find out what it is. (#346)
  • Guarda correctamente la ubicación de la caché en la página de ajustes avanzados. (#345)
  • Asegúrate de que el registro de depuración existe antes de activarlo/desactivarlo para garantizar que se le agregue el código de autenticación http.
  • Devuelve el tipo de caché correcto a la REST API. Ignorar el estado habilitado de supercaché. (#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

  • Corregido un error crítico que causaba que el desenlace se ejecutara en nulo al eliminar el plugin.

1.5.2

  • Agrega una barra inclinada a la ruta principal. Arregla problemas al buscar el archivo .htaccess.
  • Elimina WPCACHEHOME y WP_CACHE de wp-config.php cuando el plugin se desactive.
  • Comprueba que WPCACHEHOME es la ruta correcta en cada carga de la página de ajustes.
  • Carga el código REST API sin usar WPCACHEHOME.
  • Corregido el almacenamiento en caché del navegador móvil al usar el almacenamiento en caché de WP-Cache.
  • Arregladas las comprobaciones de directorio en máquinas con Windows.
  • Cambios de CDN revertidos en 1.5.0 por causar problemas en instalaciones anteriores de “WordPress en un directorio separado”.
  • Agregada una nota a la página de CDN cuando la url del sitio != home url. Los administradores del sitio pueden usar un filtro para ajustar la URL utilizada.
  • Stop preload quicker when requested while preloading taxonomies.
  • Agregada más información para cuando falla la actualización del archivo .htaccess.
  • “Served by” header is now optional. Enable it by setting $wpsc_served_header to true in the config file.

1.5.1

  • No usar funciones anónimas en REST API
  • Verifica que el Controlador REST API esté disponible antes de cargar la REST API.
  • No use funciones de cadenas multibyte porque algunos sitios no lo tienen activado.

1.5.0

  • Ajustes de variables REST API.
  • Página de ajustess simplificada.
  • Reorganizados archivos WP-Cache.
  • Almacenamiento en caché de más encabezados http.
  • Muchos errores corregidos.

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
  • Añadida corrección al personalizador #161 y no cachear las peticiones PUT AND DELETE #178
  • Comprueba si hay superglobales antes de usarlos. #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

  • Actualizada la página de ajustes para WordPress 4.4. Cambios de diseño.

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.
  • Añadida una función de desinstalación que elimina el archivo de configuración. La función de desactivación ya no la borra.
  • Ahora es posible desactivar el plugin sin visitar la página de configuración.
  • Arreglado el sistema de reconstrucción de caché. Los archivos de reconstrucción ahora sobreviven más tiempo que la solicitud que los genera.
  • Optimizaciones menores: prune_super_cache() sale inmediatamente si el archivo no existe. La salida de wp_cache_get_cookies_values() ahora se cachea.
  • Añadido PHP pid al registro de depuración para ayudar a la depuración.
  • Varios pequeños errores corregidos.
  • Corregido restablecimiento de hora de caducidad y configuración de RB al actualizar la configuración avanzada.
  • 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.
  • Ocultar archivos de caché si los servidores muestran índices del directorio.
  • Evita la inyección de objetos PHP mediante el uso de 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.
  • Correcciones menores.

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 admin bar 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 admin bar 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.
  • Se ha agregado “¿Cómo puedo hacer que ciertas partes de la página se mantengan dinámicas?” a preguntas frecuentes.
  • 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. Corregidos problemas con entradas y comentarios que no se refrescaban.

Meta

Valoraciones

Ver todas

Soporte

Problemas resueltos en los últimos dos meses:

14 de 55

Ver el foro de soporte