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?
Das Plugin, das ich heute vorstelle, hat zwei Extreme. Es ist das Plugin mit einem der längsten Namen, „Block Editor: Reverse Columns on Mobile„, aber mit der geringsten Menge an Code. Der PHP-Code lädt nur etwas JavaScript und CSS. Alles in allem hat es etwa 250 Zeilen Code zusammengenommen.
Ich verwende es auf einer Website, die versucht, „keinen Code“ zu verwenden. Der Inhalt und das Design werden fast ausschließlich mit dem Site- und Block-Editor erstellt.
Was macht das Plugin?
Wie der Name schon sagt: Es kehrt die Spalten auf mobilen Endgeräten um. Nehmen wir an, ihr habt eine Seite mit mehreren „Medien und Text“ Blöcken. Für ein schönes Layout platziert ihr das Bild für den ersten Block auf der linken Seite, für den nächsten Block auf der rechten Seite, dann wieder auf der linken Seite und so weiter. Wenn ihr nun die Seite auf einem mobilen Endgerät anseht, würden diese Blöcke standardmäßig immer die linke Spalte über der rechten platzieren. Das Ergebnis wäre dann in etwa so: Bild, Text, Text, Bild, Bild, Text, Text, Bild, …
Das sieht auf dem Handy nicht gerade schön aus. Stattdessen möchtet ihr wahrscheinlich, dass das Bild immer über oder unter dem Text steht. Ihr könnt dies beheben, indem ihr manuell eine eigene CSS-Klasse zu jedem zweiten Block hinzufügen und dann etwas CSS in eurem Theme verwenden (oder in den globalen Stilen des Site-Editors), oder ihr könnt einfach dieses Plugin verwenden, das eine Checkbox zu den Blöcken core/columns, core/group (flexible Layouts) und core/media-text hinzufügt.
Warum verwende ich das Plugin?
Wie bereits erwähnt, verwende ich es auf einer Website, die keine speziell für die Seite programmierten Plugins oder Themes verwenden möchte. Außerdem soll es allen, die den Inhalt einer Seite bearbeiten, die Möglichkeit geben, diese Funktion problemlos zu nutzen. Für meinen persönlichen Blog und meine Websites würde ich wahrscheinlich einfach eine eigene CSS-Klasse einführen, die ich solchen Blöcken hinzufügen würde. Aber warum immer „das Rad neu erfinden“, wenn es ein Plugin gibt, das genau das tut, was es tun soll, und nicht mehr. Das CSS kümmert sich sogar um RTL (rechts nach links) Sprachen/Designs und verschiedene Möglichkeiten, Elemente nebeneinander anzuordnen. In meiner eigenen CSS-Klasse würde ich wahrscheinlich einige dieser Fälle vergessen.
Fazit
Auch wenn manche Leute argumentieren, dass man möglichst wenig Plugins einsetzen soll, mag ich Plugins wie dieses hier, das eine Sache genau so löst, wie ich sie selbst programmiert hätte.
Habt ihr auch ein Plugin gefunden, das kleine Dinge im Block- oder Site-Editor verbessert? Dann teilt sie gerne in einem Kommentar mit uns.
Ich weiß nicht mehr, wann ich BackWPup entdeckt habe und wie lange ich es schon benutze. Damals wurde es ausschließlich von Daniel Hüsken entwickelt. Irgendwann hat er aber gemerkt, dass er nicht mehr die Zeit hat, allein an dem Plugin zu arbeiten. Er hat dann bei Inpsyde angefangen, der Agentur, bei der ich derzeit arbeite (wir heißen jetzt Syde), und das Plugin dahin mitgenommen. Vor etwas mehr als zwei Jahren wurde das Plugin von WP Media übernommen, dem Unternehmen hinter Plugins wie WP Rocket, Imagify und anderen. Die neue Benutzeroberfläche, die WP Media eingeführt hat, hat vielen gar nicht gefallen, aber ich nutze das Plugin immer noch auf vielen meiner Websites sehr gerne.
Was macht BackWPup?
Es ist ein Backup-Plugin, das heißt, es dient zur Sicherung deiner Website. In der kostenlosen Version könnt ihr Backups an verschiedene Ziele senden. Es unterstützt:
E-Mail (was wirklich nur für Datenbank-Backups funktioniert)
Microsoft Azure
S3-Anbieter
Dropbox
Rackspace
SugarSync
ein externer FTP-Server
und denselben Server (der kein guter Ort für ein Backup ist)
In der Vergangenheit waren Wiederherstellungen nur in der Premium-Version verfügbar, aber jetzt kann man sie auch in der kostenlosen Version verwenden. Da ich aber weiß, wie man ein Backup von Dateien wiederherstellt, habe ich die Wiederherstellungsfunktion nie genutzt. Ich weiß einfach nicht wirklich, was genau dabei passieren würde. In einer neueren Version wurde auch eine Migrationsfunktion hinzugefügt, die ich auch noch nie getestet habe.
Warum ich BackWPup verwende?
Es gibt viele Backup-Plugins. Ein Grund, warum ich BackWPup (immer noch) verwende, könnte einfach sein, dass es das erste Backup-Plugin war, das ich entdeckt und genutzt habe. Aber ich mag auch eine seiner Hauptfunktionen: die Möglichkeit, mehrere Sicherungsaufträge einzurichten. Viele andere Backup-Plugins haben nur einen Auftrag (eine Version der Einstellungen), der nach einem Zeitplan ausgeführt werden kann. Mit BackWPup können ihr so viele Sicherungsaufträge einrichten, wie ihr möchtet. Ich habe einen, der täglich läuft und die Datenbank sichert. Ein anderer macht eine vollständige Sicherung des Dateisystems. Für jeden Auftrag könnt ihr festlegen, wo die Dateien gespeichert werden sollen. So könntet ihr zum Beispiel die Datenbank auf einem externen Dienst speichern und sie euch per E-Mail zuschicken lassen (wenn sie wirklich klein ist), während die Dateien auf einem externen Speicher abgelegt werden, der eine große Menge an Daten aufnehmen kann.
Was sind die Alternativen, die ich ausprobiert habe?
Auf einigen Websites, vor allem auf denen, die ich nicht allein betreue, verwenden wir UpdraftPlus (die kostenlose Version). Es bietet zwar eine einfachere Benutzeroberfläche und hatte in der kostenlosen Version jahrelang (vielleicht sogar von Anfang an) eine Wiederherstellungsfunktion, aber mir gefällt die Beschränkung auf nur einen Sicherungsauftrag nicht. Außerdem werden standardmäßig nur die Ordner in wp-content gesichert und in mehreren ZIP-Dateien gespeichert, die man separat herunterladen und entpacken muss. Ich habe gehört, dass die Premium-Version die gesamte Installation sichern kann, aber da BackWPup das auch kann, gibt es für mich keinen Grund zu wechseln, weil ich eben auch keine Wiederherstellungsfunktion brauche. Das Einzige, was die kostenlose Version bietet, was bei BackWPup schön wäre, ist die Unterstützung für Google Drive.
Fazit
Da ich mehrere Backup-Jobs haben möchte und kein Plugin mit einer Wiederherstellungsfunktion benötige, habe ich mich vor vielen Jahren für BackWPup als mein primäres Backup-Plugin entschieden und benutze es immer noch. Das Wiederherstellen aus der (einzelnen) ZIP-Datei ist ziemlich einfach, wenn man sowieso mit dem Terminal arbeitet. Wenn ihr Local verwenden, könnt ihr sogar direkt aus der ZIP-Datei eine lokale Umgebung einrichten. Wenn ihr also noch auf der Suche nach einer (Plugin-)Backup-Lösung seid, dann solltet ihr BackWPup einmal ausprobieren.
Das hier ist der erste Blogbeitrag meines „Plugin-Adventskalenders„. In den nächsten 24 Tagen möchte ich euch Plugins vorstellen, die ich auf meiner persönlichen Website und auf Websites, die ich betreue, einsetze. Hoffentlich schaffe ich es jeden Tag um Mitternacht einen Beitrag zu veröffentlichen.
Da ich sie in alphabetischer Reihenfolge vorstellen möchte (mit zwei Ausnahmen), musste der erste Beitrag selbstverständlich eins der Plugins behandeln, das ich für jeden Blog für unverzichtbar halte: Antispam Bee.
Dieses Plugin wurde von Sergej Müller entwickelt und wird nun vom Pluginkollektiv betreut. Da ich auch Mitglied dieser Gruppe bin, helfe auch ich bei der Weiterentwicklung.
Was macht Antispam Bee?
Es blockiert Kommentar-Spam. So einfach. Und das macht es wirklich sehr gut. Es hat viele verschiedene Taktiken, um Spam-Kommentare zu erkennen, und nur von Zeit zu Zeit muss ich einen ausstehenden Kommentar als Spam markieren, da einige Spam-Kommentare manuell von echten Menschen geschrieben werden, die Kommentarinhalte verwenden, die für den jeweiligen Blogbeitrag passend klingen.
Ihr fragt euch vielleicht, ob Antispam Bee auch andere Arten von Spam blockiert, zum Beispiel Formular-Übermittlungen oder Registrierungen? Nein, das tut es derzeit nicht. Dies war nie ein Schwerpunkt des Plugins. Es hilft nur bei Kommentar-Spam, aber hier kann es glänzen.
Aber das stimmt nur zum Teil. Das Pluginkolletiv, also auch ich, arbeitet gerade an einer neuen Version. Diese neue Version würde auch erst einmal nur für Kommentare funktionieren. Aber sie wird eine „API“ anbieten, die auch für andere Dinge als Kommentare genutzt werden kann. Verwenden ihr also zum Beispiel das Plugin „Contact Form 7“, um ein Kommentarformular zu eurem Blog hinzuzufügen? Dann wird es vielleicht in Zukunft ein Plugin (von anderen) geben, das Antispam Bee mit Contact Form 7 verknüpft.
Die Arbeit an dieser neuen Version wurde bereits vor einigen Jahren begonnen, und da die Einführung einer neuen Version für ein so erfolgreiches Plugin mit vielen Risiken verbunden ist, möchten wir wirklich sicherstellen, dass es für bestehende Websites funktioniert – Antispam Bee hat derzeit mehr als 700.000 aktive Installationen, und wir möchten keine davon kaputt machen oder den Spamschutz weniger effizient machen. Ich habe in meinem letzten Urlaub einige Zeit damit verbracht, die Effizienz des Spamschutzes der neuen „Work in Progress“-Version mit den rund 300.000 Kommentaren meines englischen Blogs zu testen, und die neue Version hat jeden einzelnen Kommentar erfasst, den die aktuelle Version auch erfasst hat, nur auf andere (und noch bessere) Art und Weise. Ich bin mir also sehr zuversichtlich, dass 2026 das Jahr sein wird, in dem Antispam Bee 3 endlich veröffentlicht wird. 🤞
Warum ich Antispam Bee nutze?
Da ich Kommentare zu meinen Blogbeiträgen begrüße – und ich würde mich freuen, wenn mehr von euch kommentieren würden 😉 – erhalte ich auch eine Menge Spam-Kommentare. Im Moment habe ich fast 157.000 Spam-Kommentare in meiner Datenbank (im englischsprachigen Blog sind es sogar fast 300.000), verglichen mit nur 1,274 Kommentaren, die kein Spam sind. Man könnte sagen, dass ich wirklich ein Plugin wie Antispam Bee brauche.
Aber warum verwende ich dieses Plugin und nicht ein anderes? Ich hatte für meinen englischen Blog ein anderes Antispam-Plugin verwendet, da es vor vielen Jahren besser gegen Kommentar-Spam auf Englisch funktioniert hat. Das lag wahrscheinlich daran, dass Antispam Bee von einem deutschen Entwickler für seinen Blog entwickelt wurde und er mehr Kommentare auf Deutsch bekam. Aber vor vielen Jahren habe ich dieses andere Plugin auch in meinem englischen Blog durch Antispam Bee ersetzt. Einige von euch verwenden vielleicht Akismet, das bei WordPress vorinstalliert ist, aber im Gegensatz zu Antispam Bee ist es nicht datenschutzfreundlich, und wir Deutschen haben ja den Ruf, dass uns der Datenschutz sehr am Herzen liegt, und das trifft auch auf mich zu.
Fazit
Wenn ihr Kommentare auf eurem Blog oder eurer Website zulasst und ihr Spam-Kommentar erhaltet, dann sollten Antispam Bee ausprobieren. Installiert und aktiviert es einfach. Die Standardeinstellungen funktionieren für die meisten Websites sehr gut und verwenden keine fortgeschrittenen Techniken, die nicht so datenschutzfreundlich sind. Wenn ihr Antispam Bee bereits verwenden und es euch gefällt, wie wäre es dann, wenn ihr es noch heute auf WordPress.org bewert?
Wenn ihr meinen Blog aktiv lest, oder ihr euch den Zeitstempel meines letzten Blogbeitrags angesehen habt, dann ist euch sicher aufgefallen, dass ich seit mehr als 14 Wochen keinen Blogbeitrag mehr veröffentlicht habe. Das hat verschiedene Gründe, der wichtigste davon ist, dass ich im September Vater geworden bin. Diejenigen von euch, die auch jemanden betreuen oder pflegen, wissen sicher, dass das einen Großteil der verfügbaren Zeit in Anspruch nimmt – und es kann auch anstrengend sein.
Werde ich weiter bloggen?
Auf jeden Fall! Ich habe mich noch immer dem #projekt26 verschrieben. In diesem Jahr konnte ich bisher nur 13 Beiträge veröffentlichen. Da mir nur noch ein Monat bleibt, könnte es schwer werden, dieses Ziel zu erreichen. Aber ich habe einen Plan – und ich hoffe, dass er funktionieren wird. 😅
Ein Plugin-Adventskalender
Wie schon im letzten Jahr werde ich versuchen, im Dezember einen weiteren Adventskalender zu machen. Letztes Jahr habe ich mich auf „Webtechnologien“ konzentriert. In den Vorjahren waren es eher „normale Themen“. Diese Themen nehmen jedoch viel Zeit in Anspruch, weil ich oft auch Code-Beispiele schreibe. Um es dieses Jahr also etwas einfacher zu machen, werde ich die Idee des Adventskalenders von KrautPress aufgreifen. Letztes Jahr haben sie Blogbeiträge veröffentlicht, die jeweils ein Plugin pro Beitrag in ihrem „Plugin-Adventskalender“ behandelt haben.
Ich habe die letzte Woche damit verbracht, eine Liste von Plugins für meinen Adventskalender zu sammeln. Jedes Plugin wird auf einer meiner Websites verwendet, oder auf einer Website, die ich mitbetreue. Einige Blogbeiträge werden sich mit mehr als einem Plugin befassen, da ich auch einige „Zusatz-Plugins“ zu größeren Plugins verwende.
Wie wird der Blog im nächsten Jahr weitergeführt?
Ich möchte weiterhin regelmäßig bloggen. Mir wurde gesagt, dass man als Elternteil mehr freie Zeit hat, je älter das Kind wird. Mal sehen, ob sich das bewahrheiten wird. Aber selbst wenn ich mich bemühe, 26 Blogposts zu veröffentlichen, könnte es sein, dass ich erst später im nächsten Jahr hier neue veröffentliche. Viele meiner Blogposts behandeln Themen, die bei meiner täglichen Arbeit aufkommen. Und da ich eine lange Elternzeit nehme, könnte es sein, dass ich nichts zum Bloggen habe. Aber ich habe eine Idee für einen neuen Blog, der sich mit einem anderen Thema befassen wird. Ihr habt es vielleicht schon geahnt, ich möchte über Dinge bloggen, die für Eltern relevant sind. 😊
Fazit
Ab nächsten Montag werdet ihr also über das erste Plugin lesen können, das ich regelmäßig auf meiner Websites verwende. Ich werde sie alphabetisch ordnen, vielleicht kannst du also erraten, welches ich zuerst behandeln werde. 😉
Im gleichen Projekts, über das ich letzte Woche geschrieben habe, hatte ich die Aufgabe bekommen, die Leistung der Website zu optimieren. Ein Hauptproblem war die sehr langsame Anmeldung ins Backend. Jedes Mal, wenn ich mich eingeloggt habe, musste ich etwa eine Minute warten, bevor ich das Dashboard sehen konnte. Aber was stimmte mit der Website nicht? Warum war sie so langsam?
Eine riesige Datenbank
Um die Website analysieren zu können, musste ich sie erst einmal lokal einrichten. Allein dafür habe ich mehrere Tage gebraucht! Die Datenbank war so groß, dass ich buchstäblich die SSD meines Laptops aufrüsten musste, bevor ich überhaupt daran denken konnte, sie zu importieren. Der Datenbank-Dump war „nur“ etwa 40 GB groß, aber nach dem Import hat sie etwa 100 GB auf meiner SSD verbraucht. Für die Optimierung der Datenbank habe ich Backups erstellt. Dazu habe ich die gesamte Datenbank schließlich zweimal dupliziert, da ich auch eine HPOS-Migration durchführen wollte. Nachdem ich also Stunden damit verbracht hatte, eine neue SSD zu installieren, mein gesamtes System zu kopieren (ein Windows/Linux-Dual-Boot), einen defekten Bootloader zu reparieren und den Datenbankimport durchzuführen, war ich endlich bereit, mit der Analyse der Seite zu beginnen.
Das Performance-Problem für die Anmeldung finden
Nach meinem ersten Login hat mir das Query Monitor Plugin zwei Abfragen angezeigt, die extrem lange gedauert haben. Die sahen wie folgt aus:
SELECT COUNT(*)
FROM wp_comments
WHERE user_id = 123456
AND comment_approved = 1
Zwei dieser Abfragen dauerten jeweils etwa 30 Sekunden. Das hat die Anmeldezeit um eine ganze Minute verlängert. Der Query Monitor gab hat mir auch gesagt, welcher „Caller“ diese Abfragen ausgeführt hat. Es war die Akismet::get_user_comments_approved Funktion.
Der Grund für diese Abfragen
Der Shop verwendet Akismet zur Bekämpfung von Spam-Kommentaren. Im Widget „Auf einen Blick“ auf dem Dashboard wird die Anzahl der Kommentare in der Spam-Warteschlange und die Anzahl der Kommentare in der Moderation angezeigt. Im Widget „Aktivität“ werden außerdem „Neueste Kommentare“ angezeigt. Für jeden Kommentar, der in dieser Liste steht und der von einem User/Customer der Website verfasst wurde, wird die Anzahl der genehmigten Kommentare ermittelt. Der Witz ist aber, dass dieser Wert zwar dem Dashboard-Widget hinzugefügt, dann aber mit einem display:none Inline-Style versteckt wird. Er wird also nicht einmal angezeigt. Die Abfragen laufen trotzdem. Zum Glück waren es nur zwei Customer und nicht die möglichen fünf, die aufgelistet wurden, sonst wäre der Login um zweieinhalb Minuten verlangsamt worden.
Analysieren des Problems
Da wir nun wissen, welche Abfrage das Leistungsproblem verursacht und warum diese Abfrage ausgeführt wird, stellt sich die Frage, wie wir das Problem beheben können. Werfen wir einen Blick darauf, warum diese Abfrage so langsam ist.
Der Shop war eine Multisite-WordPress-Installation. In einem der Shops hatten wir etwa 76.600 Kunden (der andere Shop hatte fast doppelt so viele) mit mehr als 83.000 Abonnements, was zu mehr als 1.442.000 Bestellungen führte. Ja, das sind weit mehr als eine Million Bestellungen, und das ist nur für einen der Shops. Man kann also sagen, dass es sich um einen ziemlich großen Shop handelt. Jede Bestellung hat einige „Meta-Informationen“. Eine dieser Informationen sind „Bestellnotizen“ (Englisch „order notes“), und diese werden als Kommentare in derselben Tabelle wie die normalen Kommentare gespeichert. In der Kommentartabelle hatten wir insgesamt 15.348.283 Kommentare! Das waren die Kommentar-Typen:
Einträge
comment_type
677
comment
13876120
order_note
859541
user_membership_note
Wenn wir uns nun die Abfrage ansehen, die diese langsame Anmeldung verursacht, können wir erkennen, dass sie die Kommentare nach den Spalten user_id und comment_approved filtert. Sehen wir uns die Struktur der Tabelle, dann haben wir einen Index comment_approved_date_gmt, der für die Spalte comment_approved verwendet werden kann, aber wir haben keinen Index für die Spalte user_id. Das bedeutet, dass MySQL alle mehr als 15 Millionen Kommentare durchsuchen muss, um diejenigen zu finden, für die der Wert von user_id aus der Abfrage passt. Und das wiederholt sich für jede einzelne user_id Wert, den wir haben. Das kann eine Weile dauern.
Behebung des Problems
Da wir nun den Grund für die langsame Abfrage kennen, können wir versuchen, eine Lösung für das Problem zu finden. Es gibt drei Lösungen, die funktionieren könnten:
Lösung 1: Löschen der Kommentare
Das ist vielleicht ein bisschen zu radikal, aber bei diesem Shop würde es sogar funktionieren. Interessant ist, dass die beiden Kommentare, welche die Website verlangsamt haben, auf der „Checkout“ Seite gemacht wurden. Das ist keine Seite, auf der man normalerweise Kommentare zulassen würden. Das Löschen dieser Kommentare (oder zumindest das Verschieben in den Papierkorb) löste das Anmeldeproblem, da sie nicht mehr im Widget unter „Neueste Kommentare“ angezeigt wurden.
Lösung 2: Kommentar-Typen ausschließen
Bei der Vorbereitung dieses Blogbeitrags habe ich einen Filter gefunden, der zur Verbesserung der Abfrage verwendet werden kann. Für die Abfrage zum Zählen der Kommentare für eine user_id kann man diesen Filter verwenden, um einige Kommentar-Typen auszuschließen:
Da wir die Typen order_note und user_membership_note nicht wirklich brauchen, sollten wir sie ausschließen. WooCommerce fügt einen Index für die Spalte comment_type in der Tabelle wp_comments hinzu, womit MySQL einige Kommentar-Typen sehr effektiv herausfiltern kann.
Das kann unsere die 30-Sekunden-Abfrage auf nur 0,015-0,03 Sekunden beschleunigen. Das ist schon eine ziemliche Verbesserung. Wir müssen nur darauf achten, dass wir alle Kommentar-Typen ausschließen, die wir nicht benötigen. Je nachdem, welche Plugins ihr verwendet, gibt es vielleicht noch andere Kommentar-Typen, die ihr ausschließen möchten.
Lösung 3: Hinzufügen eines Index für die user_id Spalte
Wie bereits erwähnt, besteht das Problem bei dieser Abfrage darin, dass wir versuchen, nach user_id zu filtern, diese Spalte aber keinen Index hat. Das Hinzufügen eines Index kann das Problem ebenfalls beheben. Um einen Index hinzuzufügen, müsst ihr diese Abfrage in der Datenbank ausführen (z.B. mit phpMyAdmin, Adminer, der WP-CLI oder einem anderen Tool):
ALTER TABLE wp_comments ADD INDEX `my_idx_user_id` (`user_id`);
Wenn ihr einen anderen „Präfix“ als „wp_“ verwendet, müsst ihr in der Abfrage entsprechend anpassen. Beachten aber bitte, dass das Hinzufügen eines Index zu einer Tabelle eine Weile dauern kann. Bei diesen 15 Millionen Einträgen hat es bei mir 30-35 Sekunden gedauert den Index zu erstellen. In dieser Zeit kann das Schreiben in die Tabelle langsamer sein oder sogar blockiert werden. Es ist also besser, die Abfrage zu einer Zeit auszuführen, in der weniger Aktivität im Shop herrscht.
Nach dem Hinzufügen eines Index dauert die anfängliche 30-Sekunden-Abfrage jetzt nur noch 0,001 Sekunden (oder sogar noch weniger, da dies die niedrigste Zahl ist, die ich bei der Analyse von Abfragen erhalte), d. h. sie ist sogar mehr als zehnmal schneller als bei der vorherigen Lösung.
Fazit
Die Performance-Probleme sind bei großen Websites und Shops oft ganz andere als bei kleinen Websites. Zumindest mein Blog ist weit davon entfernt, Millionen von Kommentaren zu erreichen. 😁
Die Ursache eines Leistungsproblems zu finden und es zu beheben, ist auch nicht immer eine einfache und unkomplizierte Aufgabe. Wenn ihr dabei Tools wie das Query Monitor Plugin verwendet, hilft das in der Regel sehr dabei, solche Probleme zu finden. Aber gute Lösungen zu finden, kann schwierig sein. Vor allem, wenn die Komponente, die das Problem verursacht, keine Action oder keinen Filter anbietet, um es zu lösen, oder wenn ihr nicht in der Lage seid, es anders zu beheben, wie z. B. durch das Hinzufügen eines Index. Für den in diesem Blogbeitrag erwähnten Shop habe ich am Ende die Lösungen 1 und 3 verwendet, wobei ich einen benutzerdefinierten WP-CLI-Befehl verwenden musste, um den Index zur Datenbank hinzuzufügen, da ich keinen Schreibzugriff mit Tools wie phpMyAdmin oder Adminer hatte.
Habt ihr auch einige „interessante“ Performance-Probleme mit großen Websites oder Shops erlebt? Dann teilt sie doch bitte in einem Kommentar mit uns. Oder vielleicht zwei, aber bitte nicht eine Million Kommentare. 😂
In einem Projekt hatte die Design-Agentur ein Theme ohne Suche-Template erstellt (manuelle Suchen waren aber trotzdem möglich). Nun wollten die Shop-Verantwortlichen eine Suche in der Kopfzeile der Seite haben, die aber nur nach Produkten suchen sollte.
Einige Themes haben dies bereits in der Header-Suche implementiert, wie das „Standard-Theme“ Storefront. Andere verwenden die normale WordPress-Suche, die immer nach allen Beitragstypen suchen würde. Schauen wir uns an, wie wir das ändern können.
Nur Produkte finden
In WordPress kann man ?s=something an eine beliebige URL anhängen, was die WordPress-Site nach allen öffentlichen Beitragstypen durchsuchen würde, die in den Einstellungen während der Registrierung des Post-Types nicht exclude_from_search auf true gesetzt haben. Wenn wir aber nur nach Produkten suchen wollen, können wir dies auf verschiedene Weise erreichen.
Verwenden eines verstecktes Feld, um den Beitragstyp festzulegen
Wenn wir uns den Quellcode des Headers im Storefront Theme ansehen, finden wir den folgenden HTML-Code:
Wie der placeholder Text andeutet, ist das Suchfeld nur für Produkte gedacht. Dies wird erreicht, indem ein verstecktes Feld hinzugefügt wird, das den post_type für diese Suche auf product setzt. Nach dem Absenden würde die Suche eine URL wie https://example.com/?s=something&post_type=product öffnen. Diese würde dann nur Produkte anzeigen und das Template archive-product.php verwenden, sofern es im Thema vorhanden. Hiermit würden die Suchergebnisse auf die gleiche Weise aufgelistet werden, wie im Shop (in den meisten Themes).
Umleiten der normalen Suche auf den Shop
Auch mit dieser Erweiterung wäre es immer noch möglich, nach jedem anderen Beitragstyp zu suchen, indem man den Suchparameter an eine URL anhängt, die nicht zum Shop gehört (wie oben gezeigt). Wenn wir die normale Suche wirklich einschränken wollen, damit nur Produkte anzeigt werden, können wir jede normale Suche auf die Shop-Suche umleiten. Das können wir mit einem Snippet wie diesem hier umsetzen:
function product_search_only_redirect_search_to_products() {
if ( is_admin() ) {
return;
}
if ( ! is_search() ) {
return;
}
// We are already at the right search result page.
if ( is_shop() || is_tax( get_object_taxonomies( 'product' ) ) ) {
return;
}
$search_query = get_search_query();
$shop_url = wc_get_page_permalink( 'shop' );
$redirect_url = add_query_arg( 's', rawurlencode( $search_query ), $shop_url );
wp_safe_redirect( $redirect_url );
exit();
}
add_action( 'template_redirect', 'product_search_only_redirect_search_to_products' );
In dieser Callback-Funktion zur template_redirect Aktion wird jede Frontend-Suche umgeleitet, die nicht bereits auf dem Shop oder einer Taxonomie-Archivseite durchgeführt wird. Dies verhindert jede normale Suche. Wenn wir nun auf der Seite suchen, werden wir auf eine URL wie https://example.com/shop/?s=something umgeleitet und sehen nur Produkte.
Bonus-Tipps
Ich habe mich für die zweite Option entschieden, da das Shop-Theme kein Such-Template hatte (eigentlich hatte es eines, aber es wurde nur eine leere Seite mit Kopf- und Fußzeile ausgegeben). Nach dieser Implementierung fanden wir aber zwei kleine Probleme – nicht mit dieser Lösung, sondern allgemein mit der Funktionsweise der Suche.
Leere Suchbegriffe aus dem Header des Templates entfernen
Ich habe auch ein Suchfeld zu den „Filter-Dropdowns“ hinzugefügt. Dies hatte den Effekt, dass jedes Mal, wenn einer der Filter verwendet wurde, die Ergebnisseite einen leeren Suchbegriff verwendet hat. Dies würde zu einer URL wie https://example.com/shop/?s= führen, deren Titel auf der Seite etwas wie Suchergebnisse: „“ verwendet anstelle von einem Titel wie Shop. Um das zu beheben, habe ich den folgenden Codeschnipsel hinzugefügt:
Weiterleitung der Suche auf ein einzelnes Produkt verhindern
Das zweite Problem wurde von dem Shop-Verantwortlichen bemerkt. Jedes Mal, wenn es nur ein Produkt als Ergebnis einer Shop-Suche gab, wurde dieses Ergebnis nicht mit dem „Produkt-Archiv“ Template angezeigt, sondern es auf dieses eine Produkt umgeleitet. Und da wir alle Suchanfragen auf die Shop-Suche umleiten, würde dies bei jeder Suche, die nur ein Produkt findet, der Fall sein, was verwirrend sein könnte. Glücklicherweise habe ich durch einen Blick in den Quellcode von WooCommerce die Stelle gefunden, an der das geschieht, und einen Filter gefunden, mit dem sich diese Umleitung deaktivieren lässt. Ich musste dazu nur eine weitere Code-Zeile hinzuzufügen:
Das war es auch schon! Jetzt zeigt die Suche immer eine Liste von Produkten oder nur ein einziges an, leitet aber nicht automatisch zu diesem einen Produkt weiter.
Fazit
Ich bin nicht wirklich ein WooCommerce-Experte, ganz im Gegenteil. Aber da WooCommerce Core die gleichen Techniken verwendet wie WordPress selbst, kann ich in der Regel Wege finden, es so anzupassen, wie ich es brauche.
Vor einigen Wochen wurde ich gefragt, wie ein jemand mit der Rolle „Redakteur“ den Inhalt der Datenschutzseite ändern kann. Wenn ihr die Einstellungen „Einstellungen > Datenschutz > Eine Seite für die Datenschutzerklärung auswählen“ verwenden und hier eine Seite auswählt, kann diese Seite nur von jemandem mit der Rolle „Administrator“ bearbeitet werden. Um der Rolle „Redakteur“ das Aktualisieren dieser Seite zu ermöglichen, gibt es mehrere Optionen.
Option 1: Macht die Seite zu einer normalen Seite
Wenn ihr die Seite nicht unter „Einstellungen > Datenschutz > Eine Seite für die Datenschutzerklärung auswählen“ einstellt, kann ein „Redakteur“ den Inhalt bearbeiten, da es sich nur um eine normale Seite handelt. Aber diese Einstellung hat dennoch eine gewisse Bedeutung. Zum Beispiel wird automatisch unterhalb des Formulars auf der Seite wp-login.php ein Link zu dieser Seite angezeigt. Dieser Link kann auch mit der Funktion the_privacy_policy_link() in die Navigation eines Themes eingefügt werden, was einige ältere Standardthemes (Twenty Fourteen – Twenty Twenty-One) tun.
Falls ihr diese Option verwendet, ist es in der Regel sinnvoll, die Seite nur dann während der Bearbeitung als normale Seite einzurichten. Sobald der „Redakteur“ die Seite aktualisiert hat, sollte sie wieder als „Seite für die Datenschutzerklärung“ eingestellt werden.
Option 2: Gebt der „Redakteur“ Rolle die „manage_options“ Berechtigung
WordPress verfügt über alle viele sogenannter „Berechtigungen“ (im Englischen „Capablities“), um einem „Benutzern“ (oder einer „Rolle“) die Rechte zu geben, bestimmte Dinge zu tun. Eine neuere Berechtigung heißt manage_privacy_options und klingt wie die Rolle, die wir Redakteuren (oder einzelnen Benutzern) geben müssten, um die Seite mit der Datenschutzerklärung bearbeiten zu können, richtig? Leider ist das nicht der Fall. Diese Berechtigung ist eher eine „Meta-Berechtigung“, denn wenn diese Berechtigung einem Benutzer oder einer Rolle zugewiesen wird, benötigt der Benutzer die Berechtigung manage_options, um die Seite mit der Datenschutzerklärung bearbeiten zu können. Aber mit dieser Rolle würden man ihnen auch erlauben, (fast) alle Einstellungen der Website zu ändern. Das ist wahrscheinlich zu viel Macht und Verantwortung für Redakteure.
Option 3: Verwendung von speziellen Rollen in SEO-Plugins
Ich verwende für meine Website hauptsächlich Yoast SEO, das mit zwei zusätzlichen Rollen ausgestattet ist: „SEO Editor“ und „SEO Manager“. Beide erhalten alle Funktionen der „Redakteur“ Rolle, aber auch einige zusätzliche Funktionen für das Yoast SEO-Plugin. Und der „SEO Manager“ erhält auch die Möglichkeit, die Datenschutzseite zu bearbeiten.
Andere SEO-Plugins könnten ähnliche Rollen haben, aber ich habe sie nicht überprüft. Wenn das von euch verwendete Plugin eine solche Rolle oder eine Einstellung hat, die es Redakteuren erlaubt, die Datenschutzseite zu bearbeiten, hinterlasst bitte einen Kommentar mit dem Namen des Plugins und wie es damit funktioniert.
Option 4: Einen Codeschnipsel einfügen, um die Bearbeitung der Seite zu ermöglichen
Ich habe einen kleinen Codeschnipsel geschrieben, der es Redakteuren ermöglicht, die Seite mit den Datenschutzerklärung zu aktualisieren, ohne ihnen zu viele andere Berechtigungen zu geben, die sie nicht brauchen. Der Codeschnipsel filtert die Überprüfung auf die manage_privacy_options Berechtigung und entfernt dann die Notwendigkeit für die manage_options Berechtigung aus der Liste. Hier ist der Code dafür:
Yoast SEO verwendet einen sehr ähnlichen Code, allerdings mit etwas mehr Komplexität, da es auf die eigene „SEO Manager“ Rolle überprüft.
Fazit
Ich kann verstehen, warum im WordPress Core die Möglichkeit zur Bearbeitung der Seite mit der Datenschutzerklärung auf eine kleinere Gruppe von Benutzern beschränkt wurde. In einem Ticket zu diesem Thema wurde diskutiert, dass Redakteure möglicherweise nicht „in Datenschutzgesetzen oder Unternehmensrichtlinien geschult“ sind, die erforderlich sind, um korrekte Inhalte in diese Seite zu schreiben. Aber warum sollte ein Benutzer mit der Rolle „Administrator“ unbedingt dafür ausgebildet sein? Aber nur diese Benutzer können die Seite aktualisieren, was auch einige rechtliche Risiken mit sich bringen kann, wenn dadurch eine regelmäßige Aktualisierung der Seite verhindert wird.