En un nuevo proyecto, estamos usando wp-super-cache (el complemento preferido del cliente) para crear los archivos html estáticos para tipos de contenido personalizados. Pero estamos tratando de averiguar si todo se está almacenando en caché correctamente.
Esta es una pregunta de 2 partes.
1) El tema que hemos creado utiliza plantillas de página para generar json que se ingiere a través de llamadas ajax. es decir. si llega a la página: theurl.com/sample, obtendrá json puro. Si bien hay una versión que no es javascript de cada página y publicación, Ajax impulsa el front-end de este tema. Hemos eliminado el encabezado y el pie de página en estos archivos para que sea json puro, y estamos tratando de descubrir cómo determinar si el json se está almacenando en caché. En teoría, los datos se almacenarían en caché porque técnicamente es una página servida por WordPress. Pero, ¿cómo podemos saber si se está almacenando en caché?
2) Estamos utilizando el complemento json api para servir también ciertos datos de publicación. http://wordpress.org/extend/plugins/json-api/ Para este ejemplo, supongamos que estamos utilizando el método de salida predeterminado del complemento y estamos accediendo a esta página: my url.com/category/news?json=1 - Does Alguien sabe cómo podemos verificar si esta salida se está almacenando en caché? Si no se almacena en caché, ¿qué método haría que esto suceda?
Parece que no hay mucha información sobre esto en línea, así que en el espíritu de crear sitios de WordPress atractivos y optimizados, ayude a un hermano
WP Super Cache examina las páginas de su sitio de WordPress en busca de algunas etiquetas HTML antes de almacenarlas en caché.
Sus páginas probablemente no tengan
</html>
etiqueta (problema común), en ese caso, intente agregar algo como//</html>
eso es una solución, y WP Super Cache debería generar versiones en caché de sus páginas.¿Por qué WP Super Cache lo hace así? Vea, no hay una manera obvia de verificar si una página está cargada a medias, que verificar si todas las etiquetas HTML básicas existen y están cerradas correctamente.
En las propias palabras de Donncha (desarrollador de WP Super Cache) , "es para detener el almacenamiento en caché de las páginas medio generadas".
fuente
NOTA DE SEGURIDAD: Esta (y las otras soluciones) no deben usarse a menos que tenga una forma de anular el
Content-Type: text/html
encabezado que WP Super Cache envía con elapplication/json
valor apropiado . Enviar JSON comotext/html
hará que el navegador lo represente como HTML, lo que podría ser un vector XSS.Parece que eso debe hacerse en la capa del servidor, ya que WPSC no proporciona los enlaces necesarios.
Así es como lo hice. Es similar al enfoque de Liang, pero no requiere modificar el complemento directamente, y tiene un patrón de expresiones regulares más preciso.
Si está utilizando v2 de la API REST, debe usar en
REST_REQUEST
lugar deJSON_REQUEST
.Sería bueno suscribirse a 22 y # 79 en caso de que algo cambie en WP Super Cache.
fuente
XMLHttpRequest cannot load http://api.mywebsite.com/wp-json/wp/v2/posts. Origin http://mywebsite.com is not allowed by Access-Control-Allow-Origin.
¿cómo puedo solucionarlo?Access-Control-Allow-Origin
encabezado para permitir la solicitud de origen cruzado. Supongo que las páginas en caché no generan ese encabezado.También conocí este problema. Había escrito algo de mi código para ser API. Cuando el tipo de respuesta era XML, el caché funcionaba. Pero cuando el tipo de respuesta era json, no funcionó.
Me lleva algunas horas arreglar este error.
Esto es trabajo para mi.
Simplemente actualice su código como mis cambios.
Funciona para mi ahora.
fuente
wp_cache_eof_tags
filtro en lugar de modificar el complemento directamente.