Uważajcie na Foxhound – pierwszy motyw oparty na REST API trafił do oficjalnego repozytorium

Foxhound

Jestem wielkim fanem REST API w WordPressie. Jak już wielokrotnie pisałem, otwiera to przed tym CMSem zupełnie nowe możliwości i pozwoli wykorzystywać go w projektach, do których teoretycznie wcale się on nie nadaje.

Do przewidzenia było, że REST API zostanie wykorzystany również przez twórców motywów – i rzeczywiście, bardzo szybko powstało kilka takich tworów, które na szczęście nigdy nie stały się niczym więcej niż ciekawym eksperymentem. Teraz jednak sytuacja się zmieniła, ponieważ pierwszy motyw oparty całkowicie na REST API trafił do oficjalnego repozytorium WordPressa. Tworzy to niebezpieczny dla użytkowników tego CMSa precedens: do zaufanego repozytorium trafia motyw, który nie spełnia podstawowych wymagań narzuconych (słusznie zresztą) autorom przez zespół weryfikujący motywy. Wymagania te miały między innymi zapewniać kompatybilność ze wszystkimi poprawnie napisanymi wtyczkami – czyli coś, co w przypadku tego motywu jest po prostu niemożliwe.

Motyw, o którym mowa, nazywa się Foxhound i jest minimalistycznym, całkiem przyjemnym wizualnie motywem blogowym. Został stworzony z wykorzystaniem frameworka React i jest oczywiście „aplikacją jednostronicową” (Single Page Application).

Podstawy, czyli jak działa REST API

Jeśli już wiesz jak działa REST API, to możesz spokojnie pominąć tę część wpisu.

REST API to mechanizm (interfejs), który pozwala na dostęp do różnych danych znajdujących się w udostępniającym go systemie. W naszym przypadku chodzi oczywiście o WordPressa, z którego przez REST API możemy odczytywać na przykład treść wpisów czy stron, a posiadając odpowiednie uprawnienia również tę treść modyfikować.

Jedną z głównych zalet REST API jest fakt, że interfejs udostępnia „czyste” dane (a nie – jak w przypadku zwykłej strony – kod HTML odpowiedzialny za ich prezentację), dzięki czemu pobieramy tylko to, co jest niezbędne. Pobierając na przykład wpis otrzymujemy jego tytuł, adres URL, treść, datę publikacji, identyfikator autora i kilka mniej ważnych informacji, a to wszystko w formacie JSON (przykład). Od nas zależy, co z tymi danymi dalej zrobimy: możemy je zaprezentować na stronie albo w aplikacji mobilnej, ale możemy też wykorzystać je w zupełnie innym miejscu.

Jak działają motywy wykorzystujące REST API

Motywy korzystające z REST API (takie jak omawiany tutaj motyw Foxhound) są jednostronicowymi aplikacjami, które do generowania kodu HTML strony wykorzystują JavaScript (najczęściej w połączeniu z jakimś frameworkiem, na przykład React, AngularJS czy Vue.js). Ich „jednostronicowość” polega na tym, że gdy przechodzimy na kolejne podstrony serwisu (np. ze strony głównej na stronę wpisu), nie następuje przeładowanie strony, a jedynie „podmiana” jej zawartości. Wszystko to dzieje się po stronie przeglądarki – skrypt JavaScript pobiera dane z REST API i generuje z nich kod HTML, który wyświetla przeglądarka. Świetnie to widać na wersji demonstracyjnej motywu Foxhound.

Jak nietrudno zauważyć, przechodzenie pomiędzy podstronami jest niesamowicie szybkie. Dzieje się tak dlatego, że przeglądarka nie musi za każdym razem ładować całej strony (dokument HTML, skrypty JavaScript, arkusze stylów CSS, obrazki itp.) od nowa – ładowane są tylko dane z REST API. Oczywiście w normalnej sytuacji skryptów i arkuszy stylów nie trzeba za każdym razem pobierać z serwera, bo są one przechowywane w cache przeglądarki, ale mimo to przeglądarka musi je załadować, a następnie wykonać rendering całej strony.

Wady motywów wykorzystujących REST API

Oczywiście byłoby zbyt różowo, gdyby takie podejście do tworzenia stron internetowych miało same zalety.

Przede wszystkim takie strony nie działają jeśli w przeglądarce jest wyłączony JavaScript. O ile ludzi, którzy wyłączają w przeglądarce JavaScript, jest niewielu, o tyle możemy mieć problem z różnego rodzaju robotami, które zwykle (chociaż nie zawsze) nie wykonują w ogóle kodu JavaScript. Wyjątkiem jest robot Google, który potrafi interpretować kod JavaScript.

Tutaj jednak pojawia się kolejny problem – robot Google nie będzie czekał na dane, które strona doczytuje z REST API, co w efekcie spowoduje, że pobierze on pustą stronę. Czyli mówiąc krótko, takie strony nie są poprawnie indeksowane przez Google. Jeśli ktoś nie wierzy, to niech sprawdzi jak Google widzi demo motywu Foxhound (polecam obejrzenie kopii jakiejś podstrony w wersji tekstowej). Oczywiście istnieją na to sposoby, takie jak renderowanie stron po stronie serwera (Server-Side Rendering), ale nie jest to coś, czym mógłby i chciałby zajmować się przeciętny użytkownik WordPressa.

Kolejną wadą tego typu motywów są problemy z kompatybilnością z wtyczkami. Nie będą działać praktycznie żadne wtyczki, które dodają jakiś kod do strony. Nie ma oczywiście najmniejszych szans, aby z tego typu motywem działały bardziej rozbudowane rozszerzenia, takie jak na przykład WooCommerce. Moim zdaniem spokojnie można przyjąć, że z takim motywem większość wtyczek nie będzie działać poprawnie.

Do czego w takim razie może służyć REST API?

Jak już napisałem na wstępie, jestem wielkim fanem REST API. Miałem przyjemność pracować przy projektach, w których dzięki niemu wykorzystywano WordPressa w sposób naprawdę nietypowy. Nie ma problemu, aby z tego CMSa zrobić na przykład panel zarządzania treścią dla aplikacji mobilnej.

Na „zwykłych” stronach REST API również daje sporo możliwości. Ułatwia na przykład pobieranie danych do jakichś mniej istotnych fragmentów strony (np. lista popularnych wpisów) czy budowę mechanizmu doładowywania wpisów bez konieczności przeładowywania strony. Jednak w mojej opinii budowanie całych stron w oparciu o motyw pobierający dane z REST API nie jest dobrym pomysłem.

Bezpośredni link

  • Google nie ma problemów z indeksowaniem :-).
    Z resztą się zgodzę – motyw raczej w celach demonstracyjnych / szkoleniowych lub jako starter do własnych rozwiązań.

    • Zerknij (tak jak napisałem) na kopie stworzone przez Google.

      • Możliwe, że patrzymy na inne rzeczy lub coś przegapiłem?

        Sprawdziłem tagi, kategorie i posta. Description i title zgadza się z tym co pokazuje Google w SERPach.

        Poprawnie widzi też treści jak szukasz na stronie:
        site:…. „Fraza z txt dociaganego dynamicznie”.

        Bing i Yandex nie widzi strony, ale Google ma 100% postów razem z treścią.

        • Sprawdziłeś tylko w wynikach wyszukiwania, gdzie treść i tytuł prawdopodobnie pochodzą ze znaczników meta. Natomiast kopia strony pokazuje, jak robot Google widzi stronę (brak treści) – przykład: http://webcache.googleusercontent.com/search?q=cache:SEVzEbjaC9QJ:https://themes.redradar.net/foxhound/&strip=1

          • No ale dobrze widzi kopię.

            To jest etap harvesteowania kodu na ich wewnętrzne potrzeby. Zrzut kodu dla pozostałych ich botów. Widzisz kod strony przed przepuszczenim przez silnik chrome.
            Od dawna to tak działa bo ludzie kombinowali z DOM, CSS i js.

            Indeksowanie i Scoring itd jest po zinterpretowaniu tej kopi przez silnik. Ich silnik jest np w PHP v8js. http://php.net/manual/en/book.v8js.php
            To samo w Phantom i nodejs.

            Indeksuje w SERPach dobrze czyli ich silnik dobrze interpretuje ten zrzut kodu.

            A to, że kopia nie ma CSS to wina relatywnych URLi w skórce.

          • Tu nie chodzi o brak CSS, ale o brak treści.

            Widzę, że się nie dogadamy. Moja opinia jest taka, że strona, której treść jest w całości ładowana przez JS (czyli tak jak w omawianym przypadku), nie będzie w tej chwili całkowicie poprawnie indeksowana przez Google. Nie bez powodu deweloperzy w przypadku takich stron implementują server-side rendering. Problemem nie jest sam fakt interpretowania kodu JavaScript (bo z tym Google sobie radzi), ale konieczności oczekiwania na pobierane treści (asynchroniczne żądania AJAX).

          • Ok. Moim zdaniem
            Google widzi JavaScript bardzo dobrze.

            Porownujesz 2 różne etapy pracy Google – kod przed interpretacja, z kodem po interpreracji przez silnik Chrome.

            Taka zagwozdka czemu: biorąc którykolwiek fragment tekstu mogę go wygooglac, skoro Google​ go nie widzi.

            https://www.google.pl/search?newwindow=1&ei=f7HXWLzFJ-jv6QT9j7ioDQ&q=site%3Ahttps%3A%2F%2Fthemes.redradar.net%2Ffoxhound%2F+After+installing+the+theme%2C+double+check+that+your+permalinks+are+set&oq=site%3Ahttps%3A%2F%2Fthemes.redradar.net%2Ffoxhound%2F+After+installing+the+theme%2C+double+check+that+your+permalinks+are+set&gs_l=mobile-gws-serp.3…18284.18284.0.21431.2.2.0.0.0.0.0.0..0.0….0…1c.1j4.64.mobile-gws-serp..2.0.0.2zsQ8eWIPdg

          • Powtórzę jeszcze raz (ale naprawdę ostatni): nie chodzi mi o interpretowanie kodu JavaScript (to Google potrafi robić bardzo dobrze), tylko o pobieranie danych za pomocą asychronicznych żądań.

            Co do Twojego przykładu: nie zauważyłem tego wcześniej, ale autor umieścił w źródle strony dane dla pierwszego żądania, czyli prawdopodobnie zaimplementował coś na kształt server-side renderingu. Nie jest to jednak wystarczająco skuteczne – wyszukaj sobie w ten sam sposób fragmentu z dalszej części strony (np. „The theme does not display anything if javascript is disabled”).

  • Jakby ktoś był zainteresowany, to u siebie na blogu zamieściłem informacje odnośnie tego jak pobierać dane z WordPress REST API: http://blog.piotrnalepa.pl/2017/03/15/js-pobieranie-postow-typu-wlasnego-za-pomoca-wordpress-rest-api/

  • Zobaczę, co to jest za cudo :)

  • Carlito

    Bardzo dobry wpis; dzięki. Pomijając kwestie sporne odnośnie indeksowania to fajnie wyjaśniłeś ‚single page’ i użycie REST API.