Publishing Fundamentals

FTP publishing patterns, template variables, scheduling strategies, and caching — the practical foundation for getting station data onto the web.

FTP Publishing Patterns

FTP remains the most common method for pushing weather station pages to a web server. Despite its age, it works reliably when configured correctly. The two modes you need to understand are active and passive.

In active mode, the server opens a data connection back to the client. This works on local networks but fails through most NAT firewalls and home routers. Passive mode reverses the connection direction: the client opens both the control and data channels outward, which passes cleanly through firewalls.

If your FTP uploads fail intermittently — connecting but then timing out during file transfer — the first thing to check is whether you are using passive mode. Almost every residential internet connection requires it.

Directory Structure Best Practices

Organise your remote FTP directory so that HTML pages, images, and data files occupy separate subdirectories. A typical structure looks like this:

/public_html/weather/
  index.html          ← main page (template output)
  /images/
    temp_24h.png      ← 24-hour temperature graph
    wind_24h.png      ← 24-hour wind graph
    pressure_48h.png  ← 48-hour pressure graph
  /data/
    current.xml       ← latest readings
    daily.csv         ← daily summary

This separation matters because graph images are regenerated on a different schedule than the HTML page. If everything sits in one directory, you risk a half-uploaded state where the page references a graph that is still being written.

Templating and Variables

GraphWeather templates use variable placeholders that get replaced with live data at publish time. The syntax wraps variable names in delimiters — typically <%variable_name%> or {{variable}} depending on the application version.

Common variables include:

• outdoor_temp — current outdoor temperature in the configured unit
• outdoor_humidity — relative humidity percentage
• barometer — sea-level-corrected barometric pressure
• wind_speed, wind_direction — current wind readings
• rain_today, rain_rate — daily accumulation and current rate
• dewpoint — calculated dew point temperature
• windchill, heat_index — computed comfort indices
• last_update — timestamp of the most recent reading

Templates can include conditional blocks, loops over historical data arrays, and format specifiers for decimal places and unit suffixes. See the WeatherLink and Templates guide for detailed syntax reference.

Scheduling Strategies

How often you publish depends on your use case and server resources. Most hobbyist stations publish every 5 to 15 minutes, which is frequent enough for casual viewers and light enough to avoid FTP connection limits.

Three common scheduling approaches:

1. Built-in timer — GraphWeather desktop has an internal scheduler. Set the interval in the publishing configuration and let the application manage the cycle. This is the simplest approach and handles retry logic automatically.
2. Cron (Linux/macOS) — For server-side PHP publishing, a cron job triggers the data processing and upload script. A typical entry: */5 * * * * /usr/bin/php /home/user/weather/publish.php
3. Windows Task Scheduler — Similar to cron, for Windows-based setups where the desktop app is not running continuously.

Caching and Cache Busting

Weather graphs change every few minutes, but browsers and CDNs aggressively cache images. If your graphs appear stale to visitors, the problem is almost always caching rather than a publishing failure.

The most reliable cache-busting technique is appending a query parameter to image URLs that changes with each publish cycle:

<img src="/images/temp_24h.png?v=<%publish_timestamp%>" width="800" height="400" alt="24-hour temperature graph">

The Image Refresh and Caching guide covers this topic in depth, including CDN-specific strategies and HTTP cache-control headers.