A PHP weather site lives and dies by include paths. Partners who want a shared current-conditions strip do not want to guess whether the fragment lives in /SWN/, /SWN_new/, or a file in the web root. The historical URL /swn-page.php is the root alias: the short, embeddable address for the same networked conditions module. It is not a third mesonet, not a live Mesa meter, and not a different scientific product from the directory copies.
This article answers why three URLs existed. The data contract (identifier, time, units) belongs on /SWN/SWN-page.php. The HTML/CSS restyle belongs on /SWN_new/SWN-page.php. Here the subject is addressing: how an include is referenced, copied, and kept stable for other sites.
Recovered dumps of this root file are historical. Observation tables from those captures are not current weather and are not reprinted here as a live report.
Historical context
Server-side includes were the integration API of personal weather websites. A typical partner page looked conceptually like “header, my station stats, shared regional strip, footer.” The regional strip had to be one fetch or one include away. A file in the document root named swn-page.php is the path of least resistance: it works with a short relative include, a hot-link, an iframe src, or a documented absolute URL on the same host.
The path token SWN still denotes that shared conditions module. This article does not invent an official expansion of the letters. Recovered dumps described a southwestern affiliation of personal weather websites; that historical labeling is not treated here as a currently operating, independently verified organization. The function of this URL is the alias.
A recovered member roster on this path carried a December 2008 stamp. Directory copies on the same host have other snapshot dates. Those dates show coexistence, not a mystery. Aliases and sandboxes are how PHP sites ship. They are not three separate observation networks.
Why a root alias is not a duplicate article
Search engines and humans see three URLs and assume three topics. The honest distinction is operational:
| URL | Role | What a backlink usually meant |
|---|---|---|
| /swn-page.php | Root alias; embed and include target | “Put this path in your template” |
| /SWN/SWN-page.php | Namespaced production fragment plus assets | “The module lives in this folder” |
| /SWN_new/SWN-page.php | Parallel restyle | “Try the new layout without breaking the old include” |
If this page only repeated the contract article, it would be a clone. The root file’s job is to explain resolution: which path a partner should pin, what happens when that path moves, and why a site that included the root file did not need to know about _new until it opted in.
That is the same class of problem as a package having a canonical import path and a versioned directory. Weather did not require three URLs. Deployment did.
How three URLs arise on a PHP host
The mechanics are ordinary and still bite people who inherit weather sites.
Includes are path-literal. include 'swn-page.php'; and include 'SWN/SWN-page.php'; are different files even if they once rendered similar tables. A webmaster who documented the short name created inbound links and template lines that must keep working.
Directories carry assets. A folder can hold CSS, a map image, and the member list beside the fragment. The root file may have been a thin wrapper that included the directory copy—or a standalone snapshot used for embeds. Either way, the public URL is the contract with partners. Changing it without a redirect breaks foreign templates. This restoration keeps the historical path as a 200 article; it does not claim the old include still executes.
Case and spelling matter. /SWN/ and /swn-page.php differ in case and in whether a directory exists. On Windows development hosts they can look interchangeable. On a case-sensitive production server they are not. Three URLs is sometimes an accident of that mismatch plus a later tidy-up that never deleted the old entry point.
Sandboxes must not overwrite embeds. If twenty partner sites include the root file, you cannot test a layout change on that file. You test on _new and leave the alias stable until members switch. That is why the restyle URL and the alias URL must remain distinct in the historical footprint.
What an embeddable conditions module owes its callers
Callers of a root alias are other websites, not only human visitors. That changes the product requirements.
Stable path. The alias should not move when the stylesheet does. Visual work belongs under _new or in CSS files the fragment references.
Stable field set. An iframe or a remote include that parsed columns will break if the alias silently tracks a restyle that dropped the timestamp. Pinning the alias to the production contract is the conservative choice.
Honest failure. If the harvest cannot build a table, the alias should not serve last week’s HTML without a date. An embed that looks “live” because the parent page refreshed is a lie if the fragment is stale.
No implied authority. An embedded strip of personal stations is still personal stations. It is not an NWS product. Putting the alias in a sidebar does not promote the rows to quality-controlled MADIS observations. Publishing to CWOP or a map network is a different path, with different IDs.
Configuration still belongs to each member. The alias does not replace a station’s own configuration record. Siting, sensor suite, and units are metadata on the originating site. The include only harvests what members already published.
Practical guidance if you find this path in an old template
If a recovered site still points at /swn-page.php, /SWN/SWN-page.php, or /SWN_new/SWN-page.php:
- Treat all three as historical addresses for the same module family, not as live feeds.
- Do not copy archived temperatures into a “current conditions” block.
- If you are rebuilding a regional strip, implement a documented JSON or HTML contract with ID, time, and units per row—then give it one canonical URL and, if needed, one alias, not three competing bodies.
- If partners need a restyle, version the path or the payload; do not silently retarget the alias.
- Prefer official observations when the use is climatology or hazards. The National Weather Service and MADIS/CWOP exist for ingest and QC. A hobby include does not.
The weather-station hub is the index for this family of pages. That is the natural next step if you arrived here from an old embed and need the surrounding station articles rather than a dead include.
Modern relevance
Today the alias problem shows up as vanity API paths, CDN origins, and widget script URLs. Teams still keep /v1/ live while /v2/ is designed, and they still regret it when documentation listed the short name. The lesson from this URL is not nostalgia for PHP. It is that the include path is part of the observation product. Change the path and you have changed what partners fetch, even if the sensors did not move.
TNET’s public discussion of source identity and freshness is data sources, quality controls, and methodology. How observed, modelled, and derived information are distinguished in TNET’s own service is how the service works. Neither reconstructs this alias, and this alias is not a current TNET widget.
Sources
- TNET, Weather-station hub
- TNET, Data sources, quality controls, and methodology
- NOAA / NCEP MADIS, Citizen Weather Observer Program: madis.ncep.noaa.gov/madis_cwop.shtml