Kau-Boys

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.

Ich mag keine Cookie-Banner, aber wer mag sie schon? In diesem Blog habe ich alles entfernt, was ein „Zustimmungs-Management-Tool“ benötigt, und bin entweder zu Lösungen ohne Cookies oder zu Zwei-Klick-Optionen übergegangen. Mehr dazu in den folgenden Blogbeiträgen.

Auf manchen Websites benötigt man aber ein Tool zur Verwaltung von Einwilligungen. Dann hat man die Möglichkeit, aus einer breiten Palette verschiedener Tools auszuwählen, sowohl aus kostenlosen als auch aus Premium-Tools. Viele große Websites nutzen sogar komplette externe Dienste, die vielleicht nicht einmal in Form eines WordPress-Plugins vorliegen. Einige Lösungen, bei denen es sich um WordPress-Plugins handelt, sind entweder ausschließlich Premium-Lösungen oder bieten eine kostenlose Version an, die so eingeschränkt ist, dass sie nicht wirklich genutzt werden kann. Hier habe ich das Complianz-Plugin als eine Lösung gefunden, die in der kostenlosen Version tatsächlich nutzbar ist.

Was macht Complianz?

Nun, es ist ein Cookie-Einwilligungsbanner, das heißt, es hilft euch dabei, dass eure Website nur dann Cookies setzt, wenn sie entweder notwendig sind oder die Zustimmung zum Setzen von Cookies gegeben wurde. Es kann auch externe Einbettungen blockieren, wie Videos von YouTube, Vimeo und anderen Streaming-Portalen oder Einbettungen von Google Maps, Twitter, Instagram und so weiter. Sie zeichnet auch die erteilte Zustimmung auf, um Vorschriften wie der GDPR zu entsprechen.

Es bietet einen „Cookie-Scanner“ an, der auf eurer Website und nicht über einen (bezahlten) externen Dienst läuft. Der Scanner versucht, alle Cookies zu finden, die eure Website setzt. Ihr könnt diese Cookies dann in verschiedene Kategorien einordnen oder eigene Cookies hinzufügen. Außerdem wird eine dynamische Seite „Cookie-Richtlinie“ erstellt, die alle Cookies in den verschiedenen Kategorien auflistet.

Es gibt auch eine Premium-Version des Plugins, die erweiterte Funktionen wie Statistiken, A/B-Tests, Geo IP-Zustimmung, weitere Dokumente und vieles mehr bietet. Aber für eine einfache Website, bei der es nur darum geht, die Annahme bestimmter Cookies zu ermöglichen, sind diese Funktionen meiner Meinung nach nicht wirklich notwendig.

Warum verwende ich Complianz?

Von all den verschiedenen „Cookie-Content“ Plugins, die ich getestet habe, erfüllt dieses Plugin in der kostenlosen Version meine Bedürfnisse am besten. Wenn ich kein Budget für Premium-Lösungen habe, ist Complianz das Plugin, das ich verwenden würde. Falls ich überhaupt eine dieser Lösungen verwenden muss.

Fazit

Wenn ich über die auf einer Website verwendeten Dienste entscheiden kann, würde ich immer versuchen, nur solche zu wählen, die datenschutzfreundlich sind und keine Cookies setzen oder externe Daten laden. Aber wenn ich solche Dienste nutzen muss, werde ich ein Plugin wie Complianz verwenden, das kostenlos ist und auf der Website selbst läuft, und nicht ein kostenpflichtiger externer Dienst, um ein Cookie-Einwilligungsbanner zu implementieren.

Vielleicht werden sich einige von euch jetzt wundern, dass ich diese beiden Plugins vorstelle. Ich benutze den Block-Editor schon, als er sich noch im Beta-Stadium befand und nur über das Gutenberg-Plugin verfügbar war. Ich bin also nicht der übliche Nutzer des Classic Editor Plugins. Aber ich habe zwei Websites, die ich betreue, auf denen ich es verwende.

Was machen die beiden Plugins?

Sowohl der Classic Editor als auch das Classic Widgets Plugin werden verwendet, um die „Legacy-Komponenten“ aus älteren WordPress-Versionen zu erhalten, die heutzutage die Block-Editor-Schnittstelle verwenden würden. Das Classic Editor Plugin ermöglicht es euch, Gutenberg entweder ganz zu deaktivieren und den alten TinyMCE-Editor für eure Inhalte zu verwenden, oder aber ihr entscheidet für jedes Inhaltselement, welchen Editor ihr nutzen möchten.

Das Classic Widgets Plugin hingegen bringt den alten „Widget-Admin-Bereich“ zurück, der in WordPress 5.8 durch die „Gutenberg UI“ ersetzt wurde und der es euch nun erlaubt, jeden Block in jedem Widget-Bereich zu verwenden.

Warum verwende ich beide Plugins?

Das Classic Editor-Plugin wird auf der von mir gehosteten Podcast-Website verwendet. Das Podcast-Plugin, das ich dort verwende (dieses wird in einem anderen Blogbeitrag vorgestellt), funktioniert nicht vollständig im Block-Editor. Alle „Meta-Boxen“ funktionieren zwar, aber der Editor stürzt ab, zumindest für bestehende Episoden.

Ich verwende das Plugin auch auf der Website einer Bekannten. Diese Bekannte ist kein „technischer Mensch“ und die neue Eingabe über den Block-Editor für einige Plugins erschwert das Erstellen und Bearbeiten von Inhalten.

Das Classic Widgets Plugin wird auf diesem Blog hier verwendet. Ich nutze immer noch ein Theme, das vor etwa 15 Jahren geschrieben wurde, und das einige Widgets und Widgetbereiche mitbringt, die nicht gut mit dem neuen „Block-Editor-Widget-Bereich“ funktionieren. Sobald ich das Theme endgültig durch ein FSE-Theme ersetzt habe, kann ich auch dieses Legacy-Plugin entfernen.

Fazit

Auch wenn ich ein großer Verfechter des Site- und Block-Editors bin, sehe ich doch auch Fälle, in denen Plugins wie der Classic Editor oder Classic Widgets notwendig sind. Es sollte unser Ziel sein, diese Plugins überflüssig zu machen, besonders wenn wir selbst Plugins entwickeln. Aber die Realität ist wohl, dass es sie noch einige Jahre lang geben wird.

Benutzt ihr auch den Classic Editor? Und tun ihr es, weil ihr den Block-Editor nicht mögt, oder eher, weil auch ihr mit veralteten Websites zu tun habt?