Blog

Hugo Tutorial PL. Odsłona druga.

Druga odsłona "przysposobienia" do Hugo. Dzisiejszy wpis dotyczy tworzenia kontentu, a właściwie jego roli w projekcie.

Hugo Tutorial PL. Odsłona druga.

Dzisiaj bez zbędnych wstępów przechodzimy do rzeczy, a zwłaszcza daruję sobie psychoanalityczne czy autotematyczne wtręty.

Zwyczajowo każdy poradnik dla Hugo zaczyna się od omówienia struktury projektu, czyli czym są te wszystkie katalogi i pliki, z którymi styka się użytkownik na początku swojej przygody z tym narzędziem. W mojej opinii nie ma to większego sensu, ponieważ w przypadku osób początkujących - a do takich skierowana jest ta seria wpisów - należy zacząć od próby wyłożenia idei, jaka stoi za tym rozwiązaniem. Z tej perspektywy patrząc znaczenie mają tak naprawdę dwa foldery, czyli content oraz layout (ewentualnie themes/layout, jeśli tak jak my zamierza się korzystać z “zewnętrznych” motywów). Od razu zaznaczę, że w dzisiejszym wpisie skupię się na tym pierwszym katalogu (czy właściwie idei kontentu jako takiego), ale przy omawianiu tego zagadnienia nie da się uniknąć pewnych odwołań również do drugiego z katalogów czy raczej kwestii związanych z aspektem prezentacji treści przy pomocy szablonów (layout).

KONTENT A WYGLĄD NASZEJ STRONY

W przypadku Hugo kontent (czy mówiąc bardziej po polsku: zawartość) jest fundamentem naszej witryny i to w dwójnasób. Po pierwsze, pliki umieszczane w katalogu content są nośnikiem tych treści, które chcielibyśmy prezentować na poszczególnych stronach naszej witryny. Tutaj jednak konieczna jest pewne uzupełnienie tego stwierdzenia na samym początku, choć w swoim czasie bardziej obszernie potraktujemy to zagadnienie: to nie jest tak, że w tym folderze czy poszczególnych plikach w nim umieszczonych musi się znaleźć wszystko, co zobaczy osoba odwiedzająca naszą witrynę. Gdyby tak było idea generatorów statycznych (dalej SSG) stron nie miałaby większego sensu.

By lepiej naświetlić to zagadnienie muszę odwołać się do kwestii szablonów, czyli drugiej fundamentalnej idei każdego CMS czy SSG, ponieważ to co finalnie zobaczą osoby odwiedzające naszą witrynę jest kombinacją czy raczej wypadkową połączenia naszych treści (zawartość katalogu content) oraz szablonów właśnie (zawartość katalogu layout). Jak się niedługo przekonamy w przypadku Hugo zawartość tworzona jest w postaci plików Markdown (nie jest to cała prawda, ale dla uproszczenia załóżmy, że jest tak faktycznie),  zaś praca z tymi plikami jest dużo bliższa korzystaniu z jakiegoś edytora tekstu niż rzeczywistego tworzenia kodu w HTML-u, a przy tym nie zawiera innych elementów typowych dla stron internetowych jak chociażby stylizowanie CSS czy elementy Javascript. By nasza witryna prezentowała się jak “porządna” strona internetowa odpowiadają w głównej mierze szablony, które mogą czy wręcz powinny zawierać te wszystkie charakterystyczne dla stron WWW składowe, ale przy tym mają jeszcze coś ekstra. To “coś ekstra” to miejsca w kodzie, gdzie szablon oczekuje dostarczenia określonego wsadu, który odpowiednio zostanie przez niego sformatowany i w efekcie zaprezentowany odwiedzającym naszą witrynę.

W tym miejscu warto odwołać się do czegoś bliższego życia, czyli na przykład sposobu tworzenia masowej korespondencji do klientów. Załóżmy, że chcemy wysłać z drukarni listy dla tysiąca naszych subskrybentów, informujące o jakiś istotnych zmianach po naszej stronie - ot chociażby wdrożeniu jakiejś fantastycznej usługi/oferty, która uszczęśliwić może nadawcę pisma, a nas uczynić bogatymi. Nic nie stoi na przeszkodzie, by do tego celu zatrudnić tabun studentów i kazać im w edytorze tekstu klepać odpowiednie zawiadomienie per adresat. Jednak jest to działanie mało optymalne, ponieważ w takim przypadku duża część treści będzie identyczna dla każdego potencjalnego odbiorcy (na przykład 90% całości stanowić będzie komunikat przygotowany przez dział marketingu), zaś jedynymi unikalnymi informacjami będą dane nadawcy (tak jak to widać na załączonym niżej obrazku).

W takiej sytuacji na ogół tworzony jeden wspólny szablon (gotowiec), zaś te spersonalizowane informacje będą wstawiane z jakiegoś zewnętrznego źródła (np. baza danych). I dokładnie o to samo chodzi w Hugo, a cała zabawa polega na opanowaniu mechanizmów czy zasad, które pozwalają połączyć zawartość naszych plików z katalogu content z odpowiednimi szablonami w folderze layout, ale tym zajmiemy się w kolejnych wpisach.

Dla pełni obrazu warto zwrócić uwagę na jeszcze jeden aspekt szablonów przy okazji omawiania naszego przykładu z korespondencją. Otóż to właśnie ta wprzódy przygotowana matryca określa nie tylko gdzie i jakie dane się pojawią, ale wyznacza też ogólne aspekty wizualne, ponieważ definiuje chociażby szerokość marginesu czy rodzaj i kolor użytej czcionki do prezentacji pobranych treści. Jak się przekonamy w trakcie tego kursu, w przypadku Hugo mamy możliwość wpływania na finalny wygląd strony internetowej już na poziomie kontentu w znacznie większym stopniu niż w naszym przykładzie z listami. Tym niemniej na ten moment chodzi nade wszystko o próbę zobrazowania generalnej zasady, że każda strona tworzona w Hugo to wypadkowa tych dwóch rzeczywistości, czyli połączenia pliku Markdown z odpowiadającym mu szablonem. Bez któregokolwiek z nich strona po prostu się nie wygeneruje.

KONTENT A STRUKTURA NASZEJ WITRYNY

W tym momencie chciałbym przejść do drugiego aspektu (czy tam fundamentu, jak napisałem wyżej) zawartości tworzonej w folderze content. Ale zanim do niej przejdę jedna uwaga natury ogólnej: używanie Hugo czy innego SSG do tworzenia witryn składających się z jednej czy dwóch stron mija się zupełnie z celem. Dlatego nieprzypadkowo celem tego kursu jest utworzenie prostego bloga, ponieważ z definicji zakłada on, że taka witryna będzie mniej lub bardziej dynamicznie rozwijana i tym samym powstawać będą kolejne podstrony. To powiedziawszy możemy przejść do sedna tej części wpisu.

Ja wspominałem w pierwszym tekście z tego cyklu nasz witryna będzie składała się ze strony głównej (Home), tej gdzie piszemy trochę o portalu lub jego twórcy (About), strony z wykazem wszystkich wpisów blogowych (Blog) oraz rzecz jasna określonej liczby stron odpowiadającym tym ostatnim, czyli wszystkim tekstom podwieszonym na naszym blogu. To o czym przed momentem napisałem będzie się rzecz jasna przekładało na konkretne adresy URL, tak jak zostało to przedstawione niżej.

Tytuł strony

Ścieżka w adresie URL

Home

/

About

/about

Blog

/blog

Pierwszy wpis

/blog/1-wpis

Drugi wpis

/blog/2-wpis

Trzeci wpis

/blog/3-wpis

Co by nie było wątpliwości przedstawię to samo na przykładzie mojej domeny, czyli borciugne.pl. Wówczas wyglądałoby to następująco:

Jak ten cel można osiągnąć przy pomocy Hugo? Otóż dość prosto, bowiem wystarczy utworzyć odpowiednią strukturę katalogów i plików w naszym projekcie a dokładniej: w folderze content, która to struktura będzie odpowiadały z grubsza adresom URL naszej witryny. W efekcie powinniśmy otrzymać takie drzewko jak niżej.

├── about

│   └── index.md

├── blog

│   ├── 1-wpis.md

│   ├── 2-wpis.md

│   ├── 3-wpis.md

│   └── _index.md

└── _index.md

Plik “_idex.md” (zwracam uwagę na dolne podkreślenie przed słowem “index” - jego znaczenie omówię w następnym wpisie) znajdujący się w katalogu głównym odpowiada stronie domowej (“/”), zaś w katalogu about znajduje się plik “index.md” (tym razem bez podkreślenia), który stanowi bazę dla podstrony About (/about).

Jak widać -  nieco sprawy upraszczając - każdy plik Markdown w katalogu content odpowiada za oddzielną stronę naszej witryny, zaś tym o nazwie “idex” przypada szczególne znaczenie, ponieważ tożsame są z nazewnictwem katalogu nadrzędnego. By bardziej tę logikę unaocznić wklejam niżej przykład z dokumentacji Hugo.

.

└── content

└── about

|   └── index.md  // <- https://example.com/about/

├── posts

|   ├── firstpost.md   // <- https://example.com/posts/firstpost/

|   ├── happy

|   |   └── ness.md  // <- https://example.com/posts/happy/ness/

|   └── secondpost.md  // <- https://example.com/posts/secondpost/

└── quote

├── first.md       // <- https://example.com/quote/first/

└── second.md      // <- https://example.com/quote/second/

Już na koniec dzisiejszej “lekcji” pozostaje nam jedynie odtworzyć strukturę plików, którą przedstawiłem wyżej. Tym niemniej by nie tworzyć ich “ręcznie” skorzystamy z CLI dla Hugo, ponieważ w ten sposób plik będą już wstępnie spreparowane. Całość tym sposobem sprowadzi się do wprowadzenia następujących poleceń w terminalu:

$ hugo new _index.md

$ hugo new about/index.md

$ hugo new blog/_index.md

$ hugo new blog/1-wpis.md

$ hugo new blog/2-wpis.md

$ hugo new blog/3-wpis.md

Zwracam uwagę na podkreślenia dolne w przypadku pierwszego i trzeciego polecenia, które to znajdują się przed słowem “index”.

Na dzisiaj to byłoby wszystko. W kolejnym tekście pochylimy się na drugim filarem, czyli szablonami.