Beide führen Code aus.Qualität und Pflege machen den Unterschied.
Warum ich diese Frage stelle
Wenn ich Videotitel wie „Weniger Plugins – verwende stattdessen Code-Snippets“ sehe, werde ich skeptisch. Hinter der Empfehlung kann ein sinnvoller Gedanke stecken. Als allgemeine Regel führt sie aber in die Irre: Schlechter Code kann eine Website ausbremsen oder Sicherheitslücken schaffen – unabhängig davon, woher er kommt.
Als ich den ursprünglichen Beitrag 2025 schrieb, nutzte ich kleine Funktionsplugins bereits seit mehr als 15 Jahren. Code Snippets begleitet mich seit 2012 auf vielen Websites, und ich arbeite ausgesprochen gern damit. Dieser Beitrag ist also kein Plädoyer gegen Snippets. Ich möchte zeigen, warum ich beide Wege schätze und je nach Projekt bewusst abwäge.
Was für beide Wege gilt
- Code muss irgendwo liegen und geladen werden: im Plugin-Verzeichnis, im Theme oder Child-Theme, in der Datenbank oder in einer vom Snippet-Manager erzeugten Datei. Der Speicherort allein sagt wenig über seine Qualität aus.
- Code braucht Pflege. Sicherheitsprobleme sowie Änderungen an WordPress oder PHP können Anpassungen notwendig machen.
- Unsicherer oder fehlerhafter Code kann überall Probleme verursachen. Auch die Fehlersuche kann schwierig werden – im Snippet ebenso wie im Plugin oder in der functions.php.
- Ein Vor- kann auch ein Nachteil sein: Fest vorgegebene Bedingungen schützen in einem Kundenprojekt vor unbeabsichtigten Änderungen, in einem anderen schränken sie die notwendige Flexibilität ein.
Plugins: Stärken und mögliche Nachteile
Was dafür spricht
- Updates lassen sich über einen passenden Update-Kanal erhalten und gegebenenfalls automatisch installieren.
- Übersetzungsdateien und WordPress-Sprachpakete lassen sich in die Plugin-Struktur einbinden. Das hilft bei übersetzbaren Oberflächen und mehrsprachigen Projekten.
- Bei Multisite kann eine Netzwerkaktivierung die gemeinsame Verwaltung erleichtern.
- Geeigneter Code lässt sich auch als Must-use-Plugin organisieren: Er wird automatisch geladen und bleibt aktiv.
- Plugins können mit WP-CLI über die Kommandozeile verwaltet werden.
- Vom Entwickler festgelegte Ausführungsbedingungen sind für Kunden nicht ohne Weiteres veränderbar. Das kann erwünscht sein.
- Mehrere PHP-Dateien lassen sich übersichtlich zusammenfassen.
- Scripts, Stylesheets und andere Dateien können als zusammengehöriges Paket eingebunden werden.
- WordPress bringt grundlegende Fehlerprüfungen bei der Plugin-Aktivierung mit. Diese ersetzen keine vollständige Prüfung.
- Für das WordPress.org-Verzeichnis gelten Einreichungs- und Prüfregeln. Das bietet einen Rahmen, ist aber keine Garantie für fehlerfreien oder sicheren Code.
- Der Plugin-Quellcode liegt normalerweise in Dateien statt in der Datenbank. Je nach Angriffsszenario kann diese Trennung hilfreich sein.
- Ein erkennbarer Autor und ein gepflegtes Projekt bieten oft einen Weg für Rückfragen, Feedback oder Support.
Was du abwägen solltest
- Manche Plugins wachsen über ihre eigentliche Aufgabe hinaus und sammeln unnötige Einstellungen an.
- Werbung und aufdringliche Verkaufsangebote können den WordPress-Admin unübersichtlich machen.
- Einige Plugins laden ihre Dateien auch dort, wo sie nicht gebraucht werden. Das kann unnötigen Aufwand verursachen.
- Das Aktivieren und Deaktivieren fühlt sich für manche Nutzer umständlicher an als das Umschalten eines Snippets.
- Die reine Anzahl wird leicht mit einem Leistungsproblem verwechselt. Auch viele kleine, gut geschriebene Plugins können problemlos zusammenarbeiten; entscheidend ist die einzelne Implementierung.
- Fest eingebaute Bedingungen lassen sich unter Umständen nur mit zusätzlichem Code oder überhaupt nicht anpassen.
Code-Snippets: Stärken und mögliche Nachteile
Was dafür spricht
- Viele Nutzer finden das Ein- und Ausschalten sowie das Verwalten von Bedingungen besonders einfach.
- Je nach Snippet-Manager lassen sich Bedingungen über eine grafische Oberfläche festlegen.
- Titel, Beschreibung, Schlagwörter und weitere Angaben helfen, eigene Anpassungen zu ordnen.
- Für kleine, klar abgegrenzte Aufgaben sind Snippets praktisch – beispielsweise für wenige bis einige Dutzend Zeilen Code.
- Ein Snippet-Manager kann Site Buildern helfen, wenn sie auf einer Kundenseite keinen Zugriff auf Theme-Dateien oder SFTP haben.
- In der Datenbank gespeicherte Snippets können zusammen mit einer Datenbanksicherung übertragen werden.
- Ein Safe Mode kann die Wiederherstellung nach einem problematischen Snippet erleichtern, sofern der Manager ihn anbietet.
- Nach meiner Erfahrung können die Aktivierungsprüfungen eines Snippet-Managers hilfreicher sein als die grundlegenden WordPress-Prüfungen. Sie erkennen dennoch nicht jeden logischen Fehler.
Was du abwägen solltest
- Ein kopiertes Snippet erhält normalerweise keinen eigenen automatischen Update-Kanal. Seine Pflege bleibt dann bei dir.
- Übersetzungen und WordPress-Sprachpakete sind bei einem einzelnen eingefügten Snippet weniger geradlinig als bei einem entsprechend aufgebauten Plugin.
- Multisite-Unterstützung hängt vom Manager ab. Ich schätze hier die netzwerkweiten Snippets von Code Snippets, die ich bereits in der kostenlosen Ausgabe nutzen konnte.
- Der Manager muss zuerst laden, bevor er seine Snippets ausführt. Bei zeitkritischen Hooks kann ein Plugin oder Must-use-Plugin geeigneter sein.
- Unzureichend benannte Funktionen und fehlende Präfixe können Konflikte mit anderem Code verursachen.
- Bei frei kursierenden Snippets fehlen mitunter Berechtigungsprüfungen, Eingabeprüfung oder sichere Ausgabe. Das kann Sicherheitslücken schaffen.
- Ein Code-Snippet wird durch eine einfache Einfügeoberfläche nicht zu einer No-Code-Lösung.
- Wer Code kopiert und aktiviert, trägt Verantwortung für seine Wirkung – auch dann, wenn er den Code nicht vollständig versteht.
- Ohne erkennbare Herkunft oder erreichbaren Autor fehlen häufig ein sinnvoller Supportweg und die Möglichkeit, Feedback zu geben.
Kurze Auswahlhilfe für deinen Alltag
Diese Beispiele sind eine Orientierung, keine festen Regeln. Die Auswahlhilfe ergänzt den ursprünglichen Beitrag von 2025. Entscheidend bleiben die konkrete Umsetzung und die Frage, wer den Code künftig betreut.
Hier passt oft ein Snippet
- Eine kleine Anpassung für genau eine Website: Du möchtest etwa einen vorhandenen Filter nutzen, um eine Beschriftung anzupassen. Ein überschaubares Snippet kann dafür gut passen.
- Eine gezielte Ergänzung zu einem vorhandenen Plugin: Du nutzt einen dokumentierten Hook und kennst die Voraussetzungen. Ein Snippet hält diese individuelle Anpassung getrennt vom Plugin-Code.
- Wenige projektspezifische Anpassungen, die du selbst pflegst: Du arbeitest bereits mit einem Snippet-Manager und möchtest die einzelnen Änderungen dort benennen, ordnen und gezielt ein- oder ausschalten.
Hier passt oft ein Plugin
- Eine zusammengehörige Funktion mit mehreren Dateien: PHP, Stylesheets, Scripts und eventuell Übersetzungen sollen als ein Paket gepflegt werden. Dafür ist ein Plugin oft übersichtlicher.
- Dasselbe Werkzeug auf mehreren Kundenwebsites: Du möchtest eine nachvollziehbare Version und einen geregelten Update-Weg. Ein gepflegtes Plugin mit passendem Update-Kanal ist dafür häufig die bessere Grundlage.
- Eine Funktion, die sehr früh laden muss: Ihr benötigter Hook wird ausgeführt, bevor der Snippet-Manager den Code lädt. Dann kann ein passend eingebundenes Plugin oder Must-use-Plugin nötig sein; die konkrete Ladefolge entscheidet.
Meine Antwort: passend zur Aufgabe entscheiden
Ich würde weder ein Plugin allein wegen seiner zusätzlichen Zeile in der Plugin-Liste ablehnen noch ein Snippet allein wegen seiner Kürze bevorzugen. Eine kleine Anpassung im gut betreuten Snippet-Manager kann genau richtig sein. Für zusammengehörige Funktionen, mehrere Dateien und einen geregelten Update-Weg kann ein Plugin die passendere Form sein.
Wichtig ist die informierte Entscheidung für das konkrete Projekt: Welche Funktion brauche ich? Wer pflegt den Code? Welche Möglichkeiten habe ich bei einem Fehler? Plugins und Snippets sind Werkzeuge – keine konkurrierenden Glaubensrichtungen.