WordPress und Abwärtskompatibilität

Wenn man Entwickler nach den Gründen fragt, weshalb WordPress um so viel erfolgreicher ist als andere Content Management Systeme wie Drupal, Joomla und so weiter, so fällt unweigerlich der Begriff der Abwärtskompatibilität. Seit den Anfängen von WordPress haben die Entwickler darauf geachtet, dass die Funktionalität von einer Version zur nächsten nicht zusammenbricht.

Ein Beispiel dafür sind veraltete Funktionen: Funktionen, welche in einer Version nicht mehr benötigt werden, werden nicht einfach aus WordPress entfernt sondern über mehrere Versionen als veraltet markiert und weiter mitgeführt, bis man sie schließlich entfernt. Entwickler können sich auf dieser Seite lange im voraus informieren, um diese Funktionen in den eigenen Plugins rechtzeitig zu ersetzen. Und auch mit WP_DEBUG auf true werden sie darüber informiert.

Ein weiteres Beispiel ist die Datenbank. So findet die Tabelle wp_links im WordPress Core zwar keine Anwendung mehr, wird jedoch weiterhin mitgeführt. Es mag zunächst simpel klingen: WordPress benötigt die Tabelle in der aktuellen Version nicht mehr, also wird sie rausgeschmissen. Da jedoch niemand weiß, was einzelne Installationen in dieser Tabelle womöglich für Informationen gespeichert haben und wie diese genutzt werden, würde ein solches Vorgehen drastische Konsequenzen haben. Würde man die Tabelle einfach rausschmeißen, würden Administratoren so quasi Inhalte verlieren, welche sie mühsam aufgebaut haben. Statt also aus Gründen einer konsistenten Struktur diese Tabelle zu entfernen führt WordPress sie weiter mit.

Damit zusammenhängend: Hat sich schon einmal jemand gefragt, warum die Post ID in der Datenbanktabelle wp_term_relationship object_id heißt und nicht konsistent wie in allen anderen Tabellen auch post_id? Auch Spalten aus der wp_links können hier verknüpft sein, weshalb man sich für object_id entschied, da es sich nicht nur um Post IDs handelt. Doch, obwohl es sich mittlerweile eigentlich nur noch um Post IDs handelt wird die Spalte nach wie vor object_id genannt. Warum? Wie viele Plugins gibt es, die – auch wenn sie nur die Terms eines Posts oder ähnliches abfragen – einen direkten SQL-Zugriff unternehmen und in ihrer Syntax object_id verwenden? Alle diese Plugins würden zusammenbrechen. WordPress hat eine Geschichte und man kann sie in diesen Inkonsistenzen lesen.

Auch innerhalb überarbeiteter Funktion finden sich Beispiele, wie WordPress diese Philosophie umsetzt. Betrachten wir beispielsweise den zweiten Parameter von load_plugin_textdomain(), welcher immer mit false angegeben wird. Bis zur Version 2.7 wurde hier der relative Pfad angegeben, in welchem Verzeichnis sich die Übersetzungsdateien befinden. Da man heute nicht mehr den relativen Pfad ausgehend von ABSPATH, sondern ausgehend von WP_PLUGIN_DIR bestimmt, ist dieser Parameter veraltet und der dritte Parameter übergibt den relativen Pfad. Dennoch wird der Parameter weiter mitgeführt und muss von Entwicklern standardmäßig mit false übergeben werden. Der Grund dafür ist einfach: Ältere Plugins verwenden diesen Parameter vielleicht noch und würde man ihn entfernen würden diese Plugins nicht mehr funktionieren.

Aus Anwendersicht mag sich das Ganze etwas anders darstellen. Mit jedem Update fluten die Foren mit Fragen wie „Habe gerade auf WordPress XY aktualisiert und komme nicht mehr in den Admin/sehe keine Bilder mehr/die Seite ist nicht mehr erreichbar“. Alle diese Fragen zeigen zwei Dinge:

1. Wie wichtig Abwärtskompatibilität ist und
2. wie schwierig es tatsächlich ist, diese in einer Umgebung wie WordPress zu realisieren.

Unter Entwicklern ist Abwärtskompatibilität hingegen ein zweischneidiges Schwert, denn es bläst den Code – für manche unverhältnismäßig – auf. Bedenkt man jedoch die Debatte um Sicherheitslücken und die Notwendigkeit, das System immer auf dem aktuellsten Stand zu halten kommen die meisten zu dem Schluss: an Abwärtskompatibilität führt kein Weg vorbei. Alles andere würde gerade für kleine Blog- und Shopbetreiber zu einem unverhältnismäßig höherem Aufwand führen oder aber – bedenkt man, dass ca. 20 Prozent der Internetseiten auf WordPress laufen – zu einem unsichereren Internet.

Aber: Ist Abwärtskompatibilität nur ein Thema für die Core-Entwickler oder betrifft es auch uns, die Theme- und Pluginentwickler? Natürlich betrifft das auch uns. Auch das Aktualisieren von Plugins muss ein sicherer Vorgang sein, bei dem nach Möglichkeit nichts kaputt geht.^* In seiner Rede auf der Loopconf 2015 spricht Pippin Williamson, Autor von Easy Digital Downloads, deshalb ausführlich über Abwärtskompatibilität und was sie für uns Entwickler bedeutet. Er zeigt auch an Beispielen, wie schwierig es manchmal ist, diese zu gewährleisten und warum wir dennoch unser Bestes geben sollten. Ein sehr guter Vortrag, der jedem WordPress Entwickler ans Herz gelegt sei:

Youtube

Click the button below to load the content from Youtube.

Always allow Youtube

*) Ich muss mich hier allerdings noch an der eigenen Nase packen und dies für eines meiner Plugins tatsächlich auch umsetzen. Doch das mach ich jetzt nicht hier in diesem Post. Er dient mir auch als Mahnung 🙂