Sign inRegisterCheck connection

Common PHP Site Design for Personal Weather Stations

Why personal weather websites shared one include-based PHP architecture: a single change to chrome, units, or navigation updates every observation page.

Back to Personal weather station notebooks

A personal weather website is a publishing system for measurements. Every page that shows a temperature, a rain total, or a pressure tendency is making a scientific claim, and that claim is usable only when the number travels with the same metadata everywhere: station identity, timezone, units, and a consistent frame around those fields. That requirement—not a preference for a particular template look—is why dozens of personal weather websites in the PHP era shared an include-based architecture. One change to chrome, navigation, or unit labels could update every page because those decisions lived in shared files rather than in dozens of independent HTML documents.

This URL is the historical TNET Weather notebook that other sites cited as a reference for that common PHP site design. The article explains why the architecture existed and what it protected. It does not redistribute the recovered tutorial, offer the old PHP for download, or claim that modern TNET Weather authored or still ships the package.

Historical context

The original weather-station site kept a notebooks series for operators who published backyard observations with PHP. The notebook at /nb-0200 documented a small include stack that assembled a document head, header, menu, and footer around unique page content. Neighboring notebooks covered logger file layouts, NOAA-report parsing, and unit-conversion helpers. Incoming links treated this address as the explanation of shared site chrome, which is why the URL remains a backlink target.

The recovered page was a worked tutorial with named include files and example fragments. That expression is not reproduced here. The useful residue is the problem the notebook was solving: a station site with many page types (current conditions, climate tables, storm notes, webcam pages, error pages) that all had to remain scientifically comparable to one another.

Modern TNET Weather preserves the address and the subject as part of the weather notebooks archive. It is not a continuation of the original tutorial as a runnable product.

An observation is a number plus its frame

Meteorological practice treats metadata as part of the measurement. The World Meteorological Organization’s Guide to Instruments and Methods of Observation (WMO-No. 8) is explicit that an instrumental reading is not a complete observation until it is accompanied by time, location, and the other identifying information that lets another analyst use the value. A temperature of 40 with no unit is not an observation. A timestamp with no timezone is not an observation. A rain total with no accumulation rule—calendar day, rolling 24 hours, or water year—cannot be compared with the neighboring station.

Personal weather sites fail that standard in a specific way. The logger may be recording a defensible value. The website then copies unit symbols, station names, and clock labels into every HTML page by hand. After a year of edits, one page still says MST, another says MDT, a climate table still says inHg after the current-conditions page switched to hectopascals, and a mesonet link still uses last year’s station identifier. Visitors think they are comparing stations. They are comparing inconsistent publications of stations.

Include-based design does not make the sensor more accurate. It makes the publication internally consistent, which is the precondition for comparing pages on one site and, later, for comparing sites in a loose backyard network.

Why weather sites needed shared includes more than brochure sites

A news archive can tolerate a slightly different header on a 2003 article. A weather site cannot tolerate a slightly different unit legend on yesterday’s climate table. Personal weather operators in the 2000s typically did four things at once:

  1. Ingested a frequently updated data file from station software (Weather Display clientraw-style dumps, later Cumulus realtime files, and similar text payloads).
  2. Published many page types from one instrument: current conditions, daily climate, trends, lightning, webcams, and narrative notes.
  3. Participated informally in networks where visitors compared neighboring backyard stations as if they were a mesonet.
  4. Changed operational details—timezone labels, unit policy, logger version credits, navigation to a new graph—more often than they changed the underlying science.

Those operators needed the site to behave like a small instrument network, not like a pile of handmade pages. PHP was the available server language on inexpensive hosting. require_once on a settings file, then a handful of chrome includes, was the practical way to keep constants and presentation in one place. Shared CSS handled appearance. Shared includes handled structure and the metadata that gives every number its meaning.

The pattern was never unique to one notebook. Homemade include stacks, widely copied Weather Display PHP templates, and later content-management themes all solved the same problem. This URL became a cited explanation of the common design rather than a downloadable product that every site ran.

What “one change updates every page” actually protects

The operational slogan is easy to remember. The scientific content is narrower.

Chrome is identity. Logo, site name, and header clock tell the reader which station produced the page. If half the URLs still show an old station name, two pages cannot be treated as the same instrument.

Units are part of the value. A shared settings file can hold the unit policy; shared helpers can format every temperature, wind, rain, and pressure figure from that policy. The symbol and the conversion stay coupled. Scattered hard-coded °F strings do not.

Navigation is the catalog of the record. Current conditions, daily climate, storm notes, and siting information are products of one station. A shared menu keeps them in one information architecture so a reader can move from a number to the page that explains how it was taken.

Footer credits are provenance. Operator name, logger software, and a notice that the site is not an official National Weather Service product belong on every observation page. A shared footer is a cheap way to keep that provenance attached to every number.

Error pages are still station pages. A 404 that does not inherit the same chrome is a hole in the record: the visitor has left the instrument’s frame even though they are still on the host.

None of those concerns is cosmetic. Each one is a class of silent error that makes published observations harder to compare.

The six-include idea, without the old tutorial

The historical notebook described six shared pieces: a settings file of site constants, a helpers file, a document-head fragment, a visible header, a menubar, and a footer. Optional extras—unit-conversion functions, a parser for the logger’s text file, a graphing library—were included only on pages that needed them.

That split still maps onto a clean scientific design:

| Shared concern | Why it is shared | |---|---| | Station ID, timezone, units, data paths | They change the meaning of every number | | Formatting helpers | They keep labels and conversions in lockstep | | Document head | Charset, language, and cache policy apply to the whole station site | | Header and menu | Identity and information architecture | | Footer | Credits, last-modified stamps, and closing markup | | Page body | The unique observation, article, or table |

This page is about why that split existed. The companion article at /nb-0200/index.php treats the same stack as a data-flow: how configuration moves into every rendered number. The sample at /nb-0200/sample.php treats the unique body as content versus chrome—the blank inner page that inherits the frame.

The historical PHP is not executed here and is not offered as a package. Recovered include trees from unknown archives are a poor choice for a public server: they are unmaintained, often tied to obsolete PHP behavior, and they are not licensed for redistribution by virtue of having been captured in a web archive. The reusable idea is the metadata discipline, which can be implemented with any current layout system.

Comparable presentation across a station network

A backyard network is scientifically useful only when visitors can compare like with like. That does not require identical hardware. It requires a shared publishing contract.

Same time base. Archive in UTC when you can. If you display local time, name the zone. Mesa, Arizona, is a standing example: America/Phoenix is Mountain Standard Time year-round, which is not the same as a Mountain zone that switches to daylight time. A header clock that calls the zone “MST” in July on a Denver station is a different error from a Mesa station that really is on MST in July. The include file that sets the timezone is where that distinction belongs.

Declared units. Dual display (Fahrenheit and Celsius, inches of mercury and hectopascals) is fine when both strings come from one conversion path. Dual display that was pasted independently onto each page will drift.

Station identity on every page. A map that links into pages with mismatched identifiers is a data-integrity bug. The identifier belongs in settings, then in the header or a linked station-information page, not in a comment that only one article author remembered to update.

Honest observation versus derived. Heat index, wind chill, humidex, and apparent temperature are derived. They must not be presented as thermometer readings. A shared helper that labels derived fields reduces that class of error across the whole site.

Siting notes in the inherited frame. If the thermometer sits over asphalt, or the rain gauge is sheltered by an eave, that fact belongs in chrome or on a configuration page linked from chrome. It should not live only in a single notebook entry that search engines never associate with the current-conditions URL.

Those rules are why include-based design was a weather practice and not merely a web-design fashion. They are the same rules that make official station networks comparable, scaled down to a single operator’s site.

Practical checklist

If you maintain a station site today:

  • Put station ID, coordinates, elevation, timezone, unit policy, and the path to the latest observation file in one configuration source.
  • Format every temperature, wind, rain, and pressure value through helpers that read that policy.
  • Inherit header, navigation, and footer. Do not paste them into articles.
  • Label derived quantities as derived.
  • Keep one siting-and-instrument page and link it from the inherited chrome.
  • Treat cache headers as part of the observation: a page that claims “current” conditions must not be cached like a static brochure.
  • Do not run recovered PHP from an archive on a public host. Reimplement the layout with a maintained toolchain.

What still applies

Layouts moved from PHP includes to components, static-site partials, and server frameworks. The metadata problem did not move. A modern page that hard-codes unit strings in twelve files has the same failure mode the 2000s notebooks were preventing. The scientific motivation remains consistent metadata and comparable presentation of observations across a station network—even when that “network” is one backyard station with many URLs.

TNET’s public note on data sources, quality controls, and methodology is the current counterpart of that discipline: observed, modelled, and derived information are distinguished, and source quality is treated as part of the result rather than as decoration around it. That is the useful next step if you care about how numbers are framed. The weather station archive collects the related historical instrument pages.

Sources