/graphs2&action=login is the gate string for a second graph collection—a versioned or parallel set of figures—not a duplicate of the first gallery’s hotlink essay and not an observations article about reading traces. Weather sites grew a graphs2 when the first pack could not be changed in place: new sensors, a new JpGraph major version, a new log column map, or a climate-scale set beside the 24-hour set. Each collection needed its own URL. If the first collection was login-gated, the second often was too, with a separate session check so a cookie for v1 did not silently authorize v2.
There is no form on this page. TNET does not restore either gallery’s account table. The first collection’s reasons for gating (hotlinking and scrape load on a PHP renderer) live at /graphs&action=login. How a JPGraph figure must declare units and missing samples lives at plotting Cumulus observations. /graphs and /graphs2 as observation galleries are a different wave of articles; this URL does not write them.
Historical context
PHP weather CMS packages reused a pattern: graphs for the original scripts, graphs2 for the rewrite. Sometimes graphs2 meant extra sensors (UV, solar, soil) after the core temperature–pressure–rain pack shipped. Sometimes it meant a second style (filled plots, different fonts) after JpGraph 2.x versus 1.x broke includes. Sometimes it meant daily climatology images beside high-frequency traces. The public menu showed two entries. Crawlers captured two login URLs.
A single login action on graphs cannot honestly represent both collections. The query string on graphs2 is evidence that the site treated them as two resources. Preservation keeps two articles. Merging them would teach search engines that v1 and v2 were always the same lock on the same bytes.
The original scripts, ZIPs, and member cookies are not rehosted. JpGraph remains third-party software with its own licenses and PHP constraints (JpGraph, last checked 13 August 2026). TNET does not maintain it.
Why a second collection is a different authorization object
Access control is per resource, not per “graphs section of the website.”
Different bytes. A v2 renderer may read a new log format. Granting a v1 session the right to run v2 is granting a different program. If v2 includes extra sensors or a wider date range, the privacy and CPU profile changed.
Different hotlink surface. Forum users who inlined graphTemp.php might not have known graphSoil2.php existed. Publishing v2 under the same cookie as v1 advertises the new scripts to every session that only needed the old temperature PNG. Splitting login URLs (even when the password was the same) made the target visible in logs: which collection was being fetched.
Different cache and scrape behaviour. A climate-scale graphs2 that draws a year of daily maxima is a heavier job than a 24-hour trace. Rate limits and cache keys must differ. One gate HTML page in front of two renderers invites one crawler to hammer both.
Version pinning. Operators who were mid-migration needed v1 to stay frozen while v2 was tested. A shared login landing that always bounced to “the current graphs” destroyed that pin. Distinct /graphs2&action=login meant a bookmark still named the new set even when the operator’s menu still said “Graphs” for the old set.
None of this requires two passwords. It requires two resources. HTTP already models that: different paths, different authorization. Folding both into /graphs&action=login would be the mass-301 mistake applied to auth.
What “versioned graph set” means scientifically
Versioning a figure collection is not a theme refresh. It is a change to the experiment’s output contract.
If graphs2 added soil temperature, the collection gained a new observed quantity with its own sensor height and units. The info card and the figure caption must name that sensor. A login does not name it.
If graphs2 switched JpGraph major versions, fonts, and default smoothing, the pixels changed. Cubic splines and missing-sample handling can hide or invent ramps. The scientific rule does not change: no sample, no line. The versioned set must document which library version drew it. A cheat-sheet for includes belongs on the JPGraph wiki fragment; a library choice (GD vs JpGraph vs later JavaScript charts) belongs on graphics library notes. This login URL documents only that v2 could be locked separately.
If graphs2 was climatology (daily high/low/rain) beside graphs as high-frequency traces, the two collections are different evidence families: dayfile-scale historical appendix versus homemade realtime-log derived series. Gating them together implies they are interchangeable views of one series. They are not.
What this URL must not become
It must not be a second copy of the hotlink essay with “graphs2” search-replaced. The first login article already covers renderer theft and scrape load. Those threats still apply to v2; they are not the distinct thesis. The distinct thesis is split collections, split gates.
It must not be a fake upgrade announcement (“log in to see the new graphs”). There is nothing to log in to.
It must not steal the observations gallery. Reading a pressure trace, axis units, and holes in the series is /graphs / /graphs2 work for the observations cluster.
It must not restore credentials, session names, or password-file paths.
Practical checklist for a versioned gallery
- Give the new collection its own public path before you give it a lock.
- Document what changed: sensors, log schema, library version, time span.
- Do not reuse v1 cache filenames for v2 output (
temp.pngoverwritten by a new renderer is a silent experiment change). - If both are public, prefer static PNGs for both; if both are private, authorize each path.
- Caption v2 figures with the library version and the log they read.
- Keep the historical
&action=loginURL as documentation, not as a controller.
TNET research bridge
A versioned figure set is a provenance problem: which program, which schema, which interval. TNET’s public note on source identity and schema discipline is data sources, quality controls, and methodology. Observed versus derived labeling is how the service works.
The Cumulus hub indexes the software family. The first gallery’s gate remains /graphs&action=login. Neither path is a sign-in form.
Sources
- JpGraph (last checked 13 August 2026)
- Cumulus Wiki: realtime.txt
- Cumulus Wiki: Toolbox (last checked 13 August 2026)
- RFC 9110: HTTP Semantics
- TNET: data sources and methodology
- TNET: how the service works
- TNET Cumulus hub