Comment mettre en cache json avec wp-super cache

Dans un nouveau projet, nous utilisons wp-super-cache (le plugin préféré du client) pour créer les fichiers html statiques pour les types de contenu personnalisés. Mais nous essayons de déterminer si tout est correctement mis en cache.

Il s'agit d'une question en deux parties.

1) Le thème que nous avons créé utilise des modèles de page pour sortir json qui est ingéré via des appels ajax. c'est à dire. si vous accédez à la page: theurl.com/sample - vous obtiendrez du json pur. Bien qu'il existe une version non javascript de chaque page et publication, Ajax pilote le front-end de ce thème. Nous avons supprimé l'en-tête et le pied de page de ces fichiers afin qu'ils soient purement json, et nous essayons de déterminer comment déterminer si le json est mis en cache. En théorie, les données seraient mises en cache car il s'agit techniquement d'une page servie par wordpress. Mais, comment pouvons-nous savoir s'il est mis en cache?

2) Nous utilisons le plugin json api pour servir également certaines données de publication. http://wordpress.org/extend/plugins/json-api/ Pour cet exemple, disons que nous utilisons la méthode de sortie par défaut du plugin et que nous voyons cette page: mon url.com/category/news?json=1 - Est-ce que quelqu'un sait comment nous pouvons vérifier si cette sortie est mise en cache? S'il n'est pas mis en cache, quelle méthode y arriverait-il?

Il ne semble pas y avoir beaucoup d'informations à ce sujet en ligne, donc dans l'esprit de créer des sites wordpress convaincants et optimisés, aidez un frère

Il est apparu que le json n'était pas mis en cache par wp-super-cache, mais nous avons décidé d'adopter une approche différente. En utilisant l' API transitoire , nous avons pu faire un faux-cache sur tous les json, et réduire considérablement la taxation de la base de données. Ensuite, du côté ajax, nous mettons en cache le code HTML créé à partir de ce json semi-mis en cache. Les choses sont super rapides! Voici une version réduite du code et du concept.

    $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 examine les pages de votre site WordPress à la recherche de certaines balises HTML avant de les mettre en cache.

Vos pages n'ont probablement pas de </html>balise (problème commun), dans ce cas, essayez d'ajouter quelque chose comme //</html>- c'est une solution de contournement, et WP Super Cache devrait alors générer des versions mises en cache de vos pages.

Pourquoi WP Super Cache le fait-il comme ça? Vous voyez, il n'y a pas de moyen évident de vérifier si une page n'est qu'à moitié chargée, que de vérifier si toutes les balises HTML de base existent et sont fermées correctement.

Selon les propres mots de Donncha (développeur de WP Super Cache) , "c'est pour empêcher la mise en cache des pages à moitié générées."

NOTE DE SÉCURITÉ: Ceci (et les autres solutions) ne doit pas être utilisé sauf si vous avez un moyen de remplacer l'en- Content-Type: text/htmltête que WP Super Cache envoie avec la application/jsonvaleur appropriée . Envoi de JSON en tant quetext/html que le navigateur le rendra en HTML, qui pourrait potentiellement être un vecteur XSS.

Il semble que cela doit être fait au niveau de la couche serveur, car WPSC ne fournit pas les hooks nécessaires.

C'est comme ça que je l'ai fait. C'est similaire à l'approche de Liang, mais ne nécessite pas de modifier directement le plugin, et a un modèle d'expression régulière plus précis.

Si vous utilisez la v2 de l'API REST, vous devez utiliser à la REST_REQUESTplace de JSON_REQUEST.

Ce serait bien de s'abonner à 22 et # 79 au cas où quelque chose changerait dans 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' );

J'ai aussi rencontré ce problème. J'avais écrit un peu mon code pour être API. Lorsque le type de réponse était XML, le cache fonctionnait. Mais lorsque le type de réponse était json, cela n'a pas fonctionné.

Il me faut quelques heures pour corriger ce bogue.

C'est du travail pour moi.

Mettez simplement à jour votre code comme mes modifications.

Ça marche pour moi maintenant.