Betreff: Re: Optimiert: Austausch zu Skripten / Performance-Schutz nach Serverumzug
Hallo Wolfgang,
vielen Dank für die Analyse und den optimierten Code-Entwurf! Ich habe mir deine Änderungen genau angeschaut und direkt in der Testumgebung ausprobiert.
Du hast da ein paar hervorragende Punkte eingebracht:
1. Die origWarn-Umleitung: Das ist die perfekte Balance. Die Fehler fluten nicht mehr rot die Konsole, werden aber trotzdem im Hintergrund als Warnung markiert. So übersehen wir bei der Entwicklung eigener Plugins definitiv nichts mehr. Geniale Idee!
2. Der DOM-Start-Check (readyState): Der Kniff mit dem Fallback, falls das Skript asynchron zündet, ist extrem wichtig für die Stabilität im Xobor-System. Das hatte ich so nicht auf dem Schirm.
3. Schließen-Button & Regex: Das "X" wertet das Widget optisch und funktional extrem auf. Auch das enger gefasste Regex greift super und isoliert die Server-MIME-Fehler jetzt absolut präzise.
Beim Testen und Überfliegen der Zeilen ist mir nur noch eine winzige Kleinigkeit für die absolute Performance-Spitze aufgefallen:
Das fängt Einzelfehler super ab! Wenn Xobor allerdings native Fehler-Objekte oder komplexe Instanzen in die Konsole wirft, liefert String(args) im Browser oft nur "[object Object]". Dadurch könnte das Regex fehlschlagen, weil der eigentliche Fehlertext (z.B. im message-Property) nicht geprüft wird.
Vorschlag: Man könnte die Argumente mit .some() prüfen. Das bricht sofort ab, sobald der erste Treffer im Regex erzielt wird, schont den Arbeitsspeicher (Garbage Collector) vor unnötigen .join()-Strings und schaut auch tiefer in Objekte hinein:
1 2 3 4 5 6 7 8 9 10 11 12 13
function markXoborError(args) { const isXobor = args.some(arg => { if (!arg) return false; if (arg instanceof Error) return xoborErrorPattern.test(arg.message); if (typeof arg === 'object') return xoborErrorPattern.test(JSON.stringify(arg)); return xoborErrorPattern.test(String(arg)); }); if (isXobor) { origWarn("[Xobor-Serverfehler abgefangen]", ...args); return true; } return false; }
Ich habe unsere modifizierte Version (jetzt Version 2026.5.1) genau so auf dem Live-Forum aktiv. Die Seite lädt spürbar ruhiger und die User können das Widget sofort wegklicken.
P.S. Mir sind beim finalen Feinschliff für das Skript noch zwei kleine Neuerungen aufgefallen, die ich direkt mit eingebaut habe, um es absolut ausfallsicher zu machen:
1. queueMicrotask statt setTimeout: Für das sanfte Einblenden der CSS-Klasse "is-visible" nutze ich jetzt queueMicrotask(). Das sorgt dafür, dass das Widget direkt im nächsten Microtask-Zyklus der Browser-Engine aktiviert wird. Das verhindert unschönes Layout-Flackern (Layout Thrashing) beim schnellen Laden der Forenseite.
2. DOM-Existenzprüfung beim Auto-Close: Im 25-Sekunden-Timer habe ich eine Abfrage eingebaut, ob das Widget überhaupt noch im DOM existiert:
1
if (document.body.contains(widget)) { ... }
Falls ein User das Schild nämlich schon nach wenigen Sekunden über dein neues "X" manuell schließt, würde der automatische setTimeout-Timer nach 25 Sekunden ins Leere laufen und im Hintergrund eine Fehlermeldung (Null-Pointer-Exception) werfen. So ist es sauber und fehlerfrei abgefangen.
Vielen Dank noch mal für diesen großartigen Austausch unter Bastlern! Genau so macht Foren-Entwicklung Spaß.
vielen Dank noch mal für deine starke Analyse und die Optimierungen am Core-Script! Das hat mir eine absolut sichere und stabile Basis geliefert, auf der man perfekt aufbauen kann.
Ich hatte danach noch eine richtig coole Idee, um das Ganze für Lui auf ein modernes Level zu heben, und habe mich noch mal intensiv an den Code gesetzt.
Da wir ja mitten im Xobor-Serverumzug stecken, wollte ich das Widget von einer reinen Fehler-Ausblendung zu einer echten Live-Diagnose-Zentrale aufrüsten.
Ich habe das Script um folgende Features erweitert und komplett neu geschrieben:
Live Performance-Messung: Das Script liest jetzt über die Browser-Engine die echte Server-Antwortzeit und die Ladezeit in Millisekunden aus.
Netzwerk- & System-Tracker: Es zeigt Luis Live-Protokoll (HTTP/2 h2) und die aktuelle RAM-Last des Templates an.
Hunderter Live-Zähler: Ein dynamischer Zähler erfasst im Hintergrund jede Cookie-Blockade und jede CSS-Ignorierung, während Lui surft.
Fortschritts- & Phasen-Rechner: Das absolute Highlight. Das Script prüft die MIME-Sperren und schlüsselt den Miranus-Migrationsstatus live in 5 Phasen und exakte Unterpunkte (Sub-Tasks) auf. Lui sieht jetzt bei Phase 3 rot blinken, dass es exakt am Verzeichnis-Mapping hakt, während die Daten-Backups schon grüne Haken haben.
Der Code läuft im Business v4 Template absolut fehlerfrei, frisst keine CPU und verschluckt durch deine Hooks keinerlei eigene Fehler. Schau dir mal an, wie genial die Anzeige jetzt auf Luis Bildschirm aussieht!
Ich danke dir für die super Zusammenarbeit – zusammen haben wir da echt ein verdammt starkes Werkzeug für Lui gebaut.
// TIEFEN-ANALYSE DER UNTERPUNKTE function berechneMigrationsStatus() { const fill = document.getElementById("daishi-progress-fill"); const percentText = document.getElementById("daishi-mig-percent");
Optimiert: Austausch zu Skripten / Performance-Schutz nach Serverumzug - Erweitert
Habe noch ein Test-Tool für Dich, um zu sehen, ob die Xobor-Fehler richtig erkannt und angezeigt werden!
Das komplette Skript wird wegen der Foren-Variablen als Plugin unter "Untere Leiste / Header" angelegt.
Wichtig! Im Plugin muss rechts oben das "Unterstützte Template " markiert werden, z.B. Business - Template (144) & Mobil - Template (177), Auswahl mit Mausklick oder Strg + Mausklick !
Nur für den Admin: {{user_admin==true.start}} ... {{user_admin==true.end}}
/* === Kurz-Helper für DOM === */ const $ = id => document.getElementById(id);
/* === Fehlererkennung (Xobor, Inline, Cross-Realm) === */ function markXoborError(args){ const list = Array.from(args); let type = "Xobor-Serverfehler";
Habe es mit einem einfacheren CSS hinbekommen, dass für das Forum Update (Verlinkung) nicht solche komischen Zeichen stehen. Allerdings ist mir der Code von euch zu kompliziert 🤣 Das ihr euch die Mühe gemacht habt, mein Respekt an euch.
Ich habe mir aus der aktuellen Situation heraus mal ein paar Gedanken gemacht und an einer kleinen Idee gebastelt. Ich wollte das einfach mal als Inspiration und eventuelle Übergangslösung mit euch teilen – vielleicht hilft es dem einen oder anderen Admin ja weiter, solange das Xobor-Team noch an den Servern arbeitet.
Da das Problem ja primär beim Absenden der Daten (durch das alte ISO-Charset in manchen Templates) entsteht, habe ich ein kleines JavaScript aufgesetzt. Die Idee dahinter ist ganz simpel: Das Skript sucht im Hintergrund nach Formularen und stellt das accept-charset im Browser des Nutzers sicherheitshalber direkt auf UTF-8 um, bevor die Daten rausgehen.
Zusätzlich habe ich eine kleine, dezente Info-Meldung eingebaut, die den Usern kurz signalisiert, dass ein temporärer Umlaut-Schutz aktiv ist. Damit das nicht nervt, blendet ein Klick auf das "X" die Meldung für die gesamte restliche Sitzung aus (sessionStorage). Auf Folgenseiten taucht sie also nicht mehr auf!
Wer Lust hat, kann es ja mal in seinem Forum testen. Es wird einfach als Template-Element im Plugin bei bottom_header (Untere Leiste / Header) hinterlegt (wichtig: rechts im Plugin das entsprechende Template markieren).
// 2. BENUTZERFREUNDLICHE MELDUNG (Einmalig pro Sitzung) if (!sessionStorage.getItem('daishi_utf8_fix_closed')) { // Erstellt die Meldung dynamisch über den Forum-Kategorien var bannerHTML = '<div class="daishi-fix-banner" id="daishiFixBanner">' + '<strong>Hinweis:</strong> Ein temporärer Umlaut-Schutz ist aktiv, damit Beiträge fehlerfrei abgesendet werden.' + '<span class="daishi-fix-close" id="daishiCloseBtn">×</span>' + '</div>';
// Fügt es in den Hauptbereich ein (angepasst an Business 4 Strukturen) if ($("#main").length > 0) { $("#main").prepend(bannerHTML); } else { $("body").prepend(bannerHTML); }
// Schließen-Logik $("#daishiCloseBtn").on("click", function() { $("#daishiFixBanner").fadeOut(); // Merken, dass der User es geschlossen hat -> Keine Anzeige mehr auf Folgenseiten! sessionStorage.setItem('daishi_utf8_fix_closed', 'true'); }); } }); </script>
Wie gesagt, das ist nur eine Idee und als temporärer Übergang gedacht. Sobald Xobor alles serverseitig gelöst hat, kann man das Plugin ja einfach wieder löschen.
Was meinst du dazu, Wolfgang? Meinst du, das könnte als Zwischenlösung klappen, oder habe ich bei dem Template-Aufbau noch etwas übersehen? Freue mich über dein Feedback!
Ich hoffe sehr, dass diese Idee gut bei euch ankommt. Ich dachte mir das einfach als eine schnelle Übergangslösung für die aktuellen Probleme. Ich gebe mir wirklich große Mühe zu helfen und es ist einfach eine lieb und gut gemeinte Idee von mir für die Community.