La eliminación de caché HTML5 Boilerplate .htaccess no funciona con WordPress

3 minutos de lectura

los .htaccess configuración de caché para HTML5 Boilerplate (http://html5boilerplate.com/) son increíbles, pero tengo un problema con la configuración de eliminación de caché para las versiones de JS y CSS.

<IfModule mod_rewrite.c>
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule ^(.+)\.(\d+)\.(js|css|png|jpg|gif)$ $1.$3 [L]
</IfModule>

Parece que no puedo hacer que esto funcione con la configuración de reescritura de WordPress ya presente en el .htaccess expediente.

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
</IfModule>

En el mejor de los casos, la reescritura en mis archivos JS nunca sucede. En el peor de los casos, rompe el sitio.

¿Alguien tuvo suerte haciendo que esto funcionara con WordPress?

  • Así que han pasado seis meses. ¿Ni una sola respuesta? ¡Asombrado!

    – Chris Fernando

    8 oct 2013 a las 20:58

  • “En el mejor de los casos, la reescritura en mis archivos JS nunca sucede. En el peor de los casos, rompe el sitio”. Eso significa script.000.js -> 404 no encontrado; algo -> 500 error del servidor?

    – sam

    10/10/2013 a las 17:12


  • 3 cosas con las que jugar: 1-Desactive cualquier almacenamiento en caché de WP (JetPack). 2-Agregar rand var al final de JS/CSS a través de get param falsificará “nuevo archivo” y se eliminará el caché. 3-Recientemente (últimos 9-12 meses) he notado que los navegadores almacenan en caché MÁS DURO, especialmente cuando se usa JS moderno con uso de hash/#. (El hachís ahoga la recarga fresca). ¿Cuál es el escenario del caché? Tipo de desarrollo/producción/servidor local (nginx es diferente, por ejemplo).

    – Marc

    24/09/2014 a las 20:54


¿Puede hacer algunas configuraciones de php.ini incrustadas en su .htaccess y luego probar el sitio web en busca de cambios, solo para probar incluso si su archivo .htaccess funciona o no?

En la mayoría de los casos, he experimentado que hay algunos archivos ocultos que los sistemas basados ​​​​en CentOS 5.5 no muestran (no sé si ya se conoce el error). Pero si crea un nuevo archivo con el mismo nombre .htaccess, verá algunas líneas diferentes a la original.

Simplemente significa que ambos son dos archivos diferentes. Así que solo intente verificar cuál funciona con su sitio web. Además, para comprimir archivos JS y CSS, he escrito un tutorial bastante detallado aquí.
http://www.codeandcommand.com/web-based/how-to-optimize-joomla-3-x-pagespeed.html

avatar de usuario
Sam

  • Asegúrese de que sus URL de prevención de caché realmente coincidan con el patrón de reescritura (script.0.js)
  • Poner reglas de reescritura de cache-busting antes de de WordPress
  • Si puede acceder a la configuración del servidor y leer los registros, configure RewriteLog 2 (o superior) y luego mire los registros de reescritura. Son difíciles de seguir, pero pueden darte algunas pistas.
  • “En el peor de los casos, rompe el sitio”. Si eso significa que está recibiendo un error de servidor 500, verifique los registros de su servidor; le dirá si hay un ciclo de reescritura.

Cambiar la regla de WordPress a

RewriteRule ^[\w/-]+$ /index.php [L]

y ver si eso ayuda.

En el mejor de los casos, la reescritura en mis archivos JS nunca sucede.

¿Estás viendo la respuesta “no encontrada” de WordPress o la de Apache?

En el peor de los casos, rompe el sitio.

¿Error del servidor Apache o error de WordPress?

Prueba estos

<IfModule mod_expires.c>
  ExpiresActive off
</IfModule>
<IfModule mod_headers.c>
  Header unset Cache-Control
</IfModule>

¿Ha sido útil esta solución?