Cómo almacenar en caché json con wp-super cache

13

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 mediante llamadas ajax. es decir. Si golpeas la página: theurl.com/sample, obtendrás json puro. Si bien hay una versión no javascript de cada página y publicación, Ajax controla el extremo delantero de este tema. Hemos eliminado el encabezado y el pie de página de estos archivos para que sea json puro, y estamos tratando de averiguar cómo determinar si el json se está almacenando en caché. En teoría, los datos se almacenarán en caché porque, técnicamente, es una página servida por wordpress. Pero, ¿cómo podemos averiguar si se está almacenando en caché?

2) Estamos utilizando el complemento json api para proporcionar ciertos datos de publicación también. enlace Para este ejemplo, digamos que estamos utilizando el método de salida por defecto del complemento y visitando esta página: my url.com/category/news?json=1 - ¿Alguien sabe cómo podemos verificar si esta salida se almacena en caché? Si no se almacena en caché, ¿qué método haría que esto sucediera?

No parece haber mucha información sobre esto en línea, por lo que, con el espíritu de crear sitios de wordpress atractivos y optimizados, ayude a un hermano

    
pregunta Starfs 26.04.2012 - 16:48

4 respuestas

9

Parecía que ws-super-cache no estaba ocultando el json, pero decidimos adoptar un enfoque diferente. Al utilizar la api transitoria , pudimos hacer un faux-cache en todo json, y reducir drásticamente los impuestos de la base de datos. Luego, en el lado ajax de las cosas, almacenamos en caché el html que se creó a partir de este json semi-cached. ¡Las cosas son súper rápidas! Aquí hay una versión reducida del código y el concepto.

    $transient_key = 'my-transient-key'; 
    $data = get_transient( $transient_key ); 

    if ( $data == '' ) { 
      $args = array(

    'post_type' => 'brand', 
    'posts_per_page' => 50

  );

  $postsArray = array();  
  // The Query
 query_posts( $args );

  // The Loop
  while ( have_posts() ) : the_post();

    $brand_id = get_the_ID();
    $slug = basename(get_permalink());
    $title = get_the_title();
    $description = get_the_content();

                $posts = array(

                   'brand_id' => $brand_id,
                   'machine_name' => $slug,
                              'postTitle' => $title,
                   'description' => $description,

                   );

    array_push($postsArray,$posts);


  endwhile;

   $data = json_encode($postsArray);


 set_transient( $transient_key, $data, 60 * 60 * 24 ); // one day
 }  // now all the brand information is cached as one table call.

echo $data;
    
respondido por el Starfs 09.05.2012 - 01:07
6

WP Super Cache examina las páginas de su sitio de WordPress en busca de algunas etiquetas HTML antes de que las almacene en caché.

Lo más probable es que sus páginas no tengan la etiqueta </html> (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í? Mira, no hay una manera obvia de verificar si una página está solo a medio cargar, que verificar si todas las etiquetas HTML básicas existen y están cerradas correctamente.

En Donncha's (desarrollador de WP Super Cache) propias palabras , "Es para evitar que la mitad de las páginas generadas se almacenen en caché".

    
respondido por el its_me 08.05.2012 - 03:55
3

NOTA DE SEGURIDAD: Esto (y las otras soluciones) no deben usarse a menos que tenga una forma de anular el encabezado Content-Type: text/html que WP Super Cache envía con el valor apropiado de application/json . Enviar JSON como text/html hará que el navegador lo muestre 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ás usando v2 de la API REST, deberías usar REST_REQUEST en lugar de JSON_REQUEST .

Sería bueno suscribirse a 22 y #79 en caso de que algo cambie en WP Super Cache.

/**
 * Tell WP Super Cache to cache API endpoints
 *
 * @param string $eof_pattern
 *
 * @return string
 */
function wcorg_json_cache_requests( $eof_pattern ) {
    global $wp_super_cache_comments;

    if ( defined( 'JSON_REQUEST' ) && JSON_REQUEST ) {
        // Accept a JSON-formatted string as an end-of-file marker, so that the page will be cached
        $json_object_pattern     = '^[{].*[}]$';
        $json_collection_pattern = '^[\[].*[\]]$';

        $eof_pattern = str_replace(
            '<\?xml',
            sprintf( '<\?xml|%s|%s', $json_object_pattern, $json_collection_pattern ),
            $eof_pattern
        );

        // Don't append HTML comments to the JSON output, because that would invalidate it
        $wp_super_cache_comments = false;
    }

    return $eof_pattern;
}
add_filter( 'wp_cache_eof_tags', 'wcorg_json_cache_requests' );
    
respondido por el Ian Dunn 31.12.2015 - 00:23
0

También encontré este problema. Yo había escrito algo de mi código para ser API. Cuando el tipo de respuesta fue XML, el caché funcionó. Pero cuando el tipo de respuesta fue json, no funcionó.

Me lleva algunas horas solucionar este error.

Esto es un trabajo para mí.

Solo actualiza tu código como mis cambios.

Funciona para mí ahora.

    
respondido por el Liang Rongze 07.09.2015 - 05:05

Lea otras preguntas en las etiquetas