Blog

Ghost CMS. Tworzenie własnego tematu. Wprowadzenie.

Pierwsza część serii wpisów na temat tworzenie własnego tematu na potrzeby Ghost CMS.

Ghost CMS. Tworzenie własnego tematu. Wprowadzenie.

Domyślny temat, z którym Ghost posadowi się na naszej maszynie, nazywa się Casper i jest on równie odkrywczy jak wybrana nomenklatura. Mnie akurat to nie przeszkadza, ponieważ nie lubię wodotrysków, które odciągają uwagę od samej zawartości, a zwłaszcza takich, które potęgują uczucie zagubienia. Ghost to platforma dla bloggerów w pierwszej kolejności, więc taki wybór dziwić nie może, choć rzecz jasna twórcy przewidzieli możliwość zaimportowania innego motywu, gdyby ich autorska propozycja nie do końca podpasowała użytkownikom. Rzecz jasna przejrzałem tylko bardzo niewielki wycinek darmowych motywów, ale w zasadzie wszystkie one prezentowały podobny poziom złożoności i tak naprawdę tylko dwa z nich wpadły mi w oko na tyle, że byłbym skłonny wymienić domyślny temat na nie (Material Kit oraz w mniejszym stopniu Caffeine Coding). 

Jeśli ktoś zapoznał się z moim trzeci wpisem na temat platformy Express.js albo ma jakiekolwiek doświadczenia z językami szablonów powinien czuć się nieco swobodniej, ponieważ całość dość mocno bazuje na Handelbars, o którym to narzędziu miałem już okazję krótko wspomnieć. W dzisiejszym wpisie skupię się jednak na strukturze projektu tematu przewidzianych dla Ghost, więc na ten moment wiedza w zakresie Handlebars nie będzie koniecznie wcale.

.

├── /assets

    ├── /css

        ├── screen.css

    ├── /fonts

    ├── /images

    ├── /js

├── /partials

    ├── list-post.hbs

├── default.hbs

├── index.hbs [required]

└── post.hbs [required]

└── package.json [required]

Wyżej przedstawiony został (za dokumentacją dostępną na stronie ghost.org) przykładowy schemat plików i katalogów. Czerwoną czcionką wyróżniłem te pliki, które są wymagane z punktu widzenia każdego tematu. Nie wygląda to jakoś imponująco, ale to jest absolutne minimum i wystarczy rzucić okiem na faktyczną strukturę dość ascetycznego tematu przewodniego, by przekonać się, że w rzeczywistości, by osiągnąć nawet niespecjalnie wyszukany rezultat, trzeba się trochę bardziej postarać.

Zrozumienie, w jaki sposób w przypadku Ghost należy budować własny temat jest kluczem do sukcesu. Zacznijmy od katalogów, bo raz że jest ich mało, a dwa specjalnie nie ma o czym w tym przypadku deliberować. Pierwszy z nich czyli folder assets to zwyczajowy pojemnik na dobra wszelakie w postaci fotek, czcionek czy skryptów CSS oraz JS. Rozwodzić się nad tą kwestią póki co nie ma większego sensu. Drugi katalog jest znacznie ciekawszy, ale nieco szerzej zostanie on omówiony (czy dokładniej: zawartość, która w nim może być zamieszana) później. Na ten moment wystarczy napisać, że nie jest to obligatoryjna część jakiegokolwiek tematu, a tym samym nie ma oczywiście potrzeby tworzyć go każdorazowo. Oczywiście pod pewnymi warunkami – zwłaszcza w przypadku większych projektów – wykorzystanie mechanizmu odseparowanych reużywalnych bloków kodu, bo tego właśnie ten katalog dotyczy, można nieco ułatwić utrzymanie pewnego porządku w budowanym rozwiązaniu, tym niemniej – przynajmniej na ten moment – zastanawiam się na celowością jego umieszczania w typowych projektów Ghost, czyli zazwyczaj dość prostych blogów.

default.hbs

Zwyczajowo powinien to być kluczowy widok w takich przypadkach, ponieważ w zamyśle jest to pewna matryca, która narzuca charakter czy tam wspólne ramy wszystkim pozostałym stronom/widokom na naszym blogu. Oczywiście nic nie stoi na przeszkodzie, by w projekcie stworzyć kilka takich wzorców, choć mając na uwadze charakter większości rozwiązań na bazie Ghosta budowanych nie ma to raczej większego sensu.

index.hbs

Chyba najbardziej istotny plik w kontekście tego, co można zobaczyć potem na blogu czy stronie przygotowanej przy użyciu Ghost. Kod tam umieszczony odpowiada za wyświetlanie listy wpisów (postów), które zostały przez nas utworzone. Z tego co zdążyłem się zorientować w przypadku dużej części (prawdopodobnie większości) darmowych motywów odpowiada on za to, co nazwalibyśmy stroną główną bloga. 

post.hbs

Tu z kolei mamy do czynienia z widokiem, który odpowiada – jak łatwo się domyślić – za wyświetlanie treści dla pojedynczego wpisu. 

page.hbs

To widok odpowiadający za statyczne strony, o ile widzimy potrzeby ich umieszczenia w naszym projekcie.

home.hbs

Jeśli czujemy potrzebę odseparowania strony głównej od bloga czy też listy wpisów wszelakich, wówczas należy skorzystać z pliku o takiej właśnie nazwie. Będzie on wówczas odpowiadał za wyświetlenie widoku dla trasy “/”.

tag.hbs/author.hbs

Widoki te odpowiadają zwyczajowo za zbiorczą prezentację użytych we wpisach tagów oraz odpowiednio autorów. W tym ostatnim przypadku mają one oczywiście sens wyłącznie wówczas, gdy piszących jest co najmniej dwójka. Osobiście nie do końca czuję potrzebę ich umieszczania, a przynajmniej specjalnego wyróżniania w nawigacji strony (co dzieje się za bardzo często), ale to dopiero początek mojej przygody z Ghost i być może z czasem przekonam się do tej idei.

error.hbs

Widok odpowiedzialny za “obsługę błędów”, jeśli chcielibyśmy zaprezentować w takiej sytuacji coś więcej niż standardowy komunikat przeglądarki. Ja w wielu przypadkach można stworzyć różne widoki na potrzebę odmiennych zdarzeń, choć znowu nie dostrzegam w tym większego sensu, gdy mamy do czynienia z prostym blogiem. 

Każda strona w motywie Ghost należy do pewnego kontekstu, który określa między innymi to, jakie dane będą dla niej  dostępne i jaka zawartość zostanie wyprowadzona przez tak zwanego helpera {{body_class}}. Być może na ten moment nie brzmi to specjalne zrozumiale czy w sposób cokolwiek mówiący, ale po lekturze kolejnych wpisów z tego cyklu mam nadzieję, że wszystko stanie się jasne. Na ten moment wystarczy napisać, iż chodzi o to, że Ghost umożliwia czy też odpowiada za mapowanie adresów URL do widoków wyświetlających konkretnie określone dane. Może  to być listą postów, pojedynczy wpis bądź kanałem RSS. To właśnie trasa określa, jakie dane mają być wyświetlane i jaki szablon użyty do ich renderowania. Idzie o to, by w miejsce zapewniania dostępu do wszystkich danych dla każdej strony (adresu URL), w ramach pewnej optymalizuje, za którą odpowiada właśnie Ghost, wybrane dane te były pobierane przy użyciu wspomnianych kontekstów, a wszystko to w imię dostarczenia superszybkich publikacji.

Natomiast by swobodniej poruszać się w tym zakresie trzeba niestety przynajmniej odrobinę przyswoić mechanizmy działania Handlebars, z którego twórcy Ghost w dużym stopniu skorzystali we własnym projekcie. W związku z tym kolejny tekst poświęcony zostanie wprowadzeniu do tego języka szablonów, ale już niejako poza kontekstem samego CMS-a, nad którym obecnie się pochylamy.