User-Init lief über Pipedream ↔ Adalo strukturell instabil — Webhooks brachen ab, Rate-Limits liefen über, Accounts blieben halb initialisiert. Der neue Service ersetzt das: stabil, idempotent und selbstheilend, jeder neue Account wird verlässlich vollständig aufgesetzt. Code und Tests stehen, der Service läuft bei uns — jetzt soll er auf eure Infrastruktur umziehen.
Bei der Registrierung ruft die App einen kleinen PHP-Endpoint auf. Der bestätigt sofort und legt danach im Hintergrund die rund 254 Startdaten des Nutzers in 5 Collections an. Die App zeigt so lange einen Ladescreen, bis alles steht — der User merkt vom Vorgang nichts.
Sign-up in der App │ ▼ POST /api/init-user.php [Init-Service] → 202, sofort bestätigt │ ▼ läuft im Hintergrund weiter [5 Collections] 254 Startdaten anlegen │ ▼ Flags INIT + INIT_GTG gesetzt [App] pollt Status → Ladescreen aus
Standard-LAMP, kein Lock-in. Bevor wir Dateien und Anleitung bereitstellen, klären wir, ob diese Bausteine bei euch eingerichtet werden können:
| Baustein | Wozu / Anforderung | Frage an euch |
|---|---|---|
| PHP 8.3 (FPM) | Führt den Service aus. Wichtig: als FPM, nicht nur CLI — nur damit funktioniert die sofortige Bestätigung samt Hintergrund-Job (fastcgi_finish_request). |
Lässt sich PHP 8.3 als FPM bereitstellen? |
| Webserver | Vhost auf eigener Subdomain, langer Timeout (~300 s) für den Hintergrund-Job, interne Ordner (data/, lib/) gesperrt. |
Nginx oder Apache — und können wir die Timeouts setzen? |
| Datenbank | Kleine MariaDB/MySQL-DB + eigener DB-User nur fürs Job-Tracking — keine Nutzerdaten. Das Schema liefern wir mit. | Können DB + DB-User angelegt werden? |
| Subdomain + DNS | Z. B. init.deinespuren.online — A-Record auf euren Server. |
Welche Subdomain, und wer pflegt den DNS-Eintrag? |
| SSL-Zertifikat | Let's Encrypt für die Subdomain. Pflicht — Adalo spricht den Endpoint nur über HTTPS an. | Per Panel / Certbot machbar? |
| Cronjob | Ruft alle paar Minuten cron.php auf und holt abgebrochene Inits automatisch nach — das Self-Healing. |
Lässt sich ein Cronjob einrichten? |
| Adalo-Zugang | Der Service braucht den Adalo-API-Key + App-ID, um die Records anzulegen. | Wer verwaltet künftig den Adalo-Key? |
In drei Schritten, kein Big-Bang: 1. Voraussetzungen oben klären (heute) — passt alles, schnüren wir das Code-Paket samt Schritt-für-Schritt-Anleitung. 2. Wir bauen die App-seitige Adalo-Anbindung (Custom Action beim Sign-up + Ladescreen) und testen sie end-to-end — das steht noch aus, bisher wurde der Service nur ohne Adalo getestet. 3. Migration mit Test-Usern auf eurer Infrastruktur; die bisherigen Pipedream-Workflows laufen als Sicherheitsnetz weiter — scharf geschaltet wird erst nach erfolgreicher Verifikation.
Schlanke statische Single-Page-App — Frontend hostet ihr, Backend (Token-Validierung + Submit) läuft unverändert über Pipedream. Keine Datenbank, keine Server-Logik nötig.
Nutzer erhalten einen Einladungslink mit Token-Parameter. Die Seite validiert den Token gegen Pipedream, zeigt das passende Formular mit dem Anzeigenamen, sendet die Antworten beim Absenden zurück.
[Link] ?token=ABC │ ▼ GET /validate [Pipedream] → valid / expired / finished │ ▼ [Formular] 6 Skala-Fragen + Kommentar │ ▼ POST submit [Pipedream] → Adalo │ ▼ [Danke]
Reine Static-Files. Keine PHP-Version, keine Datenbank, kein Node.js — funktioniert auf jedem Webspace.
index.html — die Seite selbststyle.css — Layoutscript.js — Token-Logik + Formular-SubmitAssets/IMG/* — die 7 Frage-Icons
Vorgeschlagen: meinungen.deinespuren.online oder extern.deinespuren.online.
Im DNS-Verwaltungstool (z. B. Plesk, cPanel, DNS-Provider) einen A-Record auf
eure Webserver-IP setzen.
| Type | Name | Value | TTL |
|---|---|---|---|
| A | meinungen | <eure Server-IP> | 3600 |
Alternativ kann statt eines A-Records auch ein CNAME auf den Hauptserver-Hostnamen gesetzt werden.
DNS-Propagation: in der Regel 5–60 Minuten.
Im Server-Panel einen Vhost (Apache/Nginx) für die neue Subdomain anlegen.
Document-Root z. B. /var/www/meinungen.deinespuren.online/. Keine PHP-, keine
Datenbank-Konfiguration nötig — nur statisches Hosting.
Die fertigen Files (von uns bereitgestellt) per SFTP/FTP/Git ins Document-Root spielen:
Let's Encrypt im Hosting-Panel für die Subdomain ausstellen lassen — bei Plesk/cPanel meist ein Klick. Der Token-Link aus dem Buch funktioniert nur über HTTPS, daher Pflicht.
Sobald die Subdomain technisch erreichbar ist, prüfen wir den Flow zusammen — Token-Validierung, Formular, Submit-Pfad. Den Test-Token und die genauen Aufruf-Parameter bringe ich mit, damit kein Test-Eintrag versehentlich in der Produktion landet.
Backend bleibt komplett bei uns. Token-Validierung und Submit laufen über zwei Pipedream-Endpoints, die im JavaScript fest hinterlegt sind. Auf eurer Seite werden ausschließlich die statischen Frontend-Dateien gehostet — keine PHP-Pflege, kein DB-Backup, keine Skript-Updates. Updates am Frontend tauschen wir bei Bedarf einfach gegen die Files aus.