Seit gut 10 Jahren setzte ich WordPress ein. Angefangen als Nutzer, habe ich mittlerweile auch eine ganze Menge kleiner Plugins für meine Seiten geschrieben. Hier möchte ich meine Erfahrungen teilen.
Wer an seiner Website herumbasteln möchte, sollte das am besten in einer lokalen Entwicklungsumgebung machen und nicht auf dem Live-Server. Das gilt auch für WordPress!
Am besten funktioniert das, indem man eine Kopie der echten Website erstellt. Entscheidend ist hier vor allem die Datenbank. Legt man davon lokal eine Kopie an, hat man direkt den passenden Content an dem man z.B. das neue Theme ausprobieren kann.
Weiterlesen „WP CLI: Backup & Import in einem Befehl“WordPress bietet für Custom Taxonomies die Möglichkeit diese hierarchische anzuordnen. Das heißt, man kann für jeden Term wie bei einer Kategorie ein übergeordneten Term festlegen.
Wir nutzen bei Travel-Dealz hierarchische Taxonomies für Reiseziele. Und von diesen haben wir über 1.000 angelegt. Diese sind nach Kontinent → Land → Stadt angeordnet.
WordPress war ursprünglich dafür gedacht ein digitales Tagebuch, einen Blog, zu führen. Doch davon sind die meisten mit WordPress betreibenen Seiten weit entfernt. An diversen Stellen in WordPress begegnet man diesem ursprünglichen Gedanken. Besonders in den Standardeinstellunen für Permalinks. Hier wird als Standardeinstellung die URL-Struktur für einen Beitrag aus dem Datum mit Jahr, Monat, Tag und dem Beitragstitel z.B. /2020/02/20/beispielbeitrag/ generiert. Perfekt für ein Tagebuch aber schlecht für eine Website wo man regelmäßig Änderungen an seinem Inhalt vornimmt um diesen aktuell zu halten.
Bei einem Seitenaufruf von einer WordPress-Seite wird von Haus aus bei jedem Aufruf PHP ausgeführt, die Datenbank abgefragt und schlussendlich die Antwort als HTML an den Nutzer gesendet. Egal, ob sich etwas an der Seite seit dem letzten Seitenaufruf geändert hat oder nicht.
Wenn die eigene Website nur eine Handvoll Aufrufe pro Tag hat, ist das kein Problem. Hat man aber plötzlich sehr viele Aufrufe in einer kurzen Zeit, ist der Server schnell überfordert und wird sehr schnell 503 Service Unavailable Antworten senden.
Weiterlesen „WordPress Performance Hack: Cache direkt vom Webserver ausliefern lassen“Ich betreue seit ein paar Monaten die Website für den Tanzclub Düsseldorf e.V. Vor meiner Zeit wurde dort Drupal eingesetzt und natürlich nach der Installation nie wieder geupdated und auch keine automatischen Backups erstellt. Was auf Dauert dann garantiert irgendwann passiert: Die Seite wurde gehackt.
Das sollte sich nicht wiederholen und neben regelmäßigen Backups war mir eins besonders wichtig: Automatische Updates von WordPress aber auch der verwendeten Plugins & Themes.
Weiterlesen „Plugin Tipp: Automatische WordPress-Updates mit Benachrichtigungen“Nicht jeder Programmierer denkt bei der Entwicklung eines Plugin (aber auch Themes) daran, ressourcenschonend mit den eingebunden Scripts & Styles umzugehen. Statt die Assets nur bei Seitenaufrufen zu laden, wo sie auch wirklich verwendet werden, werden häufig alle Datein bei jedem Seitenaufruf geladen. Das ist nicht nur schlecht für die Performance beim Leser sondern kostet auch einfach Resourcen.
Ein gutes Beispiel ist das beliebte Contact Form 7 Plugin (es gibt bessere Kontakformular-Plugins, ich bin z.B. ein Fan von HTML Forms, aber darum soll es hier nicht gehen). Installiert und aktiviert lädt es bei jedem Seitenaufruf 1,61 KB Stylesheet und 14,10 KB (+94,60 KB jQuery als Abhängigkeit) Javascript. Ein Kontaktformular haben die meisten Websites aber nur unter /kontakt/ eingebunden. Es ist also zu 99% unnötig, dafür Bandbreite und Rechenzeit zu verschwenden.
Viel geschickter wäre es, Style & Scripts nur zu laden, wenn bei einem Seitenaufruf auch der Shortcode für ein Formular [contact-form-7] eingebunden ist.
Der Button-Block von Gutenberg ist sehr praktisch um Call to Action-Buttons zu erstellen. Allerdings wird der hinterlegte Link, wie alle Links in Gutenberg, standardmäßig im selben Tab geöffnet. Standardmäßig hätte ich aber gerne den Button in einem neuen Tab geöffnet.
Weiterlesen „Gutenberg-Button standardmäßig im neuen Tab öffnen lassen“Der Button-Block in Gutenberg ist wirklich sehr praktisch. Keine Shortcodes mehr um eigentlich einem <a> nur eine Klasse zu verpassen. Leider hat er meiner Meinung einen riesigen Konstruktionsfehler (bisher): Der Link wird immer im selben Tab geöffnet. Möchte man den Besucher über den Button zu einer anderen Website leiten und dabei die Seite in einem neuen Tab öffnen targt="_blank", geht das bisher nicht. Man kann kein Link Target angeben. Alle Button-Links werden im selben Tab geöffnet.