A notice file is not a web page until something formats it. Weather Display could upload a whatsnew-style text file; a local PHP template still had to read that file, split it into dated blocks, and emit HTML that matched the rest of the station site. The wrapper is a different object from the notices. It can add headings, miss entries, and go stale while the text file sits on disk.
The historical TNET Weather page at /tws-sitenews.php was that wrapper. The tws- prefix marked a TNET Weather Station template script, not the stock /sitenews.php slot. Recovered copy on the page said the news lived in a simple text file that PHP read when the page was generated. This article is about that wrapping step. It does not reprint the captured notice list, does not rehost the script, and does not treat the URL as a live log.
Historical context
As the station site moved from a first PHP layout to a named generator (footer captures on sibling TWS pages printed a local web-generator version), filenames were prefixed so forks would not overwrite template originals. Site news was one of the forks. /sitenews.php remained the earlier, WD-oriented news URL. /tws-sitenews.php became the templated reading of a text file inside the TWS include system: shared header, menubar, CSS “SITE NEWS” markers, and a loop over records.
That split is ordinary in long-running PWS sites. The software vendor defines a file. The webmaster defines a presentation. Years later, inbound links point at both. If preservation collapsed them into one article, the backlink that expected the TWS script would land on the WD product description, and the backlink that expected auto-published whatsnew would land on a PHP include lesson. Both would be slightly wrong.
TNET Weather restores each path with a distinct job. This path’s job is the wrapper.
What the wrapper actually did
A typical TWS-style news script did four mechanical things.
- Opened a text file on the web host (not the logger database). The file was the published copy, already uploaded.
- Split records on a delimiter the operator had chosen: a heading line, a date pattern, or a blank-line convention. The recovered TWS page later used a format the operator described as easier to maintain than the first news layout.
- Emitted HTML that matched the site chrome: a heading, alternating boxes, optional links the notice text contained.
- Failed closed or failed messy when the file was missing, empty, or malformed. A blank news page could mean “no news” or “the include path broke.” Those are different outages.
The wrapper therefore sat in the publication chain after the station PC and before the visitor. It did not measure weather. It did not author the notices unless the operator typed into the text file by hand instead of through WD. Mixed authorship is the first provenance problem: a file that is usually auto-uploaded and sometimes edited in place has no single source.
The second provenance problem is completeness. The recovered TWS page included an operator admission that many changes were never listed. A wrapper cannot fix an unwritten log. It can only make the written part look official. That appearance is why a formatted news page is more misleading than the raw text file: CSS and headings imply editorial care that the file may not have received.
Distinct from /sitenews.php and from /news
Three URLs on this host touch “news.” They are not clones.
/sitenews.php is the auto-published WD whatsnew product: the idea of a station-software changelog in the same upload loop as ClientRaw. Read that article for what belongs in such a log and why it is not an observation.
/tws-sitenews.php (this page) is the local template/script that wrapped notices for the TWS layout. Read it for presentation, file-to-HTML conversion, and why a wrapper can drift from the file.
/news is the editorial operations log for the property as a site-history URL. It is not a WD slot and not a TWS include.
A fourth neighbor, /tws-sitemap.php, listed this page as “Site News” because the template knew the filename. That is include-graph knowledge, not a claim that the wrapper was complete.
When you cite a historical notice, cite the path you actually mean. “TWS site-news said X in a 2009 capture” is a statement about a wrapped page. “WD whatsnew recorded a probe change” is a statement about the software product. They may contain the same sentence. They are still different documents.
What the wrapper added, and what it hid
Presentation is not neutral.
Added. Consistent headings, dates in a visible place, links to sibling tools (parser, lightning page, credits), and the surrounding menubar that told a visitor they were still on a weather site. For accessibility, a text-and-CSS heading was better than a news GIF. The recovered earlier news layout had already moved from an icon to a text marker for that reason.
Hid. The raw delimiter, whether a record was truncated, whether two events shared one date, and whether the file on disk was older than the HTML cache. A wrapper that printed the newest twenty records hid the rest unless someone opened the file. A wrapper that sorted badly could put a 2012 server-move note above a 2005 webcam note and still look chronological.
Could leak. Notice text that mentioned internal hostnames, account paths, or unreleased scripts became public HTML. A template that echoed the file without sanitizing links could turn a changelog into an open redirect list. This article does not reproduce those lines. The lesson is to treat a news file as public the moment it is uploaded.
None of that makes the wrapper malicious. It makes it a derived page. Derived pages need a source citation: which file, which read time, which script version. TWS footers that printed a generator version were attempting that citation for the website. They rarely cited the news file’s own modification time next to each block.
Incomplete logs are the expected case
Operators skip news when the storm is happening, when the UPS is on the floor, and when the change feels too small. A template that always shows a polished “And the news…” heading makes that skip look like a complete diary. The honest caption is: these are the notices that were written and successfully wrapped, not the set of all station events.
For scientific reuse, prefer:
- logger files and monthly HTML for the measurements;
- a configuration page for hardware;
- the news file only as a dated hint that something in those records may have changed.
If the wrapper and the file disagree, the file wins for wording; the wrapper wins only as evidence of how the site presented that wording.
Practical checklist
If you still wrap station notices in PHP:
- Keep the text file the canonical log; the HTML page is a view.
- Print the file’s last-modified time on the page, separate from each item’s date.
- Do not let the wrapper invent headings the file did not contain.
- Limit public notices to sensor, software, and hosting events; keep gadget notes off the climate-facing view.
- Do not rehost an old news script with unknown rights; describe the workflow instead.
- Point readers at
/sitenews.phpfor the WD product and at/newsfor editorial continuity, rather than duplicating both here.
Modern relevance
TNET’s restored pages are themselves a wrapping problem: historical URLs presented in a modern layout without pretending the original generator still runs. The site-history hub is the primary modern destination from this URL. It is the honest index of continuity articles, including this wrapper explanation, without a fake news ticker.
How public research distinguishes observed, modelled, and derived information is how the service works. A TWS news page is derived presentation of a historical operations file. Source identity and quality-control language for records used in connection research live on data sources, quality controls, and methodology. The legacy hub remains the organized entry to the footprint.