docs(lead-engine): Document iFrame troubleshooting & Nginx/SyntaxError fixes [31988f42]\n\n- iFrame Robustness: Added a robust JavaScript snippet to for the WordPress landing page, ensuring it functions with or without specific booking parameters and provides a fallback to the general MS Bookings URL.\n- Nginx Configuration Fix: Corrected the to properly route nested paths to the service, resolving the "Synology error page" issue.\n- Python SyntaxError Resolution: Documented the fix for the in (caused by invalid module import syntax), which prevented the service from starting.\n- Restart Instructions: Included necessary restart commands for Nginx and the lead-engine after these changes.
This commit is contained in:
@@ -91,6 +91,68 @@ Dieser Prozess stellt sicher, dass wir nicht "blind" entwickeln, sondern auf Bas
|
||||
* **Problem:** Die API-Endpoints gaben nackten Text zurück, was für Kunden unprofessionell wirkte.
|
||||
* **Lösung:** Der Server liefert nun saubere HTML-Snippets zurück. Durch Setzen der `WORDPRESS_BOOKING_URL` in der `.env` führen die Links in der Kunden-E-Mail direkt auf die Kunden-Website. Dort wird das HTML-Ergebnis (Erfolg inkl. Teams-Link ODER Fallback zum Microsoft Bookings Kalender bei Doppelbuchung) unsichtbar in einem iFrame geladen.
|
||||
|
||||
#### 5.1 Troubleshooting der iFrame-Integration
|
||||
|
||||
Um sicherzustellen, dass die Buchungs-Landingpage auf WordPress immer korrekt funktioniert – sowohl mit spezifischen Terminvorschlägen als auch als Fallback zu einer allgemeinen Buchungsseite – sind mehrere Konfigurationsschritte und Fehlerbehebungen notwendig:
|
||||
|
||||
**1. Robuster iFrame-Code für Ihre WordPress-Seite**
|
||||
Der folgende JavaScript-Code sollte in Ihre WordPress-Seite integriert werden, die als Landingpage für Terminbuchungen dient (z.B. `robo-planet.de/terminbestaetigung`). Er prüft, ob spezifische Termindaten (Job-UUID und Timestamp) über die URL übergeben werden, und lädt entsprechend entweder den spezifischen Termin-Slot oder die allgemeine Microsoft Bookings URL als Fallback.
|
||||
|
||||
```html
|
||||
<iframe id="booking-iframe" width="100%" height="800px" style="border:none;" scrolling="no"></iframe>
|
||||
<script>
|
||||
const urlParams = new URLSearchParams(window.location.search);
|
||||
const jobUuid = urlParams.get('job_uuid');
|
||||
const timestamp = urlParams.get('ts');
|
||||
|
||||
let iframeSrc = "";
|
||||
|
||||
if (jobUuid && timestamp) {
|
||||
// Wenn beide Parameter vorhanden sind, den spezifischen Buchungslink verwenden
|
||||
iframeSrc = "https://floke-ai.duckdns.org/feedback/book_slot/" + jobUuid + "/" + timestamp;
|
||||
} else {
|
||||
// Andernfalls auf die allgemeine MS Bookings URL verweisen
|
||||
iframeSrc = "https://outlook.office.com/book/KennenlernenmitRoboplanet@wackler-group.de/?ismsaljsauthenabled";
|
||||
}
|
||||
|
||||
document.getElementById('booking-iframe').src = iframeSrc;
|
||||
</script>
|
||||
```
|
||||
|
||||
**2. Nginx-Konfiguration für korrekte Pfad-Weiterleitung**
|
||||
Das Laden der spezifischen `/feedback/book_slot/...`-URL im iFrame scheiterte initial, da der Nginx-Proxy die verschachtelten Pfade nicht korrekt an den `lead-engine`-Container weiterleitete. Dies führte zur "Synology-Fehlerseite".
|
||||
|
||||
* **Problem:** Die `location`-Regel in `nginx-proxy-clean.conf` für `/feedback/` war zu starr.
|
||||
* **Lösung:** Die Konfiguration wurde mit einer `rewrite`-Regel angepasst, um sicherzustellen, dass der gesamte Pfad korrekt an den `lead-engine`-Dienst weitergegeben wird und die notwendigen Proxy-Header für moderne Webanwendungen gesetzt sind.
|
||||
|
||||
```nginx
|
||||
location /feedback/ {
|
||||
auth_basic off;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Upgrade $http_upgrade;
|
||||
proxy_set_header Connection "upgrade";
|
||||
rewrite ^/feedback/(.*)$ /$1 break;
|
||||
proxy_pass http://lead-engine:8004;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
```
|
||||
* **Aktion nach Änderung:** Nach dem Anpassen von `nginx-proxy-clean.conf` muss der Nginx-Container neu gestartet werden:
|
||||
`docker-compose restart nginx`
|
||||
|
||||
**3. Behebung des `lead-engine` Service-Absturzes (`SyntaxError`)**
|
||||
Der `lead-engine`-Dienst selbst stürzte aufgrund eines Python `SyntaxError` ab, der durch einen ungültigen Import-Pfad verursacht wurde, der Bindestriche enthielt. Dies verhinderte, dass der Dienst überhaupt eine Antwort senden konnte, was ebenfalls zu einer leeren iFrame-Anzeige beitrug.
|
||||
|
||||
* **Problem:** Eine Zeile `from connector-superoffice.superoffice_client import SuperOfficeClient` in `manager.py` verursachte einen `SyntaxError`, da Bindestriche in Python-Modulnamen nicht erlaubt sind.
|
||||
* **Lösung:** Die fehlerhafte `sys.path.append`-Anweisung und die ungültige `import`-Zeile wurden aus `lead-engine/trading_twins/manager.py` entfernt, da sie Teil eines verschobenen Tasks waren.
|
||||
|
||||
* **Aktion nach Änderung:** Nach der Korrektur in `manager.py` muss der `lead-engine`-Container neu gebaut und neu gestartet werden:
|
||||
`docker-compose up -d --build --force-recreate lead-engine`
|
||||
|
||||
Durch diese Maßnahmen wird die iFrame-Integration nun robust funktionieren und immer eine sinnvolle Ansicht auf der WordPress-Landingpage bieten.
|
||||
|
||||
## 🚀 Inbetriebnahme & Test
|
||||
|
||||
### Inbetriebnahme
|
||||
|
||||
Reference in New Issue
Block a user