Ciężko mi wyobrazić sobie prowadzenie bloga bez sekcji komentarzy. Czy dodałam tę funkcjonalność, zanim zrobiłam zakładkę “O mnie”? Może.

Zależało mi na kilku rzeczach:

1. Przechowywaniu komentarzy bezpośrednio na GitHubie, a nie u innego, zewnętrznego dostawcy.

2. Braku konieczności posiadania przez komentującego/cą konta na GitHubie.

3. Możliwości korzystania z prywatnego repozytorium.

Giscus

Jeśli nie zależy Ci na na drugim punkcie, ciekawą alternatywą są Giscus i Utterances. Pewnie lepszym wyborem będzie Giscus, który zresztą był mocno wzorowany na Utterances. Głównie dlatego, że ostatni commit w Utterances jest sprzed 2 lat, a Giscus jest nadal rozwijany.

Cała idea polega na tym, że dodane komentarze otwierają dyskusję dla konkretnego pliku (w Utterances są dodawane jako issue, co trochę psuje sens tej zakładki – kolejny minus). Masz zatem dostęp do nich bezpośrednio na GitHubie i nie musisz tworzyć żadnej bazy danych. Jednak żeby ktoś mógł dodać komentarz, musi mieć konto na GitHubie i:

• albo dodać autoryzację dla aplikacji Giscus, żeby opublikowała komentarz w ich imieniu,
• albo dodać komentarz bezpośrednio w GitHub Discussion.

Jeśli czujesz, że to dobry wybór dla Ciebie to tutaj są dwa tutoriale, które wyglądają ciekawie → 1 2

Disqus

Jeśli nie zależy Ci na przechowywaniu danych na GitHubie, ale za to chcesz by użytkownik nie był ograniczony tylko do konta na GiHubie, to Disqus wygląda na bardzo popularne rozwiązanie.Gdzieś obiło mi się o uszy, że kwestia prywatności danych nie jest do końca jasna, ale nie zgłębiałam tematu, bo i tak to rozwiązanie nie spełnianiło pierwszego punktu z mojej listy. Za to ma naprawdę fajny formularz do dodawania komentarzy - tak zwany WYSIWYG (what-you-see-is-what-you-get).

Darmowa wersja Disqus jest obarczona reklamami. Tutaj możesz podejrzeć inne, open-source’owe alernatywy → Remark42, Isso, Commento

Rozwiązanie użyte przeze mnie

Dzięki temu postowi → https://rachsmith.com/static-blog-comments/ ustaliłam, na czym tak naprawdę mi zależy. Myśl, że wszystkie komentarze można właściwie przechowywać podobnie jak posty w repozytorium była bardzo zachęcająca. Rach używa formularza Netlify do odbierania wysłanych przez użytkowników komentarzy, a dzięki Netlify API stworzyła sobie lokalnie aplikacje do ich przetwarzania. Musi jednak ręcznie commitować te zmiany.

Jeśli chcesz zgłębić bardziej temat Netlify to tutaj jest tutorial, gdzie Brad Traversy tworzy prosty formularz kontaktowy, obsługiwany właśnie w Netlify 📺

Chciałam żeby ten proces był bardziej automatyczny niż u Rach. Czy w związku z tym wybrałam narzędzie, które nie było aktualizowane od 2020 roku? Cóż, to prawda… Oto Staticman.

Dzięki temu, gdy użytkownik dodaje komentarz do strony, tak naprawdę wysyła go do Staticmana, który następnie otwiera pull request w naszym repozytorium. Stąd możemy go zaakceptować - mergując go, jako nowy plik .yml w naszym repozytorium, lub odrzucić - zamykając PR.

Tutaj możesz zobaczyć Staticman w akcji (w połączeniu z Gridsome) → 👀.

Możliwe, że któregoś dnia napiszę własną aplikację do tego, (wydaje mi się, że Make świetnie by się do tego sprawdziło) albo chociaż zaktualizuje bibliotki. Na razie jednak chciałam sprawdzić czy w ogóle uda mi się zintegrować Staticman z Astro, gdzie przecież Staticman rozpoczęło swoją stagnację rok przed tym jako Astro w ogóle zostało zaprezentowane światu.

Jest kilka tutorialów, które pokazują jak połączyć Staticmana ze swoją aplikacją. Mamy nawet instrukcję od samego twórcy: https://staticman.net/docs/getting-started.html. Jedak generowanie klucza RSA w sposób w niej przedstawiony mi nie działało, pomógł mi dopiero tutorial od Average Linux User (jeśli wolisz wersję wideo, to jest tutaj → 📺). Poniżej prawidłowa wersja:

ssh-keygen -m PEM -t rsa -b 4096 -C "staticman key" -f ~/.ssh/staticman_key
cat ~/.ssh/staticman_key | tr -d '\n'

Najbardziej jednak polecam ten szczegółowy tutorial od Travis Downs, → https://travisdowns.github.io/blog/2020/02/05/now-with-comments.html. Mimo że dotyczy połączenia Staticmana i Jekyll to opisuje dokładnie cały proces, i wskazuje co chcemy osiągnąć w każdym z kroków, dzięki czemu łatwo go uogólnić do Astro.

Heroku przestało niestety oferować darmowe pakiety, dlatego szukałam też informacji jak zdeployować Staticmana za darmo. I finalnie wrzuciłam go na Render 🚀.

Z minusów - w wersji darmowej strona odpala się długo, kiedy nie ma żadnej aktywności. W związku z tym mam na głównej stronie request/ping, który pozwala na rozruszanie się strony w “tle”, zanim użytkownik będzie chciał dodać komentarz.

Jeśli nie lubisz Render, to tutaj jest jeszcze tutorial o tym jak przenieść Staticmana na Netlify.

Jeśli nie wiesz jak ustawić konfigurację, to tutaj jest przykładowy staticman.sample.yml.

Kolejny przydatny link, to zebrane najczęstsze problemy ze Staticmanem, i jak sobie z nimi poradzić → https://vincenttam.gitlab.io/post/2018-12-25-staticman-repo-setup-errors/. Ja na przykład miałam ustawiony zły branch w staticman.yml (master zamiast main 🤦‍♀️).

Oprócz tych błędów, to po 30 dniach wygasł mi token na botowym koncie na githubie i smuteczek, bo nie ogarnęłam poprawnie pokazywania błędu przy wysyłaniu komentarza, więc jeśli ktoś próbował w tym czasie dodać komentarz, to mógł myśleć, że poprawnie dotartł do dalszej weryfikacji, choć naprawdę zniknał w czeluściach 500-setki.

Dodatkowo, w międzyczasie eksperymentowałam z preventDefault() w formularzu, kompletnie niepotrzebnie.

Ogólnie cały proces był długi i bolesny 😅 Nadal nie działa to wpełni optymalnie, a w przyszłości zamiast zwykłego pola tekstowego, widzę rich text editor. Ale pierwsze koty za płoty 🐈‍⬛

Pozdrawiam
Monika