Moja strona ponownie "moja"

Migracja mojej strony opartej na WordPress do Hugo

Ponad dekadę temu rozpocząłem swoją przygodę ze stronami internetowymi pisanymi w notatniku i HTML-u, po czym nastały czasy WordPress’a (zacząłem z nim przygody w 2008). Przez ten okres zbudowałem kilkanaście stron opartych właśnie na nim, z czego nadal zarządzam jeszcze kilkoma.

O ile wszystko działa, to nie ma problemu. Na każdym jednak kroku muszę śledzić i sprawdzać, czy coś się na nich nie zepsuło oraz pracować nad ich ciągłą optymalizacją.

Jeżeli chodzi o mój blog, zauważyłem, że więcej czasu poświęcam na dopieszczanie, poprawianie oraz zabezpieczanie strony a niżeli na tworzeniu wpisów.

Coraz to nowe zagrożenia czy też zmiany w algorytmach wyszukiwarki powodują konieczność ciągłego dostosowywania do zmieniających się warunków.

Moja strona jest moja, dopóki dbam oto, aby działała, opłacam serwer, na którym leży oraz domenę.

Jednakże moja strona nie jest tak do końca moja.

Tak jak z plikiem Word. Jest on twój, dopóki jest on zapisany lokalnie na dysku. Możesz go udostępnić w internecie, ale zawsze masz oryginał “pod ręką”.

W przypadku WordPress twoja strona jest rozproszona pomiędzy serwerem, gdzie znajdują się twoje pliki a bazą danych, gdzie znajdują się twoje wpisy.

Tak naprawdę nic nie jest twoje. Oprócz oczywiście kopii zapasowej w niezbyt czytelnym formacie, jeżeli chcesz coś uruchomić bez internetu. Jeżeli coś się stanie, zaczynają się schody.

A gdyby tak wrócić do podstaw budowania stron w HTML+CSS?

Pliki HTML i style CSS zapisane były na dysku wraz z obrazkami. Wszystko wrzucało się na serwer i tak pojawiało się w internecie. Całą stronę miałeś dostępną na dysku i mogłeś uruchomić ją bez konieczności posiadania odpowiedniego oprogramowania. Jeżeli serwer usługodawcy wysiadł lub po prostu ów usługodawca zwinął walizki i wyłączył wtyczkę (a w przyszłości miałem tego typu przygody z firmą znaną wówczas pod nazwą Cyberion.pl), wówczas jesteśmy ugotowani.

Jeżeli masz stronę dostępną w prostej formie, jej przywrócenie nie potrwa za długo.

Nie planuję jednak wracać do totalnych podstaw.

Pisanie stron od zera w HTML było największą bolączką (chociaż i nauką), dlatego też WordPress stał się moim podstawowym narzędziem. Nie zamierzam cofać się do etapu sprzez Web 2.0, ale zamierzam iść naprzód, z zachowaniem starego podejścia z nowoczesnym sposobem jego implementacji.

Otóż chciałbym mieć stronę dostępną lokalnie, którą mogę podejrzeć bez konieczności zmagania się z bolączkami serwerów oraz przeróżnych usług cache po drodze.

Ostatnio opublikowałem wpis innej stronie, którą zarządzam, gdzie zapomniałem dodać ważnego elementu. Po szybkiej aktualizacji walczyłem kilka godzin pomiędzy cache mojego usługodawcy, konta hostingowego a Cloudflare, aby zobaczyć zaktualizowaną zawartość. Koszmar!

Chcę widzieć, jak moja strona — wpis będzie wyglądać, nim zdecyduje się go upublicznić w internecie.

Jednocześnie, chce mieć dostęp do treści w taki sposób, abym mógł rozpocząć jej edycję, gdziekolwiek jestem, na dowolnym komputerze, dowolnym systemie operacyjnym, z dostępem do internetu czy też bez.


W momencie, gdy coraz to bardziej zacząłem moje przygody z GitHub’em rzucił mi się na oczy sposób pisania i publikowania treści wraz z wyróżnieniami — kodem.

Stąd też zacząłem moje eksperymenty z Markdown.

Markdown pozwala na stworzenie formatowanego tekstu wraz z nagłówkami, pogrubieniami, zdjęciami itp. z wykorzystaniem dowolnego edytora tekstowego.

W skrócie skupiasz się na pisaniu tekstu, a później, twój tekst przygotowany w formie Markdown używasz, aby wygenerować w postaci pliku HTML, który natomiast będzie serwowany w internecie.

Skupiając się na treści, nie myślisz o kodzie, jego dostosowaniu do różnych rozmiarów ekranu czy też sprawdzeniu, czy będzie on poprawnie wyświetlany w Chrome, czy Firefox. Kierujesz się tylko tym, jak funkcjonuje Markdown.

Zapomnij o sprawach technicznych, skup się na treści, a resztę pozostaw “narzędziu”, które zrobi całość za ciebie i zadba o wszystko to, na co musiałbyś tracić swój cenny czas.

Narzędziu? – zapytasz.

Otóż narzędzi jest mnóstwo. Jednymi z popularnych są obecnie Jekyll, Hugo czy Gatsby.js.

Oczywiście, wymagają one od ciebie nieco wiedzy. Umiejętności obsługi Worda, w sposób przeciągnij i upuść na nic się tutaj zdadzą, stąd też spora część ludzi pozostanie przy Wordpress-ie, szczególnie gdy bloki Gutenberg znacząco ułatwiają pisanie treści.

Gutenberg w WordPress nie jest taki zły, jak już go opanujesz. Obsługuje on również Markdown. Problemy zaczynają się w przypadku wpisów, które nie powstały na przełomie ostatnich lat — taka jak moje (2008!).

Moje pierwsze wpisy pisane były w edytorze klasycznym WordPress i przeniesienie ich teraz do Gutenberg jest nieco nierealne, czasochłonne, po prostu zbędne.

Jeżeli już ogarnąłeś sposób funkcjonowania niezbędnych narzędzi (w moim przypadku wybrałem Hugo) zauważysz, że nasza strona jest stroną statyczną, która nie potrzebuje dużej mocy obliczeniowej, bazy danych, obsługi PHP. Co za tym idzie, nie potrzebujemy wyspecjalizowanego konta hostingowego, które nie mało kosztuje, a stronę możemy wrzucić gdziekolwiek, gdzie będziemy mogli, aby stała się publicznie dostępna.

I tak, zamiast płacić tak, jak ja przez ostatnie lata 200zł rocznie (plus VAT) za konto na dzielonym hostingu, pieniążki te możemy wykorzystać na coś bardziej pożytecznego, a naszą statyczną stronę wrzucić na darmowe rozwiązanie.

Ale czy darmowe, nie oznaczać będzie, że gorsze? – zapytasz.

Otóż nie.

W przeciwieństwie do dynamicznego WordPress’a nasza strona nie będzie potrzebować dużej mocy obliczeniowej procesora oraz sporej ilości pamięci, aby wyświetlić treść, która dla czytelnika — odbiorcy końcowego wyglądać będzie dokładnie tak samo.

Tym oto darmowym miejscem na twoją statyczną stronę będzie, chociażby GitHub Pages lub w moim przypadku Netlify na podstawie repozytorium na GitHub.

Oba te rozwiązania (jak również tona innych dostępny i darmowych) pozwolą ci na osiągnięcie zamierzonego celu, czyli konwersję tekstu napisanego z wykorzystaniem Markdown na stronę HTML.


Jaki jest sens w tym wszystkim?

Nasze wpisy piszemy po to, aby ktoś je czytał. Jeżeli ktoś je czyta, to znaczy, że istnieje potrzeba na ich istnienie. A jeżeli ktoś, kto przeczytał, zyskał na tym, chociażby rozwiązując własny problem, osiągnęliśmy zamierzony cel.


Dodatkową zaletą powrotu do podstaw jest fakt bezpieczeństwa. Liczba stron zbudowanych na podstawie WordPress przekroczyła 60% wszystkich stron w internecie.

Uruchomienie strony opartej o WordPress to nie tylko zainstalowanie podstawowego skryptu. Musimy zadbać również o bezpieczeństwo, gdyż bardzo szybko możemy zobaczyć, że nasza strona zostanie przejęta i wykorzystana do niepożądanych celów.

O ile mi się to nie zdarzyło, to nie raz pomagałem w przywróceniu strony po przejęciu i zabezpieczeniu jej w odpowiedni sposób, aby uniknąć podstawowego błędu. Zajmuje to sporo czasu, a cierpi na tym reputacja strony w internecie, którą odbudować nie jest łatwo i jest to czasochłonne. Z reguły może trwać od kilku miesięcy do kilku lat, w zależności, kiedy zauważyliśmy, że nasza strona została skompromitowana i jak szybko zareagowaliśmy, nim wyszukiwarki takie jak Google zrobiły swoje.

W każdym tygodniu spędzam co najmniej godzinę na sprawdzenie, czy wszystko działa oraz zadbanie o bezpieczeństwo stron, z którymi współpracuję. Jest to godzina, którą można byłoby spożytkować inaczej.

Stąd też, w lipcu 2020 rozpocząłem intensywną analizę sytuacji, aby uprościć cały proces, zaczynając od mojej strony domowej.

Przeniesienie wszystkiego z WordPress do formy Markdown z założenia miało być jak kopiuj wklej, oczywiście nie było!.

Na tym etapie postanowiłem poświęcić mój czas na nauczenie się czegoś nowego, aby w przyszłości zyskać nie tylko w formie materialnej, ale również niematerialnej, w postaci wolnego czasu.

Na tym etapie zauważyłem problem związanym z tym, że moja strona zaczęła lata temu z klasycznym edytorem, a teraz używa Gutenberg do komponowania wpisów. Dostępne narzędzia konwersji WordPress do Markdown pomogły, ale nie pozwoliły mi w szybki sposób udostępnić mojej strony w postaci statycznej.

Wpisy klasyczne zatraciły formatowania, odnośniki do zdjęć i adnotacje nie wyświetlały się tak, jak trzeba. W związku z tym spędziłem porą część czasu (zaraz po tym, jak stworzyłem wygląd strony) na poprawie każdego ze 186 wpisów, wracając do tych pierwszych z 2008 roku! Tutaj zauważyłem, że dużo się nauczyłem od tego czasu, szczególnie jak pisać, aby treść była pożądana.

Na szczęście na tym etapie pomocny okazał się program MassReplaceIt, dzięki któremu byłem w stanie masowo zmienić błędnie wstawione znaczniki i formatowania na te, które są poprawnie używane w Markdown.

Dodatkowo użyłem wordpress-export-to-markdown, który pozwolił mi ponownie wygenerować Markdown z pliku export.xml (z naciskiem na treść), aby poprawić posty, które okazały się problematyczne.


Wracając do wyglądu strony, bo od tego zacząłem.

Moja strona na WordPress używała motywu Twenty Twenty, który bardzo przypadł mi do gustu i spełnił moje aestetyczne potrzeby, jak mój blog ma wyglądać.

Na bazie tego motywu stworzyłem mój motyw-dziecko (child theme), do którego dodałem co nieco. Efekt osiągnięty.

W pierwszej kolejności myślałem o wykorzystaniu Hugo oraz przerobionego motywu przerobionego Twenty Twenty do Hugo na te potrzeby.

Po kilku eksperymentach i zagłębieniu się w kod postanowiłem spróbować czegoś innego, ale pozostając z Hugo jako podstawowe narzędzie (próbowałem Gatsby.js oraz Jekyll, ale jak dla mnie, Hugo było szybszy w ogarnięciu i zrozumieniu logiki).

I tak przerobiłem motyw Minos, który tak naprawdę jest modyfikacją motywu o tej samej nazwie Minos, tyle że dla platformy Hexo.

Wzorując się na tym, jak mój blog wyglądał na WordPress i motywem Twenty Twenty osiągnąłem ostateczny wygląd, który aktualnie podziwiasz.

Cała praca z dostosowywaniem motywu do moich potrzeb odświeżyła mi moją zardzewiałą wiedzę o HTML oraz CSS (w tym poszerzyła o JavaScript). Doceniłem również sposób, w jaki Hugo funkcjonuje i generuje strony. Zagłębiając się w Hugo, odkrywałem nowe opcje oraz prostotę w ich implementacji. I, mimo że apetyt rośnie w miarę jedzenia, myślę, że osiągnąłem zamierzony efekt.

Nie obyło się przy tym bez kompromisów, ale nic takiego, którego nie dałbym z cierpieć lub zastąpić “lżejszym” rozwiązaniem.

WordPress wraz ze swoimi wtyczkami pozwolił mi na rozleniwienie się w tej kwestii.


Przeniesienie mojej strony, mimo że potrwało znacznie dłużej, niż to założyłem, pozwoliło mi osiągnąć to, co chciałem.

Na etapie szybkiej nauki dodałem kilka elementów, które wymagałoby kilku wtyczek w Wordpress. Całość została oparta na HTML oraz CSS z małą pomocą JavaScript. Dodatkowo, dodałem coś, czego nie wyobrażałem sobie w WordPress (nie w sposób tak prosty, jak w Hugo), a mianowicie ciemny motyw strony.

Gdy nasz komputer, telefon lub tablet przełączy się w tryb nocny, moja strona również. Takie małe czary-mary, dzięki czemu łatwiej się będzie czytać późnym wieczorem.


Prosta, przejrzysta strona, zachęcająca do skupienia się na treści powiązana z nowoczesnym wyglądem to podstawa.

Co dla mnie było ważne, to obrazek wyróżniający do każdego postu, zachęcający do zagłębieniu się we wpis. Z własnego doświadczenia wiem, że to, oraz początkowy tekst (zajawka wpisu) decyduje o tym, czy dalej chcę czytać, czy nie.

Oczywiście tytuł wpisu jest równie ważny, ale nie stosuję tutaj praktyki ze szmatławskich stron, których treść nijak się ma do tego, co tytuł obiecywał.

Nie ma co się oszukiwać, WordPress nie umrze tak szybko, a ja nie przestanę go używać w innych projektach. Dla mojej strony migracja była czymś jak odwyk i oczyszczenie. Bez względu czy z Hugo będę przez kilka lub kilkanaście lat, myślę, że dostępność postów w Markdown pozwoli zachować mi ład i kompatybilność do przyszłych zmian, które dopiero nadejdą.


Nim opublikowałem moją stronę, posłużyłem się narzędziem Broken Link Checker do sprawdzenia, gdzie moje odnośniki nie działają oraz gdzie podczas eksportu (chociażby zdjęć) odnośnik nie został poprawnie przekonwertowany.

Posiadając uruchomionego HUGO w trybie developerskim hugo serve wykonałem następującą komendę:

blc -e http://localhost:1313 -ro 2>&1 | tee result.sh

Opcja -e pozwoliła mi skupić się tylko na wewnętrznych odnośnikach, a rezultat otrzymałem w pliku result.sh.

I tak moja strona została przeniesiona i opublikowana w godzinach porannych 9 sierpnia 2020. Nie było praktycznie żadnych przerw.

Oczywiście, odkryłem kilka problemów, które w trakcie dnia naprawiłem, jednocześnie testując proces aktualizacji strony w repozytorium GitHub-a oraz obserwując, jak jest ona upubliczniana ze strony Netlify. Magia!


Krótkie porównanie WordPress vs Hugo dla mojego bloga po zakończonej migracji.

PorównanieWordPressHugo
Wtyczki195 MB0 MB
Motywy3.5 MB3.7 MB
Treść0 MB11.2 MB
Uploads820 MB164.4 MB
Inne8 MB0.9 MB
Baza danych102 MB0 MB2
Koszt serwera200zł/rok + VAT (nazwa.pl)0zł (zero, GitHub/Netlify)

  1. Treść przechowywana jest w bazie danych ↩︎

  2. Hugo nie potrzebuje bazy danych. Treść przechowywana jest w plikach .md ↩︎

Komentarze
Kategorie