Die größten WordPress-Verbrechen

Vergangenen Mittwoch war ich spontan (sehr spontan!) Teilnehmer des ersten Online-Meetups des WordPress-Meetups Stuttgart. Simon Kraft hatte mich dazu kurz vor der Veranstaltung eingeladen. Und da mich das Thema interessierte, habe ich ebenso spontan zugesagt.

Wir haben dann in einem lockeren Gespräch zusammen erzählt, welche „Verbrechen“ wir schon in und an WordPress-Installationen vorgefunden haben. Es ging also nicht darum, was WordPress selbst falsch macht (dazu könnte ich auch mal was schreiben), sondern eher darum, wie Seitenbetreiber WordPress (nach unserer Auffassung) „falsch“ benutzt haben. Typische Fehler bei der Benutzung von WordPress, die am Sinn von WordPress vorbei gehen, es ggf. sogar schwieriger machen, mit dem System zu arbeiten.

Was bietet sich also mehr an, als diese Erfahrungen in einem Blogbeitrag nochmal niederzuschreiben. Diese Liste ist natürlich nicht vollständig. Ich befürchte sogar, dass ich noch nicht mal alle Aspekte unseres Gesprächs vom Mittwoch erfolgreich verschriftlicht habe. Wer aber Interesse am Gespräch hat, kann sich tatsächlich auch eine Aufzeichnung davon ansehen.

Aber fangen wir an mit den „größten WordPress-Verbrechen“:

Mehrere Plugins für denselben Zweck installieren

Es scheint offensichtlich eines der größten Verbrechen zu sein, mehrere Plugins für denselben Zweck zu installieren. Denn immer wieder im Laufe des Abends kamen wir aus unterschiedlichen Richtungen und für unterschiedliche Zwecke auf dieses Thema zu sprechen.

Ganz allgemein werden sich mehrere Plugins für denselben Zweck in der Regel gegenseitig stören und behindern, die Wirkung gegenseitig aufheben oder doch zumindest in der Benutzung für Probleme und Verwirrung sorgen.

Performance / Caching

In der Community schon zum geflügelten Wort geworden ist der Satz „Deine Seite ist so langsam, sie benötigt zwei Caching-Plugins.“ Um es kurz zu machen: das hilft nichts. 😉 Hierbei muss man, insbesondere beim Thema Performance, jedoch die Zwecke der unterschiedlichen Plugins unterscheiden. Im Bereich Performance kann es Sinn machen, mehrere Plugins zu installieren, die aber jeweils andere Aufgaben durchführen: Bild-Optimierung, Erzeugen von statischen Cache-Dateien, Optimierung von JavaScript- und CSS-Einbindung. Dafür kann man (muss aber nicht) verschiedene Plugins einsetzen. Für dieselbe Aufgabe zweierlei Plugins zu installieren, ist aber sinnlos.

Ein gutes Beispiel ist auch die automatische Bildbearbeitung mittels Plugin (zum Beispiel Bildoptimierung). Mehrere dieser Plugins können sogar zu argen Problemen zum Beispiel beim Upload einer Datei führen. Durch die Ausführung mehrerer (gleicher) Optimierungsschritte hintereinander kann hier die maximale PHP-Ausführungszeit des Webspaces erreicht werden und so der Upload einer Bilddatei gänzlich scheitern.

Backup

Mag es beim Thema Performance noch Sonderfälle geben, bei denen die Installation mehrerer Plugins Sinn machen kann, ist dies beim Thema Backup definitiv nicht der Fall. Sind mehrere Backup-Plugins installiert und konfiguriert, besteht die Gefahr, dass die Backup-Plugins die lokal gespeicherten Backups des jeweils anderen Plugins mit in die eigenen Backups einbeziehen und diese dadurch unnötig groß werden. Geschieht dies bei beiden Plugins, schaukeln sich diese dadurch hoch, die Backup-Datei wird jeweils immer größer. Es besteht dann irgendwann die Gefahr, dass selbst kleine Websites riesige Backup-Dateien haben und die Backup-Vorgänge aufgrund von Limitationen des Webspaces (Speicherplatz, Limit Ausführungszeit) nicht mehr erfolgreich durchgeführt werden können.

Die eigenen im Webspace liegenden Backup-Dateien werden von einem Backup-Plugin in der Regel beim Erstellen eines weiteren Backups ausgenommen, nur gelingt dies eben nicht mit den Backup-Dateien anderer Plugins.

Ganz abgesehen davon, sollten Backup-Dateien übrigens gar nicht lokal im Webspace der Website liegen, sondern auf einem anderen Backup-Server liegen. Das erhöht Verfügbarkeit und Sicherheit. Aber selbst dann sind zwei Backup-Plugins nicht sinnvoll. 🙂

Sicherheit

Ein ernsthaftes Problem kann auch bei der Benutzung mehrerer Sicherheitsplugins entstehen. Schreibt eines davon zum Beispiel Sicherheitsregeln in die htaccess-Datei und wird diese Datei vom anderen Plugin auf unberechtigte Schreibzugriffe überwacht, kann es dazu führen, dass die Änderungen automatisch rückgängig gemacht werden oder die Datei blockiert wird und das erste Sicherheitsplugin einen Fehler meldet. Im schlechtesten Fall setzt das zweite Sicherheitsplugin die htaccess in Quarantäne (blockiert Schreib- und Leserechte) und legt so die komplette Website lahm.

Die Anzahl der installierten Sicherheitsplugins sagt daher nichts über die Sicherheit des Systems aus. Im Gegenteil: umso erfahrener der Website-Betreiber, desto weniger sind in der Regel Plugins für die Herstellung der Website-Sicherheit notwendig. Auf meinen Installationen ist in der Regel „nur“ eine Web Application Firewall (Ninja Firewall) installiert. Deutlich wird auch, dass es oft besser ist, Plugins mit spezifischen Einzelfunktionen zu nutzen, als große Plugin-Suiten mit vielfältigen Funktionsmöglichkeiten.

Formulare

Wir haben beim Online-Meetup auch über Formulare gesprochen. Aber ernsthaft: machen mehrere Formularplugins gleichzeitig denn Ärger? Aus meiner Erfahrung tatsächlich nicht, gegenseitig in die Quere kommen sie sich nicht. Aber macht es Sinn, mehrere Formularplugins gleichzeitig zu nutzen? Häufig passiert dies, wenn ein neuer Dienstleister etwas an der Website ändern soll. Jeder Dienstleister und jede Agentur hat eigene Favoriten, wenn es um Plugins geht, natürlich auch für Formulare. Und so kommt es, dass jeder für die gestellte Aufgabe dann das eigene Lieblings-Plugin installiert und nutzt. Im Falle von Formularen werden die bisherigen, weiter in Benutzung befindlichen Formulare natürlich nicht umgestellt auf das neue Plugin und so bleibt es bei einer undurchsichtigen Menge an Formular-Plugins: welches Formular wurde womit gebaut? Wo ist welches Formular eingebunden?

Zugegeben: häufig liegt es natürlich auch am Kunden, der ggf. nicht die Lust oder das Budget hat, auch alle anderen bereits existierenden Formulare auf das neue Plugin umzubauen (oder am Dienstleister, der keine Lust hat, seine bekannten Bedienpfade zu verlassen).

Erschwerend kommt natürlich hinzu, dass ggf. einzelne Formularplugins die gewünschten Funktionen für das neue Formular nicht unterstützen oder nur mit kostenpflichtigen Erweiterungen.

Shop-Funktionen mit WooCommerce

Wer einen Shop mit WooCommerce betreibt, befindet sich nochmals in einem ganz anderen Plugin-Universum. Hier gibt es extrem viele Zusatzplugins, um weitere Funktionen nachzurüsten. Ein Klassiker in Deutschland sind die Plugins „German Market“ und „Germanized“, die beide Funktionen zur Erfüllung der rechtlichen Anforderungen an Shops in Deutschland nachrüsten. Ich darf an dieser Stelle aber sagen: beide Plugins gleichzeitig einzusetzen, macht den Shop dadurch nicht noch rechtssicherer. Im Gegenteil: da beide Plugins in die WooCommerce-Templates eingreifen und zum Teil deutliche Änderungen vornehmen, ist die Kombination von beiden Plugins ggf. sogar dafür verantwortlich, dass an manchen Stellen des Shops nichts so funktioniert wie es soll und dadurch die Rechtssicherheit definitiv nicht gegeben ist.

Aber auch unabhängig von diesen beiden Plugins kann der Plugin-Einsatz bei WooCommerce Probleme verursachen, selbst wenn die installierten WooCommerce-Plugins gar nicht offensichtlich zum gleichen Zweck installiert sind. Da all diese Plugins in das Template-System von WooCommerce eingreifen und/oder über Hooks eigene Inhalte einfügen, können auch zwei Plugins für eigentlich unterschiedliche Zwecke im Shop sich gegenseitig ihre Änderungen überschreiben.

Weniger Plugins ist meist mehr

Nachdem wir also diverse Bereiche beleuchtet haben, in denen mehrere Plugins zum gleichen Zweck eigentlich immer für Ärger sorgen, sollte der Grundtenor klar sein: weniger ist mehr. Das gilt sowohl für Plugins des gleichen Zwecks, also auch generell. Je weniger Plugins installiert sind, desto weniger können sich diese, unabhängig von ihrem Zweck, in die Quere kommen.

Missbräuchliche Nutzung von Themes

Kommen wir nun zu den anderen besprochenen Themen des Online-Meetups, die nichts mit der Nutzung mehrerer Plugins zum selben Zwecke zu tun haben. 🙂

Ein weiteres Themengebiet in unserem Gespräch befasste sich mit Themes. Auch hier gibt es verschiedene Stolpersteine.

Überschreiben von Themes ohne Child-Theme

Häufig, aber nicht gerne gesehen, ist die „Unart“, Änderungen direkt im Theme-Code vorzunehmen ohne dafür ein Child-Theme zu nutzen. Dabei geht es häufig um funktionale Änderungen oder das Ausblenden von bestimmten Inhaltsbereichen. Statt dies aber über die wunderbare Möglichkeit eines Child-Themes zu machen, werden diese Änderungen direkt im Code des Original-Themes vorgenommen. Die Konsequenz ist, dass bei einem Update des Themes diese Änderungen wieder verloren gehen. Unterlässt man stattdessen das Theme-Update, verpasst man aber Fehlerkorrekturen, Sicherheitsupdates und (je nach Theme) auch Updates der mitgelieferten Plugins.

Sprachanpassungen im Theme

Gerne genutzt werden Theme-Anpassungen auch für die Übersetzung oder Änderung von Texten im Theme. Hierfür ist dann sogar noch nicht mal ein Child-Theme notwendig. Änderungen an den Texten sind in der Regel (bei ordentlichen Themes, die entsprechend vorbereitet sind) über Sprachdateien problemlos möglich, ohne in den Themecode eingreifen zu müssen. Die Sprachdateien können sogar ganz einfach mit einem Plugin wie „Loco Translate“ im WordPress-Backend bearbeitet werden.

Inhalte in Theme-Dateien

Die Steigerung dieser „Verbrechen“ ist jedoch die missbräuchliche Nutzung der Theme-Dateien dafür, Inhalte dort direkt einzubinden anstatt die Möglichkeiten des CMS zu nutzen. Damit wird die Daseinsberechtigung des CMS konterkariert, denn genau für die Inhaltsaufbereitung wird ja ein Redaktionssystem wie WordPress genutzt. Es macht keinen Sinn, Inhalte in die Theme-Dateien auszulagern.

Hintergrund mag sein, dass mit den zur Verfügung stehenden Mitteln eine Umsetzung auf die gewünschte Art und Weise nicht möglich ist oder ein entsprechender Weg dorthin nicht bekannt ist. Jedoch gibt es im WordPress-Universum so viele verschiedene Lösungsansätze für die diversesten Probleme, dass sich in aller Regel auch für das eigene Darstellungsproblem immer eine Lösung finden lässt.

Übrigens genauso schlimm, aber im Meetup gar nicht besprochen, ist es, nicht nur Inhalte in den Theme-Code zu packen, sondern Funktionalitäten dort fest einzuprogrammieren und dabei den „WordPress-Weg“ zu verlassen. WordPress bietet ungemein viele eigene Funktionen an, die genutzt werden können, um zum Beispiel Datenbankabfragen durchzuführen. Jedoch gibt es immer wieder Fälle, in denen Entwickler nicht die WordPress-eigenen Funktionen nutzen, sondern mit manuellen Wegen die Problemlösung realisieren.

Dies führt dann schon mal dazu, dass andere Plugins, die auch in das System eingreifen (wollen), nicht kompatibel sind. So ist es mir bereits geschehen, dass ein Theme-Autor für ein im Theme fest einprogrammiertes Kontaktformular beim Absenden des Formulars nicht die wordpress-eigenen E-Mail-Funktionen genutzt hat. Dies führte dazu, dass ein Plugin, welches zur Konfiguration eines SMTP-Versands von E-Mails gedacht war, hier keine Auswirkungen hatte. Dadurch konnten die Mails dieses Kontaktformulars nicht korrekt versendet werden und landeten regelmäßig im Spam.

Mißbräuchliche Nutzung von Pagebuildern

Inhalte in Pagebuilder-Modulen als HTML

Was mit Themes geht (siehe oben), geht auch mit Pagebuildern. Pagebuilder sind per se nicht bei allen WordPress-Professionals beliebt. Hauptkritikpunkt ist der sogenannte Lock-in-Effekt, der besagt, dass bei einer Nutzung eines Pagebuilders in aller Regel kein Wechsel zu einem anderen Pagebuilder möglich ist, ohne alle Inhalte neu anlegen zu müssen.

Wird aber ein Pagebuilder genutzt, sollten die Inhalte auch mit den dadurch zur Verfügung stehenden Mitteln aufbereitet werden. Immer wieder finde ich aber Websites, die innerhalb einer mit einem Pagebuilder gebauten Seite ein Textmodul integriert haben, welches individuelles HTML mit eigenem CSS enthält, um die gewünschte Darstellung zu erreichen. Dies ist genauso ungünstig, wie die Einbindung von HTML-Content in Theme-Dateien. Wer einen Pagebuilder nutzt, sollte auch alle Inhalte damit aufbauen.

Mehrere Pagebuilder

Dies impliziert auch, dass man idealerweise nur einen Pagebuilder auf einer Website nutzt (siehe auch den langen Abschnitt am Anfang dieses Artikels 😉 ). Immer häufiger sehe ich Websites, die für verschiedene Unterseiten mit verschiedenen gleichzeitig installierten Pagebuildern arbeiten und so das Chaos auf der Website nur noch erhöhen. Eine gute Pflege einer solchen Website ist dann quasi nicht mehr möglich, da Inhalte zwischen Einzelseiten auch nicht mehr ausgetauscht werden können.

Einbindung von wiederholenden Elementen auf jeder Seite

Eine Website hat oft einen wiederkehrenden Kopfbereich („Header“) und einen Fußbereich („Footer“). Diese werden global im Theme definiert. Mit manchen Pagebuildern kann man diese als „Theme-Bereiche“ auch mit dem genutzten Pagebuilder erstellen.

Eine Unart ist es jedoch, diese Kopf- und Fußbereiche auf jeder einzelnen Seite jeweils einzeln zu implementieren. Dadurch müssen für Änderungen an diesen Bereichen alle Einzelseiten bearbeitet werden, was in Konsequenz dazu führen wird, dass sich die Bereiche auf Dauer auf den einzelnen Unterseiten unterscheiden und kein einheitliches Website-Bild abgeben.

Häufiger Grund dafür ist die Unkenntnis des Anwenders in Bezug auf das Theme oder den Pagebuilder und er sieht so die einzige Möglichkeit, das gewünschte Aussehen zu erreichen. Bei allem Verständnis für teilweise hohe technologische Hürden gehört eine Website-Umsetzung in dieser Art tatsächlich zu den größten „WordPress-Verbrechen“.

Updates nicht durchführen

Es mag eines der Mantras sein, die ich gerne und immer wieder erzähle, deswegen wird es aber nicht weniger wichtig: die beste Möglichkeit, seine WordPress-Installation sicher und funktionstüchtig zu erhalten ist es, regelmäßig alle zur Verfügung stehenden Updates für WordPress selbst, Plugins und Themes durchzuführen. Dabei macht es Sinn, diese Updates nicht bei allen Plugins sofort nach Veröffentlichung der neuen Version durchzuführen, sondern ein paar Tage zu warten. Bei den meisten Plugins ist ein Update in der Regel aber vollkommen problemlos. Veraltete Versionen von WordPress, Plugisn und Themes hingegen führen in aller Regel zu Kompatibilitätsproblemen, Sicherheitslücken oder schlechter Performance.

Installationen verschachteln

Auch immer wieder beliebt, aber deswegen nicht weniger schlecht ist es, WordPress-Installationen zu verschachteln. Dies bedeutet, dass zum Beispiel unter domain1.de eine WordPress-Website installiert ist und man gleichzeitig unter domain1.de/nochnewebsite eine weitere von der ersten Installation getrennte WordPress-Installation nutzen möchte. Die technisch einfachste, jedoch ungünstigste Möglichkeit dazu ist, die zweite Installation in das Unterverzeichnis „nochnewebsite“ der ersten Installation zu installieren. Dies führt in aller Regel zu vielfältigen Problemen. Zum einen gilt die htaccess-Datei der Erstinstallation auch für die Unterinstallation (mit teils ungeahnten Folgen und Problemen), zum anderen reißt dies auch Sicherheitsprobleme zwischen beiden Installationen auf. Ganz zu schweigen von Problemen beim Backup.

Perfektioniert wird dieses „Verbrechen“ nur dadurch, dass anstatt einer weiteren WordPress-Installation sogar die Installation einer anderen Software auf diese Weise durchgeführt wird. Beliebtes Beispiel ist die Statistik-Software Matomo (ehemals Piwik). Aber auch ineinandergeschachtelte Installation von WordPress in Kombination mit Joomla oder Typo3 habe ich schon gesehen.

Einzig sinnvoll ist hier die Trennung der Systeme in komplett unterschiedliche Verzeichnisse. Technisch ist dies dann am einfachsten mit Subdomains zu realisieren (nochnewebsite.domain1.de).

Fazit

Nur weil es technisch geht, ist es nicht auch gleichzeitig sinnvoll. Manchmal ist es aber gar nicht so einfach herauszufinden, was denn nun „Best Practice“, also eine übliche und gute Vorgehensweise, ist und was ein „Verbrechen“ ist. Im Meetup haben wir die Themen noch um andere Anekdoten ergänzt, aber die hauptsächlich genannten Punkte habe ich in diesem Beitrag zusammengefasst. So hoffe ich, dass mehr WordPress-Anwender in Zukunft versuchen, diese „Verbrechen“ zu vermeiden.

Kennt ihr noch andere WordPress-Verbrechen?