Every release, on the record

Recent releases

1. v1.1.6 30 June 2026

   Public website mode and new module extension points

   A feature release that lets an installation double as a public website and widens what modules can add. With a frontpage module enabled, Wintertrace serves a public homepage at the root URL and lets you choose exactly which pages search engines may index — while login, the admin area, the customer portal and the driver app stay private and unindexed, as before. Under the surface, modules gain three new ways to extend the app: custom job types, extra fields in the driver shift and job flows, and a GPS-position signal. Fully backwards compatible; no database migration.

   Added

   • Public website mode. A frontpage module can take over the root URL and serve a real homepage instead of redirecting visitors to login, so an operator with no website of their own can run their public site and their job documentation from one installation. Everything else stays private by default.
   • Precise control over search-engine indexing. Public pages are opted in one at a time; the homepage, named sections and an optional sitemap can be exposed while the rest of the installation keeps a strict noindex. The decision is enforced consistently across the robots.txt file, the response headers and the page markup, so private pages cannot be exposed by accident.
   • New extension points for module developers: modules can register their own job types, add their own fields to the driver shift-start, shift-end, job-start and job-end flows, and react to every GPS position a driver's app reports. This is the groundwork for upcoming modules such as grounds-care, depot/stock tracking and geofencing.

   Changed

   • robots.txt is now generated per request rather than served as a static file, so it always reflects which pages are currently public. The static public/robots.txt has been removed in favour of this route.
   • The noindex response header is now applied per request by the application (the SecurityHeaders middleware) instead of a blanket rule in the Apache configuration, which is what makes selective public indexing possible.

   Upgrade notes

   Minor release — fully backwards compatible; no database migration. From v1.1.5: update through the in-app updater, or upload the archive manually and run the cache-clear commands afterwards. Apache installs: make sure the updated .htaccess from the package is applied — the old blanket noindex header it carried has moved into the application, and an outdated .htaccess would keep public pages from being indexed.

   Related: Developer documentation

   SHA-256 34681343ef87…

   View v1.1.6 on GitHub →
2. v1.1.5 23 June 2026

   Module updates apply without a restart

   A patch release that removes the last manual step after a module change and finishes the per-user and per-customer language work. Installing, updating or removing a module now takes effect on the next page load — no server restart. The interface language set per user now applies across the whole admin area, and a customer's language drives the portal and their emails together. The module page is also tidier. Fully backwards compatible; no database migration.

   Added

   • Module updates apply without a server restart. After a module is installed, updated or removed, Wintertrace now clears the compiled caches and resets PHP's OPcache automatically, so the change takes effect on the next page load. Previously the instance had to be restarted for module changes to take hold — rarely possible on shared web hosting, where OPcache kept serving the old module bytecode.

   Changed

   • A customer's assigned language now drives the customer portal and their emails together, not just the email language. The choice covers every installed language pack — Czech or French, for example.
   • Tidier module page. Long module descriptions are truncated to 150 characters and can be expanded on demand. Each module card now links to the module's info page — including its virus-scan result — instead of a misleading "Unsigned" label, and the misleading "Community" label has been removed, so modules from the official catalogue are no longer shown as third-party.
   • Locale handling is unified behind a single SetUserLocale middleware for all signed-in web users, removing duplicated logic; a new ModuleCacheRefresher serves both the admin UI and the CLI commands (modules-sync, modules-remove). The release build now excludes the developer example module's assets, and the release adds further automated tests with the full suite green.

   Fixed

   • The interface-language setting under Admin → Users now applies across the whole admin area. It was previously applied only on driver pages, so the selection appeared to have no effect.
   • The module catalogue no longer marks every module as "Unsigned" and "Community". This was a display fault only; the integrity protection — the SHA-256 check at download time — was unaffected and stays active.

   Security

   • The module info URL's scheme is validated server-side (only http and https are accepted), so a tampered catalogue cannot inject executable javascript: links into the interface.

   Upgrade notes

   Patch release — fully backwards compatible. From v1.1.4: update through the in-app updater, or upload the archive manually and run the cache-clear commands afterwards. No database migration is required.

   Related: Modules

   SHA-256 d5d456ad7ed6…

   View v1.1.5 on GitHub →
3. v1.1.4 11 June 2026

   Navigation follows the interface language

   A patch release that fixes the last place the interface language did not reach: the menus. With a non-German language active, the admin menu and the customer-portal navigation stayed in German while the rest of the page was already translated. Both now resolve per request in the active language, so page and navigation read consistently in the same language — the fix that matters once a language pack such as French is installed. Fully backwards compatible; no database migration.

   Changed

   • Both navigation registries (admin and portal) share a single pattern — labels are translation keys resolved only at render time, so no part of the code can reintroduce the freezing.
   • Adds 5 new automated tests covering the language-aware navigation.

   Fixed

   • Menus now follow the interface language. The admin menu and the customer-portal navigation stayed German under a non-German language because their labels were frozen at boot, before the language was applied; they are now resolved per request in the active language, so the whole interface — page and navigation — appears in one language.

   Upgrade notes

   Patch release — fully backwards compatible. From v1.1.3: update through the in-app updater, or upload the archive manually and run the cache-clear commands afterwards. No database migration is required.

   Related: French language pack

   SHA-256 f6ba82eefb7d…

   View v1.1.4 on GitHub →
4. v1.1.3 8 June 2026

   Per-user interface languages and language packs

   A feature release that makes the interface language fully flexible. Wintertrace can now load additional languages as modules, and the interface language can be set per driver and per customer — independent of the app-wide default. Modules can also add their own entries to the customer portal navigation. Fully backwards compatible: a single database migration runs automatically during the update.

   Added

   • Language packs as modules. Additional interface languages — Czech, for example — can be added through a central locale registry without touching the core.
   • Per-driver interface language. Admins assign each user their own interface language under Settings → Users; the driver sees the app in that language from login.
   • Per-customer language. Customers pick their language in the portal profile from every installed language.
   • Module-provided portal navigation. Modules can add their own entries to the customer portal menu, in both the desktop and mobile navigation — the groundwork for upcoming portal modules such as contract management.

   Changed

   • The app-wide default language (Settings → Company) now accepts any installed language, not only German or English.
   • Locale validation is centralised — no more hardcoded de/en lists scattered through the code — and the release adds 24 new automated tests.

   Upgrade notes

   Minor release — fully backwards compatible. From v1.1.2: update through the in-app updater, or upload the archive manually and run the cache-clear commands afterwards. A new database migration (users.locale) is applied automatically during the update; no manual steps are required.

   SHA-256 44b95318541f…

   View v1.1.3 on GitHub →
5. v1.1.2 30 May 2026

   Search-engine blocking and module log housekeeping

   A patch release that keeps a self-hosted installation out of search engines and tidies up module logging. A new three-layer block stops crawlers from indexing a live Wintertrace instance, the OwnTracks help page gains topic icons and direct app-store links, and module logs now rotate on a seven-day cycle. No behaviour changes and fully backwards compatible.

   Added

   • Search-engine blocking for live installations. Three independent layers keep a self-hosted instance from being indexed by Google and other crawlers: a robots.txt with Disallow: /, an X-Robots-Tag: noindex, nofollow response header set on every request, and noindex, nofollow meta tags across all eight HTML layouts.

   Changed

   • The OwnTracks help page now carries an icon for each help topic and direct Apple App Store and Google Play links.

   Fixed

   • Module logs no longer grow without bound. The per-request module boot entry that bloated log files has been removed, and a new seven-day rotation — the PurgeModuleLogs command — keeps module logs trimmed.

   Upgrade notes

   Patch release — fully backwards compatible. From v1.1.1: update through the in-app updater, or upload the archive manually and run the cache-clear commands afterwards. No database migration is required.

   SHA-256 3667fa434576…

   View v1.1.2 on GitHub →
6. v1.1.1 29 May 2026

   Diagnostics reporting across every error path

   A patch release that completes the diagnostics integration begun in v1.1.0. Every error-handling path — across module management, the update system, PDF generation, email settings, the customer portal and the dashboard — now reports failures to the diagnostics module, so problems that were previously silent surface where operators can see them. Each report is wrapped so that a diagnostics failure never interrupts the original operation. No behaviour changes and fully backwards compatible.

   Changed

   • Error reporting now covers the whole application. Around 31 error-handling paths across 15 files report failures to the diagnostics module; each one uses a safety wrapper so the diagnostics call can never break the operation it is observing.
   • Module management reports failures during catalogue fetch, download, installation, migration, update, settings and removal.
   • The update system reports failures during the update check, download and installation.
   • PDF generation, email settings, the customer portal and the dashboard report failures too — including .env write errors, test-email failures, portal credential dispatch, and widget rendering or filter errors.

   Fixed

   • PDF attachments in queued emails are now base64-encoded, resolving a UTF-8 serialisation error that could break mail carrying report attachments.

   Upgrade notes

   Patch release — fully backwards compatible. From v1.1.0: update through the in-app updater, or upload the archive manually and run the cache-clear commands afterwards. No database migration is required.

   SHA-256 3c0a3beb4c66…

   View v1.1.1 on GitHub →
7. v1.1.0 27 May 2026

   Module platform and role-based access control

   A feature release that turns Wintertrace into an extensible platform. Modules can now add navigation, dashboard figures, notifications, roles, background tasks, and storage and report backends — and are distributed through a signed catalogue with verified trust levels. Fully backwards compatible: existing installations keep running with no manual migration step.

   Added

   • Module platform — Wintertrace is now extensible. Modules can add navigation entries, dashboard figures, notification channels and background tasks, and each module is isolated so a faulty one cannot bring the rest of the system down.
   • Background-task overview in the admin area lists every scheduled task with its last-run status and lets you enable or disable each one individually; a failing task no longer stops the others.
   • Swappable photo storage and report formats — the photo storage backend can be replaced (existing local photos stay readable after a switch), and report output is now modular, with PDF and CSV as the defaults.
   • Per-module logging with its own admin log viewer, plus a versioned module REST API secured with per-module access tokens.

   Changed

   • Role-based access control replaces the fixed Admin/Driver split. Roles and permissions are now flexible, a user can hold several roles at once, and a new user-management screen handles assignment — with the last remaining administrator protected from removal. Existing installations keep working unchanged.

   Security

   • Module signature verification. Modules from the catalogue are checked against an Ed25519 signature chain before they are installed or updated; tampered, revoked or expired modules are blocked and unsigned ones are flagged. Each catalogue entry carries a trust level — Official, Verified, Community or Unknown.

   Upgrade notes

   Minor release — fully backwards compatible. From v1.0.5: update through the in-app updater, or upload the archive manually and run the cache-clear commands afterwards. Schema changes for the new roles and permissions tables are applied automatically during the update; existing user roles are preserved and no manual migration step is required.

   SHA-256 6b909a231b51…

   View v1.1.0 on GitHub →
8. v1.0.5 21 May 2026

   Bug fixes and English data protection template

   Roll-up release after feedback from a test install. Seven independent fixes — from a form-breaker to translation gaps and log hygiene. The manual job entry was broken since v1.0.3 and should be patched.

   Added

   • English (UK/EU GDPR) data protection template for new installs. Existing English installs must regenerate manually from the admin UI.

   Changed

   • Default logging is quieter (warning level, 14-day daily rotation). Existing installs must remove explicit LOG_LEVEL=debug from .env to inherit the new default.
   • Example module is no longer shipped or auto-loaded. Developers can opt back in with EXAMPLE_MODULE_ENABLED=true.
   • Settings cards now carry icons for visual scanning.

   Fixed

   • Manual job entry form works again — broke when a customer name contained a quote character.
   • Installer preflight no longer shows a hardcoded German error on English installs.

   Upgrade notes

   From v1.0.4: works through the in-app updater. From v1.0.3 or older: manual upload recommended due to a self-updater bug in older versions — see v1.0.4 release notes for recovery details.

   SHA-256 fc1b841494b5…

   View v1.0.5 on GitHub →
9. v1.0.4 19 May 2026

   Self-updater hotfix

   Emergency maintenance release after v1.0.3. The self-updater had two critical bugs that only surfaced in real-world use. Anyone running v1.0.3 should upgrade — without this fix, future auto-updates will not work correctly either.

   Changed

   • Build now produces ZIPs without the wrapper folder. The v1.0.4 update therefore installs cleanly on v1.0.3 installs that still have the buggy older updater.

   Fixed

   • Self-updater now extracts release archives correctly. Previously the new files landed inside a versioned sub-folder instead of overwriting the live files — the state file reported success while the live code stayed on the old version.
   • Rollback-protection check no longer fires after a successful update. Same-version detection now runs first; the counter check only triggers on a real manifest change.

   Upgrade notes

   From v1.0.2: manual upload via FTP or the in-app updater (now fixed). From v1.0.3 with stranded files in a versioned sub-folder under your install root: recovery instructions are documented in the v1.0.4 GitHub release notes.

   SHA-256 c3207abed804…

   View v1.0.4 on GitHub →
10. v1.0.3 19 May 2026

    Module stability and visibility fixes

    Maintenance release with five corrections from the first real-world run of v1.0.2. The bulk affects stability and visibility: logs were hidden by the new diagnostic layer, the module subsystem had several drift bugs, and the version display was stuck on 1.0.0.

    Fixed

    • Logs are visible again. The exception handler swallowed all errors when no diagnostic reporter claimed them; on fresh installs that meant nothing reached the Laravel log file.
    • Creating a customer object works again. The notification-recipient field had drifted between migration, validation, form, and consumers — all layers now agree on a fixed enum; the form uses a dropdown.
    • Version display now reflects the actual installed version. Footer, settings and dashboard were stuck on 1.0.0 because the version was hardcoded in config; it now reads from the VERSION file.
    • Module catalogue renders correctly. Two combined bugs (i18n field treated as a string, 304 response falling back to stale state) are resolved; the catalogue body is cached and 304 returns the cached body.
    • Modules extract correctly. The installer recognises a common top-level folder in module archives and strips it; modules land under modules/<slug>/ regardless of archive layout.

    Upgrade notes

    From v1.0.2 or older: manual upload via FTP (overwrite files, keep .env and storage/app/installed.lock). Run the cache-clear commands afterwards or the footer will still show the old version. Auto-update via the in-app updater is available but had a separate bug fixed in v1.0.4.

    SHA-256 c5f3fd3a9c60…

    View v1.0.3 on GitHub →
11. v1.0.1 17 May 2026

    Installer locale detection

    The installer now reads the browser's Accept-Language header on the first request and picks the matching language and brand. English-speaking visitors see the Wintertrace branding from step one; German-speaking visitors are routed to the Schneespur variant. A locale switcher in the header allows manual override.

    Added

    • First-request locale detection from the Accept-Language header. The installer renders the correct language and brand from step one, not from step five.
    • DE/EN switcher in the installer header for manual override during the session.
    • ext-sodium is now an explicit Composer requirement (used by the auto-update mechanism).

    Changed

    • The brand-name helper resolves the correct name even without a database connection — locale-based fallback.

    Upgrade notes

    From v1.0.0: manual upload via FTP (overwrite files, keep .env and storage/app/installed.lock). No database migration needed.

    SHA-256 13351dd30d6d…

    View v1.0.1 on GitHub →
12. v1.0.0 17 May 2026

    First public release

    The first public release. Wintertrace runs on standard web hosting with PHP and MySQL; operators own their data. Documents winter service end-to-end: GPS, weather, photos, customer-facing PDF reports.

    Added

    • Service documentation with GPS track (OwnTracks), photos and notes.
    • Automatic weather data captured at the time of service (Open-Meteo).
    • Customer portal with PDF service-proof reports.
    • Shift tracking and time overview.
    • CSV export and monthly statistics.
    • Data-protection support — data export and anonymisation features.
    • Progressive Web App, offline-capable.
    • Module system for extensions.
    • In-app update mechanism.

    SHA-256 5d20a7a61fde…

    View v1.0.0 on GitHub →