WordPress Weather Station Publishing

Hosting requirements, GraphWeather PHP integration, FTP configuration, and caching strategies for running a weather station site on WordPress.

WordPress is one of the most common platforms that weather station operators land on when they want a web presence beyond a raw data page. The PHP runtime, FTP access, and cron support baked into most shared hosting plans make it a natural fit for GraphWeather PHP publishing workflows — and the content management layer is useful for operators who want to post observations, station notes, or setup guides alongside the automated data output. This guide covers the practical overlap: hosting requirements, directory layout, FTP configuration specific to shared WordPress hosts, and the caching quirks that catch people out when live weather data and an aggressive caching plugin share the same server. For background on publishing fundamentals independent of platform, see the Publishing Fundamentals pillar.

WordPress as a Weather Station Publishing Platform

The combination of WordPress and a GraphWeather PHP publishing workflow is more common than it might initially appear. Most shared hosting plans that run WordPress also provide everything GraphWeather PHP needs: PHP 7.4 or later, passive FTP access, and the ability to schedule recurring tasks via cron. The two systems occupy different parts of the directory tree and run independently on the same server without conflict.

What WordPress adds beyond a plain PHP hosting environment is a front-end layer: pages, menus, SEO handling, and a CMS for less technical contributors. If your station is part of a larger site — a local weather blog, a club with multiple stations, or a personal site where weather is one section among several — WordPress gives you a unified administration interface without forcing the weather publishing scripts into a secondary role.

What WordPress does not handle, and which operators sometimes assume it does, is the weather data pipeline itself. WordPress has no native concept of station data ingestion, graph generation, or automated FTP polling. That is GraphWeather PHP’s job. The two systems are wired together through directory placement and URL routing — nothing more complex than that, but it requires deliberate configuration.

Hosting Requirements

Not every WordPress hosting plan suits a station data publishing setup. Before choosing a provider, verify these specific capabilities:

• PHP 7.4 or later — GraphWeather PHP uses GD functions for graph generation that are unavailable in PHP 5 environments. Most current shared hosts run PHP 8.x, but some legacy plans are still on 7.2.
• Passive FTP access — almost every shared host requires passive mode. Confirm the host supports FTPS (FTP over TLS) if credential security on the upload leg matters.
• Cron job support — the server-side PHP scripts need to run on a schedule. Most cPanel-based shared hosts include cron access, but some budget plans restrict this to higher tiers.
• Sufficient storage for PNG graphs — a station generating 24-hour, 48-hour, weekly, and monthly graphs at 800×400 px produces roughly 200–500 KB per publish cycle. Plans with 5 GB storage handle this comfortably; 1 GB plans may not.
• PHP execution time above 15 seconds — graph generation with GD can push past a 15-second cap on overloaded shared servers, causing intermittent generation failures. Most reputable hosts default to 30 seconds or higher.

For a current comparison of plans that meet these requirements across the most commonly used providers, the full breakdown of wordpress hosting options covers the key variables — PHP version, FTP access, cron support, and storage — in detail.

Directory Structure: GraphWeather PHP Alongside WordPress

The standard approach is to install WordPress at the domain root and place GraphWeather PHP output in a subdirectory that WordPress does not manage. A typical layout:

/public_html/
  index.php                ← WordPress root
  wp-content/
  wp-includes/
  /weather/                ← GraphWeather PHP output (FTP target)
    index.html             ← generated station page
    /images/
      temp_24h.png         wind_24h.png
      pressure_48h.png
    /data/
      current.xml          daily.csv

With this layout, the station page lives at https://yoursite.com/weather/ and WordPress controls everything else. The FTP upload target in GraphWeather should point directly to /public_html/weather/. WordPress permalinks, .htaccess rewrite rules, and plugin URL handling are all rooted in /public_html/ and do not touch the /weather/ subdirectory.

The one common pitfall is WordPress’s default .htaccess catch-all rewrite rule. This rule runs after the static file check, so it should not affect files that actually exist on disk — but some caching plugins insert their own rewrite rules above the WordPress block that can intercept requests in /weather/. If the station page returns a WordPress 404 after first deployment, check whether a caching plugin has inserted rules above the standard WordPress rewrite block in .htaccess.

FTP Configuration on Shared WordPress Hosting

Shared hosting FTP behaviour has several quirks compared to a bare Linux server:

• Always use passive mode — shared hosts sit behind load balancers and firewalls that reject active-mode FTP data connections. “Connection refused” during file transfer while the control channel connects successfully is the passive-mode symptom.
• Respect connection limits — shared hosts frequently cap simultaneous FTP connections per account at 2–5. GraphWeather configured to open multiple parallel upload streams will hit this limit and fail with cryptic errors. Set uploads to sequential single-connection mode.
• Use the cPanel FTP hostname, not the domain name — some shared hosts route domain-name FTP connections through a different server than where your files live. The cPanel-specific hostname connects directly to the correct file system.
• Check file permissions after upload — some hosts set uploaded files to mode 600. Web-accessible files need 644. A 403 on a freshly uploaded page almost always means permission mode is wrong.

For a complete FTP configuration walkthrough covering passive mode, retry logic, and directory mapping, see the FTP Publishing Guide.

Caching and Data Freshness

This is the most common source of confusion when WordPress and GraphWeather PHP share the same hosting environment. WordPress caching plugins — W3 Total Cache, WP Super Cache, WP Rocket, and similar — serve static versions of pages as fast as possible. They are not aware that the /weather/ directory contains files that should never be cached beyond the next publish cycle.

The typical symptom is a station page that updates correctly for the first few visits and then serves a cached version for hours. The underlying GraphWeather PHP output is being overwritten correctly on the server; the caching layer is serving an older copy from its disk store.

Three reliable approaches, used in combination:

• Exclude the weather directory from the caching plugin — most plugins have an “excluded pages” or URL-pattern bypass. Add /weather/ and /weather/* to that list.
• Query-parameter cache-busting on graph images — append a timestamp variable to image URLs so each publish cycle generates a new cache key. GraphWeather templates support this via the publish_timestamp variable. See the Image Refresh and Caching guide for implementation details.
• Short Cache-Control headers on the weather directory — add a .htaccess inside /weather/ that sets Cache-Control: max-age=300 for HTML and PNG files. This overrides host-level and plugin-level headers and tells browsers and CDN layers these files are short-lived.

Embedding Station Output in WordPress Pages

Some operators want the station page inside the WordPress theme — sharing the header, footer, and navigation — rather than as a standalone HTML file. Three approaches with different trade-offs:

Original Knowledge Hub Archive

This section of the site was originally maintained as a WordPress installation hosting GraphWeather guides, tutorials, and reference material. That content has been reorganised into the current knowledge base for easier navigation and search. All original topic areas — desktop application setup, PHP web publishing, template variables, FTP configuration, and sensor calibration — are covered in the Publishing KB and Tutorials sections below.