Nachlese zum WordPress Meetup #128 – Juli 2025 – Code Snippets

Code Snippets vs. Plugins: Ein Leitfaden für WordPress-Entwickler

Rückblick auf meine Präsentation beim WordPress Meetup Hamburg 2025

Bei unserem letzten WordPress Meetup in Hamburg hatte ich die Gelegenheit, über ein Thema zu sprechen, das viele von uns täglich beschäftigt: Code Snippets vs. Plugins. Die Entscheidung zwischen diesen beiden Ansätzen kann den Unterschied zwischen einer performanten, wartbaren Website und einem aufgeblähten, schwer zu pflegenden System ausmachen.

Zunächst zur Klarstellung: Code Snippets sind kleine, fokussierte Code-Blöcke in PHP, CSS oder JavaScript, die entweder direkt in die functions.php oder über Snippet-Management-Plugins eingefügt werden. Sie lösen spezifische, einzelne Probleme. Plugins hingegen sind komplette Software-Pakete mit umfangreichen Features, Benutzeroberflächen und automatischen Update-Mechanismen.

Die Performance-Frage: Warum Code Snippets oft die Nase vorn haben

Code Snippets sind wahre Performance-Champions, und das aus gutem Grund. Sie laden nur den Code, den du wirklich brauchst – keine unnötigen Skripte, weniger Datenbankabfragen und minimaler Impact auf die Ladezeiten. Während ein Plugin oft ein komplettes Framework mitbringt, um eine einfache Funktion zu erfüllen, macht ein Code Snippet genau das, was es soll – nicht mehr und nicht weniger. Besonders bei Server-Ressourcen macht sich das bemerkbar, da nur das Nötigste ausgeführt wird und keine zusätzlichen HTTP-Requests für Assets anfallen.

Dazu kommt die volle Kontrolle über jeden Aspekt des Codes. Du bestimmst exakt, was passiert, wann es passiert und wie es passiert. Keine versteckten Features, keine Überraschungen bei Updates und keine unerwarteten Wechselwirkungen mit anderen Komponenten. Diese Transparenz ermöglicht es auch, die Ausführungsreihenfolge präzise zu steuern – ein Aspekt, der bei der WordPress-Entwicklung oft unterschätzt wird.

Aus finanzieller Sicht sind Code Snippets ebenfalls attraktiv: keine Lizenzkosten, keine Abhängigkeit von Drittanbietern und keine Überraschungen bei Preisänderungen. Einmal geschrieben und getestet, läuft der Code langfristig stabil, ohne dass jährliche Erneuerungen oder plötzliche Vendor Lock-ins drohen.

Die Herausforderungen: Warum nicht jeder zu Code Snippets greifen sollte

Natürlich haben Code Snippets auch ihre Schattenseiten. Der größte Nachteil liegt auf der Hand: Du brauchst Programmierkenntnisse. Ein einziger Fehler kann die komplette Website lahmlegen, und es gibt keine integrierten Validierungssysteme oder „Sandboxing“ wie bei professionellen Plugins. Das Risiko ist real und sollte nicht unterschätzt werden.

Der Wartungsaufwand ist ein weiterer kritischer Punkt. Updates müssen manuell durchgeführt werden, Kompatibilität mit neuen WordPress-Versionen muss selbst sichergestellt werden, und es gibt keine automatischen Sicherheits-Patches. Ohne eine ordentliche Dokumentation und Versionskontrolle kann das schnell zum Alptraum werden, besonders wenn mehrere Entwickler am Projekt arbeiten oder du nach Monaten eigenen Code wieder anfassen musst.

Plugins: Komfort hat seinen Preis

Plugins punkten zweifellos mit ihrer Benutzerfreundlichkeit. Installation mit wenigen Klicks, intuitive Benutzeroberflächen und Zugänglichkeit auch für Nicht-Techniker machen sie zur ersten Wahl vieler WordPress-Nutzer. Dazu kommt die professionelle Entwicklung mit regelmäßigen Updates, dediziertem Support und ausführlicher Dokumentation. Die Community testet die Software und meldet Bugs zurück, was zu einer robusten Architektur führt, die auch Edge-Cases berücksichtigt.

Aber dieser Komfort hat seinen Preis – und zwar nicht nur finanziell. Der Performance-Impact kann erheblich sein, da Plugins oft unnötige Features laden, die du gar nicht brauchst. Datenbank-Bloat, multiple HTTP-Requests für Assets und erhöhter Speicherbedarf auf dem Server sind häufige Folgen. Noch problematischer sind Kompatibilitätsprobleme zwischen verschiedenen Plugins oder Theme-Inkompatibilitäten, die schwer vorhersehbare Wechselwirkungen verursachen können. Besonders bedenklich: Plugins sind für 54% aller WordPress-Sicherheitslücken verantwortlich.

Technische Einblicke: Loading Order und Debugging

Ein Aspekt, den viele übersehen, ist die WordPress-Ladereihenfolge. Must-Use Plugins werden zuerst geladen, dann reguläre Plugins, gefolgt von Setup-Theme-Hooks, dem Theme selbst und schließlich dem vollständigen WordPress-System. Diese Reihenfolge zu verstehen ist entscheidend für die korrekte Implementierung von Code Snippets, besonders wenn sie mit anderen Komponenten interagieren sollen.

Für das Debugging von Code Snippets sind die richtigen wp-config.php-Einstellungen essentiell. WP_DEBUG sollte aktiviert, WP_DEBUG_LOG auf true gesetzt und WP_DEBUG_DISPLAY im Live-Betrieb deaktiviert sein. Tools wie Query Monitor für Hook-Tracking oder Debug Bar für Performance-Analyse können bei der Fehlersuche wahre Lebensretter sein.

Der goldene Mittelweg: Wann was verwenden?

Für diejenigen, die nicht direkt in die functions.php eingreifen wollen, gibt es professionelle Snippet-Management-Lösungen. WPCode mit über 2 Millionen Installationen bietet automatische Fehler-Deaktivierung und einen Safe Mode. Code Snippets punktet mit 900.000+ Installationen durch Tags, Beschreibungen und Multisite-Kompatibilität. FluentSnippets fokussiert sich auf Zero-Query-Ausführung für beste Performance, während WPCodeBox als Premium-Lösung Cloud-Backup und eine umfangreiche Bibliothek bietet.

In der Praxis zeigen sich klare Anwendungsbereiche: Code Snippets sind ideal für einfache, fokussierte Funktionen wie das Deaktivieren von Gutenberg, rollenbasierte Admin-Umleitungen oder Custom Dashboard-Widgets. Besonders bei performance-kritischen Websites, budget-beschränkten Projekten oder wenn langfristige Stabilität gewünscht ist, spielen sie ihre Stärken aus.

Plugins sind hingegen die richtige Wahl bei komplexer Funktionalität wie E-Commerce oder Membership-Systemen, bei Zeitdruck in der Implementierung, für nicht-technische Nutzer oder wenn professioneller Support benötigt wird.

Fazit: Die Kunst der richtigen Entscheidung

Die Entscheidung zwischen Code Snippets und Plugins ist keine Entweder-oder-Frage. Der richtige Mix macht’s! Code Snippets bieten Kontrolle und Performance, Plugins Komfort und Support. Wichtig ist dabei, immer zuerst in einer Testumgebung zu implementieren, Code gut zu dokumentieren, Sicherheitsaspekte zu durchdenken und umfangreiche Prüfungen vor dem Produktiveinsatz durchzuführen.

Das WordPress-Ökosystem bietet uns die Flexibilität, für jeden Anwendungsfall die beste Lösung zu wählen. Die Kunst liegt darin, diese Entscheidung bewusst und fundiert zu treffen – basierend auf den spezifischen Anforderungen des Projekts, den verfügbaren Ressourcen und den langfristigen Zielen.

Habt ihr Fragen oder eigene Erfahrungen mit Code Snippets vs. Plugins? Ich freue mich auf eure Kommentare und den Austausch in der WordPress-Community!

WordPress Meetup #128 – Juli 2025 – Code-Snippets

Thema: WordPress Code-Snippets – Performance, Sicherheit & Barrierefreiheit durch maßgeschneiderte Lösungen

In diesem Talk zeigen wir euch, wie ihr mit durchdachten Code-Snippets euer WordPress in verschiedenen Bereichen optimieren könnt – ganz ohne aufwendige Plugins. Wir stellen verschiedene Snippet-Management-Tools vor und demonstrieren praxiserprobte Lösungen, die ihr sofort umsetzen könnt.

Ein Talk für alle, die wissen wollen, wie WordPress mit wenigen Zeilen Code spürbar besser gemacht werden kann.

Im Anschluss wird es wie immer Zeit für Fragen, Gespräche und Networking geben. Wir freuen uns auf angeregte Diskussionen, den Austausch von Erfahrungen und nützlichen Tipps rund um das Thema WordPress.

Weiterlesen

Nachlese zum WordPress Meetup #126 – Mai 2025 – Barrierefreie Websites

Mit dem European Accessibility Act und dessen Umsetzung in nationales Recht als Barrierefreiheitsstärkungsgesetz (BFSG) kommt ab dem 28. Juni 2025 eine neue Anforderung auf uns zu. Allerdings mit vielen Einschränkungen, für wen das Gesetz überhaupt gilt.

Im Gegensatz zum letzten Meetup mit diesem Thema wurde dieses Mal gemeinsam Wissen zusammengetragen und praktisch an das Thema herangegangen.

Wichtige Ressourcen

Wichtiger Hinweis

Öffentliche Einrichtungen mussten schon vor dem BFSG Barrierefreiheit beachten!

Low Hanging Fruits – Schnell umsetzbare Maßnahmen

1. Skip to Main Content

  • Falls nicht vorhanden: Theme wechseln!
  • Nach dem öffnenden <body>-Tag gibt es einen Action Hook in WordPress
  • Wird oft auch von Google genutzt
  • Dort kann man den Skip-Link einfügen

2. Überschriften-Hierarchie

  • Korrekte Heading-Struktur einhalten (H1 → H2 → H3 etc.)
  • Keine Ebenen überspringen

3. Farbkontraste und klickbare Elemente

  • Ausreichende Kontraste sicherstellen
  • Klickbare Elemente anderweitig kennzeichnen (Unterstriche, Icons)
  • Nicht nur auf Farbe als Unterscheidungsmerkmal setzen

4. Alt-Texte richtig einsetzen

  • Logo auf Startseite: Welcher Text sollte es haben?
  • Alt-Texte können in den Media-Elementen customized werden
  • Alt-Texte dürfen gerne beschreibend sein
  • Dekorative Bilder: aria-label="hidden", role="presentation" oder leerer Alt-Text alt=""
  • Alt-Texte sind auch gut für SEO!
  • Entscheidungshilfe: W3C Decision Tree für Alt-Texte

5. Formulare barrierefrei gestalten

  • Checkboxen via aria-label auch über Text ansteuerbar machen
  • Labels für Suchleisten sind sinnvoll
  • Aria-Labels für Formulare korrekt einsetzen
  • ARIA Dokumentation: MDN aria-label | ARIA Landmark Roles

6. Typografie und Lesbarkeit

  • Schriftstärken beachten – mit und ohne Serifen
  • Schriftschnitte immer mit laden bei mehreren font-weights
  • Keinen Blocksatz setzen! (erschwert das Lesen)

7. Weitere wichtige Punkte

  • 404-Seiten auf Barrierefreiheit checken
  • Vermeiden von CAPTCHAs mit Bildern
  • ARIA richtig verstehen und einsetzen

Testing-Tools für Barrierefreiheit

Grundsatz: Es gibt viele Möglichkeiten barrierefreie Seiten zu testen, aber am besten ist es, selbst zu testen!

Browser-Extensions

Online-Tools

Zertifizierung

  • CPACCT – Testverfahren/Zertifikat für Audits

WordPress-spezifische Lösungen

Theme-Fixes

Fehlerhafte Themes können mit dem WP Accessibility Plugin gehotfixt werden.

Warum Accessibility-Overlays keine gute Idee sind

Experten im Bereich Barrierefreiheit

Weiterführende Materialien

Ausblick

Im Anschluss an die Präsentationen gab es wie immer Zeit für Fragen, Gespräche und Networking. Die Teilnehmer tauschten Erfahrungen und nützliche Tipps rund um das Thema WordPress und Barrierefreiheit aus.

Hinweis: Das WordPress Meetup Hamburg ist immer auf der Suche nach neuen Vortragenden und helfenden Händen, die Lust haben, bei der Organisation des Meetups mitzuwirken!

Nachlese zum WordPress Meetup #125 – April 2025 – Unsichtbare Fehler

Torsten begann seinen Vortrag mit einem Verweis auf das Buch „In the Beginning Was the Command Line“ und erläuterte die Evolution von der Command Line über User Interfaces bis zur heutigen Abstraktion. Er stellte die WordPress-Philosophie vor und wies auf RSS-Feeds als wichtiges Tool zum Abonnieren von Blogs hin. Seine zentrale Frage: Was passiert, wenn Technik zu sehr vereinfacht wird?

Die häufigsten unsichtbaren Fehler

1. Standard-Inhalte und Demo-Content

  • Der berüchtigte „Just another WordPress Website“ Untertitel bleibt oft unverändert
  • Der „Hallo Welt“ Standard-Post ist bei vielen Seiten noch live
  • Die Beispielseite wird häufig vergessen und bleibt öffentlich zugänglich
  • Demo-Inhalte von Themes und Plugins (wie /portfolio-demo3, /portfolio-demo4) werden versehentlich als öffentliche Posts statt als Entwürfe veröffentlicht

2. Grundlegende Einstellungen

  • Favicon: Oft wird das Standard-WordPress-Icon nicht geändert
  • Zeitzone: Falsche Zeitzoneneinstellungen können zu Problemen bei geplanten Beiträgen führen
  • Permalinks: Sprechende URLs (mod_rewrite) werden häufig nicht aktiviert, wodurch alles über index.php läuft

3. Anhangseiten-Problematik

Anhangseiten erstellen Einträge in der Post-Tabelle und sind immer als Attachment gekennzeichnet. Probleme:

  • Kommentare sind standardmäßig aktiviert, was zu Spam führen kann
  • Beste Praxis: Kommentare sofort deaktivieren oder Anhangseiten direkt auf das Medium weiterleiten
  • Diese Seiten werden für Google nicht benötigt

4. Plugin-Fallen

  • Akismet: Meist aktiviert, aber ohne API-Key funktionslos (zudem datenschutzrechtlich problematisch)
  • Hello Dolly: Wird von niemandem gebraucht
  • Geschlossene Plugins: Erhalten keine Updates mehr, zeigen aber auch keine Warnung an – das Plugin „Plugin Report“ kann hier helfen

5. Sicherheit und Performance

SSL und Weiterleitungen:

  • HTTP zu HTTPS Redirects fehlen oft
  • Wichtig: 301-Weiterleitungen einrichten und in der Datenbank umfassend ändern, um Loops zu vermeiden

PHP-Version:

  • Veraltete PHP-Versionen sind unsicher und hackbar
  • Kompatibilität mit WordPress-Version prüfen

Datenschutz und Sicherheit:

  • Gravatare sind datenschutzrechtlich schwierig
  • Display_errors sollte deaktiviert sein
  • Directory Index sollte deaktiviert sein
  • FTP-Server sind keine Dropbox: Keine .bak-Dateien oder ähnliches speichern

6. Technische Optimierungen

Autoload-Problematik:

  • In der Options-Tabelle wird alles gespeichert
  • Bei jedem Request werden alle Optionen mit autoload=yes geladen
  • Tool-Tipp: AAA Option Optimizer zum Debuggen
  • Transiente speichern Caches und können die Datenbank aufblähen

Health Check:

  • Der WordPress Website-Zustand ist eine wunderbare Übersichtsseite
  • Nicht alle Warnungen müssen beachtet werden

Veraltete Konstanten:

  • WP_MEMORY_LIMIT oft zu niedrig eingestellt
  • COMPRESS_JS, COMPRESS_CSS sind ressourcenfressend (besser serverseitig)
  • DEBUG_LOG kann versehentlich aktiviert bleiben und riesige Log-Dateien erzeugen

7. SEO und Sitemaps

  • Custom Post Types können ungewollt in XML-Sitemaps landen
  • Seiten ohne Inhalt (Daten über Custom Fields) sollten auf noindex gesetzt werden
  • Robots.txt: Seit WordPress 6.8 gibt es einen Check im Website-Zustand
  • WordPress-Suche nutzt MySQL Fulltext und findet auch HTML-Befehle und Block-Markup
  • Plugin-Tipp: Relevanssi für bessere Suchergebnisse

8. Weitere technische Details

  • Inode-Limits: Begrenzung der Dateianzahl auf Servern (Problem bei Caching-Plugins wie W3 Total Cache)
  • Links: Bei target=“_blank“ wird automatisch rel=“noopener“ gesetzt
  • htaccess: Cross-Site-Scripting-Schutz oft veraltet, Cache-Control-Einstellungen fehlen
  • Themes: Mehr als ein Standard-Theme ist unnötig – alle anderen löschen

Fazit

Torstens Vortrag zeigt eindrucksvoll, wie viele „unsichtbare“ Fehler sich in WordPress-Installationen verstecken können. Die meisten entstehen durch:

  • Vernachlässigung nach der Installation
  • Zu starke Abstraktion der Technik
  • Fehlende Wartung und Updates
  • Unkenntnis über Sicherheitsrisiken

Die wichtigste Erkenntnis: Regelmäßige Überprüfung und bewusste Konfiguration sind essentiell für sichere und performante WordPress-Websites.

Nachlese zum WordPress Meetup #124 – März 2025 – ChatGPT und PHP-/Plugin-Coding

Im März 2025 stellte Mark Max Henckel in seinem Vortrag vor, wie AI-Tools wie Claude und ChatGPT effektiv zur WordPress-Entwicklung genutzt werden können. Dabei zeigte Mark auf, wie diese Tools Entwickler unterstützen können, maßgeschneiderte Funktionen zu erstellen, ohne auf unnötige Plugins zurückzugreifen. Ein zentrales Beispiel war die Erstellung eines Custom Fields, in das ein Wert eingegeben wird. Je nach diesem Wert erhält der Body-Tag der Seite eine bestimmte Klasse, und der Hintergrund wird eingefärbt. Eine einfache, aber effektive Methode, um dynamische Designs umzusetzen.

Die Vorteile von AI in der WordPress-Entwicklung

Dynamische Design-Änderungen mit Custom Fields: Mark zeigte, wie AI dabei helfen kann, benutzerdefinierte Felder zu erstellen, die mit einer einzigen Eingabe dynamische Änderungen auf der Webseite vornehmen, wie zum Beispiel die Veränderung von Farben oder das Hinzufügen von Klassen im Body-Tag.

Vermeidung unnötiger Plugins: Statt für einfache Aufgaben wie die Erstellung eines Custom Post Types (wie „ShortNews“) ein zusätzliches Plugin zu installieren, kann AI hier den benötigten PHP-Code generieren. So bleibt die Website schlank und benötigt keine zusätzlichen Plugins, die die Leistung beeinträchtigen könnten.

Slider im MU-Ordner: Mark stellte außerdem einen Slider vor, der im Must-Use (MU) Ordner von WordPress gespeichert war. Dieser Ansatz wurde jedoch als problematisch angesehen, da MU-Dateien schwer zu debuggen sind. Stattdessen wurde in der Gruppe empfohlen, solche Funktionen lieber über Code Snippets oder ein Plugin zu lösen, das leichter zu warten und zu debuggen ist.

Die Diskussion über den besten Umgang mit AI-generiertem Code

Mark betonte, dass AI-generierter Code nicht in einem Vakuum existiert und es wichtig ist, diesen Code richtig zu verwalten. In der Gruppe wurde über verschiedene Möglichkeiten diskutiert, den generierten Code zu speichern und zu integrieren. Während Mark die Verwendung von Code im Theme-Ordner oder MU-Ordner bevorzugte, stellten andere vor, dass Code Snippets oder die Nutzung von Child Themes ebenfalls praktikable Optionen darstellen könnten.

Der Einsatz von AI zur Dokumentation

Ein besonders spannender Punkt war der Einsatz von AI-Tools zur Dokumentation von Plugins. In der Diskussion wurde vorgeschlagen, dass AI-Tools wie ChatGPT und Claude dabei helfen können, Dokumentationen zu erstellen, indem sie die wichtigsten Funktionen und Variablen aus den Plugin-Dokumentationen extrahieren. So kann AI auf Grundlage dieser Informationen eine übersichtliche, leserfreundliche Dokumentation generieren, die immer wieder genutzt werden kann, ohne dass man sich ständig wiederholen muss. Das spart Zeit und hilft, sich auf das Wesentliche zu konzentrieren.

Einfache WordPress-Funktionen sind kein Geheimnis

Da WordPress Open Source ist, sind einfache Funktionen und grundlegender Code keineswegs ein Geheimnis. Bereits vor der Einführung von AI-Tools gab es zahlreiche Foren und Communities, in denen grundlegende Codes geteilt und diskutiert wurden. AI-Tools bieten lediglich eine Möglichkeit, diese bestehenden Lösungen schneller zu finden und effizienter anzuwenden.

Der Unterschied zwischen privaten und kommerziellen Anwendungen von AI-generiertem Code

Es gibt einen wichtigen Unterschied zwischen dem privaten Gebrauch von AI-generiertem Code und der Nutzung in kommerziellen Webdesign-Dienstleistungen. Wenn ein Webdesigner einen Code erstellt, der auf AI basiert, und diesen an einen Kunden weitergibt, ist es wichtig, sich der rechtlichen Implikationen bewusst zu sein. Kunden sollten darüber informiert werden, dass der Code mit Hilfe von AI generiert wurde und die Qualität sowie Wartbarkeit des Codes entsprechend geprüft werden muss.

Haftung und Berufshaftpflichtversicherung

Wie bei jeder professionellen Tätigkeit ist es auch bei der Nutzung von AI-Tools in der Webentwicklung wichtig, eine Berufshaftpflichtversicherung abzuschließen. Diese Versicherung schützt vor möglichen rechtlichen und finanziellen Konsequenzen, falls Fehler im Code zu Problemen führen oder Kunden unzufrieden sind.

Prüfung und Kommentierung von AI-generiertem Code

Trotz der Unterstützung durch AI ist es wichtig, dass der generierte Code gründlich geprüft wird. Ein Schritt, den Entwickler immer durchführen sollten, ist, die AI nochmals zu fragen, ob der Code sicher ist. Zusätzlich sollte die AI gebeten werden, den Code mit Kommentaren zu versehen, um ihn für andere Entwickler besser verständlich zu machen oder um ihn später leichter an einen Kunden zu übergeben.

Es ist auch ratsam, den AI-generierten Code von einer anderen AI oder einer anderen Quelle auf Sicherheit und mögliche Probleme überprüfen zu lassen. Testumgebungen sind unerlässlich, um sicherzustellen, dass der Code unter realen Bedingungen funktioniert, ohne die Live-Website zu gefährden.

Als zusätzlichen Hinweis sollte man der AI auftragen, den Code zu prüfen, „als wenn mein Arbeitsplatz daran hängen würde“, um sicherzustellen, dass die Prüfung gründlich und mit höchster Sorgfalt durchgeführt wird.

AI hat nicht immer den aktuellsten Stand

AI-Systeme, auch solche wie ChatGPT oder Claude, können manchmal veraltete Informationen liefern. Ein Beispiel aus der Diskussion war die WordPress-Konstante COMPRESS_CSS, die in älteren AI-Antworten als noch nutzbar bezeichnet wurde, obwohl sie in neueren WordPress-Versionen nicht mehr verwendet wird. Dies zeigt, dass AI nicht immer den neuesten Stand eines Themas widerspiegelt, und es ist wichtig, Informationen zusätzlich zu überprüfen. AI kann sich auch mit spezifischen, älteren Fehlerberichten beschäftigen, die inzwischen behoben oder nicht mehr relevant sind, was zu Missverständnissen führen kann.

Ein konkretes Beispiel für einen LLM-Fail wurde in der Diskussion gezeigt: ChatGPT’s fehlerhafte Antwort im Vergleich zum tatsächlichen WordPress Core Trac Ticket #63017.

Fazit: AI als hilfreicher Partner in der WordPress-Entwicklung

AI-Tools wie Claude und ChatGPT bieten eine wertvolle Unterstützung in der WordPress-Entwicklung, indem sie einfache und effektive Lösungen für häufige Aufgaben bieten. Von der Erstellung benutzerdefinierter Felder bis hin zur Optimierung von Code und der Dokumentation von Plugins – AI kann den Entwicklungsprozess erheblich beschleunigen und vereinfachen. Wichtig ist jedoch, dass Entwickler den Code verstehen und darauf achten, wie sie AI sinnvoll in ihren Workflow integrieren.

Weiterführende Ressourcen:

Wir freuen uns bereits auf die nächsten Meetups und die spannenden Diskussionen, die dort geführt werden. Wenn du auch ein Thema präsentieren möchtest, melde dich gerne bei uns!