diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..7e20944
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1,15 @@
+# Zeilenenden nicht anfassen – einige Dateien liegen bewusst mit CRLF vor.
+* -text
+
+# Dateien, die nicht ins Release-ZIP gehoeren.
+# `git archive` (siehe .github/workflows/release.yml) wertet export-ignore aus.
+/.gitattributes export-ignore
+/.gitignore export-ignore
+/.dockerignore export-ignore
+/.github export-ignore
+/docs export-ignore
+/tests export-ignore
+/tools export-ignore
+/phpunit.xml.dist export-ignore
+/phpstan.neon export-ignore
+/composer.lock export-ignore
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
new file mode 100644
index 0000000..3fc3001
--- /dev/null
+++ b/.github/workflows/release.yml
@@ -0,0 +1,152 @@
+name: Release-Paket
+
+# Bei jedem Merge nach main entsteht ein installierbares ZIP und landet als
+# Vorab-Release "latest-main" im Repository. Wird ein Tag v* gepusht, wird
+# daraus ein regulaeres Release mit derselben Mechanik.
+on:
+ push:
+ branches: [ main ]
+ tags: [ 'v*' ]
+ workflow_dispatch:
+
+jobs:
+ package:
+ name: ZIP bauen und veröffentlichen
+ runs-on: ubuntu-latest
+
+ steps:
+ - uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+
+ - name: Version und Dateinamen bestimmen
+ id: meta
+ run: |
+ set -eu
+ VERSION="$(tr -d ' \r\n' < VERSION)"
+ SHORT_SHA="$(git rev-parse --short HEAD)"
+ BUILD_DATE="$(date -u +%Y-%m-%d)"
+
+ if [ "${GITHUB_REF_TYPE:-branch}" = "tag" ]; then
+ TAG="${GITHUB_REF_NAME}"
+ NAME="unifi-voucher-tool-${TAG}"
+ TITLE="Version ${TAG}"
+ PRERELEASE="false"
+ else
+ TAG="latest-main"
+ NAME="unifi-voucher-tool-${VERSION}+${BUILD_DATE}.${SHORT_SHA}"
+ TITLE="Aktueller Stand von main – ${VERSION} (${SHORT_SHA})"
+ PRERELEASE="true"
+ fi
+
+ {
+ echo "version=${VERSION}"
+ echo "short_sha=${SHORT_SHA}"
+ echo "build_date=${BUILD_DATE}"
+ echo "tag=${TAG}"
+ echo "name=${NAME}"
+ echo "title=${TITLE}"
+ echo "prerelease=${PRERELEASE}"
+ } >> "$GITHUB_OUTPUT"
+
+ - name: ZIP erzeugen
+ run: |
+ set -eu
+ mkdir -p dist
+ # git archive wertet die export-ignore-Regeln aus .gitattributes aus,
+ # docs/, tests/, tools/ und CI-Dateien bleiben also draußen.
+ git archive --format=zip -9 \
+ --prefix="unifi-voucher-tool/" \
+ -o "dist/${{ steps.meta.outputs.name }}.zip" HEAD
+ cd dist
+ sha256sum "${{ steps.meta.outputs.name }}.zip" > "${{ steps.meta.outputs.name }}.zip.sha256"
+ ls -lh
+
+ - name: Inhalt kurz prüfen
+ run: |
+ set -eu
+ # Ein paar Dateien muessen enthalten sein, sonst ist das Paket kaputt.
+ for required in \
+ unifi-voucher-tool/index.php \
+ unifi-voucher-tool/install.php \
+ unifi-voucher-tool/database.sql \
+ unifi-voucher-tool/assets/global.css \
+ unifi-voucher-tool/assets/vendor/inter/inter.css \
+ unifi-voucher-tool/includes/Ui.php
+ do
+ if ! unzip -l "dist/${{ steps.meta.outputs.name }}.zip" | grep -q "$required"; then
+ echo "Fehlt im Paket: $required" >&2
+ exit 1
+ fi
+ done
+ echo "Paket vollständig."
+
+ - name: Als Build-Artefakt sichern
+ uses: actions/upload-artifact@v3
+ continue-on-error: true # Artefakt-Speicher ist optional
+ with:
+ name: ${{ steps.meta.outputs.name }}
+ path: dist/*
+ retention-days: 30
+
+ - name: Release anlegen bzw. auffrischen
+ env:
+ # Forgejo stellt den Token automatisch bereit; FORGEJO_TOKEN
+ # (persönlicher Token) dient als Ausweichweg.
+ TOKEN: ${{ secrets.GITHUB_TOKEN || secrets.FORGEJO_TOKEN }}
+ API: ${{ github.server_url }}/api/v1/repos/${{ github.repository }}
+ TAG: ${{ steps.meta.outputs.tag }}
+ NAME: ${{ steps.meta.outputs.name }}
+ TITLE: ${{ steps.meta.outputs.title }}
+ PRERELEASE: ${{ steps.meta.outputs.prerelease }}
+ VERSION: ${{ steps.meta.outputs.version }}
+ SHORT_SHA: ${{ steps.meta.outputs.short_sha }}
+ BUILD_DATE: ${{ steps.meta.outputs.build_date }}
+ run: |
+ set -eu
+ if [ -z "${TOKEN:-}" ]; then
+ echo "Kein Token vorhanden – Release wird übersprungen." >&2
+ exit 0
+ fi
+ AUTH="Authorization: token ${TOKEN}"
+
+ # Rollendes Vorab-Release durch ein frisches ersetzen, damit der
+ # Download-Link stabil bleibt und auf den aktuellen Stand zeigt.
+ if [ "$TAG" = "latest-main" ]; then
+ OLD_ID="$(curl -sf -H "$AUTH" "${API}/releases/tags/${TAG}" \
+ | grep -o '"id":[0-9]*' | head -1 | cut -d: -f2 || true)"
+ if [ -n "${OLD_ID:-}" ]; then
+ curl -sf -X DELETE -H "$AUTH" "${API}/releases/${OLD_ID}" || true
+ curl -sf -X DELETE -H "$AUTH" "${API}/tags/${TAG}" || true
+ fi
+ fi
+
+ # Release-Text bewusst ohne Anfuehrungszeichen und Backslashes,
+ # damit er ohne jq direkt in den JSON-Body passt (\n bleibt literal).
+ BODY="Automatisch gebaut aus Commit ${SHORT_SHA}.\n\n"
+ BODY="${BODY}| | |\n|---|---|\n"
+ BODY="${BODY}| Version | ${VERSION} |\n"
+ BODY="${BODY}| Commit | ${SHORT_SHA} |\n"
+ BODY="${BODY}| Gebaut am | ${BUILD_DATE} |\n\n"
+ BODY="${BODY}**Neuinstallation:** ZIP entpacken, Dateien auf den Webserver legen, install.php aufrufen.\n\n"
+ BODY="${BODY}**Update einer bestehenden Installation:** config.php, uploads/ und updater/storage/ nicht ueberschreiben "
+ BODY="${BODY}- oder gleich den eingebauten Updater unter Administration, System-Update verwenden.\n\n"
+ BODY="${BODY}Pruefsumme: siehe beigelegte .sha256-Datei."
+
+ RELEASE_ID="$(curl -sf -X POST -H "$AUTH" -H 'Content-Type: application/json' \
+ -d "{\"tag_name\":\"${TAG}\",\"target_commitish\":\"${GITHUB_SHA}\",\"name\":\"${TITLE}\",\"body\":\"${BODY}\",\"draft\":false,\"prerelease\":${PRERELEASE}}" \
+ "${API}/releases" | grep -o '"id":[0-9]*' | head -1 | cut -d: -f2)"
+
+ if [ -z "${RELEASE_ID:-}" ]; then
+ echo "Release konnte nicht angelegt werden." >&2
+ exit 1
+ fi
+
+ for file in "dist/${NAME}.zip" "dist/${NAME}.zip.sha256"; do
+ curl -sf -X POST -H "$AUTH" \
+ -F "attachment=@${file}" \
+ "${API}/releases/${RELEASE_ID}/assets?name=$(basename "$file")" > /dev/null
+ echo "Angehängt: $(basename "$file")"
+ done
+
+ echo "Release ${TITLE} steht bereit: ${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/releases/tag/${TAG}"
diff --git a/Readme.md b/Readme.md
index e558be6..46a8a84 100644
--- a/Readme.md
+++ b/Readme.md
@@ -4,12 +4,15 @@
**Webbasiertes WLAN-Voucher-Management für UniFi OS** – mit Multi-Site-Support, Benutzerverwaltung, Microsoft-365-Login und integriertem Auto-Updater.
+Entwickelt von **[Loheide.eu](https://loheide.eu)**
+
-
-
+
+
+[](https://git.loheide.cloud/friloo/Unifi-Voucher-Tool)
@@ -25,6 +28,8 @@
## ✨ Features
- 🎟️ **Voucher-Erstellung** mit sofortiger QR-Code-Anzeige, Druckvorlage und E-Mail-Versand
+- 🖥️ **Display-Seiten (Kiosk)** – öffentliche Seite je Site, an der Gäste sich mit einem Klick selbst einen Zugang holen
+- 🎨 **Jede Display-Seite eigenständig gestaltbar** – Logo, Hintergrundbild, Akzentfarbe, helle oder dunkle Karte
- 📦 **Bulk-Erstellung** – bis zu 20 Vouchers auf einmal, inkl. Sammeldruck-Layout
- 🧩 **Voucher-Profile/Templates** – vordefinierte Laufzeiten & Gerätelimits per Schnellauswahl
- 🏢 **Multi-Site-Support** – beliebig viele UniFi-Standorte zentral verwalten
@@ -80,6 +85,18 @@
+### Display-Seite für Gäste
+
+
+
+
+
+
+
+
+
+
+
@@ -140,8 +157,8 @@
## 🚀 Installation
```bash
-git clone https://github.com/friloo/unifi-voucher-tool.git
-cd unifi-voucher-tool
+git clone https://git.loheide.cloud/friloo/Unifi-Voucher-Tool.git
+cd Unifi-Voucher-Tool
```
1. Dateien auf den Webserver hochladen
@@ -211,6 +228,64 @@ Während eines Updates wird die Anwendung kurz in den **Wartungsmodus** versetzt
---
+## 🖥️ Display-Seiten für Gäste
+
+Für Empfang, Lobby oder Tagungsraum lässt sich je Site eine **öffentliche Seite**
+anlegen, die auf einem Bildschirm oder Tablet läuft. Gäste tippen auf einen
+Knopf und bekommen sofort einen eigenen Zugangscode – ohne Anmeldung, ohne
+Personal am Tresen.
+
+**Anlegen:** Administration → **Display-Seiten** → *Display-Seite anlegen*
+
+
+
+
+
+| Einstellung | Wirkung |
+|---|---|
+| Site | für welchen Standort die Codes erzeugt werden |
+| Voucher-Profil | Laufzeit, Geräteanzahl und Bandbreite der Codes (leer = Standardwerte) |
+| Überschrift / Text | was auf dem Bildschirm steht |
+| Codes pro Tag | Obergrenze je Kalendertag (0 = unbegrenzt) |
+| Wartezeit | Abstand zwischen zwei Codes an diesem Display |
+| Anzeigedauer | danach springt der Bildschirm automatisch zurück |
+
+Jede Seite hat einen **eigenen, geheimen Link** (`kiosk.php?k=…`). Er lässt sich
+kopieren, als QR-Code anzeigen (praktisch, um ihn am Tablet zu öffnen) und
+jederzeit erneuern – der alte Link ist dann sofort ungültig. Den Link nicht
+öffentlich verbreiten: wer ihn hat, kann im Rahmen der Limits Codes ziehen.
+
+Auf dem Startbildschirm steht zusätzlich ein QR-Code, der auf dieselbe Seite
+zeigt. Gäste können sie damit **am eigenen Handy** öffnen – praktisch bei
+Bildschirmen ohne Touch.
+
+### Jede Seite eigenständig gestalten
+
+Jede Display-Seite bringt ihr eigenes Erscheinungsbild mit – das Hotel am
+Empfang sieht anders aus als der Tagungsraum nebenan:
+
+| Einstellung | Wirkung |
+|---|---|
+| Logo | eigenes Logo auf der Karte (leer = Logo aus den Einstellungen) |
+| Hintergrundbild | formatfüllend hinter der Karte, z. B. ein Foto des Hauses |
+| Abdunklung | 0–90 % dunkle Ebene über dem Bild, damit die Karte lesbar bleibt |
+| Akzentfarbe | färbt den Knopf dieser Seite (leer = Farbe aus dem Design-Tab) |
+| Karte | hell oder dunkel – auf Fotos wirkt die dunkle Karte meist ruhiger |
+
+Logo und Hintergrund lassen sich direkt hochladen (PNG, JPG, WEBP, GIF, SVG bis
+3 MB) oder als URL hinterlegen; beim Löschen einer Display-Seite verschwinden
+die hochgeladenen Dateien mit.
+
+Die ausgegebenen Codes erscheinen normal in *Live Vouchers*, im *Reporting* und
+im *Audit-Log* (Aktion „Voucher am Display geholt"), sodass jederzeit
+nachvollziehbar bleibt, woher ein Zugang stammt.
+
+> Display-Seiten funktionieren unabhängig vom globalen öffentlichen Modus – der
+> geheime Link ist der Zugang. Webhook-Benachrichtigungen werden für diese Codes
+> bewusst **nicht** ausgelöst, sonst wäre der Slack-Kanal voll.
+
+---
+
## ⚙️ Konfiguration
### `config.php`
@@ -512,10 +587,78 @@ Tests und statische Analyse:
```bash
composer install
-vendor/bin/phpunit
-vendor/bin/phpstan analyse
+vendor/bin/phpunit # 29 Tests (Crypto, TOTP, API-Keys, Upload, Ui)
+vendor/bin/phpstan analyse # Level 5
```
+Die Versionsnummer steht in der Datei **`VERSION`** im Projektstamm. Sie wird
+im Admin-Bereich unten in der Seitenleiste angezeigt und benennt das
+Release-Paket – für eine neue Version also dort (und im Badge oben) anheben.
+
+Die Pipeline (`.github/workflows/ci.yml`) führt zusätzlich einen
+Syntax-Check über alle PHP-Dateien aus und prüft, ob `lang/de.php` und
+`lang/en.php` dieselben Schlüssel enthalten und jeder im Code verwendete
+Schlüssel existiert. Dieselben Schritte lassen sich lokal ausführen.
+
+---
+
+## 📦 Repository & Mitwirken
+
+Der Quellcode liegt auf der eigenen Forgejo-Instanz – **nicht** auf GitHub:
+
+****
+
+```bash
+# HTTPS
+git clone https://git.loheide.cloud/friloo/Unifi-Voucher-Tool.git
+
+# SSH (Port 2222)
+git clone ssh://git@git.loheide.cloud:2222/friloo/Unifi-Voucher-Tool.git
+```
+
+### Fertige Pakete
+
+Jeder Merge nach `main` erzeugt automatisch ein installierbares ZIP
+(`.github/workflows/release.yml`) und hängt es an das rollende Vorab-Release
+**`latest-main`**:
+
+****
+
+Das Paket enthält nur die Laufzeit-Dateien – `docs/`, `tests/`, `tools/` und die
+CI-Konfiguration bleiben draußen (rund 1,4 MB). Wird ein Tag `v*` gepusht,
+entsteht daraus ein reguläres Release mit derselben Mechanik.
+
+> Beim **Update einer bestehenden Installation** `config.php`, `uploads/` und
+> `updater/storage/` nicht überschreiben – oder gleich den eingebauten Updater
+> verwenden, der genau diese Pfade schützt.
+
+Voraussetzung ist ein registrierter **Forgejo-Actions-Runner**; ohne Runner
+bleiben die Workflows in der Warteschlange stehen. Compose-Datei und Anleitung
+dafür liegen in [`tools/runner/`](tools/runner/README.md).
+
+### Mitwirken
+
+Fehlerberichte und Änderungsvorschläge laufen über die **Issues** und **Pull
+Requests** dort. Für die Kommandozeile eignet sich [`tea`](https://gitea.com/gitea/tea),
+die Gitea-/Forgejo-CLI:
+
+```bash
+tea pr create # Pull Request öffnen
+tea issues ls # offene Tickets ansehen
+```
+
+> Die Workflows unter `.github/workflows/` werden von Forgejo Actions
+> mitgelesen; das Badge oben ist bewusst statisch, solange kein Runner
+> registriert ist. `docker-publish.yml` veröffentlicht nach `ghcr.io` und
+> stammt noch aus der GitHub-Zeit – für den Forgejo-Betrieb entweder auf die
+> eigene Registry umstellen oder entfernen.
+
+Der **Auto-Updater** ist davon unabhängig: er zieht seine Pakete über
+`update.loheide.eu` (Channels `stable` und `development`) und nicht direkt aus
+dem Git-Hoster.
+
+---
+
## 🗺️ Roadmap
- [x] Voucher-Templates (vordefinierte Laufzeiten)
@@ -534,11 +677,14 @@ vendor/bin/phpstan analyse
- [x] Branding über die Oberfläche (Farben, Logo, Login-Seite)
- [x] Assets lokal ausliefern (keine Drittanbieter-CDNs)
- [x] Vollständige englische Übersetzung des Admin-Bereichs
+- [x] Display-Seiten: Selbstbedienung für Gäste am Bildschirm
---
+ 
+
+### Display-Seite für Gäste
+
+
+ 
+
@@ -140,8 +157,8 @@
## 🚀 Installation
```bash
-git clone https://github.com/friloo/unifi-voucher-tool.git
-cd unifi-voucher-tool
+git clone https://git.loheide.cloud/friloo/Unifi-Voucher-Tool.git
+cd Unifi-Voucher-Tool
```
1. Dateien auf den Webserver hochladen
@@ -211,6 +228,64 @@ Während eines Updates wird die Anwendung kurz in den **Wartungsmodus** versetzt
---
+## 🖥️ Display-Seiten für Gäste
+
+Für Empfang, Lobby oder Tagungsraum lässt sich je Site eine **öffentliche Seite**
+anlegen, die auf einem Bildschirm oder Tablet läuft. Gäste tippen auf einen
+Knopf und bekommen sofort einen eigenen Zugangscode – ohne Anmeldung, ohne
+Personal am Tresen.
+
+**Anlegen:** Administration → **Display-Seiten** → *Display-Seite anlegen*
+
+
+