Sign inRegisterCheck connection

Wiring a Cookie Notice into a Cumulus Template

Where a cookie-notice include belongs in a Cumulus PHP template, what it must not block, and how to keep observations visible without storage.

Back to Cumulus weather software guides

A Cumulus site that remembers Celsius versus Fahrenheit usually does so with a first-party cookie. A cookie notice is a second include: a banner or short policy block that declares that storage. Wiring the two together is a template-placement job—where the include goes, which Cumulus extra file it must not ride, and what the notice is forbidden to hide. This dotted URL, /projects.eucookie, is that wiring note. It is not legal advice, not a compliance kit, and not a download of the old snippet.

The engineering tension between preference cookies and EU-era notices is the slash article, preference cookies and cookie notices. Read that for the documentation problem. This page is only how to attach a notice to a Cumulus skin without breaking the station. Modern TNET Weather does not offer cookie-law services and does not maintain Cumulus templates.

Historical context

Cumulus sites of that period were PHP on shared hosting. Operators processed HTML or PHP templates with web tags, uploaded them on the standard internet interval, and sometimes uploaded a separate realtime extra file on a much shorter timer. Community snippets named “eucookie” existed because forum templates had started asking for a visible notice. The Wiki TNET scripts catalog does not list eucookie as a surviving Saratoga binary; treat any recovered include as undocumented PHP, not as a current legal instrument (last checked 13 August 2026).

A later dotted path, /projects.eucookie.pkgs.wdtemp, names a Weather Display template-oriented pack. Weather Display and Cumulus use different file contracts. Do not drop a WD include into a Cumulus extra-web-file slot and call the install done.

Which file receives the include

Cumulus can substitute tags in more than one output. The notice belongs in the human page, not in the data feed.

Processed page templates. Standard HTML or PHP pages that already include a header and footer are the right target. Put the notice in that shared header (or immediately after <body>), so every page that shows observations also shows the same short inventory. One include, one markup block, one CSS class. Duplicating the banner in every template is how later edits drift.

Do not put it in the realtime extra file. Extra-web-file rows that tick Process and Realtime exist to refresh numbers. A cookie banner uploaded every 10–15 seconds wastes bandwidth, races the visitor’s browser, and can overwrite a static include with a stampeding copy. Keep notice markup on the standard (or end-of-day) interval, or as a file that lives only on the web host and is never rewritten by Cumulus.

Do not put it in realtime.txt. That file is one line of space-separated fields. It is not a template. A checker, a banner script, or JPGraph that parses it will break if you prepend HTML.

Do not wrap the data include. The PHP that requires a processed webtag file or reads realtime.txt must run whether or not a cookie exists. Gate the notice, not the temperature. If refusing storage blanks <#temp>, the install has turned a preference mechanism into a paywall on public observations.

On MX, extra files are configured in the interface with Process, Realtime, and UTF-8 checkboxes; on Cumulus 1 the equivalent was Configuration → Internet → Files. Use Process on the page templates. Leave Realtime unticked for the notice file.

What the include must not block

Four station functions are more important than the banner’s animation.

Observation rendering. Temperature, wind, and pressure must paint with storage empty. Unit conversion can be a query string, a one-request form, or the station’s native units as the default. Storage is a convenience.

Cumulus uploads. FTP or copy of realtime.txt, JSON, and extra files must not wait on a JavaScript consent callback. The logger PC does not have a browser. A notice that “blocks all cookies until accept” must not be implemented as blocking the upload user-agent. There is no visitor in that path.

Images and gauges. Banner PNGs, avatars, and graph scripts are derived renderings of an observed packet. They should keep working when the notice is declined, unless they themselves set a tracking cookie—which a honest GD banner should not.

Stale-file checks. A host-side checker that runs from cron or a Toolbox HTTP request is not a visitor. Do not require a consent cookie to stat realtime.txt.

If the notice uses JavaScript to hide the page until a click, you have blocked the weather. CSS that leaves the numbers readable with the banner stacked above or below is the workable pattern. position: fixed overlays that cover the thermometer are a failed install, even if counsel later likes the wording.

What to put in the include (engineering, not law)

Keep the markup boring and local.

  1. A short inventory of what this template actually writes: unit preference, language preference, maybe a “notice shown” flag. Name the cookie names you configured. Do not paste an e-commerce list of advertising networks the skin does not load.
  2. A link to a static policy page that lives on the same host, processed once, not on the realtime timer.
  3. A dismiss control that sets only the notice flag, not the unit cookie. Accepting “I have seen the notice” is not the same as “store Fahrenheit.”
  4. A no-JavaScript fallback so a text browser still sees the inventory. A <noscript> paragraph is enough.

Do not interpolate the inventory from $_GET. A cookie banner is a common XSS costume. Hard-code the names you use, or read them from a local config file outside the web root.

Do not load a third-party consent platform into a hobby PWS template unless you also add that vendor to the inventory. The historical project was a documentation wrapper, not a tag manager.

Directive 2002/58/EC as amended by 2009/136/EC, and later GDPR-era rules, are national-law questions. Official texts are on EUR-Lex for 2002/58/EC and EUR-Lex for 2009/136/EC (last checked 13 August 2026). This page does not tell you whether a unit cookie is “strictly necessary,” whether implied consent was ever enough, or what a given authority expects in 2026. Get advice in the relevant jurisdiction if you need it. Historical community snippets were not a substitute then and are not a substitute now.

Interaction with unit cookies

If the skin already sets units=C on first visit, the notice include must mention that cookie by name. If you change the skin to store units only after an explicit choice, change the inventory in the same commit. A notice frozen in 2010 while the template later added a map CDN is stale documentation—the same class of failure as a stale realtime file.

Keep station units (Cumulus configuration) separate from visitor units (cookie). The packet in realtime.txt remains the observed source. The cookie only chooses a derived label. Archive the station setting, not the last browser preference, if you keep screenshots for climate notes.

Distinct from the Weather Display pack

Install paths differ. WD templates often include a Settings.php and a different cookie family. Cumulus extra-web-file rows, processed webtag PHP, and realtime.txt are the Cumulus wiring. If you maintain both stacks, use two includes and two inventories. Sharing a single “eucookie” file across WD and Cumulus is how the wrong cookie names get advertised.

Practical checklist

  1. Put the notice in the shared header of processed page templates, not in the realtime extra file and not in realtime.txt.
  2. Leave Process on; leave Realtime off for the notice file.
  3. Confirm the temperature still renders with cookies deleted and JavaScript disabled.
  4. List the real cookie names; do not copy a shop banner.
  5. Do not block FTP, cron checkers, or image scripts on a consent callback.
  6. Keep the WD pack on its own path.
  7. Do not run recovered PHP that builds markup from query parameters.
  8. Do not treat this article as current law.

Modern relevance

Unit and language preferences still exist on station sites. The wiring pattern has not changed: one shared include, observations visible without storage, inventory matching what the template writes. How a given operator meets current law is outside this article.

TNET’s public pages distinguish observed, modelled, and derived information. A unit cookie is derived presentation. How the service works is the modern discussion of those evidence labels, not a cookie-law guide. The Cumulus projects map places this helper among integrations. The Cumulus legacy hub lists related historical pages.

Sources