Field Note: Wann ich ein Plugin entferne und wann ich es behalte

Ich entscheide nicht danach, wie viele Plugins in einer WordPress-Installation stecken, sondern danach, welche Verantwortung jedes einzelne übernimmt.

Ich habe Installationen mit wenigen schlechten Plugins gesehen und Systeme mit vielen Plugins, die problemlos funktionieren. Die Anzahl ist für mich deshalb kein Urteil. Sie ist höchstens ein Anlass, genauer hinzusehen. Wenn ich überlege, ein Plugin zu entfernen oder zu behalten, interessiert mich vor allem, ob seine Funktion noch an der richtigen Stelle sitzt.

Wenige Plugins sind kein Architekturprinzip

Der Impuls, Plugins zu reduzieren, ist verständlich. Jedes zusätzliche Stück Software kann eine weitere Abhängigkeit bedeuten. Aber die Rechnung «weniger Plugins gleich besseres System» geht nicht automatisch auf. Ein einzelnes Plugin kann tief in Abläufe und Daten eingreifen. Mehrere klar abgegrenzte Plugins können dagegen überschaubar bleiben.

Ich versuche deshalb, die Diskussion von der Zahl wegzubekommen. Ein Plugin ist nicht allein deshalb gut, weil es beliebt ist, und nicht allein deshalb schlecht, weil es viele Funktionen mitbringt. Entscheidend ist, ob ich seine Aufgabe benennen kann und ob diese Aufgabe zum restlichen System passt.

Eine klare Aufgabe ist dabei ein guter Anfang, aber nicht das einzige Kriterium. Ich frage auch, ob die Funktion zur Businesslogik gehört, wie stark sie mich an das Plugin bindet, ob die erzeugten Daten exportierbar sind und wie realistisch eine langfristige Pflege ist. Dazu kommt die technische Tiefe: Greift das Plugin nur an einer gut erkennbaren Stelle ein, oder verteilen sich seine Hooks und Filter durch wichtige Teile des Systems?

Was ich zuerst prüfe: Welche Aufgabe erfüllt das Plugin heute tatsächlich – und welche Teile des Systems hängen daran? Der Name in der Pluginliste beantwortet diese Fragen nicht immer.

Die Funktion kann bleiben, auch wenn das Plugin gehen sollte

Beim Prüfen trenne ich zwei Fragen, die leicht zusammenfallen: Braucht das System diese Funktion noch? Und muss gerade dieses Plugin sie bereitstellen? Wenn ich beides als eine Frage behandle, wird die Entscheidung unnötig grob. Eine Funktion kann sinnvoll und wichtig sein, während ihre bisherige technische Heimat nicht mehr passt.

Dabei achte ich darauf, ob das Plugin eine klar begrenzte Aufgabe erfüllt oder ob es sich schrittweise zum Träger verschiedener Abläufe entwickelt hat. Mit jeder zusätzlichen Verantwortung wird schwerer zu erkennen, was beim Abschalten verloren geht und wo diese Abhängigkeiten sonst noch liegen. Ein Plugin, das ursprünglich einen überschaubaren Zweck hatte, kann so zum Mittelpunkt eines Systems werden, ohne dass diese Rolle bewusst entworfen wurde.

Besonders genau schaue ich hin, wenn eigene Daten im Spiel sind. Kann ich sie in einer verständlichen Form exportieren? Sind sie an ein bestimmtes Plugin gebunden? Ist klar, was nach einem Wechsel mit ihnen geschieht? Wenn die Antwort unklar ist, ist das nicht automatisch ein Grund, das Plugin sofort zu entfernen. Es ist aber ein Hinweis darauf, dass die Abhängigkeit Teil der Entscheidung ist – und nicht erst beim späteren Wechsel auftauchen sollte.

Auch Lock-in bewerte ich nicht nur als abstrakten Nachteil. Manchmal ist eine Abhängigkeit vertretbar, wenn sie eine konkrete Aufgabe zuverlässig übernimmt und der Nutzen die Bindung aufwiegt. Kritisch wird es für mich, wenn ich nicht mehr gut nachvollziehen kann, wie ich die Funktion ersetzen oder die Daten mitnehmen würde. Dann hat das Plugin mehr Einfluss auf die Architektur, als seine sichtbare Aufgabe vermuten lässt.

Wenn Formularlogik zum Geschäftsmodell wird

Ein Beispiel dafür ist Gravity Forms mit Erweiterungen wie Populate Anything. Solche Werkzeuge können sinnvoll sein, solange Formulare tatsächlich Formularlogik bleiben: Eingaben erfassen, Felder abhängig voneinander darstellen oder einen überschaubaren Ablauf abbilden.

Meine Frage ändert sich, wenn die zentrale Geschäftslogik immer stärker in Formularen und ihren Erweiterungen steckt. Dann geht es nicht mehr nur darum, ob das Plugin die gewünschte Funktion technisch abbildet. Ich frage mich, ob die Logik dort noch gut zu überblicken, zu pflegen und außerhalb dieses Plugins weiterzuverwenden ist. Das Formular kann weiterhin Teil der Oberfläche sein; daraus folgt aber nicht, dass auch alle Regeln des Geschäftsmodells dauerhaft darin wohnen müssen.

In so einer Situation denke ich nicht zuerst in der Alternative «alles lassen» oder «alles neu bauen». Ich schaue, welche Logik aus dem Plugin herausgelöst werden sollte und welche Formularfunktionen dort bleiben können. Das kann bedeuten, dass die Grenze zwischen Eingabe und fachlicher Regel klarer gezogen wird. Es bedeutet nicht automatisch, dass jede Formularerweiterung ersetzt werden muss.

Für mich ist das der wichtige Unterschied zwischen einem hilfreichen Werkzeug und einer ungeplanten Architekturentscheidung. Ein Plugin darf Arbeit abnehmen. Wenn es aber dauerhaft festlegt, wie zentrale fachliche Abläufe funktionieren, sollte ich bewusst prüfen, ob diese Bindung gewollt ist.

Entfernen ist auch eine Änderung am System

Wenn ich mich gegen ein Plugin entscheide, behandle ich das nicht als Aufräumen in einer Liste. Ich will zuerst wissen, welche Funktion ausfällt, welche Daten betroffen sein könnten und ob andere Teile des Systems die Funktion voraussetzen. Sonst kann ich zwar das Plugin deaktivieren, aber noch nicht beurteilen, ob die Änderung sinnvoll war.

Umgekehrt gilt: Behalten ist ebenfalls eine Entscheidung. Wenn ein Plugin eine klare Aufgabe erfüllt, die Daten handhabbar bleiben und die Pflege realistisch erscheint, sehe ich keinen Grund, es nur aus Prinzip zu entfernen. Manchmal ist die bessere Maßnahme, die Zuständigkeit genauer zu dokumentieren oder die Abhängigkeit sichtbar zu machen, statt eine funktionierende Lösung zu ersetzen.

Ich will außerdem nicht vorschnell «selbst bauen» mit «weniger Abhängigkeit» gleichsetzen. Eine eigene Umsetzung kann die passende Lösung sein, aber sie bringt ebenfalls Verantwortung für Entwicklung und Pflege mit. Einfacher ist sie nur dann, wenn sie den konkreten Bedarf tatsächlich einfacher abbildet – nicht bloß, weil kein Pluginname mehr in der Liste steht.

So wird die Entscheidung für mich konkreter: Was muss das System leisten? Wo sollte diese Funktion liegen? Was kostet es, sie an diesem Ort zu halten oder zu verlagern? Und kann ich später nachvollziehen, warum ich mich so entschieden habe? Wenn ich diese Fragen nicht beantworten kann, bin ich noch nicht an dem Punkt, an dem ich ein Plugin guten Gewissens entferne.

Was sich bei mir verändert hat

Früher lag es nahe, eine lange Pluginliste als Problem an sich zu behandeln. Inzwischen sehe ich sie eher als Inventar, das ich verstehen muss. Manche Einträge sind unkritisch, manche übernehmen eine zentrale Rolle, und manche sind schwer einzuschätzen, weil ihre Abhängigkeiten nicht deutlich werden. Erst die konkrete Aufgabe zeigt, welche davon Aufmerksamkeit braucht.

Damit verschiebt sich auch mein Ziel. Ich will nicht möglichst viele Plugins loswerden. Ich will, dass Funktionen an einem Ort liegen, an dem sie verständlich, verlässlich und pflegbar bleiben. Manchmal heißt das, ein Plugin zu behalten. Manchmal heißt es, seine Rolle zu begrenzen. Und manchmal sollte die Funktion in eine andere Schicht des Systems wandern.

Das passt zu meinem grundsätzlichen Blick auf WordPress-Systeme: Nicht die Werkzeugliste macht die Architektur verständlich, sondern klare Zuständigkeiten und nachvollziehbare Datenmodelle. Dazu passt auch meine Überlegung, wann ein Plugin reicht und wann individuelle Entwicklung sinnvoll wird. Beides sind keine Lager, für die ich mich dauerhaft entscheide. Es geht darum, für die jeweilige Aufgabe die richtige Grenze zu finden.

Meine Faustregel: Ein Plugin behalte ich, wenn seine Aufgabe klar, seine Abhängigkeiten vertretbar und seine Daten handhabbar sind. Wenn zentrale Businesslogik dauerhaft in einem Formular-Plugin steckt, prüfe ich, welche Logik dort herausgelöst werden sollte – nicht, wie ich die Pluginzahl möglichst schnell senke.

Weiterführend

• Datenmodelle statt Plugin-Stapel
• WordPress Plugin oder individuelle Entwicklung: Was ist wann sinnvoll?
• Warum immer mehr Plugins selten die Lösung sind