 OK, cześć, nazywam się Piotr Szarmach, jak widać na załączonym slajdzie. Obecnie jestem programistą w front-end, w firmie SMT1, która zajmuje się monitorowaniem social media. Z WordPressem jestem związany w sumie od wielu lat razem z Mariuszem Kasią, Rafałem, którego tutaj nie ma i Magdalemom też współorganizowałem lokalne word-upy w Trójmieście. A w tej prezentacji chciałbym Wam pokazać, jak można automatyzować proces tworzenia motywów, bardziej pod klientów, a nie pod repozytorium WordPressowe. I na początku mam pytanie do Was, czy ktoś z Was ogólnie tworzył już dewelopowałą motywę? On to sporo osób, spoko. Czy korzystaliście, dewelpując te motywy z takich narzędzi właśnie jak Webpack, Gulp? Dobra, preprocesory pewnie też. No i no i ekstra. Dobra, pierwszy slajd jest taki podstawowy, jak gdyby dewelopment motywów w najprostszej formie opiera się tak na dobrą sprawę o dwa pliki, IndexPHP i Style CSS. Wiadomo, w Style CSS zawieramy wszystkie instrukcje odnośnie kto stworzył ten motyw, na jakiej licencji, wszystkie style, a IndexPHP nazwijmy taką logiką, niestety wraz z widokiem. WordPress domyślnie posiada, jak gdyby swój standard znaczkodowania według jakich wytycznych mają być tworzone te motywy zarówno dla styli CSS-ów, JS-ów, jakich pH-ów, plików pH-owych. Wiadomo, jest to dosyć specyficzny standard, że tak powiem, w walidacji tych plików. I jeżeli ktoś się przejmuje tym, żeby motyw był w 100% napisany, tak jak twórcy WordPress-a w całości był napisany, to to jest pierwsza rzecz, jaką możemy sobie zautomatyzować, czyli automatyczna walidacja kodu. Także by narzędzie, które nam to kąpiluje, transpiluje czy parsuje jakkolwiek, mówiło nam, że słuchaj w tej linice coś jest źle, że to naprawić albo możemy to automatycznie fixnąć za ciebie. Motyw składa się ze styli, wiadomo. Jak gdyby stylem wynikowym jest plikstyle.css, który zawiera wszelkie definicje tego, jak nasz motyw ma wyglądać. Jednakże pod spodem, używając troszkę bardziej nowoczesnego podejścia niż takie klasyczne, korzystamy z preprocesorów. Cielimy sobie pliki najlepiej na jakieś mniejsze części, które później są całością tego naszego pliku style.css, czyli mamy kąpilację. I najlepiej, jeżeli wysyłamy już na produkcję taki motyw, to robimy minifikację. Żeby wiadomo, był jeden request, którego w czytanie zajmuje jak najmniej czasu. I tutaj również, to jest jak gdyby proces, automatyczne importowanie styli, kąpilowanie tych styli, połączenie wszystkich styli w plik wynikowy i minifikacja pliku wynikowego. I tutaj jak gdyby również mamy pole do popisu dla automatyzacji, czyli automatyczne importowanie, tak żebyśmy nie musieli każdej definicji pliku za każdym razem dodawać, tylko żeby na rzędzie nam globalnie szczytywał te wszystkie pliki, kąpilowanie i minifikowanie stylów. Idąc dalej, mamy JS-a, wiadomo. Zaurze się, że 99% projektów, które jako programiści frontend tworzycie, składają się z plików JS-owych. Oczywiście możemy użyć odskolowego podejścia z jQuery i to wszystko będzie działać. Jednakże obecny stak technologiczny wygląda trochę inaczej. Raczej staramy się pisać w minimum s6c, a jak każdy z was pewnie wie, albo zaraz się dowie, takie pliki nie są rozumiane z reguły przez przeglądarki. Trzeba je transpilować, najlepiej nie wiem, przez babela albo jakieś inne narzędzie, które lubicie, które korzystacie tak, aby przeglądarki mogły zinterpretować poprawnie te pliki i wyświetlić użytkownikowi daną zawartość. Również, jeżeli byśmy mieli za każdym razem odświeżać przeglądarkę po każdej zmianie JS-owej i sprawdzać w konsoli, czy wypluwają się jakieś błędy i to by było uciążliwe, więc możemy zautomatyzować kolejną rzecz, czyli automatyczna transpilacja z użyciem na przykład babela i powiedzmy możliwość wyplutowania będu w konsoli w terminalu bardziej. Kolejnym elementem, który według mnie wymaga automatyzacji, nie wiem jakie stosujecie też podejście do pisania motywów, ja akurat tworzę katalog ze źródłami, który później jest jakby kąpilowany, transpilowany ITP i trafia on do takiego katalogu produkcyjnego, więc kolejną rzeczą, którą można by tu zautomatyzować jest kopiowanie po prostu plików, wraz na przykład z możliwością optymalizacji obrazków, kompresji tych obrazków czy jakichkolwiek innych zadań, które potrafi wykonać takie narzędzie, czyli kolejna rzecz, którą możemy automatyzować, kopiowanie asetów, grafik i custom fontów ITP i TD. I teraz tak, również podczas tworzenia motywów nie wyobrażam sobie sytuacji, w której zmieniałbym na przykład coś w stylach i za każdym razem musiałbym się przeklikiwać na okno przeglądarki Command R czy Control R i musieć ogólnie odświeżać przeglądarkę, żeby zobaczyć efekt. Tak więc możemy skorzystać na przykład z takiego narzędzia Browser Sync, które automatycznie w momencie, kiedy ja wprowadzam jakieś zmiany, te zmiany są widoczne bezpośrednio w naszej ten placie. Tutaj widzicie, teraz zmień się kolor, potem zmieni się tło, potem trochę zmieni się treść tego tej strony i to wszystko dzieje się bez, jak gdyby przeładowywania witryny przeze mnie, tylko to robi narzędzie automatycznie. Jeżeli pracujecie na dwa monitory, to jest fajne. W jednym monitorze kot, w drugim przeglądarka. I to będzie fajnie działać. Czyli mamy automatyczne przeładowanie witryny wraz ze zmianami. OK, co chcemy w takiej sytuacji osiągnąć? Przede wszystkim chcemy przyśpieszyć nasz proces produkcji takiego motywu, developmentu, żeby było skalowalne, szybki, przyjemne, zachowując ogólnie przyjęte standardy, czyli piszemy zgodnie z S6, korzystamy z preprocesorów, ITP i TD. Pomóc nam, w tym mogą trzy narzędzia, webpack pierwszy, gult i joman. Jak gdyby joman trochę się różni od tych dwóch pierwszych, w sumie każdy od siebie się różni, ale joman jest totalnie czymś innym. I teraz tak, czym jest webpack? Webpack według definicji to jest tak zwany module bundler. Co to oznacza? Krótko mówiąc oznacza to tyle, że webpack potrafi przetworzyć ożyte moduły, ich zależności i wypluć nam, jak gdyby, statyczne asety. Potrafi również obsługiwać inne pliki niż JSy, tak jak to widzimy, na przykład sasy lesy. Jak gdyby z was robił sobie taką definicję ciężko konfigurowalnego narzędzia, chociaż od wersji 4 to się trochę zmieniło, już w sumie nawet nie musimy mieć defaultowego konfigur, żeby on działał. Tak na dobrą sprawę. Instalujemy go albo poprzez NPM, albo poprzez Jarno, obojętnie, kto co woli, to jest przykład z NPM. Jak gdyby command line interface instalujemy globalnie, natomiast samego webpacka jako dependencję devową. Na tym slajdzie mamy mniej więcej pokazaną strukturę, jak to działa. To jest z oficjalnej strony webpacka. Jest sobie plik JS, który posiada tam jakieś różne zależności i w efekcie dostajemy fajnie skompilowany, transpilowany kod statyczny. Tutaj jest przykładowy, taki prosty konfigur. Ogólnie konfiguracja webpacka jest, tak powiem, załatwiana przez plik webpack.config.js. Mamy cztery korowe podpunkty, czyli entry point, output, loaders i plugins. W entry point się wskazujemy, który plik ma być tym początkowym, od którego cała ta operacja ma się zaczynać. Oczywiście może być wiele entry pointów, to jak wolicie. Output, czyli tak na dobrą sprawę, gdzie te pliki mają trafić. Loaders można powiedzieć, że to jest coś takiego, co pozwala nam dać obsługę również innych typów plików, załóżmy TypeScripta czy cokolwiek innego. I plugins, czyli rozszerzanie tego webpacka. Teraz tak. Webpacka warto uruchamiać, jak gdyby jeżeli samego, bez innego narzędzia go uruchamiamy, to warto zawsze dodawać flag a watch, ponieważ wtedy on zawsze automatycznie widzi te zmiany, które my robimy w plikach. Jeżeli odpalimy webpacka raz, wpisując tą komendę do terminala, on nie będzie nam łączował, to zmiałem w pliku. I mniej więcej wygląda to tak. Wpisujemy sobie webpack z flagą watch. Ja teraz gdzieś tam w edytorze tekstowym, to było na defaultowej konfiguracji, zresztą tutaj żadnej konfiguracji nie pisałem, dlatego też jest system warning. Natomiast robię sobie jakieś zmiany w pliku index.js i webpack automatycznie widzi, że coś się dzieje i ten plik mi transpiluje. Więc mniej więcej tak to wygląda. Następnym narzędziem, który chciałbym Wam omówić, jest gulp. Gulp jest tak zwanym task runnerem. Jak gdyby jego zasada działania na tym, polega na tym, że definiujemy taski, które on później przetwarza. Możemy je na przykład kazać, compilować stylę, transpilować pliki JSowe. Ogólnie podobne operacje, jak webpack potrafi robić, ale to nie jest to samo. To jest ogólnie task runner. Jest on dużo też prostszy w konfiguracji. Również posiada dużo rozszerzalności, jeżeli chodzi o plaginy, podobnie do webpacka. Często bywa tak, że tak na dobrą sprawę nie potrzebujemy webpacka. Możemy skorzystać z gulpa i to na 100% wystarczy. Jego konfiguracja w najprostszej formie wygląda w taki sposób. Również instalacja przez MPM jak widzieliście. Wrzucamy sobie gulpa, na przykład rozszerzenie paczkę gulpsasa i piszemy sobie task o nazwie SAS, gdzie w funkcji ananimowej definiujemy, co ma się dziać tak na dobrą sprawę. Czyli patrzymy na katalog SCSS, wszystkie pliki SCSowe SAS bierzemy i następnie je kompilujemy do katalogu CSS. Również możemy dać takie polecenie gulp watch, gdzie podajemy ścieżkę, z którego mają być brane te źródła i następnie nazwę tasku, czyli będzie mniej więcej podobne działanie, jak w przypadku webpacka. On będzie też automatycznie obserwował te pliki pod kątem zmian i wykonywał te taski, które my definiujemy. Gulpa uruchamiamy w taki sposób albo gulpa, wtedy musimy mieć task o nazwie default, żeby to zadziałało, albo gulp i nazwa taska, wtedy oczywiście otwali się odpowiedni task. I jak to wygląda, mamy pokazane na tym oto slajdzie również się spisywane polecenie gulp SAS. Dostajemy informację, że on zaczyna ten plik podglądać, że tak powiem obserwować. Ja prowadzę zmiany w edytorze kodu i to wszystko jest automatycznie kompilowane. Tak więc nie musimy za każdym razem wpisywać polecenia gulp i czekać, aż to się wykona. Wprowadzamy zmiany w SAS i znowu wykonujemy to polecenie. Możemy to sobie zautomatyzować. Kolejnym narzędziem jest Joman. Joman jest tak zwanym generatorem kodu. Podzwala on nam stworzyć jakby goły projekt na podstawie generatora, który jest udostępniony w repozytorii Miomana. Na przykład jeżeli chcemy sobie postawić szybko jakiś projekt reaktowy i nie chcemy zaciągać tych wszystkich paczek, tworzyć pakiet Jasona, to po prostu używamy odpowiedniego generatora z Joman'a. Instaluje się go również poprzez MPMA. Najlepiej globalnie, żeby mieć dostęp do tej komendy ją. I w kontekście WordPressa, tak na dobrą sprawę, wtropiłem na bardzo dobry generator Heasel od firmy X5, który okazuje się, że również posiada biuro w Krakowie, o czym dowiedziałem się całkiem niedawno. Heasel pozwala nam tak na dobrą sprawę postawić WordPressa w kilka sekund, dosłownie powiedzmy dwie minuty na dobrą sprawę. Jest on z nowoczesnym stakiem technologicznym. Czyli mamy tam webpaka spiętego w gulpanie, trzeba tego konfigurować, to wszystko już jest fajnie spięte. Również możemy pisać albo w S6, albo w jQuery, jeżeli ktoś lubi tak oldschoolowo sobie popisać. Jest również wydzielenie logiki od widoków, czyli nie mamy czegoś takiego, że wszystko leci do plików pechapowych i tam jest pomieszanie jedno wielkie. Tylko jest tam użyta tyczka Timber, korzystamy z Twig'a. Również cały pechapowy kod jest napisany obiektowo, więc możemy sobie rozszerzać dowolne klasy, jeżeli to potrzebujemy. I też jest dbanie o dobry kod, zgodny z wytycznymi, czyli w momencie, kiedy budujemy wersję produkcyjną, uruchamia nam się ESLint, CSSLint i tym podobne narzędzia, i one weryfikują, czy nasz kod jest na pewno ok. Oczywiście te konfiguracje możemy sobie zmieniać i musimy się ich sztywno trzymać, więc możemy tam jakby swoje zasady zainplementować. Teraz chciałbym Wam pokazać, jak wygląda ten konfigurator Heasel'a. Wszystko odbywa się poprzez terminal. Wykonujemy komendę i o, Heasel. Czekamy chwilę, aż to nam się wszystko odpali. Następnie podajemy nazwę projektu. Na przykład World Camp 2018 Poznań. Następnie autora. Możemy wybrać właśnie albo frontendową templatkę, albo WordPressowy site. Więc jak gdyby są też dwie możliwości. My się skupimy na tym WordPressowym site. Możemy zainkludować jQuery tak jak Wam powiedziałem. I teraz przechodzimy do tych wszystkich pól, tak na dobrą sprawę mamy w klasycznym instalatorze WordPressa. Czyli podajemy title, podajemy URL-a, jak gdyby definiujemy nazwę użytkownika admina, hasło, maila i tego typu rzeczy. Też bardzo, to jest ważna opcja. Możemy zdefiniować, gdzie są te sourcy naszej templatki, czy one są obok WordPressa, czy one są bezpośrednio w katalogu motywów. Szczerze mówiąc zawsze wybieram, jednak było to rozdzielenie tak na dobrą sprawę. I w momencie, kiedy już uzupełnimy te wszystkie informacje, które są niezbędne, co tak na dobrą sprawę się stanie. Tu jeszcze możemy wybrać sobie plaginy, które będą pre-installowane, oprócz Timbera i Disabled Emoji i właśnie z tej listy jeszcze możemy jakieś wybrać. I teraz tak. Heasel zaciąga nam zawsze najnowszą wersję WordPressa w WP-celi. Więc zawsze będziemy mieli gwarancję tego, że nie korzystamy z jakiegoś starocia, tylko to, co pojawiło się w repo, będzie zaciągnięte. Zaciąga on sobie wszystkie narzędzia, webpackowe, gulpowe, które są, jak gdyby użyte w tym projekcie, tworzy sobie wszystkie, znaczy instaluje te wszystkie dependencje, linkuje sobie to wszystko. I po chwili tak na dobrą sprawę mamy już gotowy projekt, wystarczy sobie odpalić komendę NPM Randev i łącznie z browser synkiem, z ką pilowaniem CSS-ów, transpilowaniem JS-ów, on to wszystko już ma. Więc my dosłownie w przyciągu dwóch minut jesteśmy w stanie stworzyć jak gdyby taki boilerplate, na którym możemy dalej pracować. I tutaj informacja, że wszystkie wtyczki są poprawnie zainstalowane, całość się udała. Tak więc bardzo, bardzo dobry narzędzie. Gdyby struktura katalogów wygląda w taki sposób. Po lewej stronie mamy source typowo frontendowe, natomiast po prawej stronie jest domyślna templatka z podziałem właśnie klasy pch-owe, templatki napisane w twigu i pliki już tak stricte u wordpressowe typowowe. Co też jest, tutaj jeszcze mogę Wam pokazać trzy polecenia, które sobie gdyby w tym Hizelu już w pakiet JSON-ie napisane, jest to npm Randev, lint i build. Lint służy do walidacji kodu, def jak gdyby do developowania, nazwijmy to tak, a build już do wyplucia wersji produkcyjnej. I jak wygląda tak na dobrą sprawę, development w Hizelu. Wrzucamy sobie na terminalu te polecenia, npm Randev. Mamy informacje, że pod naszym lokal hostem jest jest już gotowy projekt. Wchodzimy sobie założmy na index i teraz tak, tutaj nie widać niestety edytora, bo jak gdyby ekran prezentacji nie był tak duży. Ja w tym momencie wprowadzam zmiany w edytorze i widzimy zarówno na konsoli, że nasze zmiany zostały za aplikowane, style watch zobaczył te zmiany, przeładował nam browser synkiem naszą stronę i mamy proces developmentu totalnie zautomatyzowany. Nie musimy nic tutaj konfigurować, prekonfigurować, wszystko mamy już prekonfigurowane. Jeżeli na przykład chcemy sobie zbudować już taki projekt, robimy npm run build, żeby na przykład wysłać na server produkcyjny do klienta ja specjalnie w tym projekcie zrobiłem też kilka błędów w csesie, one zostały wylogowane na konsoli, to są ładninki, więc gdyby one nie blokują procesu budowania, natomiast mamy informacje, że słuchaj, możesz to jeszcze poprawić, bo to nie jest napisane zgodnie z wytycznymi w plikach konfiguracyjnych. Więc też czas na cold review troszkę zmniejszamy, bo już mamy te błędy tutaj i wygrami z to może sam je sobie poprawić. Łącznie z hezelem też jest taka fajna metodyka csesowa, która pozwoli nam jak gdyby uniknąć tego typu egzystencjalnych rozterek. Specificity. No czasami niestety selektory są wpisane w dosyć dziwny sposób, obliczyć specificity, z kalkulatorem. Natomiast w hezelu mamy coś takiego jak itcss niektórzy to wymawiają itz Ostatnio się dowiedziałem. Ogólnie założenia są takie, że mamy odwrócony trójkąt, to jest właśnie inverted triangle cses, mamy odwrócony trójkąt, na którego jak gdyby górnej podstawie is rich, na lewym boku mamy specificity i na prawym boku nazwijmy tu jakby dokładność elementu explicitness, taką szczegółowość powiedzmy. Zaczynamy, dzielimy klik i tak na dobrą sprawę na siedem warstw siedem katalogów, gdzie umieszczamy konkretne, konkretne style. So settings, czyli definicję kolorów, definicję zmiennych, definicję, nie wiem gridów, jeżeli korzystamy jakiegoś tam piszemy własnego grida wszędzie tam są te definicje. Następnie jest warstwa tools, która odpowiada za wszelkie funkcje mixiny i tego typu rzeczy ogólnie to warstwa nie wypluwa żadnego csesa, tak jak pierwsza i dopiero w trzeciej warstwie generic, mamy pliki jak gdyby normalizujące, resetujące, to jest pierwsza warstwa która ogólnie wypluwa jakiegokolwiek csesa i zobaczcie, że ona ma dosyć duży zasięg w tym trójkącie. Następnie elementy, są to nazwijmy natywne elementy htmlowe, typu h1, ul, li itp, itd je sobie stylujemy jak gdyby globalnie następnie są obiekty, warstwa obiektów, czyli tutaj możemy powiedzieć że będzie to chociażby grid wszelkie jak gdyby kontenery które definiują strukturę naszych styli są wrzucane do tego katalogu później po obiektach jest główna, tak na dobrą sprawę można powiedzieć warstwa, komponenty tutaj dzieje się najwięcej cały user interface jest właśnie wrzucany do komponentów a na samym końcu z najmniejszym richem ale jak gdyby z największym specificity są utilities lub trumpy bo też tak, widziałem, że ktoś definiuje to ostatnią warstwę tam są z reguły takie helpery typu jak na przykład w bootstrapie pool, left, pool, right które napisują wszystko najczęściej z importantem i tak tutaj to wygląda jeszcze jak gdyby w teorii takiej totalnej i również korzystając z tego ITCSa możemy poniekąd sobie automatyzować proces developmentu ja osobiście korzystam zarówno z tej metodyki jak i z demo łączę to sobie i według mnie osobiście jest dużo lepiej, dużo łatwiej pisać tego typu style niż jakbyśmy mieli w jakiś odskólowy sposób podchodzić bez żadnej metodyki do tego jak to wszystko ma wyglądać więc polecam Wam Hizela polecam Wam różne inne generatory które możecie znaleźć na Jumenie bo jest ich sporo, ponad 7000 tak na dobrą sprawę korzystajcie z webpacka i z grupa dzięki wielkie za uwagę i ostatni slajd się nie pokazał ok, dziękuję