Wetter-Widget para TYPO3

Los sitios de turismo que no muestran el tiempo actual regalan una de las informaciones más buscadas

Cuando alguien busca en Google “tiempo Mallorca” o “Sierra Nevada tiempo ahora”, espera encontrar en el sitio del destino una indicación meteorológica. Si no la hay, el visitante abandona la página y acude a una aplicación del tiempo. Eso es una oportunidad perdida, porque el visitante ya estaba en el sitio correcto. weather2 integra datos meteorológicos actuales en TYPO3: temperatura, condiciones, precipitaciones, viento, humedad y una previsión a varios días. Los datos proceden de OpenWeatherMap o APIs equivalentes y se actualizan en un intervalo configurable. Para los sitios de turismo, los portales de eventos al aire libre y los portales regionales de noticias, es una función estándar que los visitantes esperan encontrar.

Los escenarios típicos abarcan portales de destino, campings y estaciones de esquí

El escenario más frecuente es el portal de turismo de una región. La oficina de turismo de un municipio del Mediterráneo muestra en su página de inicio el tiempo actual: 22 grados, soleado, temperatura del agua 19 grados. Al lado, una previsión a cinco días. Los visitantes que planifican una excursión de un día obtienen al instante la información relevante y permanecen en la página para reservar actividades. La temperatura del agua llega desde un endpoint de API independiente o se mantiene manualmente.

Un segundo escenario son los campings y los parques vacacionales. Un camping del Pirineo muestra en su página de reservas el tiempo de la próxima semana. Los visitantes que dudan entre dos semanas de viaje pueden usar la previsión como ayuda para decidirse. Para el operador del camping es un argumento de conversión: “Hace sol, reserve ahora”.

Tercer escenario: estaciones de esquí y eventos al aire libre. Una estación de esquí muestra la temperatura en cumbre y en valle, el espesor de nieve (desde una fuente de datos aparte) y la velocidad del viento. Un festival al aire libre muestra la previsión meteorológica para el fin de semana del festival. En ambos casos, la indicación meteorológica aporta un valor concreto que mantiene al visitante en el sitio.

La arquitectura técnica recupera los datos meteorológicos por API y los cachea localmente

weather2 se comunica con la API de OpenWeatherMap (o, alternativamente, con proveedores como WeatherAPI, Visual Crossing o Meteostat). La configuración en el backend de TYPO3 define: API-Key, ubicación (coordenadas o nombre de la localidad), unidades (métrico/imperial), idioma e intervalo de actualización. El intervalo estándar es de 30 minutos, es decir, cada 30 minutos se envía una petición a OpenWeatherMap y la respuesta se cachea en la base de datos TYPO3.

El plugin de frontend renderiza los datos meteorológicos mediante plantillas Fluid: temperatura actual, icono del tiempo (sol, nubes, lluvia), descripción en texto, viento, humedad. La previsión a varios días muestra la mínima y la máxima del día para tres a siete días. Los iconos se suministran como SVG, no como URLs de imágenes externas, para que no haya peticiones adicionales a servidores de terceros.

Para la API-Key, OpenWeatherMap ofrece un plan gratuito con 1.000 llamadas al día, lo que con un intervalo de 30 minutos (48 llamadas al día) es más que suficiente. Para sitios con varias ubicaciones (por ejemplo, una oficina de turismo con 10 municipios) se necesitan 480 llamadas al día, lo que sigue estando dentro del plan gratuito. Los planes Pro (desde 40 dólares al mes) ofrecen actualizaciones cada hora y datos ampliados como el índice UV y el polen.

Los problemas habituales afectan a los límites de la API, al caché y a los datos obsoletos

El problema más frecuente es superar el límite de la API. Si el caché de TYPO3 no está configurado correctamente y cada request de página dispara una llamada a la API, el límite del plan gratuito de 1.000 llamadas se alcanza en pocas horas. La extensión dejará entonces de mostrar datos o mostrará un error. La solución: asegurarse de que los datos meteorológicos se almacenan en el caché de TYPO3 y no se vuelven a solicitar en cada request de frontend. El cacheo debe funcionar con independencia del caché de página (tarea Scheduler o entrada de caché propia).

Segundo problema: datos meteorológicos obsoletos. Si la tarea Scheduler no se ejecuta (cronjob desactivado, migración del servidor), el sitio muestra datos del tiempo con días o semanas de antigüedad. Eso es peor que no mostrar nada. La solución: incorporar en la plantilla Fluid un fallback que compruebe si los datos cacheados tienen más de dos horas y, en ese caso, oculte el widget en lugar de mostrar datos erróneos.

Tercer tema: protección de datos. Si los datos meteorológicos los obtiene el cliente directamente vía JavaScript desde la API, el navegador transmite la IP del visitante al proveedor de la API. Se trata de una transmisión de datos a terceros con relevancia en materia de RGPD. La solución del lado del servidor (el servidor TYPO3 consulta la API, no el navegador) evita este problema.

TYPO3 v12 está soportado, la integración con la API sigue siendo estable entre versiones

weather2 utiliza la librería HTTP Client de TYPO3 para las peticiones a la API y plantillas Fluid para el renderizado. Ambas cosas son estables en el core de TYPO3. Bajo v12 la extensión funciona sin problemas. Para v13 se necesitan ajustes mínimos (registro de tarea Scheduler, configuración del plugin). Como la lógica central (petición HTTP, parseo JSON, almacenamiento en base de datos) está estandarizada, la extensión se mantiene con poco esfuerzo en los upgrades de TYPO3. Gosign configura widgets meteorológicos como parte de los proyectos de sitios turísticos y se asegura de que el caché de la API, el fallback y la protección de datos estén correctamente implementados.