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

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

Parecía que el json no estaba siendo almacenado en caché por wp-super-cache, pero decidimos adoptar un enfoque diferente. Al usar la API transitoria , pudimos hacer una caché falsa en todos los json y reducir drásticamente los impuestos de la base de datos. Luego, en el lado ajax de las cosas, estamos almacenando en caché el html que se crea a partir de este json semi-almacenado en caché. ¡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;

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".

NOTA DE SEGURIDAD: Esta (y las otras soluciones) no deben usarse a menos que tenga una forma de anular el Content-Type: text/htmlencabezado que WP Super Cache envía con el application/jsonvalor apropiado . Enviar JSON como text/htmlhará 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_REQUESTlugar 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' );

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.