Meine Tutorials

  • Hey,

    ich erhalte immer wieder Nachfragen, ob ich nich dieses oder jenes Tutorial, welches ich vor einigen Monaten verfasst und mittlerweile aus dem Netz habe verschwinden lassen, nicht noch einmal posten könnte.

    Ich möchte diesen Thread jetzt einfach mal ganz frech für ein wenig "Eigenwerbung" nutzen und die meistgelesen Tutorials noch einmal für die Ewigkeit festhalten :)

    Ich hoffe, da ist auch etwas für euch bei ;)

  • Hallo,

    schon öfter kam die Frage auf, wie man den Standardavatar im WCF 2.0 gegen einen eigenen tauschen kann.

    Hierzu gibt es verschiedene Lösungsansätze, wobei der Einfachste lautet: Ersetze den Original-Avatar (avatar-default.svg) durch deine Grafik.

    Dieses Vorgehen ist in vielerlei Hinsicht problematisch:

    • Sobald es ein Update des WCF 2.0 erfordert, wird die Datei in ihren Ursprung zurückversetzt, d.h. es wird wieder der originale Avatar an Stelle des Ersatzbildes angezeigt
    • Nicht jedes Bild eignet sich zur Konvertierung in eine SVG-Grafik
    • Nicht jeder ist in der Lage, ein Bild in eine SVG-Grafik zu konvertieren, oder Grafiken in eine SVG-Datei einzubetten

    Ein anderer, nicht weniger problematischer Lösungsansatz ist das sog. "Hardcoden" der Ersatzgrafik. Dabei werden Änderungen an der Datei /wcf/lib/data/user/avatar/DefaultAvatar.class.php vorgenommen, um das gewünschte Ergebnis zu erreichen. Die Wahrscheinlichkeit, dass die Änderungen an der Datei durch ein Update verloren gehen, ist weitaus höher, als beim erstgenannten Lösungsansatz.

    Eine weitere Idee ist, ein Bild (z.B. eine PNG- oder JPG-Grafik) in das Verzeichnis /wcf/images/avatars/ als avatar-default.svg abzuspeichern. Kann - Muss aber nicht. Zum Einen bleibt dies von der o.g. Updateproblematik nicht verschont und zum Anderen versucht der Browser natürlich, das Bild auch als SVG zu interpretieren.

    Was tun?

    Nach Meldung dieses Problems habe ich mir für eine der von mir betreuten Communities eine Möglichkeit überlegt, die zuvor genannten Probleme zumindest in Bezug auf die Updateproblematik dauerhaft zu lösen. Dazu habe ich mir im Hauptverzeichnis der Community-Installation (für gewöhnlich das Verzeichnis, in dem das WoltLab Burning Board installiert ist, da es sich dabei meist um die im WCF installierte Standard-Anwendung handelt) ein Verzeichnis custom angelegt. In diesem Verzeichnis habe ich meine Ersatzgrafiken für die Dateien avatar-default.svg (ersatzAvatar.svg) und favicon.ico (ersatzFavicon.ico) abgelegt.

    Nun habe ich eine Datei .htaccess im Hauptverzeichnis angelegt und folgenden Inhalt hinterlegt:

    Apache Configuration
    <IfModule mod_rewrite.c>
    	RewriteEngine On
    	RewriteBase /
    
    
    
    
    	RewriteRule ^wcf/images/avatars/avatar-default.svg$ /custom/ersatzAvatar.svg [L]
    	RewriteRule ^wcf/images/favicon.ico$ /custom/ersatzFavicon.ico [L]
    </IfModule>


    Was bewirkt dieser Code?

    Der eigentliche "Trick" ist in eine Bedingung (<IfModule mod_rewrite.c> ... </IfModule> eingekapselt. Diese Bedingung sagt, dass alles innerhalb dieser Bedingung nur dann ausgeführt werden soll, wenn das Apache-Modul "mod_rewrite" zur Verfügung steht d.h. das mod_rewrite-Modul ist Grundvorraussetzung für diesen "Trick". Verwendet man einen anderen Webserver (z.B. nginx), ist das Vorgehen etwas anders. Dazu jedoch später mehr.

    Wird nun die o.g. Bedingung erfüllt, teilen wir dem Webserver durch RewriteEngine On mit, dass wir im aktuellen Verzeichnis (und dessen Unterverzeichnissen) das mod_rewrite-Modul verwenden möchten. Die Zeile RewriteBase / ist optional und für gewöhnlich nur dann von Nöten (und anzupassen), wenn wir uns in einem Unterverzeichnis befinden.

    Die beiden darauffolgenden Zeilen bilden den eigentlichen "Trick". Dieser besteht darin, dass wir sog. "Umschreibungen" auf dem Webserver vornehmen und den Aufruf der Dateien /wcf/images/avatars/avatar-default.svg und /wcf/images/favicon.ico auf unsere zuvor im Verzeichnis /custom/ abgelegten Ersatzgrafiken umlenken.

    Das Ergebnis kann sich sehen lassen: Durch den erstmaligen Direktaufruf der Dateien (und u.U. einer Aktualisierung des Browser-Caches) bekommen wir beim Aufruf von /wcf/images/avatars/avatar-default.svg und /wcf/images/favicon.ico unsere Ersatzgrafiken angezeigt.

    Vorteil: Die o.g. Updateproblematik ist dauerhaft umgangen.
    Nachteil: Durch die Umschreibungen entstehen keine Nachteile. Jedoch ist das Problem mit den Grafiken, die sich nicht problemlos in SVG konvertieren lassen, nicht behoben.

    Ich möchte aber gerne eine hochauflösende JPEG-Datei als Standard-Avatar verwenden

    Wer bis hierhin aufmerksam gelesen hat erinnert sich vielleicht, dass man durch Manipulation einer PHP-Datei die Möglichkeit hat, ein anderes Bild anzugeben (was durchaus auch eine JPG-Datei sein kann). Aber die bereits mehrfach erwähnte Updateproblematik sollte nicht in Vergessenheit geraten.

    Um das gewünschte Ziel zu erreichen und zeitgleich das Problem mit den Updates zu umgehen, bemächtigen wir uns wieder der Umschreibung. Diese kann 1:1 von oben übernommen werden, jedoch müssen wir an Zeile 5 eine Änderung vornehmen.

    Theoretisch würde es reichen, aus /custom/avatar-default.svg einfach /custom/ersatzAvatar.jpg zu machen. Aber wenn wir schon dabei sind, machen wir es doch direkt richtig. Durch kleine Veränderungen an den sog. "Flags" (im o.g. Code [L]) teilen wir dem Browser einfach mit, dass es sich trotz der Dateiendung .svg um eine JPEG-Datei handelt:

    Apache Configuration
    RewriteRule ^wcf/images/avatars/avatar-default.svg$ /custom/ersatzAvatar.jpg [L,T=image/jpeg]


    Der wesentliche Unterschied ist sofort erkennbar: Hinzugekommen ist das sog. "[T]ype-Flag". Damit teilen wir dem Browser den Dateitypen der Datei mit, die wir als Ersatz für den Standard-Avatar verwenden möchten.

    Und damit war's das :)

    Ich muss in zwei Minuten dringend weg / Ist mir zu kompliziert / Ich habe keine Lust, mir das alles durchzulesen - aka "Geht das auch in Kurzform?"

    Lege im Hauptverzeichnis deines Forums ein Verzeichnis custom an. Speichere deine Ersatzgrafik für den Standard-Avatar und das Favicon in diesem Verzeichnis. Erstelle im Hauptverzeichnis deines Forums eine Datei namens .htaccess und füge folgendes ein:

    Apache Configuration
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
    
    
    
    
        RewriteRule ^wcf/images/avatars/avatar-default.svg$ /custom/ersatzAvatar.jpg [L,T=image/jpeg]
        RewriteRule ^wcf/images/favicon.ico$ /custom/ersatzFavicon.ico [L]
    </IfModule>


    Passe falls nötig die Dateinamen (ersatzAvatar.jpg und ersatzFavicon.ico) und den Dateitypen des Ersatz-Avatars (image/jpeg) an. Rufe danach die Dateien einmalig manuell in deinem Browser auf (ggf. Seite bzw. Browser-Cache aktualisieren). Fertig!

    Abschließend

    Abschließend noch ein kleiner Tipp: Ihr seid weder darauf angewiesen, dass die Dateien lokal vorliegen (d.h. auch extern gehostete Dateien sind möglich), noch muss es sich dabei um ein Bild handeln. Letzteres ist insoweit recht interessant, weil es z.B. möglich ist, dynamische Avatare mit Hilfe von PHP zu erzeugen und an Stelle des Standard-Avatars anzeigen zu lassen. Das [T]ype-Flag und auch der Header der PHP-Datei sollten jedoch einen gültigen Bildtypen zurückgeben.

    Happy rewriting!

  • Hallo,

    aufgrund einer aktuellen Diskussion im WoltLab-Forum und diesem Beitrag habe ich mich mal mit der Problematik beschäftigt.

    Was ich vorab sagen kann: Es handelt sich dabei um einen "Fehler" im CKEditor, nicht in der WoltLab-Software. Dieser wurde jedoch in einer aktuelleren Version des Editors behoben.

    Gibt's da was von Ratiopharm?


    Glücklicherweise ja. Problem ist jedoch, dass die Behebung des Fehlers einen manuellen Eingriff in den Quellcode des CKEditors erfordert. Aber ich versuche das Ganze so gut wie möglich zu erklären.

    Die Behebung ist recht schnell erledigt:

    • Öffnet die Datei /wcf/js/3rdParty/ckeditor/ckeditor.js
    • Sucht nach:

      JavaScript
      blockedKeystrokes:[CKEDITOR.CTRL+66,CKEDITOR.CTRL+73,CKEDITOR.CTRL+85,CKEDITOR.CTRL+89,CKEDITOR.CTRL+90,CKEDITOR.CTRL+CKEDITOR.SHIFT+90]
    • Ersetzt dies durch:

      JavaScript
      blockedKeystrokes:[CKEDITOR.CTRL+66,CKEDITOR.CTRL+73,CKEDITOR.CTRL+85]
    • Sucht nach:

      JavaScript
      a.setKeystroke([[CKEDITOR.CTRL+90,"undo"],[CKEDITOR.CTRL+89,"redo"],[CKEDITOR.CTRL+CKEDITOR.SHIFT+90,"redo"]]);
    • Ersetzt dies durch:

      JavaScript
      var ks=[CKEDITOR.CTRL+90,CKEDITOR.CTRL+89,CKEDITOR.CTRL+CKEDITOR.SHIFT+90];a.setKeystroke([[ks[0],'undo'],[ks[1],'redo'],[ks[2],'redo']]);a.on("contentDom",function(){var t=a.editable();t.attachListener(t,"keydown",function(t){CKEDITOR.tools.indexOf(ks,t.data.getKeystroke())>-1&&t.data.preventDefault()})});

    Das war's :) Aktualisiert nun die Seite (evtl. Browsercache leeren) und probiert, ob ihr STRG+Z bzw. STRG+Y nun verwenden könnt. Falls ja, haben wir alle unsere Hausaufgaben gemacht und erfreuen uns der neu gewonnenen Möglichkeit, im Quellcode-Modus des Editors Eingaben rückgängig machen- bzw. wiederholen zu können.

  • Hallo,

    in meinem heutigen Artikel möchte ich auf immer wiederkehrende Fragen zum Thema Seitenmenü eingehen:

    • Warum werden "externe" Links in der Seitennaviation trotz entsprechender Einstellung nicht in einem neuen Fenster geöffnet?
    • Wie kann ich dafür sorgen, dass externe Links in der Seitennavigation in einem neuen Fenster geöffnet werden?

    Warum werden "externe" Links in der Seitennaviation trotz entsprechender Einstellung nicht in einem neuen Fenster geöffnet?

    Das Problem an dieser Stelle ist eine irreführende Bezeichnung im Einstellungsbereich. Denn hier kann man zwar einen "externen" Link definieren, jedoch handelt es sich technisch nicht zwangsläufig um einen echten, externen Link. Ob es sich hier nun aber wirklich um einen "Fehler" im eigentlichen Sinne handelt, kann auch ich nicht mit Bestimmtheit sagen. Jedoch plane ich, eine entsprechende Änderung für das WCF 2.1 vorzuschlagen.

    Wie kann ich dafür sorgen, dass externe Links in der Seitennavigation in einem neuen Fenster geöffnet werden?

    Ich habe diese Frage schon in der Vergangenheit recht zufriedenstellend beantworten können. Hier gibt es aktuell zwei sinnvolle Lösungsansätze, wobei einer davon ein Plugin erfordert und der andere manuell umgesetzt werden kann. Und genau diese eine Möglichkeit möchte ich euch an dieser Stelle aufzeigen.

    Was ihr zuerst benötigt ist eine Templategruppe. Um eine neue Templategruppe anzulegen, loggt euch in das Admin Control Panel ein, und wählt den Punkt Templategruppe hinzufügen unter Darstellung -> Templates.

    Zuvor solltet ihr jedoch feststellen, ob eurem Stil bereits eine Templategruppe zugewiesen ist. Dazu wählt ihr im ACP unter Darstellung -> Stile -> Stile auflisten den von euch eingestellten Standardstil aus und prüft im Reiter Daten -> Allgemein -> Dateien den Punkt Template-Gruppe, ob hier etwas anderes definiert wurde, als "Standardtemplates". Ist dies nicht der Fall, könnt ihr wie oben beschrieben bedenkenlos eine neue Templategruppe anlegen und dem Stil dann an dieser Stelle die neu hinzugefügte Templategruppe zuweisen.

    Verwendet der Stil eine bereits bestehende Templategruppe, müssen wir keine neue Templategruppe anlegen. Jedoch müssen wir prüfen, ob die Templates, die wir ändern müssen, bereits in der Templategruppe enthalten sind. Dazu navigiert ihr im ACP zu Darstellung -> Templates -> Templates auflisten, wählt in dem Feld "Templategruppe" die entsprechende Templategruppe aus und klickt auf den Button "Absenden".

    Ihr erhaltet daraufhin eine Liste sämtlicher Templates, die in der Templategruppe enthalten sind. Sucht in dieser Liste nach den Templates:

    • footerMenu
    • mainMenu

    Ist min. eines dieser Templates vorhanden, so müsst ihr dieses im späteren Verlauf dieses Tutorials bearbeiten. Ist min. eines dieser Templates nicht in der Templategruppe enthalten (bzw. ihr habt zuvor eine neue Templategruppe angelegt), so müssen die fehlenden Templates aus den "Standardtemplates" kopiert werden. Dazu wählt ihr unter Darstellung -> Templates -> Templates auflisten die Templategruppe "Standardtemplates" und sucht die o.g. Templates.


    Links neben jedem Template findet ihr ein Icon "Template kopieren". Klickt auf dieses Icon, wählt unter dem Punkt "Templategruppe" die vorhandene (bzw. neu angelegte) Templategruppe und klickt auf "Absenden".

    Diese Schritte sind für sämtliche Stile zu wiederholen, die bei euch installiert sind. Achtet bitte darauf, dass ihr beim Kopieren der Standardtemplates keine Templates überschreibt, die in einer Templategruppe bereits existieren, da es sonst zu unerwarteten Darstellungsproblemen kommen kann.

    Nun haben wir uns eine Basis geschaffen, mit der wir relativ einfach den gewünschten Effekt erzielen können. Dazu müssen wir in sämtlichen Templategruppen die o.g. Templates bearbeiten.

    Klickt auf das Stift-Icon neben den jeweiligen Templates (bzw. klickt auf den Namen des Templates) und sucht darin folgendes:

    Code
    <a href="{$menuItem->getProcessor()->getLink()}">

    Ersetzt sämtliche Vorkommen dieser Zeile (d.h. sie kann öfter vorkommen) durch:

    Code
    <a href="{$menuItem->getProcessor()->getLink()}"{if EXTERNAL_LINK_TARGET_BLANK && $menuItem->getProcessor()->menuItemController|empty} target="_blank"{/if}>

    Das war's schon :)

    Aktuell sind diese Änderungen bei Verwendung der Standard-Templates drei Mal nötig (1x im Template footerMenu und 2x im Template mainMenu). Da sich die Standardtemplates über die Zeit mal ändern können, poste ich hier bewusst keine vollständigen Templates.

    Beachtet in dieser Hinsicht bitte, dass eigene Templates in eigenen Templategruppen bei einem Update der Software nicht automatisch mit aktualisiert werden d.h. ihr müsst eventuelle Änderungen an den Originaltemplates u.U. per Hand in eure eigenen Templates einpflegen. Jedoch könnt ihr euch das ein wenig erleichtern, indem ihr nach jedem Update des WolLab Community Framework (WCF) prüft, ob sich auf den folgenden Seiten kürzlich Änderungen ergeben haben:

    https://github.com/WoltLab/WCF/bl…/footerMenu.tpl
    https://github.com/WoltLab/WCF/bl…es/mainMenu.tpl

    Oben steht etwas von einer Plugin-Lösung. Wo finde ich die?

    Zum aktuellen Zeitpunkt ist mir kein solches Plugin bekannt. Jedoch habe ich ein solches während des Verfassens dieses Artikels bereits vollständig geplant ;)

  • Hallo,

    manch einem dürfte dies bekannt vorkommen: Man möchte unter Plesk das WBB4 installieren und unmittelbar nach Beginn der Installation erhält man die Fehlermeldung:

    Code
    504 Gateway Time-out

    Woran liegt das?

    Genau genommen handelt es sich hier um einen Softwarefehler seitens Plesk in Kombination mit nginx (bzw. php-fpm). Plesk erstellt für jeden VHost eine eigene Konfiguration, abhängig von den Einstellungen, die man im Plesk Panel vorgenommen hat. Das Problem hier ist, dass ein spezieller Konfigurationswert fastcgi_read_timeout bei der Konfiguration eines VHosts stets unberührt bleibt. Der Standardwert beträgt 45 d.h. nach 45 Sekunden Ausführungszeit rennt der Webserver in ein Timeout.

    Dieses Problem lässt sich auf zwei verschiedenen Wegen beheben. Einer davon wäre, die o.g. Konfigurationsvariable fest zu erhöhen. Das macht aber auch nur bedingt Sinn, da das später immernoch zu Problemen führen kann. Ein wesentlich besserer Weg ist, die VHost-Konfiguration mit einzubeziehen. Plesk bietet u.A. die Möglichkeit an, die PHP-Konfigurationsvariable max_execution_time für einen VHost zu definieren. Sinnloserweise kann diese Variable die Konfiguration des Webservers um Längen übersteigen. Problem daran ist jedoch, dass die Konfiguration des Webservers logischerweise höher priorisiert ist, als die PHP-Konfiguration d.h. egal, wie hoch man den Wert max_execution_time definiert, die Ausführung wird immer nach genau 45 Sekunden abgebrochen.

    Was kann ich tun?

    Wenn Sie normaler Webspacekunde sind, können Sie an dieser Stelle nichts weiter tun, als Ihren Hoster darauf aufmerksam zu machen. Sollten Sie jedoch Root-Zugriff haben (eigener V-/Root-Server), so können Sie mit Hilfe eines kleinen Workarounds dafür sorgen, dass die Webserver-Konfiguration mit Ihrer PHP-Präferenz stets synchronisiert wird.

    Dazu ist es vorab nötig, Plesk mitzuteilen, dass wir die Konfiguration unserer VHosts beeinflussen möchten. Zu diesem Zweck erstellen wir erst einmal ein Verzeichnis custom im Templates-Verzeichnis von Plesk:

    mkdir -p /usr/local/psa/admin/conf/templates/custom/domain/service/*

    Sobald dies erledigt ist, müssen wir uns das Original-Template (fpm.php) aus dem darüber liegenden Verzeichnis default/domain/service/ kopieren:

    cp -p /usr/local/psa/admin/conf/templates/default/domain/service/fpm.php /usr/local/psa/admin/conf/templates/custom/domain/service/.*

    Nachdem wir die Datei kopiert haben, müssen wir diese bearbeiten. Öffnen Sie dazu die Datei custom/domain/service/fpm.php und suchen Sie die Zeile:

    Code
    fastcgi_split_path_info ^((?U).+\.php)(/?.+)$;

    Fügen Sie darunter folgendes ein:

    PHP
    <?php if ($VAR->domain->physicalHosting->scriptTimeout): ?>
    fastcgi_read_timeout <?php echo $VAR->domain->physicalHosting->scriptTimeout; ?>;
    <?php endif; ?>

    Das war's. Jetzt noch speichern und schon sorgen wir dafür, dass die Einstellungen, die in Plesk vorgenommen werden, künftig mit der Webserver-Konfiguration von Plesk synchronisiert werden.

    Doch wer das hier liest, steht ja bereits vor dem o.g. Problem und unsere Änderungen beziehen sich ausschließlich auf künftige Veränderungen an den VHosts. Was wir also abschließend tun müssen ist, die bereits erstellten Konfigurationen zu synchronisieren. Dazu führen wir mit Hilfe der Konsole einfach folgenden Befehl aus:

    /usr/local/psa/admin/bin/httpdmng --reconfigure-all*

    Die Ausführung dieses Befehls kann u.U. einige Zeit in Anspruch nehmen, weil dadurch die Konfiguration sämtlicher bereits existierenden VHosts neu erstellt wird. Sobald dieser Vorgang jedoch abgeschlossen wurde, ist das eigentliche Problem jetzt und in Zukunft gelöst.

    Sollte es selbst hiernach noch zum o.g. Problem kommen, so versuchen Sie, die PHP-Einstellung max_execution_time für den entsprechenden VHost zu erhöhen. Ein Wert zwischen 60 und 120 ist hier im Normalfall völlig ausreichend. Von utopischen Angaben wie 3600 sollte abgesehen werden. Auch führt die Angabe von 0 (d.h. kein Timeout) nicht zum gewünschten Ziel.

    Viel Erfolg!


    * = Bitte beachten Sie hierbei, dass der Speicherort je nach Betriebssystem und Konfiguration abweichen kann!

  • Ich wurde nun mehrfach auf das Tutorial WCF 2.0: Standardavatar "sicher" austauschen angesprochen und gefragt, ob ich dies näher erläutern könnte:

    Letzteres ist insoweit recht interessant, weil es z.B. möglich ist, dynamische Avatare mit Hilfe von PHP zu erzeugen und an Stelle des Standard-Avatars anzeigen zu lassen.


    Da ich genau heute davon Gebrauch gemacht habe, möchte ich diese Frage nun kurz beantworten. Sinn macht das Ganze zum Beispiel dann, wenn man einen Stil besitzt, der in mehreren Farbvariationen zur Verfügung steht und man den Standard-Avatar gemäß der Stil-Farbe anzeigen lassen möchte. Ein Beispiel dafür ist der kürzlich erschienene Stil Base von cls-design, der in 5 verschiedenen Farben ausgeliefert wird.

    Möchte man nun für jedes einzelne Farbschemata einen anderen Avatar anzeigen lassen, ist dies aktuell nur mittels PHP möglich, da wir sonst nicht wissen (können), welches Farbschema vom aktuellen Benutzer ausgewählt ist. Ihr müsst das o.g. Tutorial nahezu vollständig abarbeiten, jedoch an Stelle der Datei ersatzAvatar.jpg eine Datei ersatzAvatar.php anlegen, wobei der Dateiname relativ egal- und nur die Datei-Endung .php wirklich relevant ist.

    In diese PHP-Datei kopiert ihr diesen Code:


    Das war's auch schon fast. Eigene Anpassungen sind an für sich nicht notwendig.


    Damit das Ganze nun den gewünschten Effekt hat, müsst ihr in den Image-Verzeichnissen sämtlicher Stile (in denen ihr den Avatar dynamisch ersetzen wollt) eine Datei namens avatar-default.svg hinterlegen. Am Ende sollte eure Struktur (ausgehend vom Stil Base) in etwa so aussehen:


    Code
    - /wcf
    -- /images
    --- /baseBlue2
    ---- /avatar-default.svg
    ---- /background.jpg
    ---- /backgroundBlur.jpg
    ---- /logo.png

    Habt ihr das für sämtliche Stile gemacht, wird beim Stilwechsel jeweils der zum gewählten Stil passende Avatar ausgewählt. Wurde für einen Stil kein Avatar hinterlegt, wird der Standard-Avatar des WCF verwendet.

    Abschließend noch einmal der Hinweis, dass ihr euren Webserver natürlich anweisen müsst, die PHP-Datei zu verwenden. Das sollte in etwa so aussehen:

    Apache2:
    RewriteRule ^/wcf/images/avatars/avatar-default.svg$ /custom/avatar-default.php

    nginx:
    rewrite /wcf/images/avatars/avatar-default.svg$ /custom/avatar-default.php last;

    Wobei /custom/avatar-default.php dem Pfad+Dateinamen der o.g. Datei entsprechen muss.

    Viel Erfolg :)

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!