Jak buforować JSona za pomocą wp-super cache

W nowym projekcie używamy wp-super-cache (preferowana wtyczka klienta) do tworzenia statycznych plików HTML dla niestandardowych typów treści. Ale staramy się dowiedzieć, czy wszystko jest właściwie buforowane.

To jest 2-częściowe pytanie.

1) Motyw, który stworzyliśmy, wykorzystuje szablony stron do generowania pliku json, który jest przyjmowany za pośrednictwem wywołań ajax. to znaczy. jeśli wejdziesz na stronę: theurl.com/sample - dostaniesz czysty json. Chociaż istnieje każda wersja strony i posta w języku innym niż javascript, Ajax obsługuje frontend tego motywu. W tych plikach usunęliśmy nagłówek i stopkę, aby był to czysty plik Json, i próbujemy dowiedzieć się, jak ustalić, czy plik Json jest buforowany. Teoretycznie dane byłyby buforowane, ponieważ technicznie jest to strona obsługiwana przez wordpress. Ale jak możemy dowiedzieć się, czy jest on buforowany?

2) Używamy wtyczki json api do obsługi niektórych danych postów. http://wordpress.org/extend/plugins/json-api/ W tym przykładzie powiedzmy, że korzystamy z domyślnej metody wyjścia wtyczki i odwiedzamy tę stronę: my url.com/category/news?json=1 - Czy ktoś wie, jak możemy zweryfikować, czy dane wyjściowe są buforowane? Jeśli nie jest buforowany, jaka metoda by to spowodowała?

Wydaje się, że nie ma zbyt wielu informacji na ten temat w Internecie, więc w duchu tworzenia atrakcyjnych i zoptymalizowanych stron Wordpress pomóż bratu

Wyglądało na to, że json nie był buforowany przez wp-super-cache, ale zdecydowaliśmy się na inne podejście. Korzystając z przejściowego interfejsu API , byliśmy w stanie zrobić faux-cache dla wszystkich plików Json i drastycznie zmniejszyć opodatkowanie bazy danych. Następnie po stronie ajax zbieramy w pamięci podręcznej plik HTML utworzony z tego częściowo buforowanego pliku Json. Sprawy są super szybkie! Oto zmniejszona wersja kodu i koncepcji.

    $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 sprawdza strony w WordPress pod kątem niektórych tagów HTML, zanim je buforuje.

Twoje strony najprawdopodobniej nie mają </html>tagów (częsty problem), w takim przypadku spróbuj dodać coś takiego //</html>- to obejście, a WP Super Cache powinna następnie wygenerować buforowane wersje twoich stron.

Dlaczego WP Super Cache tak to robi? Widzisz, nie ma oczywistego sposobu na sprawdzenie, czy strona jest w połowie załadowana, niż sprawdzenie, czy wszystkie podstawowe tagi HTML istnieją i są poprawnie zamknięte.

Własnymi słowami Donnchy (programisty WP Super Cache): „Ma to zatrzymać buforowanie w połowie wygenerowanych stron”.

UWAGA BEZPIECZEŃSTWA: Tego (i innych rozwiązań) nie należy używać, chyba że masz sposób na przesłonięcie Content-Type: text/htmlnagłówka wysyłanego przez WP Super Cache o odpowiedniej application/jsonwartości. Wysłanie JSON as text/htmlspowoduje, że przeglądarka wyświetli go jako HTML, który może potencjalnie być wektorem XSS.

Wygląda na to, że należy to zrobić na warstwie serwerowej, ponieważ WPSC nie zapewnia niezbędnych zaczepień.

Tak to zrobiłem. Jest podobny do podejścia Liang, ale nie wymaga bezpośredniej modyfikacji wtyczki i ma bardziej precyzyjny wzorzec wyrażenia regularnego.

Jeśli używasz v2 interfejsu API REST, powinieneś użyć REST_REQUESTzamiast JSON_REQUEST.

Dobrze byłoby zasubskrybować 22 i # 79, jeśli coś zmieni się w 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' );

Też spotkałem ten problem. Napisałem trochę mojego kodu jako API. Gdy typ odpowiedzi to XML, pamięć podręczna działała. Ale gdy typ odpowiedzi to Json, nie zadziałało.

Naprawienie tego błędu zajmuje mi kilka godzin.

To dla mnie praca.

Po prostu zaktualizuj kod, tak jak moje zmiany.

Teraz działa dla mnie.