Steve McDougall zadał nam świetne pytanie na Twitterze na temat naszego przeprojektowania i ponownego uruchomienia Laravel News w Statamic:
Chciałabym przeczytać komentarz kogoś z zespołu @laravelnews o tym, jak przystosowali się do @statamic i co skłoniło ich do wybrania tego jako systemu CMS.Byłoby naprawdę interesujące zobaczyć, jak musieli się dostosować, i jakie nieprzewidziane korzyści mogliby znaleźć.
Odpowiedzi na te pytania nie zmieszczą się w tweecie, więc chciałem omówić każdy punkt i podzielić się nieco za kulisami, jak to wszystko się stało.
Dlaczego wybraliśmy Statamic
Miałem oko na Statamic od pierwszego uruchomienia. Patrząc na moją historię zakupów Statamic, jestem klientem od wersji 1, ale nigdy nie poczułem, że nadszedł właściwy czas, aby przeskoczyć z mojego starego systemu. Wszystko się zmieniło, gdy został wprowadzony na rynek v3 w zeszłym roku i przeniósł go do konfiguracji w stylu pakietu Laravel.
W wersji 3 można ją zainstalować z dowolną aplikacją Laravel, co oznaczało, że mogłem zachować wiele istniejącego kodu pomocniczego, który uruchamia Laravel News. Są to takie rzeczy jak sekcja linków, automatyczny codzienny biuletyn, zarządzanie kontem itp. Wiedza, że mogę zachować to wszystko i zyskać nowy panel sterowania do pisania i publikowania postów, była wielką wygraną.
Kolejną zaletą jest to, że Statamic pozwala mieszać i łączyć z bazą danych i plikami płaskimi. Mieliśmy już użytkowników w tabeli, ale mieliśmy dziwną niezgodność z naszym starym systemem, w którym mieliśmy autorów artykułów w dwóch systemach, tabeli naszego użytkownika i witrynie WordPress. Synchronizowałem je ręcznie, aby dopasować autorów, co sprawiło, że umożliwienie publikowania postów dla gości było dość trudne.
Poza tym zawsze chciałem, aby strona wykorzystywała społeczność Laravel w jak największym stopniu, a wspieranie twórców, którzy są naszymi także moimi rówieśnikami, było kuszące.
Jak przystosowaliśmy się do Statamica
Statamic był dla mnie procesem uczenia się i wciąż muszę się wiele nauczyć. Adaptacja była dość łatwa z punktu widzenia codziennych publikacji.
Wszystkie artykuły na stronie znajdują się w jednej kolekcji Statamic z około 14 różnymi zestawami pól dla każdego posta.
Wszystko to zasadniczo odpowiada temu, czego używaliśmy w WordPress dla starej witryny, więc aspekt publikowania niewiele się zmienił.
Zmienił się sposób przechowywania wszystkiego. Statamic daje Ci możliwość używania zwykłych plików lub bazy danych, a w naszej obecnej wersji używamy płaskich plików przecen. To ponad 2500 tylko dla samych artykułów i chociaż baza danych jest prawdopodobnie bardziej wydajna w naszej skali, Statamic ma kilka wbudowanych opcji buforowania, które sprawiają, że jest to kwestia sporna.
Korzystamy z ich systemu statycznego buforowania i jak to działa, gdy strona jest ładowana po raz pierwszy, przechowuje statyczny kod HTML plik, więc wtedy Nginx próbuje go obsłużyć, jeśli istnieje. Jeśli nie, tworzy plik i wyświetla go następnym razem. To sprawia, że wszystko szybko się rozjaśnia, gdy otrzymujesz wersję z pamięci podręcznej.
Oczywiście przy 2500 postach, kilkunastu kategoriach i mnóstwie tagów liczba generowanych przez niego plików statycznych jest dość duża. Nie jest to coś, co planujemy często usuwać, tylko wtedy, gdy musimy wprowadzić poprawki projektowe. Jednak podczas publikowania usuwamy niektóre krytyczne strony, takie jak strona główna i strona kategorii nadrzędnej.
Aby sparować ze statycznym buforowaniem w dowolnym momencie, gdy mamy sekcję witryny, która potrzebuje świeżych danych, używamy Alpine.js do pobrać dane. Na przykład pod każdą stroną ze szczegółami posta znajduje się sekcja, która pokazuje najnowsze posty.
Oto wewnętrzny kod Statamic Antlers w połączeniu z Alpine, który utrzymuje go w świeżości:
<ul x-data x-init="fetch('/ajax/latest').then(response => response.text()).then(html => $el.innerHTML = html)"
class="lg:gap-16 sm:gap-8 grid grid-cols-12 col-span-10 col-start-2 gap-6">
{{ collection:articles limit="3" :id:not="id" }}
{{ partial:articles/card class="text-white" }}
{{ /collection:articles }}
</ul>Domyślnie pozycje listy są wstępnie wypełniane najnowszymi danymi, gdy plik jest początkowo buforowany, ale tak szybko, jak to możliwe, jest to zastępowane „prawdziwym” najnowszym. W ten sposób posiada dane na wypadek niepowodzenia żądania.
Na koniec, na trasie ajax/latest, pobiera z dodatkowej pamięci podręcznej Redis. Więc nadal jest buforowany, ale nie na zawsze buforowany, jak strona posta.
Innym pakietem, z którego korzystamy, jest Alpine Turbo Links.To kolejny powód, dla którego witryna tak szybko przechodzi między stronami, a po zainstalowaniu Turbolinks automatycznie pobiera stronę, zamienia jej <body> i scala swój <head>, a wszystko to bez kosztów pełnego załadowania strony.
Jakieś nieprzewidziane korzyści?
Myślę, że jest jeszcze wcześnie, ale zauważyłem, że podoba mi się panel sterowania Statamic.
