Sign inRegisterCheck connection

A Shared PHP Tooling Layer for Personal Weather Websites

Why PWS websites needed a shared PHP tooling layer: parsers, graphs, banners, and include templates as engineering problems, plus security and licensing lessons.

Back to PHP weather scripts and software guides

A personal weather station produces observations faster than a person can rewrite a web page. For more than a decade the practical answer was a shared PHP layer on the public host: small programs that read files the station software had already uploaded, then turned those files into tables, graphs, banners, and reusable page fragments. This article explains why that layer existed as an engineering necessity, not as a product catalog.

The historical TNET Weather site kept /scripts.php as an index of PHP utilities written for Weather Display websites, together with pointers to other community producers. The original page was a download list. This article is not that list. It is a taxonomy of the scientific and operational problems those scripts were trying to solve, and of the security and licensing lessons that still apply when someone inherits an old weather website.

Historical context

In the 2000s, most personal-weather-station (PWS) sites were not applications in the modern sense. Station software such as Weather Display ran on a computer next to the logger, wrote HTML reports and compact text packets, and uploaded those files by FTP on a timer. The public website was often a set of static pages plus a few PHP includes. Operators wanted current temperature, a sparkline of today's pressure, a climate table, and a banner they could paste onto a forum—without installing a database or rewriting the whole site after every software update.

PHP became the common language because it already ran on inexpensive shared hosting, could open a local text file, and could emit HTML or an image. A script that worked on one operator's host could be copied, with a path change, onto another. That reuse is why a hub page mattered. It was not merchandising. It was a way to name the recurring problems so the next operator did not have to rediscover them.

The historical index grouped work into families—sparklines, climate extractors, include snippets—and distinguished TNET-authored packages from scripts maintained elsewhere. That distinction is still the right one. TNET does not rehost those packages or claim copyright in recovered third-party code.

Why the website, not the logger, became the computation layer

Station software is responsible for talking to hardware, applying the operator's unit choices, and writing files. A public website is responsible for presenting those files to browsers, aggregating them, and surviving visitors. Mixing those jobs on the logger PC creates a fragile system: a crashed graph script can take down data collection; a public URL that executes code on the logger exposes the instrument.

The shared PHP layer sat on the opposite side of the FTP hop. Its inputs were files that already existed on the web host. Its outputs were HTML fragments, PNG or JPEG images, or rewritten responses. That split is a scientific design as much as a hosting convenience. It keeps the observation pipeline (sensor → logger → station software → file) separate from the publication pipeline (file → parser → page). When something looks wrong on the website, the operator can ask which pipeline failed.

PHP fit that split because it could open a local uploaded file, include shared headers across pages, and—with GD—emit a banner or sparkline without a database. Those same properties created the later failure modes: remote URL fetches, stale libraries, and licenses that never authorized redistribution.

The engineering problems, not the download names

Treat the historical script families as problem statements. The file names changed; the problems did not.

Parsing published station files

Station software wrote HTML reports and compact text packets so that a website could display observations without a round trip back to the logger. A parser's job was to turn a known file into named values: today's rain, this year's climate row, the current barometer. That is a data-quality problem before it is a web problem. If the file is missing, stale, truncated mid-upload, or written in a new column order after a software update, every downstream graph is wrong.

Climate-extraction snippets on the historical site read Weather Display files such as climatedatayearout.html and climatedataout.html into arrays so that graphs or tables could be built from structured values rather than from screen-scraped HTML. An averages/extremes extractor tried to do the same for daily summary HTML, and the historical notes already recorded the failure mode: Weather Display changed the output format, and the script stopped matching. That is the normal life cycle of a parser bound to a vendor's report, not a defect unique to one author.

The ClientRaw family of files is the densest example of this problem, but it has its own diagnostic article. Here the point is only taxonomic: parsers are instruments for making an uploaded file inspectable. They are not a substitute for the station software's own documentation.

Derived graphics from sparse updates

A table of numbers is faithful; a sparkline or banner is an interpretation. Graphics scripts took a time series or a current packet and drew a compact image that could be cached, hot-linked, or included in a template. The scientific risk is that the image looks authoritative while hiding missing samples, mixed units, or a file that stopped updating at 09:14.

Sparklines were attractive because they used little bandwidth and could sit beside a numeric readout. Banners and avatars served a different social function: they advertised that a station was alive. Both still depend on the same quality questions: when was the source file written, in which units, and was the upload atomic?

Include templates as a publication architecture

A weather site with twenty pages cannot afford twenty copies of the same header. Include-based templates were how operators kept chrome consistent. The notebook series treated that architecture as an inspectable method; the scripts hub treated it as a dependency. "Copy this file into your web root" was never a complete install: the operator still needed the path to uploaded WD files, a PHP version, and any required image libraries.

Access control around observation packets

Some scripts tried to wrap the compact observation files so that not every visitor, scraper, or remote parser could pull them directly. The historical ClientRaw-process idea used Apache rewrite rules to send requests for those files through a PHP gate. The engineering problem is real: a file that updates every few seconds is a public API whether or not anyone named it that. The security problem is equally real: a gate that is itself a remote-fetch proxy can become an open relay.

This article does not reconstruct that gate. If published weather files must be restricted, the restriction belongs in server configuration, not in an unmaintained PHP wrapper.

A taxonomy of historical TNET script families

The following families appeared on the historical hub. They are listed as problem classes so they are not mistaken for a current download catalog. TNET does not offer these packages for download.

| Family | Scientific / engineering job | Typical inputs | Typical outputs | Distinct from | |---|---|---|---|---| | Climate and summary extractors | Turn vendor HTML climate or averages reports into arrays or styled tables | Weather Display climate HTML, daily avg/ext HTML | Arrays, HTML tables | Not a ClientRaw field dictionary | | Sparkline / graph utilities | Render a compact time-series image from uploaded station data | WD data files already on the host | PNG/JPEG graphs | Not Cumulus JpGraph packages | | Banner and identity images | Encode current values into a small branded image | Compact current-conditions files | PNG banners or avatars | Covered as a project-packaging problem on /projects | | Include-template helpers | Share header, menu, and data includes across pages | PHP fragments plus local data files | Assembled HTML pages | Notebook series on include architecture | | Packet-access wrappers | Intercept requests for frequently updated files | HTTP requests for named files | Filtered or rewritten responses | Not a live diagnostic parser |

Neighboring community collections filled gaps the hub did not try to own. Saratoga Weather published AJAX updates, forecast includes, advisories, radar helpers, and template sets, and remains the place to look for maintained PHP weather scripts (last checked 13 August 2026). CarterLake published early PHP forecast, advisory, and template work that other operators then adapted. Those sites are independent. TNET is not a mirror of either.

Security lessons that outlived the scripts

A PHP weather utility from the mid-2000s was often written for a trusted operator on a quiet host. The internet in front of that host changed.

Remote file fetch. A parser that accepts a URL and retrieves another site's clientraw.txt is convenient for diagnostics and dangerous as a public service. It can be used as a server-side request proxy, it can hang on a slow or missing host, and it can leak the server's IP to whoever is being fetched. Timeouts, allow-lists, and disabling unused URL-fetch features are the minimum modern controls. The Open Worldwide Application Security Project documents this class of abuse as server-side request forgery.

Untrusted includes and leftover admin paths. Weather sites accumulated phpinfo tests, sample parsers, and "manage site" links. Anything that still executes on a public host is part of the attack surface, including forgotten beta scripts labeled "not available yet."

Upload races. Station software that overwrites a file in place can present a truncated packet to a parser that reads during the FTP. Atomic rename after upload—write to a temporary name, then replace—was already recommended in Weather Display template setups for this reason. A script that assumes every read is a complete line will eventually publish nonsense.

Dependency rot. GD, JpGraph, PHP 5-era short tags, and register_globals assumptions do not travel cleanly onto current hosts. A script that "just needs PHP" in 2009 may require an isolated interpreter in 2026. Incompatibility is a safety signal: do not copy the file onto a production host to "see if it runs."

Logging visitors. Some historical tools advertised that every connection was logged, including IP addresses. A modern diagnostic should not collect visitor addresses without a documented retention policy. This article does not log anyone.

Licensing: named licenses, unclear packages, and what not to rehost

The historical hub said that some TNET-authored scripts were packaged with documentation and that many were labeled GNU GPL. Other community scripts were posted as freeware. Those are historical labeling claims, not a license grant from TNET Weather today, and they do not authorize redistributing recovered ZIPs, click-tracker downloads, or pasted PHP.

Three practical rules follow:

  1. If the license is GNU GPL and the corresponding source is still available from a rights holder who offers it, the GPL's terms govern copying. TNET is not volunteering to be that archive.
  2. If the license is unclear, describe the workflow and point operators toward maintained collections. For Weather Display PHP templates and related scripts, that collection is Saratoga Weather, not a recovered forum attachment.
  3. Do not treat a Wayback snapshot as a software repository. A captured script.php is evidence that a tool existed. It is not a verified, patched, redistributable package.

Credits matter for the same reason licenses do. Parser work on this site historically named collaborators and credited Brian Hamilton as the author of Weather Display. That is attribution of a third-party product, not an endorsement of TNET by the vendor.

Practical checklist for an inherited weather website

If you take over a PWS site that still contains /scripts/ folders, treat the tree as an instrument log, not as a theme pack.

  1. Inventory files that still execute. Note PHP version, enabled extensions (GD, curl), and whether any script fetches remote URLs.
  2. Identify the station-software outputs they expect. Weather Display climate HTML, ClientRaw packets, and Cumulus realtime.txt are different contracts. A script aimed at one will misread the other.
  3. Record units and timestamps as metadata. A banner that prints 72 without saying Fahrenheit or Celsius is not an observation; it is a decoration.
  4. Disable remote-fetch entry points until you know who is allowed to use them.
  5. Do not re-upload recovered ZIPs from unknown click trackers. Prefer current official documentation for Weather Display and, for PHP templates, Saratoga's maintained sets.
  6. Keep the observation pipeline running even if the pretty layer is broken. Missing sparklines are an inconvenience. A logger that stopped because a website script crashed is a data loss.
  7. Write down what you cannot verify. A climate extractor that "used to work" is a hypothesis until it is tested against a dated file.

What still applies

The shared PHP layer was a response to a real constraint: station software published files, and the web host had to interpret them. That constraint has not vanished. Operators still upload compact current-conditions files, still generate NOAA-style HTML reports, and still want a page that can be checked without proprietary dashboards.

What changed is the platform: PHP versions, TLS, SFTP, and content-security policies make 2009 copy-paste scripts a poor default. The durable knowledge is the taxonomy. Mixing parser, graphics, and access-control jobs in one file is how a climate table becomes an open proxy.

Community maintenance moved to Saratoga's Weather Display PHP tradition (including earlier CarterLake work). Official Weather Display documentation remains the authority for what the station software writes. TNET's role on this URL is to explain the tooling layer, not to run a script store.

TNET research bridge

The same questions that made a PHP parser necessary—freshness, units, file completeness, and provenance—are the questions a research pipeline asks of any public weather record. TNET's public note on data sources, quality controls, and methodology describes how those principles apply to the weather and network records used in connection research, without publishing proprietary assembly rules.

The software and scripts hub collects the related historical articles. For the ClientRaw packet as a diagnostic object, see the Weather Display ClientRaw Parser. For how community projects were versioned and credited rather than merely listed, see weather-software project packaging. For reproducible mini-methods that sat beside these scripts, see the weather notebooks hub.

Sources