A ZIP of PHP weather scripts is not a dataset. It is a claim: that a named author released a specific version, under a stated license, that still matches the bytes on disk. Historical personal-weather-station (PWS) sites treated /projects/downloads as the place to fetch those bytes. The useful question now is not “where is the file,” but whether anyone can still prove what the file was.
The projects hub lists historical Cumulus and Weather Display utilities. This page is the policy behind that list. It explains why an unlabeled archive is a provenance failure, what a responsible downloads record must contain, and why TNET does not rehost packages whose rights and integrity are unclear.
What a download page actually records
Station operators needed PHP that could read Weather Display HTML, Cumulus tags, or a realtime file and publish a table, banner, or feed. Community sites collected those helpers in one folder so a new operator did not have to hunt forum attachments. That convenience hid five independent facts that later readers still need:
- License. Permission to run a script on a private station is not permission to republish it. GNU GPL, Creative Commons, and “free for personal use” are different grants. If the grant is missing, redistribution is not a restoration task; it is a rights problem.
- Version. A filename such as
parser.phpdoes not identify a release. Weather Display and Cumulus change output layouts. A parser that matchedclimatedatayearout.htmlin one build can misread the next. Version is how you know which layout the author tested. - Source. Upstream may be the vendor, a named maintainer, or a forum thread. “Found on a weather site” is not a source. Saratoga Weather publishes scripts with an explicit use-at-your-own-risk notice and a version history. Official Weather Display and the Cumulus Wiki document current software behavior. Those are the places to start, not a third-party ZIP with no README.
- Integrity. A checksum (SHA-256 or similar) answers a later question: did this file change after it was posted? Without a hash, “the same script” is a guess.
- Security context. PHP that reads uploaded station files, writes cache, or renders images can be abused if it is hotlinked, left world-writable, or shipped with a debug switch on. A downloads page that omits PHP version, required extensions, and known unsafe patterns is incomplete even when the license is clear.
Those five fields are the minimum provenance record. A gallery of unlabeled ZIPs fails all five.
Why weather-script archives rot
PWS PHP lived on shared hosts, attached to forum posts, and copied between station sites. Several failure modes show up together.
License drift. A script released for personal station use gets bundled into a “template pack.” The pack’s page copies the filename and drops the license. Years later a domain expires, a Wayback capture stores the pack, and a new owner treats the capture as a right to redistribute. Acquisition of a domain does not transfer copyright in third-party code.
Silent edits. Operators patched regexes when Weather Display changed a table. The patched file kept the original name. Downstream sites mirrored the patch. There is then no single canonical file, only a family of near-copies. A hash would have made each fork visible; a name does not.
Missing runtime contract. Many scripts assumed English-language WD HTML, register_globals off or on, allow_url_fopen, or a particular GD build. Those assumptions were local. When the hoster changed PHP, the script failed in ways that look like “bad weather data.” The failure is often an environment mismatch, not a climate event.
Malicious substitution. A popular filename on an expired domain is an attractive place to put a different payload. Visitors who bookmark /projects/downloads expect a weather utility. A responsible successor site therefore refuses to serve an unverified binary even if the historical URL is preserved as an article.
What TNET does not rehost
TNET preserves historical URLs so incoming links still resolve. Preservation of an address is not republication of a package. This site does not offer ZIP, PHP, image, or template downloads from the old projects tree unless a license and redistribution right are verified. That is a deliberate gap, not a missing file.
The same rule applies to recovered source pasted into a Markdown page. A Wayback copy of a script is evidence of what once ran, not a grant to ship it again. Conceptual description of inputs and outputs is enough for a reader who needs to understand the workflow. The software and scripts hub points to those explainers.
If you still operate a station, get current software from the vendor and current community scripts from the maintainer who still publishes them. Saratoga’s script index and GitHub mirrors (ktrue) are examples of living upstream with version notes. Weather Display’s own download and documentation pages are the source for WD itself. Cumulus MX documentation lives on the Cumulus Wiki. TNET is not a substitute for those channels and is not affiliated with those projects.
A checklist for any weather-script catalog
Use this list when you inventory your own scripts/ directory or when you evaluate a third-party pack.
- Identity. Project name, author, homepage, and a version that is not “latest.”
- Grant. License identifier and whether commercial redistribution, modification, and warranty disclaimer are stated.
- Bytes. Filename, byte length, and a hash computed from the file you actually stored.
- Build target. PHP version, extensions (GD, XML, mbstring), and the station software plus file names the script reads (
clientraw.txt,climatedatayearout.html, Cumulus web tags). - Units and language. English WD HTML is not the same document as a translated climate table. Unit labels (°F vs °C, inches vs millimetres) belong in the record, not only in the rendered page.
- Known breakage. Note the date a vendor HTML change broke the parser. That note is more useful than a silent 200 response from a dead script.
- Threat model. Does the script fetch remote URLs, write files, echo request parameters, or expose a
/test/URL? Those are reasons to keep it off a public host, not features.
A catalog that cannot fill this list should link out, not attach a file.
Observed files versus derived packages
Keep the evidence types separate. An observed station file is what the logger or Weather Display wrote at a timestamp. A derived package is someone else’s PHP plus maybe a sample HTML snapshot. Mixing them on one downloads page trains readers to treat a forum ZIP as if it were a climate record.
TNET’s modern research pipeline has the same distinction at a different scale: public weather and network records are usable only when source, freshness, and quality controls are documented. That is why this historical downloads URL now points forward to data sources, quality controls, and methodology rather than to a file cabinet of unlabeled scripts.
Related historical tooling on this host includes PHP GD weather banners, which raise the same integrity questions for generated images, and the scripts index, which originally pointed operators toward WD extractors and third-party authors.
Practical migration
If you inherited a station site with a /downloads folder:
- Inventory files; do not upload them to a new public URL until the checklist is complete.
- Prefer replacing a local copy with a link to living upstream.
- Keep a private, hashed archive for your own disaster recovery if the license allows private copies.
- Treat old PHP that interpolates request data into shell or SQL as retired, even if it still “works.”
- Document the station software version that produced the HTML or CSV you still parse.
The historical TNET Weather site used this path as a project download section. The modern page keeps the path and replaces the mirror with the missing documentation: license, version, hash, source, and security. That is the only honest use of a downloads URL when the packages themselves cannot be cleared.