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.
Heute habe ich einen etwas anderen Blogbeitrag für euch vorbereitet. Nicht nur das Thema ist ein wenig anders, sondern dieser Blogbeitrag wird auch der erste sein, der in zwei Formaten erscheint. Seit mehr als 16 Jahren blogge ich nun schon ausschließlich in Textform. Ich schicke auch oft Links zu meinen Blogbeiträgen an andere, wenn sie auf Themen und Probleme stoßen, die ich behandelt habe. Aber manchmal merke ich, dass es nicht einfach ist, diese Themen in Textform zu behandeln. Bei manchen Themen ist ein Video einfach leichter zu verstehen.
Mit diesem Blogbeitrag habt ihr also die Möglichkeit, entweder über das Thema zu lesen oder euch ein Video anzusehen. Oder ihr macht einfach beides und sagt mir dann, was euch besser gefallen hat. Aber nun direkt zum Thema.
Kontakt zum Löschen auswählen
Eine Bekannte nutzt Mailchimp schon seit vielen Jahren für ihren Newsletter. Manchmal hat sie aber gefälschte Anmeldungen erhalten, die sie löschen wollte. Sie hat mehrfach versucht, diese zu löschen, aber Mailchimp macht es einem etwas schwieriger als nötig.
Nachdem ihr euch in eurem Mailchimp-Konto eingeloggt habt, navigieren ihr zu „Zielgruppe“ und wählt die Kontakte aus, dir ihr löschen wollt. Anschließend fahrt ihr mit dem Mauszeiger über die drei Punkte rechts neben der Schaltfläche „Archivieren“ und wählt dort „Löschen“ aus dem Dropdown-Menü aus:
Einen Kontakt archivieren oder löschen?
Es öffnet sich ein Dialog, der etwas verwirrend ist. Im Titel wird gefragt: „Wirklich dauerhaft löschen?“ für die ausgewählten Kontakte. Für die Option, die das direkt tun würde, ist die Auswahl mit „Sie haben mich darum gebeten und ich muss Datenschutzgesetze wie die DSGVO/CCPA einhalten“ beschriftet, was für euch vielleicht nicht zutrifft. Wenn ihr den Kontakt nur aus anderen Gründen entfernen möchten, könnte es also passieren, dass ihr stattdessen „Ich möchte meine Zielgruppe bereinigen“ auswählen und dann auf „Weiter zum Archiv“ klickt:
Der verwirrende Archivieren-Dialog
Da ihr den Kontakt ja eigentlich löschen wollten, bringt euch der Dialog „Kontakte archivieren“ nicht wirklich weiter. Um zum gewünschten Dialog zu kommen, müsst ihr unter rechts auf den grauen Button „Stattdessen dauerhaft löschen“ klicken:
Den Kontakt endlich löschen!
Wenn ihr es bis hierher geschafft habt, entweder direkt oder „über den falschen Dialog“, stehen ihr nun vor der größten Herausforderung überhaupt. Ihr müsst „DAUERHAFT LÖSCHEN“ in das Eingabefeld eintippen. Wenn ihr, genau wie ich, zu faul seid, können ihr den Text auch markieren und per Drag-and-Drop in das Eingabefeld ziehen. Jetzt wird endlich der rote Button „Dauerhaft löschen“ aktiviert. Nach einem Klick auf den Button ist der Kontakt dann wirklich gelöscht.
Ihr wollt lieber Video-Tutorial? Bitte sehr!
Wie bereits erwähnt, ist dies der erste Blogbeitrag, der auch als Video verfügbar ist. Ihr könnt es euch auf YouTube ansehen. Auch wenn ich ein großer Fan von „selbst gehosteten Inhalten“ bin, muss ich auch realistisch sein und mir eingestehen, dass Videos auf Streaming-Plattformen leichter zu finden sind.
Da dies mein erstes Video dieser Art ist, würde ich mich sehr freuen, wenn ihr es euch anseht und mir Feedback geben würdet. Es ist wirklich kurz und versucht, nur das Nötigste zu erklären, ohne eine große Einleitung. Wenn ihr bereit wärt, meinen neuen Kanal zu abonnieren, wäre das auch toll und würde mir helfen, etwas mehr Sichtbarkeit zu bekommen. Aber ihr könnt euch das Video euch direkt hier oder auf YouTube ansehen:
Was hat euch besser gefallen? War die Erklärung mit Text und Bildern gut genug? Oder bevorzugt ihr solche Inhalte im Videoformat, damit ihr die Klicks, die ihr machen müsst, leichter nachvollziehen könnt?
Die Screenshots in diesem Blogbeitrag wurden alle von der Videodatei gemacht, damit sie genau denen entsprechen, die ihr im Video seht.
Kommentare zum bevorzugten Format können ihr unter diesem Blogeintrag hinterlassen. Wenn ihr allgemeines Feedback zum Video geben möchtet, kommentieren gerne stattdessen auf YouTube.
Vor zwei Wochen habe ich den Blogbeitrag zum 16. Geburtstag meiner Arbeit mit und Bloggen über WordPress geschrieben. Man könnte also meinen, dass ich nach einer so langen Zeit alles in WordPress gesehen habe, vor allem all die „alten Sachen“. Aber ihr ahnt nicht, wie viel es da gibt!
Diese Woche habe ich ein Stück Code gefunden, das mich wirklich überrascht hat. Ich wollte das in einem Blogbeitrag behandeln, habe aber vergessen, es aufzuschreiben. Während ich versucht habe, diesen Code wiederzufinden, habe ich etwas noch Erstaunlicheres gefunden, das ich heute behandeln möchte.
Der Papierkorb als „sicherer Ort“
Wir alle machen das. Wenn wir mit einem Inhalt nicht zufrieden sind, verschieben wir ihn in den Papierkorb. Die meisten Desktop-Betriebssysteme haben auch einen Papierkorb. Bei mir sind gerade nur drei Dateien drin, die alle in den letzten zwei Wochen gelöscht wurden. Als ich noch Windows als tägliches Betriebssystem genutzt habe, konnte es gut und gerne auch Hunderte von Dateien sein, die manchmal mehrere GB Speicherplatz verschwendeten haben. Meisten war es auch sicher, einfach den Papierkorb zu leeren, aber in manchen Fällen hat man dann doch mal darin Dateien gefunden, die man eigentlich gar nicht löschen wollte. Es war also beruhigend zu wissen, dass der Papierkorb in Windows (und auch in vielen anderen Systemen) nicht automatisch gelöscht wird. Das ist in WordPress nicht der Fall! 😮
Dinge in WordPress in den Papierkorb legen
Es gibt zwei Dinge, die ihr in den Papierkorb legen können: Beiträge/Seiten (und andere Inhaltstypen) und Kommentare. Aber wusstest du auch, dass sie nach 30 Tagen gelöscht werden? Ich habe das nicht gewusst!
Die Konstante EMPTY_TRASH_DAYS
Bei der Suche nach dem Code für dieses andere Thema bin ich zufällig auf die Konstante EMPTY_TRASH_DAYS gestoßen. Sie hat einen Standardwert von 30. Das bedeutet, dass jeder Beitrag oder Kommentar, der vor mindestens 30 Tagen gelöscht wurde, automatisch 30 Tage später gelöscht wird. Dies geschieht durch das WP-Cron Event wp_scheduled_delete, das täglich ausgeführt wird.
Wenn ihr die Konstante auf 0 (oder einen anderen „falschen“ Wert) setzt, deaktivieren ihr damit den Papierkorb im Grunde vollständig. Alle „In Papierkorb legen“ Links im Backend werden zu „Endgültig löschen“ Links.
Sobald ihr einen Beitrag oder einen Kommentar in den Papierkorb legt, fügt WordPress zwei Meta-Daten hinzu. Der erste ist wp_trash_meta_time, ein Zeitstempel, wann der Eintrag in den Papierkorb gelegt. Der zweite ist _wp_trash_meta_status, der den vorherigen Status des Beitrags oder Kommentars speichert. Denn wenn sie sich im Papierkorb befinden, ist ihr Status trash und mit diesem Wert kann WordPress den vorherigen Status wiederherstellen, wenn ihr einen Eintrag aus dem Papierkorb wiederherstellt.
Fazit
Wenn ihr euren Papierkorb nutzen wollt, um Dinge vorübergehen „aus dem Blickfeld zu räumen“, sollten ihr euch darüber bewusst sein, dass sie nach 30 Tagen gelöscht werden. Wenn ihr diese Zeitspanne verlängern wollt, definieren einfach die Konstante EMPTY_TRASH_DAYS in eurer wp-config.php mit einem (viel) höheren Wert.
Habt diese Konstante schon gekannt, bevor ihr diesen Blogbeitrag gelesen habt? Falls ja, habt ihr sie jemals benutzt? Und wenn ja, habt ihr die Zeit verlängert oder verkürzt, oder habt ihr sie benutzt, um den Papierkorb komplett zu deaktivieren?
Für einige von uns war der 16. Geburtstag schon etwas besonders. Endlich konnte man in Filme ab 16 gehen und auch alleine bis 24 Uhr im Kino sein. Andere haben sich den Traum eines Motorrad-Führerscheins erfüllt. Auch mein Blog wird heute 16 Jahre alt und es beginnt ein neues Kapitel.
Schließung von weiteren Plugins in Aussicht
Noch im letzten Jahr hatte ich ja gehofft, dass ich das Plugin Language Fallback endlich schließen kann. Aber leider ist Preferred Languages noch nicht im Core delandet. In die Sache wird aber durch die nun längeren Veröffentlichungszyklen etwas Bewegung kommen, denn das Plugin hat nun gute Chancen, in einer der nächsten Hauptversionen endlich enthalten zu sein. Wichtige Vorarbeiten zur notwendigen Performance-Optimierung sind bereits in WordPress 6.5 umgesetzt worden.
Auf dem WordCamp Leipzig habe ich außerdem erfahren, dass eine Schnittstelle für mein Plugin Embeds for ProvenExpert bald nicht mehr verfügbar sein wird. Ich bin darüber aber nicht so traurig, denn es gibt mittlerweile ein offizielles Plugin von ProvenExpert, das außerdem Blöcke implementiert. Meines bietet aktuell nur Widgets an und ich spare mir damit die Arbeit am Branch, der die Blöcke umsetzt. Ich werde aber natürlich versuchen einen „Migrationspfad“ für alle umzusetzen, die aktuell noch mein Plugin verwenden, damit sie möglichst ohne Probleme umsteigen können.
Die Zahlen für das vergangene Jahr
Die Besuche auf der deutschen Seite sind leider auch in den vergangen 12 Monaten stärker zurückgegangen. Der Rückgang betrug etwa 23,1% und ich gehe stark davon aus, dass dies mit der verstärkten Nutzung von AI zusammenhängt. Denn viele finden Lösungen zu Problemen mittlerweile eher direkt in den diversen AI-Tools, als über klassische Suchmaschinen. In einem Vergleichszeitraum von Februar bis Juni (weiter zurück geht es leider nicht), zeigt die Google Search Console einen Rückgang der Klickzahlen von knapp 46% an. Die Impressionen gingen aber nur um knapp 11% zurück.
Es gibt aber auch eine erfreuliche Zahl: die Aufenthaltsdauer auf der Website ist um 300% gestiegen! Es kommen also weniger auf die Seite, aber diese lesen dann auch viel länger auf meinem Blog. Es ist also mehr „qualitativer Traffic“. Am Ende sind mir aber die Zahlen nicht so super wichtig, denn ich verfolge mit der Seite ja keinen kommerziellen Zweck. Ich freue mich einfach, wenn ich anderen weiterhelfen kann und ganz besonders, wenn mir dann jemand auch einen Kommentar hinterlässt. Es gab aber leider nur 12 Kommentare, 4 davon von mir. Ihr dürft das gerne alle direkt mal unter diesem Beitrag ändern. 😉
Auf dem englischen Blog sind die Besuche übrigens um 12% gestiegen und die Verweildauer ebenfalls um 240%. Für mehr Zahlen müsst ihr aber die englische Version dieses Beitrags lesen.
Auf den ersten beiden Plätzen gab es keine Änderungen zum letzten Jahr. Allerdings ist der drittplatzierte Beitrag auf Rang 5 gerutscht und stattdessen hat es ein Beitrag von 2016 auf das Treppchen geschafft. Es ist schön zu sehen, dass das Thema SVG endlich so langsam die notwendige Bedeutung bekommt.
Für Platz 2 gab es aber kurz vor dem Jahreswechsel ein inhaltliches Update. Da der Beitrag noch immer so erfolgreich ist, er bisher aber noch nicht ins Englische übersetzt war, habe ich das nachgeholt. Bei der Gelegenheit habe ich den Inhalt auch noch einmal mit der aktuellen Version von WordPress und Contact Form 7 getestet und alle Screenshots aktualisiert. Auch eine weitere Neuigkeit betrifft diesen Beitrag, aber dazu gleich mehr.
Classic Themes funktionieren auch 2025 noch
Noch vor 12 Monaten war ich optimistisch, dass mein Projekt zur Neuimplementierung des aktuellen Themes als Block Theme erfolgreich sein würde. Aber knapp 2 Wochen später musste ich mir eingestehen, dass das Ziel nicht in der gewünschten Form erreichbar ist. Im November habe ich das Projekt dann erst einmal abgebrochen. In den vier Monaten zwischen diesen beiden Beiträgen habe ich auch sehr viel Zeit in das Theme investiert und das Bloggen vernachlässigen müssen.
Ich habe noch immer vor, das aktuelle Theme zu ersetzen, aber eben nicht mehr mit der gleichen Zielsetzung. Den neuen Versuch werde ich dann auch wieder mit Beiträgen begleiten, aber vielleicht auch noch anders.
Neues Projekt: ergänzende Videos zum Blog
Schon oft stand ich vor dem Problem, dass ich zu einem Thema einen Blogbeitrag schreiben wollte, es mir aber sehr schwerfiel, diesen in Worten, Codebeispielen und Bildern zu verfassen. Manche Dinge sind einfach zu komplex, um sie gut in dieser Form zu erklären, gerade dann, wenn man viele Schritte benötigt und nicht unbedingt 20 Screenshots von jedem einzelnen dieser Schritte haben möchte. Daher möchte ich mich an das Projekt wagen, solche Themen in einem Video zu erklären. Ich habe bereits einen YouTube Channel und auch schon mal zum Test ein Video produziert. Und nun kommen wir auch zum zweitplatzierten Beitrag zurück, denn dieser eignet sich hier wohl sehr gut, dazu auch noch ein Video aufzuzeichnen. Sobald es fertig ist, werde ich es in einem eigenen Beitrag vorstellen und wohl im Originalbeitrag einbinden.
Fazit
Einige Ziele konnte ich erreichen, andere nicht. Meine 26 Beiträge habe ich nur durch den Adventskalender im Dezember geschafft, aber es macht mir weiterhin viel Freude, neue Beiträge mit euch zu teilen. Wenn das mit den Videos auch gut funktioniert, könnt ihr euch in Zukunft auf ganz neuen Themen freuen, an die ich mich bisher noch nicht gewagt habe.
Am Ende muss natürlich auch noch ein Video kommen. Letztes Jahr habe ich die Ankündigung zum WordCamp Europe mit euch geteilt, aber es macht natürlich mehr Sinn, mein erstes YouTube Video hier zu präsentieren. Vielleicht wollt ihr mir ja einen Gefallen tun und den Channel gleich mal abonnieren. Das könnte mich etwas mehr dazu motivieren, das nächste Video noch schneller aufzuzeichnen 😉
