Hilfe & Anleitung

Diese Seite hat zwei Teile. Oben das Betreiber-Handbuch – es erklärt in einfacher Sprache, wie du die Webseite bedienst und jede Einstellung im Verwaltungsbereich (Backend) nutzt, auch ohne Technik-Vorkenntnisse. Darunter die technische Dokumentation für Entwickler (Architektur, Datenbank, Abläufe). Erreichbar über das ?-Symbol oben im Seitenkopf; das Fragezeichen kann im Backend unter Konfiguration → Hilfe-Button aus- und eingeblendet werden. Die Seite ist nicht für Suchmaschinen bestimmt (noindex,nofollow).

1. Überblick

Schatzilo ist eine standortbasierte Schatzsuch-Plattform. Eltern oder Schulen kaufen einen Spiel-Token, Kinder spielen die zugehörige Tour offline-tolerant am Smartphone und erhalten am Ende eine personalisierte Urkunde.

Drei Kern-Anwendungen

Architektur-Prinzipien

• Alle Texte aus der DB. Keine hartkodierten Strings im Code – Buttons, Hero-Texte, Mails, Rätselfragen, alles über ui_strings oder *_i18n-Tabellen.
• Pflege ausschließlich über das Admin. Kein direktes SQL nötig.
• Hauptzeile + i18n-Begleiter. Pro Entität gibt es foo (sprachneutrale Stammdaten) und foo_i18n (Texte pro Sprache).

2. Tech-Stack

3. Verzeichnisstruktur

/var/www/marco/schatzilo/
├── app/                       PHP-Code (PSR-4: Schatzilo\)
│   ├── bootstrap.php           DI-Container, Slim-App-Factory
│   ├── Admin/                  Admin-Controller (Auth, Dashboard, CRUD)
│   ├── Database/Connection.php PDO-Factory
│   ├── Http/
│   │   ├── routes.php          Alle Slim-Routen
│   │   ├── Controllers/        Web-Controller (Home, Location, Play, Checkout, …)
│   │   └── Middleware/         Session, Sprache, Admin-Auth, Play-Session
│   ├── I18n/                   LanguageResolver, Translator, Formatter (Zahl/Datum)
│   ├── Media/                  MediaRepository (Auflösung sprachspezifisch→neutral)
│   ├── Cms/                    BlockRenderer, BlockRegistry (Page-Builder)
│   ├── Payments/               PayPalClient, PaymentService
│   ├── Certificates/           CertificateService (Code, Einlösen, PDF-Versand)
│   └── Support/                Csrf, Flash, AuditLogger, Mailer, RateLimiter,
│                               AccessCodeGenerator, CertificateCodeGenerator, CertificateRenderer
├── bin/
│   ├── composer.phar           lokal (nicht im Repo)
│   └── admin-create.php        CLI: php bin/admin-create.php <email> [pass]
├── database/
│   └── schema.sql              Vollständiges Schema + Seed-Daten
├── docs/                      Konzept-Dokumente (00–10, inkl. Spiel-/i18n-Plan)
├── private/                    nicht im DocumentRoot
│   ├── .env                    Secrets (Mode 0640, group web-marco)
│   ├── .env.example            Vorlage
│   ├── backups/                Future: mysqldump-Tarballs
│   └── uploads/
│       ├── certificates/        erzeugte Urkunden-PDFs (+ /templates/ Hintergrund-PDFs)
│       └── media/               hochgeladene Medien (Auslieferung via /media/{id})
├── public/                     Webserver-DocumentRoot
│   ├── index.php               Front-Controller
│   ├── .htaccess               Apache-Rewrite (zur Vollständigkeit; live: nginx)
│   ├── assets/css/             app.css, admin.css, play.css
│   ├── assets/js/              main.js, edit-mode.js, play-map.js (Landkarte)
│   ├── assets/maps/            Karten-SVGs (z. B. demo-trail.svg)
│   ├── dev/                    map-picker.html (Koordinaten-Werkzeug, Phase-3-Vorstufe)
│   └── (…)                     _tinyfm entfernt → private/legacy/ (2026-07-13)
├── storage/                    Cache + Logs (writable von web-marco)
├── templates/                  Twig
│   ├── layouts/                Web-Layout
│   ├── web/                    Marketing-Seiten
│   ├── play/                   Spiel-App
│   ├── admin/                  Backoffice
│   └── mail/                   Bestätigungs- + Urkunden-Mails
└── vendor/                     Composer-Pakete (über composer install)

4. Datenbank-Architektur

Schema in database/schema.sql. Engine InnoDB, Charset utf8mb4, BIGINT-IDs, durchgehend created_at/updated_at, Soft-Delete via deleted_at wo Audit relevant ist.

Sprachen & UI-Strings

Inhalt: Hauptzeile + i18n-Begleiter

Geschäftsdaten

Buchbare Angebote: location_tour_types verknüpft Standort × Tour-Typ und trägt Preis, Währung, Dauer und code_validity_minutes. Der Checkout läuft pro (location, tour_type) (?type=-Slug).

users (optional, Gast-Checkout möglich) → bookings (eine pro PayPal-Order, Status-Enum, tour_type_id NOT NULL) → payments (Roh-Webhook-Events) → sessions (eine pro Buchung, Token-basiert, access_code NOT NULL, certificate_code bei Abschluss) → session_progress (eine Zeile pro Rätsel-Versuch). Plus certificates, inquiries, page_blocks (Page-Builder-Baum), media_assets (Medien), location_maps + stations.map_x/map_y/map_path_to_next (Landkarte), admins, audit_log, rate_limits (IP-basiertes Limit für /code, Kontakt & Urkunde, siehe app/Support/RateLimiter.php).

Urkunden-Vorlagen (PDF-Overlay)

Die aktive Urkunde nutzt nicht mehr certificate_templates_i18n (HTML/CSS, Legacy), sondern PDF-Overlay-Spalten direkt in certificate_templates: background_pdf_path (optionale Hintergrund-PDF), orientation/page_format und fields_json – eine Liste positionierter Textfelder (content mit Platzhaltern {name}/{date}/{location}, x/y in mm, Größe, Farbe, Ausrichtung, fett). Erzeugte Dokumente landen in certificates (mit recipient_email, file_path).

Konventionen

• FK-Auflösung über ON DELETE CASCADE für i18n-Begleiter, sonst ON DELETE RESTRICT.
• Slugs sind sprachneutral. Sprach-Prefix kommt aus der URL (/de/standort/knirpsenfarm).
• PDO::ATTR_EMULATE_PREPARES = false → Named Placeholder dürfen nicht mehrfach im selben Statement stehen (:loc_r, :loc_l statt einmal :loc).

5. i18n-System

Alles, was der User sieht, kommt aus der DB. Es gibt zwei Datenquellen, gegen die die Übersetzung läuft:

• UI-Strings (Buttons, Labels, Mails): ui_strings.string_key per Twig-Filter {{ 'btn.start_hunt'|t }}.
• Inhaltliche Felder (Standort-Name, Rätselfrage): direktes JOIN in der Query gegen locations_i18n.language_code = :lang.

Sprachen-Verwaltung (Admin)

Unter /admin/sprachen (app/Admin/LanguageController.php): Sprachen anlegen, bearbeiten (Name, Eigenbezeichnung, Sortierung, Format-Regeln), aktivieren/deaktivieren, Standard setzen, löschen – mit Abdeckungs-Anzeige (wie viel je Sprache übersetzt ist) und Schutzregeln (Default nicht deaktivier-/löschbar, immer ≥1 aktive Sprache). Der öffentliche Sprachumschalter erscheint automatisch ab ≥2 aktiven Sprachen, wechselt zur gleichen Seite (Pfad-Präfix-Tausch) und merkt die Wahl per Cookie.

Sprach-Auflösung

Reihenfolge in app/I18n/LanguageResolver.php:

1. URL-Prefix ({lang}-Routenparameter)
2. Cookie schatzilo_session_lang
3. Accept-Language-Header
4. Default-Sprache aus languages.is_default = 1 (zur Zeit de)

Twig-Filter / Funktionen

Beide lesen die aktuelle Sprache aus dem Render-Kontext (app/I18n/Formatter.php); im Admin (ohne Locale-Kontext) greift die Default-Sprache. ext-intl ist auf dem Server bewusst nicht vorausgesetzt – die Formatregeln liegen pflegbar in languages.

Spielsprache

Die sessions.language_code friert die Spiel-Sprache zur Buchung ein. Das PlaySessionMiddleware liest die Session-Sprache und überschreibt damit den URL-/Cookie-Resolver, damit ein in DE gekauftes Spiel auch DE bleibt, wenn das Kind aus Versehen en/… öffnet.

6. Routing

Definiert in app/Http/routes.php. Slim 4 mit Middleware-Gruppen.

Public

GET  /                            → 302 zur Default-Sprache
GET  /_health                      Health-Check (JSON)
GET  /dev/hilfe                    Diese Seite
GET  /{lang}/                      Startseite (Page-Builder-Onepager)
GET  /{lang}/standort/{slug}       Standort-Detail (Alias: /location/{slug})
GET  /{lang}/checkout/{slug}?type= Buchungs-Formular (pro Tour-Typ)
POST /{lang}/checkout/{slug}       PayPal-Order anlegen
GET  /checkout/return?token=…      PayPal-Return (Capture)
GET  /checkout/cancel              Abbruch-Seite
GET  /{lang}/checkout/danke/{token} Thanks + Spiel-Link
GET  /{lang}/checkout/betreut-danke Danke-Seite betreute Tour
GET/POST /{lang}/code              Freischaltcode einlösen (CSRF + Rate-Limit)
GET/POST /{lang}/code/vergessen    Code per Mail erneut senden (Anti-Enumeration)
GET/POST /{lang}/urkunde           Urkunde einlösen: Code → Name+Mail → PDF
POST /{lang}/urkunde/erstellen     PDF erzeugen + per Mail senden
GET  /{lang}/urkunde/download      zuletzt erzeugte Urkunde herunterladen
GET  /{lang}/so-funktionierts      „So funktioniert's"
GET  /{lang}/kontakt               Kontakt (Anfrageformular)
POST /{lang}/kontakt               Anfrage absenden → inquiries (CSRF, Honeypot, Rate-Limit)
GET  /{lang}/impressum             Impressum
GET  /{lang}/datenschutz           Datenschutz
GET  /media/{id}                   Medien-Auslieferung (Stream aus private/uploads od. 302 auf Link)
POST /api/paypal/webhook           PayPal-Webhook

Spiel

GET  /play/{token}/                Start oder Resume (→ Karte, falls vorhanden, sonst Station)
POST /play/{token}/begin           Markiert Session als active
GET  /play/{token}/karte           Interaktive Landkarte (Fallback: lineare Station)
GET  /play/{token}/station/{n}     Aktuelle Station mit Rätsel
POST /play/{token}/station/{n}/check  Antwort-Prüfung (JSON bei XHR, sonst 302)
GET  /play/{token}/finish          Erfolgsbildschirm; erzeugt Urkunden-Code + Glückwunsch-Mail,
                                   zeigt Code + Link zur Urkunden-Einlösung (/{lang}/urkunde)

Die frühere In-Game-HTML-Urkunde (POST /finish Namenseingabe, GET /play/{token}/urkunde) wurde durch den Code-basierten Einlöse-Flow ersetzt.

Admin

GET/POST /admin/login              Login (CSRF, Argon2id)
GET      /admin/logout
GET      /admin                    Dashboard mit KPIs
GET/POST /admin/standorte/…        CRUD Standorte (i18n-Editor)
GET/POST /admin/standorte/{id}/stationen/…  Sub-CRUD Stationen
GET/POST /admin/standorte/{id}/karte        Karteneditor: Upload + Stationsplatzierung
POST     /admin/standorte/{id}/karte/positionen  Stationskoordinaten speichern (JSON)
GET/POST /…/stationen/{sid}/raetsel/… Sub-CRUD Rätsel
GET/POST /admin/ui-texte/…         UI-Strings-Editor
GET/POST /admin/sprachen…          Sprachen-Verwaltung (aktiv/Standard/Format-Regeln)
GET/POST /admin/medien…            Medien-Verwaltung (Upload/Link, Owner, Sprache)
GET      /admin/anfragen           Kontaktanfragen (Status-Filter)
POST     /admin/anfragen/{id}/status  Bearbeitungsstatus setzen
GET/POST /admin/urkunden…          Urkunden-Vorlagen-CRUD (PDF-Upload, Feld-Editor)
GET      /admin/urkunden/{id}/test    Test-PDF mit Beispieldaten
GET      /admin/urkunden/erstellt     Liste erstellter Urkunden (+ /{id}/datei Download)
POST     /admin/standorte/{id}/test-session  Test-Session für QA
GET/PATCH/DELETE /admin/api/blocks/{id}      Page-Builder-Block-API
POST     /admin/api/pages/{id}/blocks        Block anlegen

Middleware-Stack

7. Admin-Backend

Login

Tabelle admins, Argon2id-Hash, CSRF-Token aus Session, session_regenerate_id(true) bei Erfolg. Anlage / Reset:

php bin/admin-create.php marco.schauart@gmail.com [neuesPasswort] --role=owner --name="Marco"

Module

• Dashboard – KPI-Kacheln + Übersetzungs-Lücken-Report.
• Standorte – CRUD mit Tab-Editor pro aktiver Sprache. Buttons „Stationen verwalten" und „Test-Session starten".
• Stationen – Sub-CRUD pro Standort, Reihenfolge-Bulk-Update mit Auto-Swap bei Position-Konflikten.
• Rätsel – Sub-CRUD pro Station, akzeptierte Antworten als „eine pro Zeile" → JSON-Array, bis zu 3 Hinweise.
• Karteneditor – pro Standort (/admin/standorte/{id}/karte): Landkarte hochladen (viewBox-Erkennung) + Stationen per Drag platzieren (location_maps + stations.map_x/map_y).
• UI-Texte – Tabellen-Editor mit Kontext-Filter und Suche. Neuanlage über /admin/ui-texte/neu.
• Sprachen – /admin/sprachen: Sprachen anlegen/aktivieren, Standard setzen, Format-Regeln (Zahl/Währung/Datum), Abdeckungs-Anzeige.
• Medien – /admin/medien: Bilder/Töne/Videos/PDF als Upload oder externer Link, zugeordnet zu Standort/Station/Rätsel, Rolle und optional Sprache; Alt-Text/Caption (i18n), Validierung (Whitelist, Größenlimit, Magic-Bytes). Auslieferung öffentlich über /media/{id}.
• Anfragen – Liste der Kontaktanfragen (inquiries) mit Status-Filter und Inline-Status-Wechsel; verlinkt vom Dashboard. Betreute Touren landen nach Zahlung automatisch hier.
• Urkunden-Vorlagen – CRUD für certificate_templates: Hintergrund-PDF hochladen, Felder (Text, Position mm, Farbe, Größe, Ausrichtung) im Editor setzen, „Test-PDF" zur Kontrolle. Standard- oder Standort-Vorlage.
• Erstellte Urkunden – Liste der erzeugten certificates mit Suche (Name/E-Mail) und PDF-Download.
• Page-Builder – Inline-Editor (Side-Panel, edit-mode.js) für page_blocks-Bäume; die Startseite läuft darüber. REST-API unter /admin/api/blocks, Block-Typen in app/Cms/BlockRegistry.php.

Audit-Log

Tabelle audit_log bekommt für jede mutierende Operation einen Eintrag mit action (create, update, delete, reorder, login.success, login.failed, translate.update, …), entity (Tabellenname), entity_id und JSON-diff.

8. Spielablauf

Aus bookings entsteht beim Capture genau eine sessions-Zeile mit 40-Hex-Char-Token. Lebenszyklus:

Antwort-Matching

1. riddles_i18n.accepted_answers ist ein JSON-Array.
2. Wenn trim_whitespace = 1 → User-Eingabe und jede Antwort getrimmt.
3. Wenn case_sensitive = 0 → Vergleich gegen mb_strtolower.
4. Erste Übereinstimmung gewinnt → session_progress.solved_at wird gesetzt.

Hinweise auf Abruf

Alle gepflegten Hinweise (hint_1–hint_3) sind auf Wunsch nacheinander aufdeckbar: Schalter „Gibt es einen Hinweis?" (play.hint.toggle) zeigt Hinweis 1, „Noch einen Hinweis anzeigen" (play.hint.more) den jeweils nächsten. Klassische Ansicht: verschachtelte <details> ohne JS; Karten-Panel: play-map.js (setHints/renderHints). Keine Fehlversuch-Staffelung mehr (bis 2026-07-13).

Landkarte (interaktive Spielführung)

Das Spiel hat zwei Auslieferungs-Modi, die sich dieselbe serverseitige Antwortprüfung teilen:

• Klassisch-linear – Station für Station als einzelne Seiten (oben beschrieben).
• Interaktive Landkarte (/play/{token}/karte) – das gesamte Gelände als Karte; das Kind tippt die leuchtende Station an, löst das Rätsel im Overlay-Panel, und der Kartenausschnitt gleitet entlang des Wegs zur nächsten Station.

Die Karte ist die Primäransicht, wenn der Standort eine aktive Karte hat und alle aktiven Stationen Kartenkoordinaten besitzen – sonst greift automatisch der lineare Flow. Ohne JavaScript zeigt ein <noscript>-Block Links zu den Stationsseiten. PlayController::map() baut den Spielzustand, check() liefert bei XHR JSON (richtig/falsch, Hinweise, nächste Station, Finish), sonst weiterhin 302.

Frontend: templates/play/karte.html.twig rendert ein Outer-<svg> mit der Karten-viewBox, die Karte als <image> und Marker/Wege darüber; public/assets/js/play-map.js macht Pan/Zoom, Stations-Panel, fetch-Antwort, Weg-Animation und respektiert prefers-reduced-motion. Die JSON-Insel im HTML enthält bewusst keine Lösungswörter.

Pflege im Admin (Karteneditor): Standorte → [Standort] → „Karte & Positionen" (/admin/standorte/{id}/karte, app/Admin/MapController.php): Karte als SVG/PNG/JPG/WEBP hochladen (viewBox wird bei SVG automatisch erkannt, sonst aus den Bildmaßen) → speichert in location_maps (Default-Karte, tour_type_id NULL); danach die Stationen per Drag auf der Karte platzieren (schreibt stations.map_x/map_y via /karte/positionen, JSON). Dateien liegen unter public/assets/maps/. Das frühere Standalone-Werkzeug /dev/map-picker.html bleibt als schneller Koordinaten-Picker bestehen.

Noch offen: Karte je Tour-Typ über den Editor (Schema kann es bereits), Editor für den Animationspfad (map_path_to_next), GPS-„Wo bin ich?", und Stationen mit mehreren Rätseln fallen in der Kartenansicht auf die klassische Stationsseite zurück.

9. PayPal-Flow

Implementiert ohne PayPal-SDK (reines curl in app/Payments/PayPalClient.php). Der Checkout ist tour-typ-bewusst: gebucht wird ein (location, tour_type)-Angebot. Bei betreuten Tour-Typen (is_guided=1) wird keine Spiel-Session erzeugt, sondern ein inquiries-Eintrag + „wir melden uns"-Mail (afterGuidedCapture).

Sync-Flow

1. User klickt „Mit PayPal bezahlen" auf /{lang}/checkout/{slug}.
2. PaymentService::startCheckout() legt bookings als pending an, ruft PayPal-Orders-API auf, speichert paypal_order_id.
3. 302 zur PayPal-Approval-URL.
4. Käufer approved → PayPal redirected zu /checkout/return?token=<orderId>.
5. CheckoutController::returnFromPaypal() ruft captureOrder() auf, protokolliert in payments, ruft afterCapture().
6. PaymentService::afterCapture() ist idempotent: setzt Status paid, legt sessions-Token an, sendet Bestätigungsmail.
7. 302 zu /{lang}/checkout/danke/<token>.

Webhook

POST /api/paypal/webhook dient als Sicherheitsnetz, falls der Käufer den Browser schließt, bevor der Sync-Return läuft. Verarbeitet CHECKOUT.ORDER.APPROVED|COMPLETED und PAYMENT.CAPTURE.COMPLETED, ruft denselben afterCapture()-Pfad → durch DB-Idempotenz keine doppelten Sessions/Mails. Bei ORDER.APPROVED captured der Webhook serverseitig nach (sonst gäbe es bei „Tab geschlossen vor Rücksprung" den Code ohne Geldfluss).

Wenn PAYPAL_WEBHOOK_ID gesetzt ist, wird die Signatur via /v1/notifications/verify-webhook-signature geprüft.

Konfiguration in private/.env

PAYPAL_MODE=sandbox       # oder live
PAYPAL_CLIENT_ID=…
PAYPAL_CLIENT_SECRET=…
PAYPAL_WEBHOOK_ID=…       # nach Webhook-Anlage in der PayPal-Console

Status aktuell: Credentials gesetzt sandbox

10. Urkunden-Flow

Die Urkunde ersetzt die frühere druckbare HTML-Seite durch einen Code-basierten Einlöse-Flow mit echter PDF-Erzeugung (FPDI + TCPDF). Logik in app/Certificates/CertificateService.php, Rendering in app/Support/CertificateRenderer.php.

1) Bei Abschluss

GET /play/{token}/finish ruft issueOnFinish(): für eine abgeschlossene, gekaufte (nicht Test-)Session wird einmalig ein 5-stelliger sessions.certificate_code erzeugt und eine Glückwunsch-Mail mit Einlöse-Link + Code verschickt (idempotent, keine Doppel-Mail). Die Abschluss-Seite zeigt Code + Button.

2) Einlösen (öffentlich)

1. GET /{lang}/urkunde?code=… – Code-Eingabe (aus Link vorbefüllt).
2. POST /{lang}/urkunde – Code → resolveByCode() erkennt automatisch Ort + Abschlussdatum; danach Formular für Name + E-Mail. CSRF + IP-Rate-Limit; bewusst neutrale Antwort gegen Code-Enumeration.
3. POST /{lang}/urkunde/erstellen – createAndSend() wählt die Vorlage (Standort → Default), rendert die PDF, speichert sie unter private/uploads/certificates/, legt eine certificates-Zeile an und versendet die PDF als Mail-Anhang.
4. GET /{lang}/urkunde/download – Download der in dieser Session erzeugten PDF.

3) Vorlagen-Gestaltung (Admin)

Unter /admin/urkunden: optionale Hintergrund-PDF hochladen (sonst leeres A4), und in fields_json Textfelder positionieren – jeweils Inhalt mit Platzhaltern {name}/{date}/{location}, Position in mm (X als Anker je nach Ausrichtung L/C/R), Schriftgröße, Farbe, fett. „Test-PDF" rendert die gespeicherte Vorlage mit Beispieldaten.

Hinweis: TCPDF hat bekannte Security-Advisories; relevant nur bei Fremd-Input – hier wird ausschließlich aus admin-kontrollierten Vorlagen + eigenen Texten gerendert.

11. Lokal entwickeln

Dev-Server starten

php -S 127.0.0.1:8765 -t public

Greift auf private/.env zu. Der Built-in-Server reicht für alles außer .htaccess-Tests.

Test-Session ohne PayPal

Im Admin auf einem Standort den Button „Test-Session starten" klicken. Erzeugt eine TEST-…-Buchung (Status paid) und leitet direkt zur Spiel-App.

Composer

php bin/composer.phar install
php bin/composer.phar require <paket>

Datenbank

# Offene Migrationen anwenden (idempotent, bevorzugter Weg)
php bin/migrate.php

# Schema komplett neu einspielen (zerstört Daten!)
mysql -u marco_schatzilo -p marco_schatzilo < database/schema.sql

# Schnell-Check
mysql -u marco_schatzilo -p marco_schatzilo -e "SHOW TABLES"

Twig-Cache

Im Debug-Modus deaktiviert (app.debug = true). In Produktion nach storage/cache/twig/. Bei Template-Änderungen ohne Debug: rm -rf storage/cache/twig/*.

12. Deployment

Webserver

nginx mit PHP-FPM-Pool marco (User+Group web-marco). Config: /etc/nginx/sites-available/schatzilo.schauart.de.

• DocumentRoot: /var/www/marco/schatzilo/public
• Front-Controller-Rewrite: try_files $uri $uri/ /index.php?$query_string
• Geblockt: /_tinyfm/, /includes/, Dot-Files, *.env|*.md|*.sql|*.ini|*.log|*.bak
• PHP-Ausführung nur für /index.php, andere *.php-Anfragen werden zum Front-Controller umgeleitet.

Datei-Berechtigungen

nginx neu laden

sudo nginx -t && sudo systemctl reload nginx

13. Live-Status

14. Funktions-Checkliste – funktioniert alles?

Vollständige Liste aller Funktionen der Plattform. Jeder Block sagt, was die Funktion tut, wo sie liegt und wie du in unter einer Minute prüfst, ob sie funktioniert (mit erwartetem Ergebnis). Reihenfolge = grob der Nutzerreise: erst öffentliche Seite, dann Kauf, Spiel, Urkunde, zuletzt Admin & Betrieb.

Vorbereitung für die Spiel-/Urkunden-Tests: im Admin auf einem Standort „Test-Session starten" klicken – das erzeugt ohne PayPal einen gültigen Spiel-Token, mit dem du den kompletten Ablauf durchspielst. Basis-Adresse Dev: schatzilo.schauart.de.

A. Öffentliche Website (Marketing)

B. Buchung & Bezahlung

C. Freischaltung & Spiel

D. Urkunde

E. Admin-Backend

F. Betrieb & Sicherheit

Diese Seite wird durch den Code unter app/Http/Controllers/HelpController.php und templates/web/dev-help.html.twig erzeugt. Anpassungen direkt dort, kein DB-Inhalt.