Ankündigung Neues Forum: Betatest der neuen Forumsoftware

Status
Für weitere Antworten geschlossen.
Steffen schrieb:
Ich glaube weil das Thema alt ist.
Im alten Forum werden die Ergebnisse nach der letzten Antwort von neu nach alt aufgelistet, was ich persönlich gut finde.

Wie XenForo das anstellt.. keine Ahnung.
 
Ich fände es gut, wenn die "likes" bei Beiträgen über dem normalen Optionen wären statt drunter. Finde das verwirrernd, dass Likes das Menü (Report, Like, Quote,...) verschieben.
 
Khaosprinz schrieb:
Im alten Forum werden die Ergebnisse nach der letzten Antwort von neu nach alt aufgelistet, was ich persönlich gut finde.

Wie XenForo das anstellt.. keine Ahnung.

Also ich hab es gerade hier im alten Forum ausprobiert mit "Guild Wars 2" und nur Themen.
Da kommt auf der ersten Seite gar kein Sammelthread zu Guild Wars 2....


EDIT:
@Basti was verschieben denn die Likes?
Bei mir werden die als letztes Angezeigt und verschieben damit auch nix
 
Eben und damit werden die Quote/Report/etc Buttons nach oben geschoben.
Ich finde diese sollten immer als unterstes bei einem Beitrag sein.
 
Steffen schrieb:
Im alten Forum konnte man 24 Stunden lang nicht "doppel-posten". Diese Zeitspanne fanden wir zu lang und haben sie daher auf eine Stunde reduziert. Ich hatte dazu vor ein paar Monaten die automatischen Beitragszusammenführungen im alten Forum ausgewertet und dabei kam raus, dass 79% der potenziellen Doppelposts in dieses Zeitfenster fallen.

Und wofür braucht man das?!
 
Das neue Forum unterstützt jetzt Marktplatz-Bewertungen! :)

Wie im alten Forum kann man für andere Benutzer in Marktplatzthemen eine positive, negative oder neutrale Bewertung abgeben. Dabei gibt man zudem die eigene Rolle an (Käufer, Verkäufer, Tausch) und schreibt einen Kommentar.

Wie im alten Forum hat jeder Marktplatz-Benutzer ein Trader-Profil mit einer Übersicht aller Bewertungen unterteilt in die Tabs "Alle Bewertungen", "Von Käufern", "Von Verkäufern", "Von Tauschern" und "Für andere Benutzer". Im Seitenstreifen gibt es ein paar Statistiken.

Zudem gibt es eine Übersichtsseite mit einer Liste der aktivsten Marktplatz-Benutzer und einer Liste der neuesten Bewertungen. Für normale Benutzer ist diese Liste auf die letzten 30 Tage beschränkt, Moderatoren sehen alle jemals vorgenommenen Bewertungen.

In allen solchen Listen wird hinter Benutzernamen stets die Punktzahl ausgegeben. Ob es sich um eine positive, negative oder neutrale Bewertung handelt, markieren sich optisch deutlich unterscheidende und hochauflösende Icons.

Zum Abgeben einer Marktplatz-Bewertung kann und muss man keine Themen-URLs mehr kopieren, sondern wählt einfach im jeweiligen Marktplatz-Thema den passenden Benutzer aus, wodurch Thema und Benutzer automatisch feststehen. Der bewertete Benutzer wird per Alert über die neue Marktplatz-Bewertung informiert.

Auf der Detail-Seite einer Bewertung kann jene gemeldet werden. Gegebenenfalls wird auch ein Button zum Abgeben einer "Gegen-Bewertung" angezeigt.

Neu ist, dass jetzt direkt im jeweiligen Marktplatz-Thread die zugehörigen Bewertungen ausgegeben werden (unten am Seitenende). Beispiel: https://www.computerbase.de/forum/threads/intel-core-i5-kingston-ram-mainboard-luefter.1669444/

Die Möglichkeit zum wechselseitigen Kommentieren von Marktplatz-Bewertungen (also im Endeffekt ein Thread je Marktplatz-Bewertung) entfällt, weil das erheblicher Aufwand für überschaubaren Nutzen wäre.

Auf den allgemeinen Benutzer-Profilseiten wird die Anzahl der Marktplatz-Bewertungen ausgegeben, es gibt aber keinen Tab mit Statistiken.

Es werden alle Marktplatz-Bewertungen aus dem alten Forum übernommen. Für alte iTrader-URLs werden zudem automatisch Weiterleitungen auf die neuen Trader-URLs eingerichtet.
 
Zuletzt bearbeitet: (Links aktualisiert)
Snooty schrieb:
Oder alternativ: gifs als Avatare ;)

+1 :D

Spaß bei Seite... ich würde es schade finden, wenn ich mein Avatar nach all den Jahren nicht mehr nutzen könnte.
 
wupi schrieb:
Werdet Ihr die Bunten Avatare neben den Thread titeln so lassen ? Vielleicht liegts nur an mir, aber die Dinger lenken ab.
Steht noch nicht fest, aber ich denke schon. Wenn man selbst im Thema geschrieben hat, dann wird da übrigens auch der eigene Avatar ausgegeben.

Snooty schrieb:
Oder alternativ: gifs als Avatare ;)
XenForo unterstützt zwei Image-Backends: "PHP built-in GD image library" (GD) und "Imagemagick PECL extension" (Imagick). GD ist der Default und nutzt eine gleichnamige in PHP standardmäßig eingebaute Grafikbibliothek. Bei Verwendung von GD unterstützt XenForo keine animierten Avatare.

Die alternative Imagick-Extension ist eine optionale PHP-Erweiterung, die auf das bekannte Kommandozeilen-Bildbearbeitungs-Tool ImageMagick zurückgreift (bzw. genauer gesagt auf dessen Library). Bei Verwendung der Imagick-Extension unterstützt XenForo animierte Avatare. Wieso bin ich nicht soo scharf auf diese Extension? Zum einen ist jede weitere PHP-Extension tendenziell unschön (es könnte Sicherheitslücken geben und die Chance auf Probleme bei PHP-Updates steigt). Zudem anderen legt die Readme der Imagick-Extension nahe (und Gentoo erzwingt es sogar), ImageMagick ohne Multi-Threading-Support zu kompilieren. Das Deaktivieren von Multi-Threading in ImageMagick würde aber bedeuten, dass die von den Redakteuren genutzte Bildbearbeitung in unserem CMS deutlich langsamer würde (das CMS benutzt nicht die Imagick-Extension sondern die Kommandozeilen-Tools von ImageMagick, da ist Multi-Threading kein Problem und sorgt bei großen Bildern für eine gute Performance).

Eventuell ist Gentoo da aber etwas zu streng, denn die Readme der Imagick-Extension nennt noch eine Alternative zum punktuellen Deaktivieren der Multi-Threading-Unterstützung, nämlich via "\Imagick::setResourceLimit(\Imagick::RESOURCETYPE_THREAD, 1)". Ich habe daher die Imagick-Extension mal installiert und dann wie beschrieben den Multi-Threading-Support abgeschaltet. Das scheint grundsätzlich zu funktionieren.

Allerdings: Ich habe dann mal das Avatar von addicT* (11.5 KB, 50x50 Pixel, 207 Animation-Frames) in XenForo hochgeladen. Das hat nicht wie bei statischen Avataren üblich rund eine Sekunde gedauert, sondern 48 (!) Sekunden, während derer ein CPU-Kern voll ausgelastet war. Und heraus kamen deutlich größere Avatar-Dateien mit 55 KB (48x48 Pixel), 162 KB (96x96 Pixel), 305 KB (192x192 Pixel) und 779 KB (384x384 Pixel).

vBulletin hat Avatare 1:1 so übernommen wie sie hochgeladen wurden. Der Nutzer musste sie auf maximal 80x80 Pixel verkleinern und sich um die Dateigröße (maximal 12 KB) kümmern. XenForo funktioniert anders und betrachtet die hochgeladene Datei als Quellmaterial, aus dem es mehrere Avatar-Dateien in verschiedenen Größen generiert. Das finde ich generell sinnvoll, weil der Nutzer sich nicht mehr um die Ausmaße und Dateigröße kümmern muss. Zudem kann man HiDPI/Retina-Displays so besser unterstützen. Bei Dateien wie dem Avatar von addicT*, die für eine bestimmte Fläche hochoptimiert wurden, schlägt das aber leider grandios fehl.

Es tut mir leid, aber es wird im neuen Forum deshalb höchstwahrscheinlich keine animierten Avatare geben. Ich kann verstehen, dass die in vielen Fällen eindeutig bereichend und nicht nervend sind, aber es passt einfach nicht zusammen.
 
Zuletzt bearbeitet:
Der neue Datenbank-Import ist fertig: https://www.computerbase.de/xenforo/ :)

Insbesondere sind jetzt alle Marktplatz-Bewertungen aus dem alten Forum auch im neuen Forum vorhanden, schaut mal rein und vergebt ruhig Test-Bewertungen! In einem Beitrag weiter oben stehen Details zu den Marktplatz-Bewertungen im neuen Forum.

Weitere Änderungen:

Der Importer aktiviert bei abonnierten Foren die Benachrichtigung via Alert jetzt nicht mehr pauschal, sondern nur noch dann, wenn der Benutzer bei diesem Forum-Abo im alten Forum E-Mail-Benachrichtigungen aktiviert hatte: https://xenforo.com/community/threa...all-forum-watches-with-alerts-enabled.145437/

Ich habe noch ein paar Fixes für den Import von Beitragstiteln eingebaut. Im neuen Forum haben Beiträge ja keine Titel mehr und der Importer stellt vom Thementitel abweichende Beitragstitel dem Beitragstext voran. Details: https://xenforo.com/community/threa...e-to-escape-partial-bb-code-in-titles.145435/

Und wie zuvor bereits bekannt gegeben, sollten jetzt alle Standard-Avatare korrekt übernommen worden sein und in Signaturen eventuell vorhandenen "HR"-BBCode hat der Importer automatisch entfernt.
 
In diesem Beitrag steht alles über Smileys im neuen Forum. :D

Ich habe lange überlegt, welche Smileys wir im neuen Forum nutzen sollten. Die Smileys aus dem alten Forum sind schön oldschool und wenn einige alte Hasen sie sehen, dann fühlen sie sich sofort wie zu Hause. Auf der anderen Seite sind die alten Smileys nunmal Pixelgrafiken in niedriger Auflösung, die auf HiDPI/Retina-Displays (also insbesondere auf allen Smartphones) wirklich ziemlich bescheiden aussehen.

Ich habe überlegt, diejenigen Smileys, für die es in den allseits bekannten Emojis hochauflösende Äquivalente gibt, zu ersetzen (XenForo verwendet standardmäßig Smileys von EmojiOne). Dann würden die meistgenutzten Smileys auf Smartphones und anderen hochauflösenden Displays nicht wie aus einer anderen Zeit aussehen. Diejenigen alten Smileys, für die es kein modernes Äquivalent gibt, hätten wir beibehalten, sodass es im Endeffekt einen Mix gegeben hätte. Dass es einen Mix gegeben hätte ist auch zugleich der zentrale Nachteil dieser Idee. Hinzu kommt, dass einzelne alte Smileys wie zum Beispiel der grüne Grinse-Smiley oben irgendwo cooler sind als die neuen Emoji-Äquivalente (oder?).

Das Thema ist nicht vom Tisch, aber wir haben uns dazu entschieden, im Rahmen des Forum-Upgrades erstmal nichts zu ändern. Wir haben die alten Smileys fast 1:1 in das neue Forum übernommen.

Wieso schreibe ich "fast"? Wir haben ein paar Dinge geändert:

1) Die Smiley-Syntax lautet jetzt nicht mehr ":name" sondern ":name:" (also mit Doppelpunkt am Ende). Im alten Forum hatte nur ein Smiley ("eek") diese Syntax mit zwei Doppelpunkten genutzt, alle anderen Smileys hat man mit nur einem Doppelpunkt eingefügt. Die neue Syntax entspricht dem XenForo-Standard und ist eindeutiger (geringere Wahrscheinlichkeit, dass irgendwo ein Smiley angezeigt wird wo keiner beabsichtigt ist). Der Importer schreibt alle alten Beiträge automatisch auf die neue Syntax um, d.h. in alten Beiträgen vorhandene Smileys funktionieren weiterhin.

2) Wir haben ein paar Smileys umbenannt: "freak2" -> "freaky", "PCangry" -> "pcangry", "verwandlu" -> "verwandlung", "vernasche" -> "vernaschen", "streichel" -> "streicheln", "utenforce" -> "utenforcer", "utmachine" -> "utminigun", "utflack" -> "utflakcannon", "utglob" -> "utbiorifle", "utplasma" -> "utpulsegun". Um alte Beiträge kümmert sich auch hier automatisch der Importer.

3) Wir haben die beiden Smileys redface.gif ("o") und eek.gif ("eek") zusammengefasst, weil "o" und "eek" beide dasselbe (nämlich Erstaunen) ausdrücken sollen. Wir haben die beiden Smileys Frech.gif ("frech") und lick1.gif ("zunge") mit tongue.gif ("p") zusammengefasst, weil sie dasselbe darstellen und kaum genutzt wurden. Zudem haben wir das alte Smiley angry.gif ("sauer") mit mad.gif ("mad") zusammengefasst, weil es dasselbe darstellt und selten genutzt wurde. Der Importer kümmert sich darum, Vorkommen dieser Smileys in alten Beiträgen automatisch anzupassen.

4) Ich habe alle Smiley-Dateien mit Gifsicle einer Schrumpfkur unterzogen, sodass alle zusammen jetzt nur noch 58 anstatt 89 KB groß sind. :cool_alt:

Abschließend ist hier die Liste der Smileys im neuen Forum: https://www.computerbase.de/forum/help/smilies/

Vielleicht bieten wir zukünftig irgendwann eine Einstellung an, um anstelle der Standard-Smileys hochauflösende Emojis anzuzeigen (falls ein Äquivalent vorhanden ist)? Allgemein würde mich interessieren, wie wichtig euch die klassischen Smileys sind und wie ihr die alten Smileys im neuen Forum auf eurem Smartphone empfindet. :)
 
Zuletzt bearbeitet: (Link aktualisiert)
Hmm, die Suchfunktion in diesem Thread hat nix ergeben, also poste ich mal:

Wenn ich im Testforum eine Tabelle in meinem Post erstelle, kann ich im Editor mit der Maus die Breite der Tabelle und auch der einzelnen Spalten verändern. Im endgültigen Post wird die Breite jeder Spalte dann aber unabhängig von diesen Veränderungen immer auf die minimal nötige Breite reduziert. Ist das ein Bug oder ist gar nicht gewünscht, dass man die Spalten-/Tabellenbreite einstellen kann? In zweiterem Fall wäre es ja sinnlos, diese Möglichkeit im Editor noch zu haben...
 
Dass im endgültigen Post die Breite der Tabellenspalten vom Browser automatisch bestimmt wird ist Absicht. Etwas anderes ergäbe in einem Responsive Design denke ich nicht viel Sinn, weil der Verfasser ja nicht davon ausgehen kann, dass andere Nutzer dieselbe Viewport-Breite haben wie er selbst. (Theoretisch könnte man dem Verfasser die Möglichkeit geben, die Breite aller Tabellenspalten für verschiedene Viewport-Breiten einzeln festzulegen. Abgesehen vom Implementierungsaufwand wäre das aber vermutlich auch ein Aufwand, den man keinem Verfasser zumuten kann.)

Der vom neuen Forum genutzte WYSIWYG-Editor Froala hat eine tableResizer-Option, mit der man eine manuelle Änderung der Spaltenbreite während des Editierens unterbinden kann. Wenn man die deaktiviert, haben aber einfach alle Spalten starr dieselbe Breite (unabhängig vom Inhalt).

Ich erzwinge jetzt mal testweise via CSS, dass auch beim Editieren eines Beitrags der Browser die Spaltenbreite automatisch bestimmt. Bitte probiere aus, ob das ohne Probleme funktioniert! Wenn ja, dann lassen wir das bis auf Weiteres so (und ich deaktiviere noch die "tableResizer"-Option, damit bei Maus-Hover über eine Trennlinie nicht mehr Eindruck entsteht, man könne die Spaltenbreite manuell festlegen).
 
Steffen schrieb:
Vielleicht bieten wir zukünftig irgendwann eine Einstellung an, um anstelle der Standard-Smileys hochauflösende Emojis anzuzeigen (falls ein Äquivalent vorhanden ist)? Allgemein würde mich interessieren, wie wichtig euch die klassischen Smileys sind und wie ihr die alten Smileys im neuen Forum auf eurem Smartphone empfindet. :)
Die dürfen ruhig hübscher/hoch auflösender werden, so lange man noch die ursprüngliche Bedeutung erkennen kann.
 
So wie es sich jetzt grade darstellt, kann ich den linken und rechten Rand der Tabelle im Editor weiterhin verschieben, nur wenn ich eine innenliegende Linie verschiebe (was erstmal noch zu gehen scheint) springt sie auch im Editor wieder an eine vorgegebene Position zurück.
Am schönsten wäre natürlich eine Lösung, bei der sich der Editor zumindest ähnlich verhält, wie die spätere Anzeige.
Das hieße: nichtverschiebbare Ränder und Trennlinien sowie Spaltenbreiten, die sich dem Inhalt anpassen.

EDIT:
Das Addon Editor Manager liest sich ja ganz gut, aber da ich das ohne Forum ja nicht testen kann, weiß ich auch nicht, wie deren Tabelleninplementation ist...

EDIT2:
Wäre ein kleiner Workaround ggf. den Wert tableResizerOffset auf 0 (oder -1 oder was auch immer er akzeptiert) zu setzen?
 
Zuletzt bearbeitet:
Öhm, ich hatte doch in meinem letzten Beitrag geschrieben, dass ich die "tableResizer"-Option bei erfolgreichem Test noch deaktiviere, damit bei Maus-Hover über eine Trennlinie nicht mehr Eindruck entsteht, man könne die Spaltenbreite manuell festlegen. Vielleicht war das etwas missverständlich oder kompliziert formuliert, aber jetzt habe ich diese Option deaktiviert und es sollte alles passen. Bitte nochmal probieren! :)

(Eventuell musst du explizit die Seite neuladen, damit die Änderung wirksam wird.)
 
Danke, ja, es lag wohl am Browsercache. Jetzt merke ich die Änderung. ;) Allerdings:

Steffen schrieb:
Der vom neuen Forum genutzte WYSIWYG-Editor Froala hat eine tableResizer-Option, mit der man eine manuelle Änderung der Spaltenbreite während des Editierens unterbinden kann. Wenn man die deaktiviert, haben aber einfach alle Spalten starr dieselbe Breite (unabhängig vom Inhalt).

Die Mouse-Over-Funktion ist jetzt wie erwartet weg, aber im Editor verschiebt sich die Spaltenbreite beim Befüllen der Zellen lustig hin und her. Im fertigen Post sieht nach wie vor alles aus wie vorher, also an Inhalt angepasste Breiten. Auf welche Stelle bezieht sich jetzt deine Aussage, dass dann alle Spalten starr die selbe Breite haben?

EDIT: Wenn ich an der markierten Stelle die Tabellenbreite von 100% auf z.B. 5% ändere, zeigt er im Editor die leeren Tabellenspalten in der definierten Mindestbreite (hier 15 Pixel) an und sie wachsen nur mit dem Befüllen - das würde dann exakt dem gewünschten Verhalten entsprechen. Was meinst du?

screenshot33.png
 
Zuletzt bearbeitet:
Tarkoon schrieb:
Auf welche Stelle bezieht sich jetzt deine Aussage, dass dann alle Spalten starr die selbe Breite haben?
Auf den Editor. Aber nur dann, wenn man ausschließlich diese Option aktiviert. Ich habe zusätzlich dazu via CSS noch dafür gesorgt, dass die Spalten eine flexible Breite haben ("width: auto !important").

Tarkoon schrieb:
Wenn ich an der markierten Stelle die Tabellenbreite von 100% auf z.B. 5% ändere, zeigt er im Editor die leeren Tabellenspalten in der definierten Mindestbreite (hier 15 Pixel) an und sie wachsen nur mit dem Befüllen - das würde dann exakt dem gewünschten Verhalten entsprechen. Was meinst du?
Eigentlich sollte es schon genauso sein. Die 100% Tabellenbreite stehen eigentlich nicht mehr im CSS. Kannst du nochmal bei geöffneten Dev-Tools mit Strg+Shift+F5 force-reloaden? Dann sollte es eigentlich so sein wie du es beschreibst (also wie im alten Forum). :)
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben