Widget pogodowy dla TYPO3

Witryny turystyczne, które nie pokazują aktualnej pogody, marnują jedną z najczęściej szukanych informacji

Gdy ktoś wpisuje w Google “pogoda Zakopane” lub “Mazury aktualnie”, oczekuje na stronie destynacji widoku pogody. Gdy go brakuje, odwiedzający opuszcza stronę i sięga po aplikację pogodową. To zmarnowana szansa, ponieważ odwiedzający był już na właściwej stronie. weather2 integruje aktualne dane pogodowe w TYPO3: temperaturę, stan pogody, opady, wiatr, wilgotność i prognozę kilkudniową. Dane pochodzą z OpenWeatherMap lub porównywalnych API i aktualizowane są w konfigurowalnym interwale. Dla witryn turystycznych, portali wydarzeń plenerowych i regionalnych portali informacyjnych to standardowa funkcja, której odwiedzający oczekują.

Typowe scenariusze obejmują portale destynacji, kempingi i ośrodki narciarskie

Najczęstszym scenariuszem jest portal turystyczny regionu. Stowarzyszenie turystyczne miejscowości nad Bałtykiem pokazuje na stronie głównej aktualną pogodę: 22 stopnie, słonecznie, temperatura wody 19 stopni. Obok prognoza pięciodniowa. Odwiedzający planujący wyjazd jednodniowy od razu otrzymują istotną informację i pozostają na stronie, by zarezerwować atrakcje. Temperatura wody pochodzi z osobnego endpointu API lub jest utrzymywana ręcznie.

Drugim scenariuszem są kempingi i parki wakacyjne. Kemping w Bieszczadach pokazuje na stronie rezerwacji pogodę na najbliższy tydzień. Odwiedzający wahający się między dwoma tygodniami urlopu mogą wykorzystać prognozę jako pomoc w decyzji. Dla operatora kempingu jest to argument konwersyjny: “Słońce świeci, zarezerwuj teraz”.

Trzeci scenariusz: ośrodki narciarskie i wydarzenia plenerowe. Ośrodek narciarski pokazuje temperaturę na szczycie i w dolinie, wysokość pokrywy śnieżnej (z osobnego źródła) i prędkość wiatru. Festiwal plenerowy pokazuje prognozę pogody na weekend festiwalowy. W obu przypadkach widok pogody dostarcza konkretnej wartości dodanej, która zatrzymuje odwiedzających na stronie.

Architektura techniczna pobiera dane pogodowe przez API i cache’uje je lokalnie

weather2 komunikuje się z API OpenWeatherMap (lub alternatywnie z dostawcami WeatherAPI, Visual Crossing, Meteostat). Konfiguracja w backendzie TYPO3 definiuje: klucz API, lokalizację (współrzędne lub nazwę miejscowości), jednostki (metryczne/imperialne), język i interwał aktualizacji. Standardowy interwał to 30 minut, czyli co 30 minut wysyłane jest żądanie do OpenWeatherMap, a odpowiedź cache’owana w bazie TYPO3.

Plugin frontendowy renderuje dane pogodowe przez szablony Fluid: aktualną temperaturę, ikonę pogody (słońce, chmury, deszcz), opis tekstowy, wiatr, wilgotność. Prognoza wielodniowa pokazuje minimum i maksimum dzienne dla trzech do siedmiu dni. Ikony dostarczane są jako SVG, a nie jako zewnętrzne URL-e obrazów, by nie generować dodatkowych żądań do serwerów stron trzecich.

Dla klucza API OpenWeatherMap oferuje plan bezpłatny z 1 000 wywołań dziennie, co przy 30-minutowym interwale (48 wywołań dziennie) z naddatkiem wystarcza. Dla witryn z wieloma lokalizacjami (np. stowarzyszenie turystyczne z 10 miejscowościami) potrzeba 480 wywołań dziennie - wciąż w ramach Free-Tier. Plany Pro (od ok. 160 zł miesięcznie) oferują aktualizacje godzinowe i rozszerzone dane, takie jak indeks UV i pyłki.

Częste problemy dotyczą limitów API, cache i nieaktualnych danych

Najczęstszym problemem jest przekroczenie limitu API. Gdy cache TYPO3 nie jest poprawnie skonfigurowany, a każde żądanie strony wyzwala wywołanie API, limit Free-Tier 1 000 wywołań jest osiągany w ciągu kilku godzin. Rozszerzenie pokazuje wtedy brak danych lub błąd. Rozwiązanie: zapewnić, że dane pogodowe są zapisywane w cache TYPO3, a nie pobierane na nowo przy każdym żądaniu frontendu. Cache musi działać niezależnie od cache strony (zadanie Schedulera lub własny wpis cache).

Drugi problem: nieaktualne dane pogodowe. Gdy zadanie Schedulera nie działa (cron wyłączony, migracja serwera), witryna pokazuje dane pogodowe sprzed kilku dni lub tygodni. To gorsze niż brak widoku. Rozwiązanie: w szablonie Fluid wbudować fallback sprawdzający, czy zcache’owane dane są starsze niż dwie godziny, i przy nieaktualnych ukryć widżet, zamiast pokazywać błędne dane.

Trzeci temat: ochrona danych. Gdy dane pogodowe pobierane są przez JavaScript bezpośrednio od klienta do API, przeglądarka przekazuje IP odwiedzającego dostawcy API. To przekazywanie danych podmiotowi trzeciemu, istotne z punktu widzenia RODO. Rozwiązanie po stronie serwera (serwer TYPO3 wywołuje API, a nie przeglądarka) eliminuje ten problem i jest preferowane przez UODO.

TYPO3 v12 jest wspierany, integracja API pozostaje stabilna niezależnie od wersji

weather2 wykorzystuje bibliotekę HTTP-Client TYPO3 dla zapytań API i szablony Fluid do renderowania. Oba elementy są stabilne w core TYPO3. Pod v12 rozszerzenie działa bez problemów. Dla v13 konieczne są minimalne dostosowania (rejestracja zadań Schedulera, konfiguracja pluginu). Ponieważ logika podstawowa (żądanie HTTP, parsowanie JSON, zapis do bazy) jest standardowa, rozszerzenie pozostaje niskonakładowe w utrzymaniu przy upgrade’ach TYPO3. Gosign konfiguruje widżety pogodowe jako część projektów witryn turystycznych i zapewnia, że cache API, fallback i ochrona danych są poprawnie zaimplementowane.