A weather page is a pipeline, not a layout. Configuration is loaded first. Helpers that know how to format a temperature or open a data file come next. Only then does the document emit a head, a header clock, a menu, unique content, and a footer. If the pipeline is wrong, the HTML can look finished while every number on the page means the wrong thing.
The historical notebook at this URL walked through a six-include PHP stack in that order: settings, common helpers, document top, header, menubar, and footer. The companion article at /nb-0200 explains why personal weather sites shared that architecture. This page treats the stack as data-flow: how station ID, timezone, units, and file paths should live in configuration because those four choices change the meaning of every observation the site publishes.
The recovered tutorial’s source listings are not reproduced here. Modern TNET Weather does not ship or execute that package. The names below are the historical roles, described as a pipeline you can reimplement with any current layout tool.
Historical context
On the original weather-station site, /nb-0200/index.php was the long-form notebook page for the include system—the address a visitor reached when they opened the notebook directory. It described the same six files the parent URL advertised, then showed how a content page pulled them in. Neighboring notebooks supplied the functions and parsers that a real station site would call from the helpers layer.
The useful current question is not “what did the example files contain?” It is “what information must be bound before a page is allowed to print a number?” That is a data-flow question.
Bind configuration before you print a number
Every complete observation needs at least:
- Who / where — a station identifier, and preferably coordinates and elevation.
- When — a timestamp with a named timezone, not a bare clock string.
- What — the variable (air temperature, 10-minute mean wind, daily rain, station pressure).
- In which units — symbols that match the conversion actually applied.
- From which file — the path to the logger dump, so two pages cannot silently read different payloads.
Those fields are not chrome. They are the observation. If they are scattered through templates as literals, the site has no single place to correct a lie. If they are loaded once and then referenced, a correction is a scientific act: every page that inherits the pipeline publishes the same identity, time base, unit policy, and data source.
A settings file is the first stage of the pipeline because nothing downstream can be honest until those constants exist. In the historical design that file held a site-wide structure of the $SITE type: an associative collection of constants that every later include could read. The exact keys from the recovered example are not restated here. The keys that matter scientifically are the ones below.
What belongs in settings
Station ID. This is the name you will use when a map, a climate table, and a storm note must refer to the same instrument. Changing it in one article and not in the header splits the record.
Timezone. The header clock, the “last updated” line, the axis labels on a daily chart, and the reset boundary for “rain today” all depend on it. Mesa, Arizona, uses America/Phoenix (Mountain Standard Time year-round). A server that is set to UTC, or to a zone that observes daylight time, will shift every local timestamp if the settings file does not force the station zone before date() or equivalent runs. A wrong zone does not look like a crash. It looks like a plausible time that belongs to a different hour.
Units. Temperature, wind, rain, and pressure each need a declared unit. Dual display is a function of this policy, not a second set of pasted strings. If the settings file says pressure is inHg and a helper also prints hectopascals, both figures are derived from one stored value. If each template prints its own unit token, the tokens will diverge from the numbers.
Paths. The path to the latest observation file, the image directory, and the script directory decide which data the page is talking about. A relative path that resolves differently from /nb-0200/ and /nb-0200/index.php is a classic include-stack failure: two URLs for the “same” site read different files. Absolute paths (or paths resolved from a single web root constant) belong in settings for that reason.
A minimal original sketch of the idea, not a recovery of the historical file:
<?php
$SITE = [
'station_id' => 'mesa-az-pws',
'timezone' => 'America/Phoenix',
'units' => [
'temp' => 'F',
'wind' => 'mph',
'rain' => 'in',
'pressure' => 'inHg',
],
'obs_file' => __DIR__ . '/data/latest-obs.txt',
];
date_default_timezone_set($SITE['timezone']);
Load this once with require_once so a later include cannot silently replace the station identity.
Common helpers consume settings; they should not invent policy
The second stage is a helpers file. Its job is to turn settings plus a raw value into a labeled string, a safe link, or a parsed record. It should not contain a second copy of the unit policy.
A temperature helper that reads $SITE['units']['temp'] will stay aligned with the header legend. A temperature helper that hard-codes °F will not. The same rule applies to wind (statute miles per hour versus meters per second versus knots), rain (inches versus millimeters), and pressure (inches of mercury versus hectopascals). WMO and NIST unit practice is unforgiving on this point: the symbol is part of the quantity.
Helpers are also the right place to mark derived fields. Wind chill, heat index, humidex, and apparent temperature are not thermometer readings. If the helper that prints them always appends a derived label, every page that calls the helper inherits that honesty. If each article authors its own label, some pages will present a calculated index as an observation.
Optional parsers belong at this layer too, included only on pages that need them: a reader for the logger’s text file, a unit-conversion library, a graphing bootstrap. A climate table should not load a lightning parser. A current-conditions page should not load a report archive unless it uses it. Selective includes keep the pipeline short on pages where latency matters.
Document top: the head is also data-flow
The historical top include emitted the document type, language, character set, stylesheets, and the opening of the HTML head, and it stopped short of </head> so a content page could add page-specific scripts. That is still the right seam.
Two scientific choices live here even though they look like web plumbing.
Character set and language. Observation pages mix ASCII unit symbols, degree signs, and sometimes station names with diacritics. A wrong charset garbles the unit token, which is a data error, not a cosmetic one.
Cache policy. A brochure can be cached aggressively. A page that claims to show the latest observation cannot. The document head is where the station site declares that the representation is short-lived. If settings know the logger’s update interval, the head can describe that interval once for every page that inherits it.
The page title should also be data, not decoration. Settings can supply a default station name; the content page supplies a specific title (“Daily climate”, “Storm notes”) before the top include runs. Then the browser tab, the header, and any bookmark all name the same product.
Header: identity and the station clock
The visible header is where visitors check whether they are still on the same instrument. It should read the station name and the timezone from settings, then print a clock in that zone. If the header calls date() before the timezone is applied, the clock is a different variable from the timestamps in the body.
That coupling is the whole point of the pipeline. The header is not a logo file. It is the first consumer of station identity and time base. A logo path, too, should come from settings so a host move does not leave half the pages pointing at a missing image while the other half were edited by hand.
Menubar: the catalog of products
The menubar is how a reader travels among the station’s products: current conditions, climate, notes, configuration, text bulletin. Because it is included, adding a page is one edit, and every existing page offers the new product. That is information architecture, which for a station site is also data architecture. A climate table that cannot reach the siting page is a record with a missing method note.
A current-page marker (a variable set by the content page before the menu include runs) is legitimate state in this pipeline. It does not change observations. It tells the reader which product they are looking at, which reduces the chance they cite a climate extreme as a current reading.
Footer: provenance on the way out
The footer closes the document and should repeat the provenance that settings already know: operator or site credit, logger identity if you choose to publish it, last-modified time in the station timezone, and a notice that the page is not an official forecast office product. Last-modified is not the observation time. The observation time belongs with the payload and should be read from the data file. Confusing those two clocks is a common pipeline bug: the HTML file was deployed at noon, the logger packet arrived at 00:56, and the footer prints the deployment time as if it were the measurement.
Keep those clocks separate in helpers. Let the footer print file-modified if you need a “template touched” stamp. Let the body print observation time from the payload.
Putting the pipeline in order
A content page then becomes a short script: load settings, load helpers, set the page title, include top, include header, include menubar, print the unique body, include footer. The body is allowed to assume that $SITE exists, that the timezone is already applied, and that formatters will label values in the configured units.
That is the opposite of a page that opens a logger file, hard-codes MST, prints °F, and pastes a menu. The hard-coded page can be correct on the day it is written. It cannot stay correct when the station ID, the zone, the unit policy, or the data path changes.
For the blank inner page that inherits this pipeline and contains almost no unique science of its own, see /nb-0200/sample.php. For why the architecture spread among personal weather sites, see /nb-0200.
Practical checks on the data-flow
When you review a station site—PHP includes or any later equivalent—ask:
- Can I change the station ID in one place and see it on current, climate, and error pages?
- Can I change the timezone in one place and see the header clock, the observation timestamp, and “rain today” agree?
- Can I change temperature units in one place and see every temperature label follow, including dual-unit lines?
- Do two URLs for the “same” notebook resolve the observation file through the same path constant?
- Is observation time taken from the payload, not from the template’s last-modified stamp?
- Are derived indices labeled as derived by a helper, not by ad hoc adjectives in the body?
If any answer is no, the site still has a layout. It does not yet have a data-flow.
Modern relevance
Component frameworks and static-site layouts still have a first-loaded config, a formatter module, a document shell, and a content slot. The failure mode is unchanged: literals for units and zones leak into components, and two routes disagree about what a number means.
TNET’s how the service works note is the modern analog of this pipeline thinking. Evidence is usable only when its context—what kind of input it is, how fresh it is, how it should be read—travels with the result. Station-site configuration is the same idea at page scale. Related notebooks in the weather notebooks archive cover the conversion helpers and logger-file readers that this pipeline would call.
Sources
- World Meteorological Organization, Guide to Instruments and Methods of Observation (WMO-No. 8): community.wmo.int
- NIST Special Publication 811, Guide for the Use of the International System of Units (SI): nist.gov
- IANA Time Zone Database: iana.org/time-zones
- PHP
require_once: php.net/require-once - TNET, How the service works