 Widzę, że się schodzi publika. Bardzo mnie to cieszy, pomimo tej godziny późnej w tym ostatnim dniu. Myślałem, że już wszyscy się zawinęli, ale widzę, że po obiadku wszyscy na jedzenie, więc świetnie. No tak jak już zostało wspomniane, dzisiaj jestem z tematem prezentacji apropo junipera, lub jak to woli junipera po angielsku. Jest to nasz open-source boilerplate. No więc tak, nazywam się Bartek i pracuję jako technika Litwosom Studio. Przyszedłem dzisiaj, aby podzielić się z wami technikami i różnymi trikami, które wypracowaliśmy przez ostatnie lata w Osomie, jako cały team. I sądzę, że one mocno automatyzują i usprawniają pracę naszego zespołu. Więc może przejdźmy już do Meritum. Wydaje mi się, że każdy z WordPress Developer przechodzi przez taki etap swojej ścieżki kariery, gdzie jest freelancerem. I wtedy nie do końca wiemy, czy ten kod, który wypuszczamy do klienta, jest poprawnym kodem. Nikt nie sprawdza, nikt nie robi nam code review, nikt nie marzuje naszych pooly requestów. Może wtedy zapanować pewien chaos, bo wszystko to, co mamy na staku, to wierzymy w to bez większego sprawdzania. No i załóżmy, że siadamy do jednego z naszych pierwszych projektów i musimy przechodzić przez to całe flow. Tego, jakie tule dobrać, jak postawić lokalne środowisko, czy będziemy korzystać z jakiegoś środowiska gotowego, czy będziemy stawiać osobno Apache, Nginx, jak będziemy wysyłać pliki na Repozytorium, czy będziemy tam przetrzymywać całego WordPressa, czy będziemy przetrzymywać plaginy. No wtedy oczywiście mamy problemy również z aktualizacją tych plaginów, no bo niektórzy mogą spólować, niektórzy nie. Chcielibyśmy wypuścić na środowisko docelowe. Ustalamy też, jak będziemy przechowywać pliki w samym katalogu motywu, czy będziemy wszystko wrzucać do Functions PHP. No wypadałoby jednak tego unikać z uwagi na to, że, no wiecie, posiadanie 8 tysięcy linii w pliku Functions PHP ze wszystkimi cppk i innymi rzeczami potrzebnymi w projekcie nie jest zbyt dobrym rozwiązaniem. Ustalamy sobie, jak będziemy przechowywać pliki w tym katalogu, więc tworzymy sobie osobny folder dla inkludów. Tam sobie oczywiście wszystko rekuajrujemy. No nie jest to też najlepsze rozwiązanie. Myślimy też na tym, jaki bundler użyć. Czy będziemy korzystać z jakiegoś webpaka, jak będziemy kąpilować pliki SCSCJS, czy będziemy używać zwykłego watchera w naszym, na przykład PHP Stormie albo Visual Code Studio. No schodzi na to od groma czasu i powoduje dość duży problem, który są to po prostu czynniki chaosu. A co gorsza, jeżeli mamy tych projektów sporo, no to za tydzień już po oddaniu projektu nie będziemy pamiętać o tym, jakie przyjęliśmy podejście przy tym kodowaniu. Jeśli mamy w zespole kilku deweloperów, no to kilkadziesiąt projektów nam to pewnie robi no i przy maintenance każdy deweloper musi zostać wdrożony w projekt i może być to uciążliwe, bo stracimy strasznie dużo czasu na zapoznawanie się poszczególnych członków zespołu z projektami. Nikt nie wie gdzie szukać tych plików, czy faktycznie muszą przegrzybywać cały plik functions, czy czym już mogą udać się do stworzonego wcześniej katalogu. Ja również, tak jak każdy z mojego zespołu, na początku mierzyliśmy się oczywiście z tymi problemami, no ale później postanowiliśmy usiąść i obgadać, jak możemy to wszystko zautomatyzować i optymalizować i tak właśnie powstał Uniper, albo jak to woli po angielsku Juniper i opracowaliśmy to środowisko patrząc na trzy główne grzechy deweloperów. Straliśmy się je poskromić. No i teraz je właśnie przedstawię. Pierwszym grzechem głównym, na który wpadliśmy, było ładowanie plików JS i CSS w niepoprawny sposób. Błędna konfiguracja naszego bandlera, który obraliśmy wcześniej przy wybieraniu toolów, może powodować, że w naszym PageSpeed Insight będziemy mieli problemy. Jak widzicie tutaj na górnym screenshotie jest możliwość uzyskania lepszych wyników. Jeżeli ograniczymy ładowanie nieużywanego drzewa scriptu, problem ten występuje wtedy, kiedy wrzucamy wszystkie pliki JS do jednego pliku. Nie potrzebujemy na przykład validacji kontaktforma, jeżeli ten kontaktform na danej stronie w ogóle nie istnieje. Na dolnym screenshotie widzicie, jak my to rozegraliśmy. Czyli mamy osobne pliki JS, PHP, SCSS dla każdego z naszych bloków, które używamy w naszym boilerplate. Oczywiście możemy też osiągnąć ładowanie tych plików osobno, tak żeby wybrany przez nas bandlerze nie było tego problemu. No a nie mniej tutaj w naszym środowisku mamy to od razu i nie musimy nic z tym kombinować. Drugim grzechem głównym jest plik Functions PHP, tak jak wspomniałem zawiera on zbyt wiele linii kodu. Spotkałem się z projektami, gdzie tych linii było nawet ponad 2000. No i posiadanie zbyt dużej ilości kodu w tym pliku może powodować problem w utrzymaniu takiego kodu. Często taki problem występuje, gdy otrzymujemy projekt do maintenance. I kiedyś zapytałem jednego z developerów, czemu akurat cały ten kod pakuje do Functions PHP. Niestety nie potrafił wybrnąć z tego w żaden logiczny sposób. Powiedział, że tak nas tak Overflow powiedzieli, żeby wrzucić do Functions PHP, to on tam zapakował. Już lepszą opcją byłoby tworzenie tych osobnych plików pod dodawanie CPT-ków, robienie inkludów i functions. No nie jest to rozwiązanie idealne. Pokażę Wam na następnych slajdach, jak my to rozwiązaliśmy. Wydaje mi się, że nasze podejście na ten moment jest najlepsze, jakie mogliśmy wypracować. W naszym staku plik Functions PHP ma tylko 71 linii i to jest zupełnie wystarczające na ten moment. I ostatnim grzechem, głównym, który mamy jest brak porządku w folderze motywu. Jest on mocno powiązany z tym, co mówiłem przed firmą propos pliku Functions PHP. Jak widzicie na screenie, ktoś potworzył też osobne pliki dla funkcji np. od futera. No nie mniej wszystko jest znowu wrzucone do głównego folderu templatki. No i odszukanie tutaj jakiejkolwiek funkcjonalności wiąże się z tym, że musimy przeszukiwać cały projekt. No nie możemy się łatwo połapać, w którym pliku będzie dana funkcjonalność. I jak widzicie, wygląda to tak u nas. Dla każdego bloku mamy te cztery pliki, które widzicie na lewym screenshotie. Pośrodku mamy stworzony katalog inklud i w środku są również poszczególne katalogi odpowiadające naszym blokom, kastą postajpom i taksonomiom oraz adzaksowi, jeżeli jest konieczny w danym bloku. I też dla każdego z bloków posiadamy pliki tweak i do czego one służą i jak na nich działamy to też zobaczycie na przyszłych slajdach. A więc grzechy główne mamy załatwione. Teraz możemy przejść do tuli, jak ich używamy w naszym staku. Więc czym dokładnie jest Uniper? Uniper to jest open source oprogramowanie, który jest głównie zbudowany właśnie z Bedrocka, Timbera, ACF Timber Blocksów i wielu innych narzędzi, które ułatwiają życie programistom. Usiedliśmy na chwilę i zastanowiliśmy się, co możemy zautomatyzować w naszym staku. W każdym projekcie mieliśmy do czynienia z dynamicznymi treściami. Był zazwyczaj gutemberk, więc mogliśmy to założyć, że tak będziemy tworzyć projekty. Musieliśmy tworzyć niestandardowe typy wpisów i niestandardowe taxonomie, które też przypisywaliśmy do tych naszych custom post typeów. Ostatnią rzeczą, którą mogliśmy zautomatyzować oczywiście po tworzeniu tych wszystkich wymienionych przeze mnie wcześniej rzeczy, jest stawianie projektu. Chcieliśmy mieć tam coś w stylu Wizzarda, w stylu Instalatora, który przy użyciu tylko kilku poleceń będzie w stanie wygenerować nam plik ENV, który jest wymagany w Bedroku tak, aby to działało. Tam definiowane są wszystkie zmienne, środowiskowe, coś, ale WP Config w Vanilla WordPressie. Teraz sądzę, że powinniśmy przejść przez każdy z tych tuli i opowiedzieć o nim pokrótce, bo czas też nas goni. Zacznijmy od Bedroka. Bedrok sam w sobie jest również opensource-owym boilerplate, szablonem startowym. Zarządzanie z innymi jest tutaj właśnie bardzo proste z uwagi na ten plik ENV, o którym już wspomniałem. No i to, co jedna z ważniejszych funkcjonalności Bedroka to kompozer. Przy użyciu kompozera możemy ściągać WordPressa, możemy ściągać również przy użyciu WP Packagista plaginy w odpowiednich wersjach, też bardzo polecam tego tula. I wtedy przy użyciu tych kompozera i WP Packagista nie musimy zupełnie martwić się o to, czy przechowywać plaginy i sam core WordPressa na naszym repozytorium. W połączeniu z budyń oznaczę to, że mamy kompletną automatyzację, oczywiście można też użyć innego, to jest ICD. Niemniej my działamy na budyń, mamy również dla niego potworzone pliki YAML, które nam ułatwiają pracę. I wtedy jesteśmy w stanie jakby upewnić się, że wszyscy z naszego teamu, wszyscy uczestnicy projektu będą na tym samym etapie, czyli wszyscy będą mieli te same plaginy, nie będzie problemów z kompatyjbilnością. Oraz to, że na serwer stagingowy bądź też produkcyjny wyślemy kod, który przetestowaliśmy lokalnie, idealnie w tej samej wersji. Przechodząc do Timbera, prawdopodobnie niektórzy z was już korzystają z jakiś kastomowego systemu szablonów. W WordPressie na przykład mamy Sage, w którym mamy blady pożyczone od Laravela. W Uniperze wybraliśmy Twig, który jest również na przykład w symfonie dostępny. Dlaczego Timber? Akurat zamiast Sage. Twig jest tutaj taki bardziej strict bym nazwał, a naprawdę chcemy mieć podejście w naszym bolie Playcie w stylu MVC. Dlatego nie można tutaj wklejać kawałków kodu PHPa w pliki Twigowe. Jest to na pewno bardziej utrudnione. Oczywiście możemy tam próbować jakieś sety ustawić, ale lepiej wszystko robić po stronie PHPa. I tak jak tutaj widzicie na screenshotie, możemy w bardzo prosty sposób przekazywać zmienne do naszego pliku Twig. Na początku generujemy sobie kontekst, pobieramy sobie kontekst, który już mamy, potem tworzymy nowy obiekt posta i przekazujemy post do kontekstu, a następnie rendurujemy zadaną templatkę, więc plik PHP dla naszej templatki wygląda dość prosto. Jak tutaj możecie zauważyć, mamy templatkę Twigową. Po wszystkich tych krokach możemy sobie spokojnie ją wyrenderować. I będziemy tam mieli dostępny cały szablon z kontekstem. Szablon w PHPa na pewno nie byłby tak czytelny i moglibyśmy mieć problem z późniejszym maintenanceem. Przypuszczam też, że możemy założyć, że każdy z naszych klientów potrzebuje mieć w pełni edytowalny motyw. Prawdopodobnie większość z was używa jakichś niestandardowych motywów, z jakimś flexible contentem albo pewnego rodzaju custom meta boxami. Właśnie w tym momencie jest pomocą przychodzą nam ACF WP blocksy, które przy użyciu tylko kilku, jak widzicie na lewym skrzynszocie, linijek komentarza pozwalają nam tworzyć customowe bloki w plikach Twig. Tworzenie takiego bloku polega jedynie na utworzeniu tego Twig'a oraz przy pisaniu grupy pool do ACF-owych do tego bloku. Oczywiście wymagany jest ACF w wersji PRO, ale nie musimy zupełnie korzystać z React.js przy tworzeniu tych bloków. Wszystkie pola, które sobie przypisaliśmy w ACF-ie, są od razu dostępne w tablicy fields w naszym pliku Twig. Inną fajną rzeczą jest to, że możemy używać filtrów w PHP, utworzonym specjalnie dla tego bloku i zarządzać tam kontekstem tego bloku. Ale to nie wszystko. Jesteśmy programistami, jesteśmy leniwi. Nie chcemy ręcznie kopiować, wklejać, edytować tego komentarza. Wypadałoby to jakoś również automatyzować i utworzyć jakiś skrypt. Wpadliśmy na skrypty w baszu. I tak jak wspomniałem, stawiamy bardzo na automatyzację. Stworzyliśmy z tego, co pamiętam, 5 skryptów, które pomogą w konfiguracji projektu oraz w tworzeniu typów postów. Taksonomi i bloków w zaledwie kilku kliknięciach. Jak możecie zobaczyć na screenshotie u góry, jedyną rzeczą, którą musimy zrobić, aby stworzyć nowy post type jest wywołanie baszowego pliku cptsh. I musimy wpisać jedynie nazwę cpt, o których chcemy stworzyć. To wszystko. Po kliknięciu enter i już custom post type zostanie utworzony. Automatycznie pojawi nam się już w dashboardzie. Możemy to sprawdzić. Więc wszystko już mamy tam w naszym systemie do zarządzania treścią. Jak widzicie tutaj, taki plik został utworzony poprzez wpisanie zaledwie tych dwóch linii jak. Każdy członek zespołu będzie wiedział, w którym miejscu on się znajduje. Więc mamy tutaj ściśle określoną ścieżkę. I wszędzie wszystkie funkcjonalności, dotyczące tego cptk, powinny znajdować się w tym pliku, jako że jest on też napisany w formie obiektowej. Automatycznie jest ładowane z uwagi na to, że używamy PSR-4. Czyli nie musimy zupełnie go nigdzie inkludować. Mamy porządek również w naszym pliku functionsPHP. Wszystko za nas rozwiązuje kompozer z PSR-4. I jeśli chodzi o standardy kodowania, nie chcemy też walczyć o to, czy używamy spacji, czy tabulacji w naszych plikach, które kodujemy. Zazwyczaj powoduje to problemy w repozytorium. W momencie, gdy wysyłamy Merchley Quest i akurat developer miał ustawione u siebie lokalnie Beautifier na tabulacje, a wcześniej były to spacje, to widzimy edycję wszystkich linii kodu. Jest to mocno problematyczne, gdyż nie wiemy, który kod nawet mamy sprawdzać. Doszukanie się tego jest trudne. Dlatego wybraliśmy standard WordPress Extra wraz z PHP Code Snifferem. I mamy go również połączone z naszym repozytorium w GitHubie. Takie podejście daje nam pewność, że kod napisany przez jednego dewelopera będzie identyczny jak kod napisany przez drugiego dewelopera. I nie będzie mieli problemów w całej ścieżce naszego deploymentu. Nie będzie problemów z rozwikłaniem Merchley Quest. I jak możemy zauważyć na tym slajdzie prezentacji kod jest nieuporządkowany i trochę chaotyczny. W niektórych miejscach brakuje spacji, czy jest to widoczne, może być to ciężko, ale musimy zaufać, że w niektórych miejscach brakuje spacji między zmiennymi a nawiasami. Automatyzacja tutaj może zaoszczędzić nam wiele czasu, a my wiemy, że kod stworzony przez jednego z devów będzie identyczny jak kod od drugiego. Tutaj już wygląda to lepiej. No na pewno będzie łatwiej poruszać się po tym pliku. Nie będziemy też mieli jakby rozgardiaszu pomiędzy zmiennymi a funkcjami. Wiemy też, że na pewno stosujemy tutaj poprawne odstępy. I praktykujemy również podejście test-driven development, więc korzystamy z testów jednostkowych w PHP, ale chcieliśmy mieć coś bardziej nowoczesnego dla testów frontendowych. Więc zdecydowaliśmy się na Cypressa. W naszym staku jest dodany przykładowy script, który sprawdza, czy WPrest API jest blokowane. No nie chcielibyśmy mieć widocznych wszystkich użytkowników na naszych, z naszego portalu dla szerszej publiczności, więc wtedy musimy sprawdzać za każdym razem, czy na pewno nie został ten endpoint odblokowany. I co dokładnie osiągnęliśmy tworząc i używając Unipera i jakie korzyści mogą płynąć dla Was. No głównie jest to developer experience, a więc przede wszystkim osiągnęliśmy powtarzalność, automatyzację. No i jesteśmy pewni, że przenoszenie się między projektami nie sprawi bólu głowy poszczególnym developerom. Wiemy, gdzie szukać kodu, gdzie możemy utrzymywać wtyczki, jak aktualizować naszego WordPressa w określonym środowisku. No innym aspektem jest optymalizacja, o której wspomniałem na początku, dotycząca ładowania plików JS i CSS. Każdy nowy developer będzie wiedział, w jaki sposób to u nas działa. Nie ma potrzeby przeznaczać kolejne godziny na opisywanie struktury projektu dla pozostałych kolegów. Oczywiście wymagana jest dokumentacja tylko dla takich większych funkcjonalności, typu jakieś integracje zewnętrzne, ale w związaniu mamy już załatwione od razu from diskrat. I mam nadzieję, że dacie z szanse Uniperowi i przetestujecie takie podejście, jak my próbujemy to uzyskać. Oczywiście jest to open source, więc zachęcamy też do forkowania i dodawania swoich propozycji automatyzacji. I dzięki, śliczne.