Hi,
ja, das ist der selbe Fehler.
Eigentlich würde ich jetzt sagen: „Backup vom Zustand vor der Installation einspielen“, aber:
Du könntest versuchen, in der Datei /var/www/web58/html/wsc-testforum/chat/style/be.bastelstu.chat.scss in Zeile 424 $wcfContentContainerBackground durch #FFF zu ersetzen.
Hi,
um Beta-Versionen vom Paketserver zu bekommen, musst du dich unter https://tims.bastelstu.be/index.php?user-group-list/ in die Beta-Tester-Gruppe einschreiben und am Paketserver anmelden, entweder indem du die Daten in deinem ACP einträgst oder https://packages.bastelstu.be/#be-bastelstu-chat im Browser aufrufst und auf den „Sign in“-Knopf klickst.
Zu beachten ist: Der Benutzername ist case-sensitiv, muss also genau so wie hier im Forum eingetragen werden.
Nun solltest du Zugriff auf das Paket haben. 
Hi,
das Problem ist jetzt im Git und damit in der nächsten Version behoben.
Hi,
danke, ist vermerkt.
Die Variable wurde mit dem WCF 3.1 eingeführt, da haben wir vergessen zu prüfen, ob die Variable existiert.
Was vielleicht zu erwähnen ist:
Beim Nutzernamen ist beim Paketserver die Groß- und Kleinschreibung tatsächlich wichtig.
Du kannst eine eigene Templategruppe anlegen und das zu bearbeitende Template über das ACP kopieren, ist dann der linke der drei Knöpfe
Danach dann noch im genutzten Stil die passende Templategruppe eintragen und das bearbeitete Template sollte Verwendung finden.
Hi,
wir versuchen im Chat eine kleine Anfrage an den Server zu schicken, um diesem mitzuteilen, dass man den Chat verlassen hat, wenn man die Seite wechselt oder den Tab schließt.
Leider kommt es hier auf den verwendeten Browser an, ob diese Anfrage überhaupt noch abgeschickt wird.
Ist das nicht der Fall, können wir nicht viel mehr machen, als die Benutzer nach einem Timeout (3 Minuten) aus dem Chat zu entfernen.
Diese Aktion wird mit dem stündlichen Cleanup-Cronjob und jedes Mal, wenn ein Nutzer im Chat eine Nachricht vom Server lädt, ausgeführt.
// Edit: Wir könnten diese Aktion noch beim Aufruf der Chat-Index-Seite (also der Raumauswahl) durchführen.
Für das Dashboard bzw. alle Seiten, die eine der Boxen einbinden, dürfte das zu inperformant sein.
// Edit: Safari ist einer der Browser, der diese Anfrage eben nicht sendet.
Chrome und Firefox unterstützen die sendBeacon-Funktion, die extra für solche Zwecke gedacht ist.
Wenn diese nicht unterstütz wird, müssen wir auf normale Ajax-Anfragen zurückgreifen, aber das wird beim Entladen eines Tabs in den meisten Browsern nicht mehr ausgeführt.
// Edit:
Es ist tatsächlich mal wieder nur noch der Safari, der die Technik nicht unterstützt: https://caniuse.com/#feat=beacon
In der Preview der nächsten Version soll es wohl endlich unterstützt werden …
Ist leider nicht das erste Mal, dass Apple mit seinem Browser den anderen hinterherhinkt.
Das muss ein ganz obskurer Bug im Zusammenhang mit Firefox und Perfect Scrollbar sein.
Wenn ich den Vollbild-Modus des Chats aktiviere, dann tritt das Verhalten bei mir nicht auf.
Gehe ich in den Design-Modus des Firefox und stelle eine Auflösung von 1366×768 ein, dann kann ich auch nicht über den Container hinaus scrollen.
Stelle ich dann aber den Seitenzoom auf 90% tritt das Problem plötzlich wieder auf. Das ist dann wohl irgendein Rundungsfehler.
Vermutlich in der Art: Oh, der Scrollbar-Handle ist Null-Komma Pixel unter dem Container, scrollen! 
Wenn Tim damit einverstanden ist, würde ich die „Perfect Scrollbar“ wieder rausschmeißen.
In der Doku dazu steht auch, dass die Probleme (aber nicht welcher Art) mit Flexboxen hat, wir nutzen diese im Chat zu genüge
Hatte testweise auch mal die uralte Version, die im WCF mitgeliefert wird, durch eine aktuelle ersetzt, da passiert das ebenfalls.
Ok,
im WoltLab Suite Core 3.1-Standardstil hatte ich das Verhalten im Firefox unter macOS in meiner Test-Installtion des Chats ebenfalls.
Ich tendiere dazu, ohne den Debugger auszupacken, dass "Perfect Scrollbar" da Probleme macht.
Im Safari konnte ich mit ein wenig Rumprobieren ebenfalls, aber nur ein paar Pixel, weiter scrollen, als ich können sollte. Das auch stilunabhängig.
EDIT:
Passiert bei mir auch im FF 57 unter Ubuntu.
//cc Tim
Hi,
in einer macOS Sierra VM (High Sierra hatte ich bisher nicht installiert bekommen), kann ich das Verhalten hier in der Bastelstube weder im Safari noch im Firefox reproduzieren.
– Geschrieben im Firefox 57.0.3 unter macOS Sierra über VirtualBox auf Ubuntu 17.10 
Hi,
hast du sonst alternativ die Möglichkeit, das Error Reporting von PHP zu aktivieren?
Derzeit ist es, korrekt für produktiven Einsatz, so eingestellt, dass Fehlermeldungen nicht ausgegeben werden.
Hi,
IRC ist auch heute noch ein reines Textprotokoll, alles, was nicht als Text dargestellt wird, macht dein Client. 
Aber das ist ein anderes Thema. 
Aber was genau meinst du mit „anderen Codes“?
Jeder Smiley im WCF/WSC hat einen definierten Text-Code, so heißt hier zum Beispiel :D.
Die kann jeder nutzen, sie sind nur nicht mehr so auffällig im Frontend (Text-Editor im Forum, zum Beispiel) wie früher.
Mittlerweile sieht man sie als Nutzer leider nur noch im „HTML-Modus“ und dort im Alt-Attribut des <img>-Tags, früher wurden direkt diese Codes in das Quelltextfenster eingefügt, wenn man den Smiley angeklickt oder in die Quelltextansicht gewechselt hat.
Wenn wir uns das WSC angucken, dann gibt es die Smiley-Picker aber auch nur in vollständigen Editoren, also zum Beispiel in Konversationen oder im Forum.
Die Stellen, die für kurze Texte angedacht sind (Pinnwandkommentare, Kommentare zu Artikeln) haben im WSC 3.0 nur ein reines Textfeld und im 3.1 ein Editor-Fenster, dieses hat jedoch auch keinen Smiley-Picker. Der Chat fällt eher in die letztere Kategorie.
Das heißt auch in einer normalen Installation des WSC bzw. Forums muss man diese Codes "lernen".
Hi,
Smilies sowie Emoji werden vom Chat selbstverständlich unterstützt.
Viele Smartphones haben Tastaturen, die Emoji direkt unterstützen. Soweit mir bekannt, lassen sich auch unter einem aktuellen Windows 10 und macOS Emoji über ein Auswahlfenster eingeben.
Aus Übersichtlichkeitsgründen haben wir auf einen integrierten Smiley-Wähler verzichtet, die Smilies können aber über die bekannten Codes genutzt werden.
Hi,
vermutlich ist die Installation nicht korrekt durchgelaufen.
Der Chat sollte hier nicht das Problem gewesen sein, wahrscheinlich hatte dein Server während der Installation Schluckauf.
Ich kann dir in der Situation leider nur das Einspielen eines Backups empfehlen.
Doch, doch, aber wir möchten nicht, dass eine Alpha-Software in einem produktiven System installiert wird.
Natürlich sind wir versucht, den Chat so stabil und fehlerfrei wie möglich zu halten, aber wir haben während der Entwicklung schon mehrere Stellen/Teilsysteme komplett über den Haufen geschmissen und umgebaut, und möchten nicht ausschließen, dass dies während der Alpha-Phase noch einmal passiert und möglicherweise neue Fehlerquellen in das System bringt.
Wenn serverseitig tatsächlich mal ein ganz blöder Fehler passiert, dann möchten wir nicht schuld sein, dass Community X zerschossen ist, weil das letzte Backup ein Jahr alt war.
Und weil gutes Zureden á la "Wir bitten euch darum, den Chat noch nicht produktiv einzusetzen" bei solchen Entscheidungen leider noch nie funktioniert hat, haben wir uns dazu entschlossen diese Limitierung in die Alpha-Releases zu integrieren.
Hi,
der Fehler sollte mit der Version im Anhang behoben sein.
Ich möchte noch einmal darauf hinweisen, dass wir die Verwendung der Alpha-Version im produktiven Umfeld nicht unterstützen und im Chat aktiv verhindern.
Installationen mit 5 oder weniger Benutzern erachtet der Chat als Testsystem, ansonsten „verweigert“ er den Dienst.
Zum Testen im kleinen Kreis sollte es ausreichen.
Edit: Neue Version: Tims Chat 4
Kleines Update:
Ich konnte den Fehler reproduzieren.
Ursache: Der Chat wurde in einem produktiven System* installiert und die richtige Fehlermeldung wurde nicht korrekt weitergegeben.
Das Weiterleiten der richtigen Fehlermeldung wird korrigiert, die Nutzung in produktiven System aber weiterhin nicht unterstützt.
Ich werde gleich in neues Paket hochladen.
* Definition, siehe hier: Tims Chat 4
Hi,
ich kann den Fehler in meiner Installation so in keinem meiner Browser reproduzieren.
Ich habe den Chat in folgenden Browsern getestet:
Eigentlich sollte das auch gar nicht passieren können, da die Konfiguration das Erste ist was geladen wird.
Erst nachdem die Konfigurationsdaten geladen wurden, wird der Chat initialisiert.
Tritt das Problem auch hier in der Bastelstube auf?
Falls ja:
Mögt ihr uns einmal die Versionsnummern eurer Browser nennen?
Und eventuell könnte noch Hilfreiches in euren Browser-Konsolen auftauchen (in den meisten Browsern über F12 zu erreichen).
Falls nein:
Dann wären Zugangsdaten zu einer betroffenen Installation hilfreich.
Einfach Tim und mich in eine Konversation pappen, dann gucken wir mal rein, wenn wir Zeit haben.
Hi,
das ist korrekt, da wir bisher nur Sprachvariablen für die englische Sprache angelegt haben, um uns nicht unnötig die Arbeit zu machen mehrere Sprachen zu verwalten, während der Chat sich in einer Phase befindet, in der sich noch vieles ändern kann.
In kurz also: Die deutsche Übersetzung kommt, wenn die Sprachvariablen „in Stein gemeißelt“ sind
Das was du beschrieben hast, war bereits Teil von Tims Chat 3, dort als "Temporärer Raum" bekannt. Temporäre Räume sind auch weiterhin ein geplantes Feature.
Die temporären Räume tauchen dann wie jeder Raum in der Raumliste auf, gefiltert nach den entsprechenden Rechten, da sie ansonsten vollwertige Chaträume sind.
Die privaten "Chats" waren ein reines UI-Feature, dass whisper-Nachrichten abgefangen und in einem dedizierten Tab im selben Fenster angezeigt hat, wenn man für Nutzer X einen solchen geöffnet hat.
In diesem Tab musste man dann auch nicht für jede Nachricht extra /whisper User... tippen oder die entsprechende UI-Aktion auslösen.
