Kau-Boys

Eine Frage, die ich oft gestellt bekomme, lautet: Welches Plugin verwendest du auf jeder Seite? Meine Antwort ist normalerweise: keines … außer wenn ich die Website gerade entwickle. Dann ist es Query Monitor und hier ist der Grund dafür.

Was macht Query Monitor?

Das Query Monitor Plugin ist DAS Debugging-Plugin für WordPress. Ursprünglich half es nur beim Debuggen von SQL-Abfragen, aber jetzt kann es zum Debuggen von fast allem in WordPress verwendet werden. Ich habe schon einige Beiträge darüber geschrieben, aber schauen wir uns einige der hunderten von Debugging-Funktionen an, die es mirbringt:

• SQL-Abfragen
• HTTP-Anfragen
• Geladene Template-Dateien (Partials) und verwendete Template-Hierarchie-Datei
• Geladene JavaScript-Dateien
• Geladene CSS-Dateien
• Verwendete Hooks (Actions und Filter)
• Geladene Übersetzungsdateien (und Auflistung der fehlenden Dateien)
• Vom Backend durchgeführte HTTP-API-Anfragen
• Aktualisierte Transients
• Überprüfte Berechtigungen (Capabilites)
• Informationen über die Umgebung (PHP, Datenbank, WordPress, Server)
• Liste aller true/false Conditional Tags auf der aktuellen Seite

Query Monitor ist im Frontend und Backend verfügbar. Standardmäßig können ihn nur Administrator-User nutzen, aber ihr können ein Authentifizierungs-Cookie setzen, um ihn auch dann zu nutzen, wenn ihr abgemeldet seid, was sehr hilfreich ist, wenn ihr eine Website ohne Login debuggen wollen.

Warum verwende ich Query Monitor?

Wenn ihr gerade eine Website baut und etwas funktioniert nicht, dann könnt ihr viele Schritte unternehmen, um das Problem zu beheben. Für viele typische Probleme müsst aber nicht einmal den WP_DEBUG Modus aktivieren oder etwas wie Xdebug verwenden. Das Query Monitor Plugin kann euch oft einfach sagen, was schiefgelaufen ist.

Es ist auch sehr hilfreich, um langsame SQL-Abfragen zu finden und dann weiter zu untersuchen, warum sie so langsam sind. Ich verwende es auch häufig, um herauszufinden, warum manche Übersetzungen nicht funktionieren – oft, weil WordPress versucht, eine Datei mit dem falschen Namen zu laden.

Ich weiß nicht, wie viele Stunden oder sogar Tage an Debugging-Zeit ich gespart habe, nur weil ich Query Monitor immer benutze. Irgendwann habe ich sogar einen Alias zu meinem Linux-System hinzugefügt, um Query Monitor über die WP-CLI zu installieren, nur weil ich das so oft gemacht habe. 😅

Fazit

Wenn ihr eine Website entwickelt und diese debuggen müsst, dann sollten ihr euch Query Monitor einmal ansehen, falls ihr es nicht ohnehin schon in eurem Werkzeugkasten habt.

Ihr könnt Query Monitor auch mit eurem eigenen Panel erweitern, was ich in dem Blogpost „Ein eigenes Panel zum Query Monitor hinzufügen“ Anfang des Jahres beschrieben habe.

Benutzen ihr Query Monitor? Falls ja, welche Funktionen nutzt ihr am häufigsten?

Ich habe eine Podcast-Website (aber leider gibt es seit Jahren keine neuen Episoden mehr). Als ich mit dem Podcasting anfing, habe ich mich gefragt, wie man eine Website dafür am besten einrichtet. Wenn man es wirklich einfach halten will, braucht man kein Plugin für einen Podcast. Da WordPress Audiodateien einbetten kann, könntet ihr die Podcast-Episoden einfach in eure Mediathek hochladen und sie in einen normalen Blogbeitrag einbetten. Wenn ihr es aber ermöglichen wollt, euren Podcast zu abonnieren, Transkripte oder Untertitel hinzuzufügen wollt, einen schönen Webplayer mit mehr Optionen und andere typische Podcast-Funktionen zu haben möchtet, dann solltet ihr ein geeignetes Plugin verwenden.

Was macht der Podlove Podcast Publisher?

Es gibt mehrere Plugins unter der Marke Podlove. Das wichtigste davon ist das Podlove Podcast Publisher Plugin. Es gibt auch den Podlove Web Player, aber der ist optional, wenn ihr das Publisher-Plugin verwendet. Der Publisher fügt einen neuen Beitragstyp „Episoden“ hinzu, in dem die gesamte inhaltliche Arbeit erledigt wird. Für jede neue Episode eures Podcasts würdet ihr hier einen neuen Eintrag erstellen. Ihr solltet die Einstellungen des Publishers konfigurieren, bevor ihr eure erste Episode hinzufügt. Dies wird in einem kurzen Video auf der Podlove-Dokumentationsseite beschrieben.

Eine der coolen Funktionen von Podlove ist die Tatsache, dass ihr die Dateien nicht auf demselben Server wie eure WordPress-Website speichern müsst. Ihr könnt sie auf einem externen Server oder sogar auf einem S3-Speicher haben, solange ihr die Dateinamen kontrollieren könnt. Ihr legen den Basispfad für die Episoden fest, und solange Podlove Dateinamen wie episodenname.mp3, episodenname.m4a, episodenname.chapters.txt, episodenname.vtt und so weiter findet, funktionieren diese externen Dateien genauso gut wie Dateien auf demselben Server. Das heißt, ihr könnt sogar einen dieser (Premium-)Podcasting-Dienste nutzen und den Podcast trotzdem (auch) auf eurer persönlichen Website hosten.

Neben den Episoden und den Beschreibungen kann der Podlove Podcast Publisher auch andere Dinge verwalten, die ein Podcast benötigt:

• RSS-Feeds (zum Abonnieren eures Podcasts)
• Mitwirkende (Hosts und Gäste, einschließlich Beschreibungen und Links zu Profilen in sozialen Medien)
• Spendenlinks (für Hosts und Gäste)
• Ein umfangreicher Webplayer mit Steuerelementen für Geschwindigkeit, Transkripte und Untertitel, Download-Schaltflächen usw.
• Integration in externe Dienste
• Eine Schaltfläche/Widget zum Abonnieren
• und vieles mehr …

Eine Integration betrifft das Auphonic-Projekt. Ich verwende dieses Projekt, um die Audioqualität der Audio- und Videoproduktionen zu verbessern, und Podlove kann alle eure Dateien an Auphonic senden, die Dateien optimieren lassen und die optimierten Dateien wieder auf eurem Server speichern. Aber ich habe die Integration noch nicht genutzt.

Warum verwende ich Podlove Podcast Publisher?

Zum Erstellen eines Podcasts gehört mehr, als nur in ein Mikrofon zu sprechen, vor allem, wenn man für die Nachbearbeitung und Veröffentlichung verantwortlich ist. Da ich diese Rolle für den Podcast, den ich mitmoderiere, übernommen habe, wollte ich ein Plugin haben, das mich so gut wie möglich unterstützt. Mit all den Funktionen, die Podlove bietet, war der Prozess nach der ersten Einrichtung wirklich einfach, und das Veröffentlichen einer neuen Episode war so einfach wie das Veröffentlichen eines Blogbeitrags. Die Verwendung der Vorlagenfunktion von Podlove machte es sogar noch einfacher.

Fazit

Wenn ich heute einen neuen Podcast starten würde, wäre das Podlove-Plugin das erste, das ich installieren würde. Ich habe kein anderes Plugin gesehen, das auch nur annähernd mithalten kann. Und da ich die Idee mag, meine Dateien „zu besitzen“, liebe ich die Möglichkeit, sie auf demselben Rechner zu haben und sie trotzdem jederzeit und ohne Komplikationen auf einen externen Speicherplatz verschieben zu können.

Haben ihr auch einen Podcast? Warum teilt ihr ihn dann nicht hier, um mehr Menschen zu erreichen? Und wenn ihr WordPress für euren Podcast verwenden, wie verwalten ihr ihn?

Wie im letzten Blogbeitrag erwähnt, verwende ich auf diesem Blog etwa 18 Plugins. Für manche klingt das nach viel, aber das ist es nicht wirklich. Ich sage immer, es geht nicht um die Anzahl der Plugins, sondern um deren Qualität und Komplexität. Es kann schwierig sein, den Überblick über all die Plugins zu behalten, die man hat. Werden sie noch aktiv gepflegt? Wurden sie mit Ihrer aktuellen WordPress-Version getestet? Werden sie automatisch aktualisiert? All diese Fragen können mit dem Plugin Report Plugin beantwortet werden.

Was macht Plugin Report?

Wenn ihr das Plugin auf einer Single-Site installiert habt, wird eine „Plugin Report“ Seite im Abschnitt „Plugins“ des Dashboards hinzugefügt (bei einer Multisite-Installation finden ihr die Seite in der Netzwerk-Verwaltung). Wenn ihr zu dieser Seite navigiert, wird eine Tabelle mit allen installierten Plugins angezeigt, und es werden sofort die folgenden Informationen für jedes Plugin abgerufen:

• Name
• Autor
• Repository
• Aktiviert
• Installierte Version
• Automatische Aktualisierung
• Zuletzt aktualisiert
• Getestet bis WP-Version
• Bewertung

Die Spalte „Repository“ ist vermutlich die interessanteste. Wenn hier „wordpress.org“ in grün anzeigt wird, ist das ein gutes Zeichen. Wenn sie rot ist, mit dem Hinweis „wordpress.org, Plugin nicht gefunden“, kann das auch noch OK sein kann, wenn es sich um ein selbst geschriebenes Plugin handelt. Sollte hier aber die Meldung „wordpress.org, Plugin geschlossen“ stehen, dann solltet ihr das Plugin überprüfen. Es könnte aus Sicherheitsgründen geschlossen worden sein. Wenn „Zuletzt aktualisiert“ für ein solches Plugin auch schon recht lange her ist, dann kann dies ein potenzielles Sicherheitsrisiko für eure Website darstellen.

Alle Daten werden im Cache gespeichert, es wird also nicht jedes Mal der Status jedes Plugins neu abfragt, wenn ihr die Seite aufruft. Ihr könnt den Cache aber auch gezielt leeren, um frische Daten zu erhalten.

Warum verwende ich Plugin Report?

Bei fast 20 Plugins können ihr nicht wirklich alle manuell überprüfen, und ihr werdet euch auch nicht daran erinnern, wann ihr das letzte Update für eines der Plugins gesehen habt. Es gibt auch immer noch ein Problem mit Plugins, die auf wordpress.org geschlossen wurden, aus welchem Grund auch immer: ihr erhaltet keine Informationen darüber in euere WordPress Installation. Ein Plugin könnte schon vor Jahren entfernt oder wegen eines Sicherheitsproblems geschlossen worden sein. Ihr könnt dann keine Updates mehr für diese Plugins erhalten, aber da diese Updates auch nicht angezeigt werden, merkt ihr wahrscheinlich nicht einmal, dass ihr ein unsicheres Plugin in eurer WordPress-Installation habt. Alleine für diesen einen Anwendungsfall kann der Plugin Report schon helfen, um nur die Plugins zu verwenden, die noch gewartet werden oder zumindest irgendwann ein Update erhalten könnten.

Fazit

Der Plugin Report kann euch nicht wirklich sagen, welche Plugins Probleme verursachen könnten, aber er gibt euch einen Überblick über den aktuellen Status der einzelnen Plugins. Ihr oder die Person, die für die Wartung Ihrer Website verantwortlich ist, kann dann auf der Grundlage dieser Informationen handeln. Ich verwende das Plugin für viele der WordPress-Installationen, die ich betreue, und es hilft mir, schnell zu sehen, welche Plugins ich auf wordpress.org auf aktuelle Informationen überprüfen sollte.

Das Plugin wurde ursprünglich von Roy Tanck entwickelt und wird nun vom deutschen Community-Mitglied Torsten Landsiedel gepflegt, der auch Mitglied des Pluginkollektivs ist.

Benutzen ihr auch dieses Plugin? Oder habt ihr ein ähnliches Tool, dass euch solche Informationen liefert? Dann teile eure Tools und Arbeitsabläufe gerne in einem Kommentar mit uns.

Das Plugin, über das ich heute schreibe, ist eines der wichtigsten auf meinem Blog. Ich könnte ohne viele der etwa 18 Plugins leben, die ich auf diesem Blog verwende. Aber da dieser Blog in zwei Sprachen präsentiert wird, brauche ich ein Plugin, um die beiden Blogs bestmöglich miteinander zu verbinden. Und für mich persönlich ist der beste Weg die Verwendung einer Multisite.

Was macht MultilingualPress?

Es nutzt die Multisite-Funktion von WordPress, um Websites (auch mehrere) in mehr als einer Sprache zu ermöglichen. In meinem Fall ist die Hauptseite meiner Multisite die englische Seite, die zweite Seite ist die deutsche Seite. Mit MultilingualPress kann ich dann alle Inhalte (Beiträge, Seiten, Taxonomien, eigene Beitragstypen, eigene Taxonomien) miteinander verbinden. Wenn ihr eine größere Multisite habt, könnt ihr sogar mehr als zwei Sites miteinander verbinden oder „mehrere Sets“ von Websites mit verschiedenen Sprachen erstellen. Es ist wirklich sehr flexibel.

Wenn ich neue Blogbeiträge schreibe, dann schreibe ich sie in der Regel zuerst auf Englisch, obwohl meine Muttersprache Deutsch ist. Das hilft mir etwas dabei, meine englischen Schreibfähigkeiten zu trainieren. Nachdem ich einen Blogbeitrag fertiggestellt habe, lasse ich MultilingualPress einen damit verbundenen deutschen Blogbeitrag als Entwurf erstellen. Seit Version 5.0 bietet MultilingualPress jetzt automatische Übersetzungen an. Ihr könnt entweder DeepL, Amazon Translate oder die OpenAI API verwenden. Die letzten beiden bieten nur Bezahl-Versionen an, weshalb ich DeepL verwende. Es gibt eine kostenlose Version mit 500.000 Zeichen pro Monat, das reicht völlig aus. Im Dezember wurden in meinen ersten 11 Adventskalender-Blogbeiträgen nur 34.536 Zeichen verbraucht, ich bin also weit davon entfernt, das kostenlose Limit zu erreichen. Das einzige, was in der kostenlosen Version von DeepL nicht verfügbar ist, ist „informelles Deutsch“, was ich für meine deutschen Blogbeiträge verwende. Aber da ich den „Klang“ meiner deutschen Blogeinträge so anpasse, dass es so klingt, als hätte ich den Text erst auf Deutsch geschrieben, ändere ich sowieso viel Text. Das spart mir immer noch eine Menge Zeit. Ich verwende den Block-Editor für meine Beiträge, und MultilingualPress erledigt die Übersetzung der Blöcke perfekt. Das Einzige, was nicht funktioniert, sind Codeblöcke, die nicht korrekt von DeepL zurückkommen.

Ihr könnt sogar Kommentare von MultilingualPress übersetzen lassen. Ich habe diese Funktion noch nicht getestet – und muss vorher noch einige Kommentare bereinigen oder in die richtige Sprache verschieben – aber ich werde auch diese Funktion mal ausprobieren. Vielleicht werde ich auch über den Prozess bloggen, aber das muss bis nächstes Jahr warten.

Warum verwende ich MultilingualPress?

In den frühen (zweisprachigen) Tagen meines Blogs habe ich qTranslate verwendet. Aber als MultilingualPress vor mehr als 13 Jahren aufkam, bin ich umgestiegen. Ich sehe eine Menge Vorteile in der Verwendung einer Multisite für mehrsprachige Seiten. Zu viele, um sie in diesem Blogbeitrag zu nennen. Aber wenn ihr schon einmal versucht habt, eine größere mehrsprachige Website mit Single-Site-Lösungen wie WPML oder Polylang zu erstellen, kennt ihr wahrscheinlich die vielen Probleme, auf die man dabei stößt.

In meinem Blogbeitrag vor zwei Tagen über das Individual Multisite Author Plugin habe ich erwähnt, dass ich dieses Plugin eigentlich nicht mehr brauche. Das liegt daran, dass MultilingualPress auch ein Modul zur Übersetzung von Profil-Informationen anbietet. Aber auch dieses Modul habe ich noch nicht getestet.

Fazit

Wenn ihr eine mehrsprachige Website wollt, bei der ihr wirklich alles übersetzen könnt, also sogar die Plugin- und Theme-Einstellungen, dann ist die Verwendung einer Multisite wahrscheinlich die beste Lösung. MultilingualPress bietet keine kostenlose Version an, aber sie ist jeden Cent wert. OK, ich muss zugeben, dass ich nicht dafür bezahle, da ich jetzt für die Agentur arbeite, die es entwickelt. Aber ich habe es mehr als 10 Jahre lang benutzt, bevor ich zu dieser Agentur kam.

Gestern hatte ich erwähnt, dass ich auf diesem Blog zwei verschiedene Statistik-Plugins verwende. Das „einfache“ ist Koko Analytics, das erweiterte ist Matomo.

Die Verwendung von Matomo mit einer WordPress-Website gibt es in zwei Varianten. Ihr könnt das Matomo-Plugin verwenden, was die einfachere Version ist. Dabei wird eine vollständige Matomo Anwendung in den Ordner wp-content/plugins/matomo/app installiert. Die Aktualisierung des Plugins aktualisiert auch die Matomo-Installation, was sehr praktisch ist. Aber es fügt auch mehr als 50 Tabellen (einschließlich 30+ „Archivtabellen“) in eure WordPress-Datenbank ein. Das kann ziemlich chaotisch sein und wird nur für sehr kleine Seiten empfohlen, sogar von Matomo selbst. Wenn ihr eure WordPress-Datenbank von Matomo trennen möchten oder eine Multisite betreiben, wie ich es tue, würde ich einen anderen Weg empfehlen.

Was macht Connect Matomo?

Im Gegensatz zum Matomo-Plugin kann man das leichtere Connect Matomo Plugin, früher bekannt als WP-Matomo oder WP-Piwik (Piwik war der alte Name für Matomo), verwenden. Es wird eingesetzt um eine WordPress-Installation mit einer „Matomo On-Premise“ Installation zu verbinden. Das bedeutet, dass ihr Matomo als separate App auf eurem Webserver installieren müsst. Oder ihr nutzen einen externen Dienst, der euch eine Matomo-Installation anbietet. Ihr könnt Matomo auch mit der Matomo Cloud verbinden, aber mit derzeit 22 Euro pro Monat ist das eine ziemlich kostspielige Option. Ich meine, das Schöne an Matomo ist ja, dass man es auf seinem eigenen Hosting laufen lassen kann, nicht wahr?

Ich möchte nicht zu sehr ins Detail gehen, wie man eine Matomo-Installation einrichtet und wie man sie mit WordPress verbindet. Das könnte man in einer ganzen Blogserie behandeln, da es ziemlich komplex werden kann. In meinem Fall habe ich es auf demselben Server wie meine WordPress-Multisite installiert<. Ich verwende dann die Option „Selbst-gehostet (HTTP-API, Standard)“ für den „Matomo-Modus“, verweise auf die „Matomo-URL“, gebe meinen „Auth Token“ an und es werden automatisch alle Seiten meiner Multisite zu Matomo hinzugefügt. In der Registerkarte „Tracking aktivieren“ kann ich zwischen verschiedenen Möglichkeiten wählen, den Tracking-Code einzubetten und wo er platziert werden soll. Sobald diese beiden Schritte abgeschlossen sind, beginnt das Tracking.

Innerhalb von WordPress erhält man einen kleinen Dashboard-Bereich, der die Besuche der letzten 30 Tage, eine Übersicht über die Besuche und die besuchten Seiten von gestern sowie Metriken wie Browser, Bildschirmauflösungen, Gerätetypen, Betriebssysteme, Städte, Länder, Suchbegriffe, Verweise und vieles mehr anzeigt. Um die vollständigen Statistiken einzusehen, müsst ihr euch bei eurer Matomo-Instanz anmelden. Auch wenn ihr das Matomo-Plugin verwendet, würde es die „Matomo-App“ öffnen und nicht alles in WordPress einbetten.

Warum verwende ich Connect Matomo?

Da ich erweiterte Statistiken haben möchte und Google Analytics nicht mehr in Frage kam, war Matomo die offensichtliche Alternative. Weil ich aber die Matomo-Tabellen nicht in meine Blog-Datenbank stopfen wollte und ich Matomo auch für andere WordPress-Seiten verwende, habe ich mich für das Connect Matomo Plugin entschieden, um es in meinen Blog zu integrieren.

Für meine jährlichen „Blog-Geburtstag“ Posts hole ich mir aus Matomo die Informationen zu den beliebtesten Blogbeiträgen und um den Tag mit den meisten Besuchen zu finden. Es hilft mir auch zu verstehen, woher die Zugriffe kommen (welche Verweise und welches Land bzw. welche Stadt) und welche Geräte verwendet werden. Dies hilft mir, die Seite zu optimieren und die richtigen Inhalte für mein Publikum zu finden.

Fazit

Wenn ihr mehr als nur ein einfaches Statistik-Plugin benötigt und auf den Datenschutz achten wollen, dann ist Matomo eine gute Wahl. Ihr müsst nur entscheiden, wie ihr es mit eurer WordPress-Installation verwenden möchtet. Während die separate Matomo-Instanz die Dinge sauberer getrennt hält, ist sie mit einem gewissen Wartungsaufwand verbunden. Aber Matomo hat einen großartigen Update-Prozess, fast so einfach wie bei WordPress, und er ist bei mir noch nie fehlgeschlagen.

Benutzt du auch Matomo? Wenn ja, welches Plugin verwendest du? Und betreibst du deine eigene Instanz, oder hast du jemanden, der es für dich hostet, oder nutzt du sogar die Matomo Cloud?

Als ich alle Plugins und Dienste entfernt habe, die Cookies verwenden, habe ich auch die Verbindung zu Google Analytics gekappt. Aber ich wollte immer noch ein Plugin haben, das mir einige Statistiken und Einblicke in meine Websites und die am häufigsten gelesenen Inhalte gibt. Ich habe daher eine Zeit lang drei potenzielle Ersatzlösungen gleichzeitig genutzt, parallel zu Google Analytics als Referenz. Die beiden „einfacheren Plugins“ werden heute behandelt.

Was macht Koko Analytics?

Das Koko Analytics Plugin bietet nicht viele Statistiken, aber die wichtigsten sind in der kostenlosen Version enthalten (es gibt auch eine Premium-Version, die ich aber nie getestet habe und auch nicht wirklich brauche). Es erfasst die Seitenaufrufe und zeigt auch, woher diese Aufrufe kommen. Es listet keine Dinge wie Länder, Gerätetypen, Bildschirmauflösungen, Suchbegriffe oder andere Metriken auf. Aber es bietet ein schönes Dashboard-Widget, das die Top-Seiten und Referrer des Tages anzeigt. Ihr könnt Benutzerrollen und statische IP-Adressen von der Erfassung ausschließen.

Die Erfassung kann auf „cookie“ eingestellt werden, wodurch wiederholte Seitenaufrufe erkannt werden können. Dies erfordert aber eine Cookie-Richtlinie und/oder eine Zustimmung. Es gibt auch eine (neue) „cookieless“ Option, die versucht, wiederholte Besuche ohne ein Cookie zu erkennen. Ich verwende die alte Einstellung „none“, die sich nicht wirklich um einmalige oder wiederholte Seitenaufrufe kümmert.

Alle Daten können nach einem bestimmten Zeitraum gelöscht werden, es sei denn, man setzt diesen Zeitraum auf null, um die Daten nie zu löschen (was ich normalerweise tun würde). Alles in allem ist es ein nettes kleines Statistik-Plugin, wenn ihr euch nur dafür interessieren, wie viele Seiten/Beiträge pro Tag aufgerufen wurden.

Was macht Statify?

Dies ist ein weiteres Plugin des Pluginkollektivs, an dem ich aber nicht regelmäßig mitarbeite. Wie unterscheidet sich das Statify-Plugin von Koko Analytics? Es ist noch einfacher, da es nur ein Dashboard-Widget mit den letzten Seitenaufrufen und Verweise bietet. Ihr könnt den Zeitraum der Tage festlegen, die im Widget angezeigt werden sollen, und ihr könnt auch hier einen Löschzeitraum festlegen (oder ihn auf null setzen, um alte Statistiken nicht zu löschen). Genau wie Koko Analytics ist es sehr datenschutzfreundlich, da es keine Cookies setzt. Im Gegensatz zu Koko Analytics bietet es nicht einmal eine Option, die das Setzen von Cookies vorsieht.

Mehr Statistiken mit dem Add-on „Statify – Extended Evaluation“.

Es gibt einige Add-ons zu Statify, von denen ich selbst eines verwende: Statify – Extended Evaluation. Dieses Plugin wird bald in Statify integriert und erweitert die Statistiken um Übersichten der Seitenaufrufe pro Monat und Jahr. Es gibt euch auch einen Überblick über die beliebtesten Seiten, Beiträge und andere öffentliche Beitragstypen (wie Episoden auf meiner Podcast-Website). Ihr könnt die Statistiken auch in eine CSV-Datei exportieren.

Warum verwende ich diese Plugins?

Ich verwende Koko Analytics und Statify (in Kombination mit Statify – Erweiterte Auswertung) auf verschiedenen Seiten, abhängig von meinen Bedürfnissen. Auf diesem Blog verwende ich Koko Analytics, da Statify zu viele „falsch positive“ Aufrufe (potenziell von einigen Bots, die meinen Blog mögen) aufgezeichnet hatte und zu sehr von dem abwich, was Google Analytics mir an Zahlen anzeigte.

Fazit

Wenn ihr ein datenschutzfreundliches (und ohne Cookies) Plugin benötigen, kann ich euch eines der beiden empfehlen. Allerdings bekommt ihr nur begrenzte Statistiken, hauptsächlich Seitenaufrufe und Verweise. Ich verwende auch ein anderes Statistik-Plugin, das euch viel mehr bietet, aber dazu morgen mehr.

Benutzen ihr eines der beiden Plugins? Oder vielleicht eines der anderen kostenlosen (oder premium) Statistik-Plugins da draußen? Dann teilt sie gerne in einem Kommentar mit uns.

Am Ende jedes Blogbeitrags finden ihr ein Feld „Veröffentlicht von“ mit einer kurzen Vorstellung des Autors des jeweiligen Blogbeitrags. Dieser Text stammt aus meinem WordPress-Benutzerprofil auf diesem Blog, und das kann bei mehrsprachigen Blogs ein Problem darstellen.

Was macht das Plugin?

Weil ich für diesen Blog eine Multisite verwende, gibt es nur ein „Benutzerobjekt“ für mich als Autor von Blogbeiträgen. Daher gibt es auch nur ein Textfeld „Biografische Angaben“, das für das Feld „Veröffentlicht von“ unter jedem Blogbeitrag verwendet werden kann. Wenn ihr in zwei verschiedenen Sprachen auf zwei verschiedenen Websites in einer Multisite schreibt (oder wenn ihr eine andere „Persona“ auf verschiedenen Website habt), dann steht euch nur einen Text für alle zur Verfügung.

An dieser Stelle habe ich „Individual Multisite Author“ als perfektes kleines Hilfs-Plugin für mich entdeckt. Das Plugin bietet ein Bio-Textfeld auf jeder Unterseite in Ihrer Multisite-Installation an. Es überschreibt automatisch das Standardfeld und gibt auch den richtigen Inhalt auf den verschiedenen Unterseiten zurück, wenn die „WordPress API-Funktionen“ verwendet werden, um diese Informationen zu erhalten.

Das Plugin wurde ebenfalls von einem Mitglied der deutschen WordPress-Community entwickelt: Thomas Maier. Es ist immer wieder lustig, wenn man ein Problem hat, dann eine Lösung findet und sogar denjenigen kennt, der sie geschrieben hat. 😊

Warum ich dieses Plugin verwende?

In den Anfängen meines Blogs habe ich keine Multisite verwendet. Auch nach dem Wechsel hatte ich kein Feld „Veröffentlicht von“ unter den Blogbeiträgen. Als ich dann endlich mal einen Text hatte, bin ich auf genau dieses Problem gestoßen und war froh, ein kleines Plugin zu haben, welches genau dafür entwickelt wurde, eine übersetzte Bio für die zweite Sprache zu bekommen.

Fazit

Wenn ihr eine Multisite betreibt und auf den verschiedenen Unterseiten eine andere biografische Information benötigen, entweder weil sie in einer anderen Sprache sind oder weil ihr sie für andere Zwecke verwenden, könnte dieses Plugin genau das Richtige für euch sein.

Vor ein paar Monaten habe ich herausgefunden, dass ich das Plugin eigentlich gar nicht mehr brauche. Das Plugin, das ich für die Mehrsprachigkeit einsetze, bietet eine ähnliche Funktionalität. Weil das Plugin aber immer noch seinen Zweck erfüllt, bin ich noch nicht auf die andere Lösung umgestiegen.

Wie ich gestern schon erwähnt habe, möchte ich ein weiteres Plugin von Matthias Kittsteiner und der Marke Epiphyt vorstellen. Heute stelle ich euch sein Plugin Impressum Plus vor. Der Begriff „Impressum“ wird meist auf deutschen Webseiten verwendet und ist lateinischen Ursprungs. Auch wenn man ein „Impressum“ eher nur auf deutschsprachigen Seiten findet, gibt es in vielen anderen Ländern ähnliche Seiten, typischerweise mit Namen wie „Legal Notice“, aber mit sehr ähnlichem Inhalt. Nichtsdestotrotz gibt es bestimmte Dinge, die eine solche Seite auflisten muss, und hier kommt Impressum Plus ins Spiel.

Was macht Impressum Plus?

Es gibt eine kostenlose Version, die einfach „Impressum“ heißt. Es erstellt dynamisch allen erforderlichen Inhalten für eine solche Seite. Das Plugin ist aber ist nicht nur auf deutschsprachige Länder beschränkt, sondern kann auch für diejenigen verwendet werden, die eine „Legal Notice“ Seite haben wollen. Es bietet euch einige Textfelder und Fieldsets für euren Namen, Adresse, E-Mail-Adresse, Telefonnummer, Rechtsform und vieles mehr an. Ihr könnt dann entweder einen Block oder einen Shortcode verwenden, um ihn auf einer Seite zu platzieren und die endgültige Seite dynamisch generieren zu lassen. Ihr könnt auch auswählen, ob ihr Überschriften einfügen oder nur den Inhalt ohne Überschriften dazwischen haben wollt.

In der „Plus“-Version bietet es auch die dynamische Generierung der Seiten mit der Datenschutzerklärung und den Informationen zur Barrierefreiheit an. Die Erstellung aktueller Datenschutzseiten kann eine zeitraubende Aufgabe sein, die regelmäßig erledigt werden muss. Wenn ihr das nicht manuell machen wollt, dann könnte euch die Plus-Version hier helfen.

Warum ich Impressum Plus verwende?

Ich muss zugeben, dass ich es auf meiner deutschen Seite noch nicht verwende. Aber ich benutze es auf der englischen Seite dieses Blogs. Normalerweise benutze ich einen dieser „Datenschutzgeneratoren“ und bearbeite die Texte dann manuell, um sie an die Dienste anzupassen, die ich auf diesem Blog benutze. Als Impressum Plus zum ersten Mal veröffentlicht wurde, habe ich direkt eine Lizenz gekauft, um diese manuelle Seite zu ersetzen. Das war vor fast 6 Jahren. 😅

Ich habe es sogar ein wenig angepasst, da das Plugin einige Filter bietet, um den dynamisch generierten Text zu ändern. Ich verwende eine kombinierte Seite für das Impressum und die Datenschutzerklärug und musste die Überschriftenebenen ändern, was ich mit diesem „Hack“ getan habe:

function ipc_privacy_policy_content( $policy ) {
	$headline_level_increase = 1;

	return preg_replace_callback(
		'#<(/?)h(\d)>#',
		function ( $match ) use ( $headline_level_increase ) {
			$new_headline_level = intval( $match[2] + $headline_level_increase );

			return "<{$match[1]}h{$new_headline_level}>";
		},
		$policy
	);
}
add_filter( 'impressum_privacy_policy_content', 'ipc_privacy_policy_content' );

In neueren Versionen gibt es noch einige weitere (und bessere) Filter, die ihr in der „Entwickler-Dokumentation“ finden könnt.

Fazit

Wenn ihr ein Impressum benötigen, was ihr höchstwahrscheinlich braucht, es sei denn, eure Website ist passwortgeschützt und nur für eure Familie bestimmt, dann spart ihr euch bei der Erstellung und Aktualisierung des Impressums Zeit und schützt euch vor rechtlichen Risiken, da sich die Anforderungen von Zeit zu Zeit ändern. Dies gilt umso mehr für die Seiten mit der Datenschutzerklärung. Impressum Plus ist das einzige Premium-Plugin, für das ich ein Abonnement habe, aber es lässt mich weniger Stress mit diesen Seiten haben. Jetzt muss ich es nur noch endlich auch auf meiner deutschen Seite verwenden. 😁

Vor zwei Tagen habe ich über Complianz geschrieben, das Plugin, das ich zur Umsetzung eines Cookie-Banners verwendet habe. In dem Blogbeitrag habe ich erwähnt, dass ich alle Cookies von diesem Blog entfernt habe und stattdessen eine Zwei-Klick-Lösung für alle Einbettung verwende. An dieser Stelle kommt das Plugin Embed Privacy ins Spiel.

Was macht Embed Privacy?

Wenn ihr eine externe Ressource in WordPress einbetten möchtet, fügt ihr oft einfach die URL dieser Ressource, z. B. eines YouTube-Videos, in den Editor ein, und WordPress bettet sie automatisch über das oEmbed Format ein. Das ist sehr praktisch, bedeutet aber auch, dass die externe Ressource geladen wird, sobald jemand diese Seite besucht, und dass damit personenbezogene Daten an diesen externen Dienst übermittelt werden können. Um die DSGVO und ähnliche Vorschriften einzuhalten, ist das oft nicht ohne weiteres erlaubt. Ihr benötigt in der Regel eine Zustimmung, um die eingebettete Ressource anzuzeigen und (möglicherweise) Daten an diesen externen Dienst zu senden. Ihr könnt diese Zustimmung über eine Kategorie eures Cookie-Banners einholen, oder aber ihr lasst euch die Einbettung über einen zusätzlichen genehmigen. Genau das ermöglicht euch Embed Privacy. Es ersetzt automatisch viele Einbettungen auf eurer Website durch eine „Zwei-Klick-Lösung“. Das heißt, wenn jemand zum ersten Mal eine externe Einbettung sieht, wird nach einer Zustimmung zur Anzeige der Ressource gefragt. Hier ist ein Beispiel für eine YouTube-Einbettung aus einem kürzlich veröffentlichten Blogbeitrag:

Um das Video anzuzeigen, könnt ihr entweder auf das „Overlay“ klicken, oder ihr wählt aus, dass YouTube-Einbettungen immer auf der Seite angezeigt werden. Es gibt auch Links zur Datenschutzerklärung des einbettenden Dienstes und einen Link zum Öffnen der externen Ressource. Embed Privacy bietet auch die Möglichkeit, das „Platzhalter“-Bild vom externen Dienst herunterzuladen, wenn es verfügbar ist. Diese Platzhalter-Bilder werden im Ordner wp-content/uploads/embed-privacy/thumbnails/ auf eurem Server gespeichert/gecacht. Diese Bilder werden also nur durch euren Server heruntergeladen, nicht durch den Browser, was diese Option datenschutzfreundlich macht.

Warum verwende ich Embed Privacy?

Wie bereits erwähnt, mag ich keine Cookie-Banner auf Websites, wenn es andere Alternativen gibt. Und meiner Meinung nach ist Embed Privacy das perfekte Plugin, um Zwei-Klick-Lösungen für viele Einbettungen zu implementieren. Wenn ihr einen Dienst einbetten müsst, den das Plugin noch nicht beherrscht, könnt ihr eigenen Dienste hinzufügen. Ich werde wahrscheinlich im Januar einen Blogbeitrag darüber schreiben, wie man das macht.

Ein weiterer Grund, warum ich dieses Plugin mag, ist die Tatsache, dass es von dem deutschen Entwickler Matthias Kittsteiner unter der Marke Epiphyt entwickelt und gepflegt wird. Vielleicht schreibe ich noch über ein anderes seiner Plugins, vielleicht auch nicht. Vielleicht schon morgen. 😉

Fazit

Wenn es euch wie mir geht und ihr eine Zwei-Klick-Lösung für Einbettungen nutzen möchtet, dann probiert Embed Privacy doch einfach mal aus. Nutzen ihr es vielleicht schon oder habt ihr eine ähnliche Lösung gefunden, dann teilen gerne eure Erfahrungen in einem Kommentar mit uns.

Es ist immer noch überraschend, dass Contact Form 7 so viele Installationen hat, aber es ist das drittmeist installierte Plugin im WordPress-Plugin-Directory ist. Es ist ziemlich „technisch“, da man seine Formulare mit Shortcodes erstellen muss. Das Einbinden in eine Seite funktioniert heute auch über einen Block.

Was machen die Plugins?

Das Contact Form 7 Plugin ist ein Formular-Plugin, d.h. es wird verwendet, um ein Formular auf einer Website bereitzustellen, das eine E-Mail versendet. Normalerweise sendet es eine E-Mail an Verantwortliche der Website, aber es kann auch eine zweite E-Mail senden, die normalerweise verwendet wird, um eine Kopie an die Person zu senden, die das Formular ausgefüllt hat. E-Mails werden mit der Funktion wp_mail() verschickt, daher ist ein korrekt konfigurierter Webserver erforderlich.

Um Formular-Spam zu verhindern, könnt ihr Contact Form 7 mit Akismet, Turnstile von Cloudflare und reCAPTCHA verbinden. Wenn ihr eine datenschutzfreundlichere Alternative wünscht, die keinen externen Dienst nutzt, könnt ihr „Honeypot-Felder“ zu eurem Formular hinzufügen. Das Plugin, das ich hier verwende, heißt jetzt CF7 Apps (vorher hieß es Contact Form 7 Honeypot). Es bietet mehr als nur Honeypot-Felder, aber das ist es, wofür ich es hauptsächlich verwende. Ihr könnt auch mehrere Honeypot-Felder hinzufügen, und in vielen Fällen reicht das aus, um den meisten Formular-Spam zu verhindern.

Eine andere Sache, die Contact Form 7 nicht standardmäßig macht, ist die Speicherung der gesendeten E-Mails. Ihr könnt entweder eines der allgemeinen „Mail-Logging-Plugins“ verwenden, das alle von WordPress gesendeten E-Mails protokolliert, oder ihr könnt das Flamingo-Plugin installieren, das vom Entwickler von Contact Form 7 erstellt wurde. Es ist ein sehr minimalistisches Plugin, das euch ein „Adressbuch“ und eine Liste der E-Mails anzeigt, die mit den Formularen von Contact Form 7 verschickt wurden.

Warum verwende ich diese Plugins?

Ich verwende Contact Form 7 in Kombination mit CF7 Apps auf zwei Websites, die ich betreue. Auf einer von ihnen verwende ich auch Flamingo. Da diese beiden Seiten nur einfache Formulare benötigen und ich weiß, wie man mit Contact Form 7 brauchbare und barrierefreie Formulare erstellt, erscheint mir die Installation eines „ausgereifteren“ Formular-Plugins als übertrieben.

Fazit

Wenn ihr mit der Bearbeitung eines Formulars mit Shortcodes umgehen könnt und nur einfache Formulare ohne Dinge wie mehrseitige Formulare, bedingte Felder usw. benötigen, dann ist Contact Form 7 vielleicht alles, was ihr braucht. Viele Themes bringen sogar besseren CSS-Styles mit, da es so weit verbreitet ist. Und es gibt auch viele Plugins, die Contact Form 7 um zusätzliche Funktionen erweitert, wie die beiden anderen Plugins, die ich in diesem Blogbeitrag vorgestellt habe.

Verwenden ihr auch Contact Form 7? Vielleicht mit anderen zusätzlichen Plugins? Oder verwendet ihr ein größeres Formular-Plugin? Dann teilt gerne bitte eure Erfahrungen in einem Kommentar mit.