deckerweb Plugins · Wissen & Werkzeuge

Warum ich meine Plugins heute auf GitHub veröffentliche

Sat, 07 Nov 2026 15:58:21 GMT

Seit 2011 veröffentliche ich eigene WordPress-Plugins. Viele Jahre war das Plugin-Verzeichnis von WordPress.org dafür mein Zuhause. Dort haben meine Plugins ihre Nutzer gefunden. Ich habe viel gelernt, Erfahrungen gesammelt und Menschen erreicht, die meine Arbeit bis heute schätzen.

Ein anderer Weg

Trotzdem habe ich mich entschieden, meine Plugins inzwischen über GitHub zu veröffentlichen. Dahinter steckt eine Entwicklung über viele Jahre – und die Frage, wie ich heute arbeiten möchte.

WordPress.org hat mir viel ermöglicht

Als ich anfing, war das offizielle Plugin-Verzeichnis für mich der naheliegende Weg. Wer ein Plugin suchte, konnte es direkt im WordPress-Admin entdecken und installieren. Diese Sichtbarkeit war für einen unabhängigen Entwickler enorm wertvoll.

Eine eigene Website mit ZIP-Downloads war für mich 2011 keine ernsthafte Alternative. GitHub lernte ich damals gerade erst kennen. Ich nahm es vor allem als Plattform für die gemeinsame Arbeit am Code wahr, kaum als Vertriebsweg für fertige WordPress-Plugins.

WordPress.org hat mir deshalb viel ermöglicht. Diese Zeit möchte ich weder schlechtreden noch aus meiner Geschichte streichen.

Irgendwann passte der Rahmen immer weniger

Über die Jahre wurde die Plattform für meine Arbeitsweise zunehmend einengend. Anforderungen und Vorgaben nahmen zu. Bei der Präsentation meiner Plugins, bei Screenshots und Verlinkungen hatte ich weniger Spielraum, als ich mir wünschte.

Das betraf auch Affiliate-Links. Bei kostenlos bereitgestellten Plugins konnten solche Einnahmen für mich eine der wenigen finanziellen Anerkennungen für einen erheblichen Entwicklungs- und Pflegeaufwand sein.

Mit den Support-Foren wurde ich ebenfalls nie richtig glücklich. Das lag sowohl am technischen System als auch an manchen Abläufen. Aus früheren Jahren erinnere ich mich beispielsweise an die Vorgabe, auf Englisch zu kommunizieren – selbst bei Plugins, deren Inhalte und Nutzerkreis ausschließlich deutschsprachig waren. Für mich passte das nicht zusammen.

Spätestens um 2018 wurde mein Wunsch nach einem anderen Weg deutlicher.

Reichweite hat auch eine persönliche Seite

Ein erfolgreiches Plugin bringt Aufmerksamkeit mit sich. Dazu gehören Fragen, Fehlermeldungen, Erwartungen und gelegentlich negative Bewertungen.

Mich hat das oft stärker belastet, als von außen erkennbar war. Wenn ein Plugin von Hunderten oder mehreren Tausend Menschen verwendet wurde, konnte sich eine einzelne Fehlermeldung für mich wie eine Katastrophe anfühlen.

Natürlich müssen Nutzer Probleme melden können. Trotzdem musste ich mir irgendwann eingestehen, wie viel Stress mir diese Form der Öffentlichkeit bereitete. Auch die Atmosphäre auf der Plattform empfand ich nicht immer als angenehm.

Heute ist mein Business kleiner geworden. Eine kleinere Nutzerbasis ist für mich durchaus willkommen: weniger Druck, mehr Ruhe und mehr Raum für konzentrierte Arbeit.

Der letzte Anstoß

Mein persönlicher letzter Anstoß war Matt Mullenwegs Vorgehen im Konflikt mit WP Engine. Ich empfand es als ausgesprochen abstoßend. Für mich gab das den Ausschlag, eine schon lange gewachsene Entscheidung tatsächlich zu treffen.

Von außen mag mein Weggang deshalb vor allem politisch wirken. Die Gründe reichen jedoch wesentlich weiter zurück. Die Plattform passte bereits seit Jahren immer weniger zu meinen Bedürfnissen.

Auch die Abhängigkeit von Entscheidungen über Plugin-Sperrungen und die für mich schwer kalkulierbaren Folgen wollte ich so nicht länger hinnehmen. Die Guidelines erlebte ich zunehmend als starres Regelwerk, in dem ich mich mit meiner Arbeit nicht mehr wohlfühlte.

Ein weiterer Punkt waren Eingriffe in meine Plugin-Übersetzungen. Ich habe mehrfach erlebt, dass Formulierungen verändert wurden, ohne dass die dahinterliegenden Architekturentscheidungen bekannt waren. Ich möchte solche Änderungen im Zusammenhang mit dem gesamten Plugin prüfen und verantworten können.

Warum GitHub heute besser zu mir passt

Auf GitHub empfinde ich die Arbeit als schneller, angenehmer und freier. Ich kann Code, Dokumentation, Screenshots und Veröffentlichungen so organisieren, wie es zu meinen Projekten passt.

GitHub ist ebenfalls eine fremde Plattform mit eigenen Nutzungsbedingungen. Auch dort ist nicht alles perfekt. Für den heutigen Umfang meines Business, meiner Plugin-Entwicklung und meiner Kundenarbeit ist es aber der passendere Rahmen.

Den Preis dafür kenne ich: Ich verzichte auf die große Entdeckungsmöglichkeit über den Plugin-Installer von WordPress.org. Diesen Nachteil nehme ich bewusst in Kauf.

Mit meiner eigenen Website, ausführlicher Dokumentation sowie dem deckerweb Updater und der deckerweb Library gestalte ich inzwischen einen anderen Zugang zu meinen Plugins.

Eine persönliche Entscheidung

Mir ist wichtig, eines ausdrücklich festzuhalten: Ich hatte keinen persönlichen Konflikt mit den angestellten oder ehrenamtlichen Mitarbeitenden von WordPress.org. Im direkten Kontakt wurde ich freundlich behandelt. Meine Entscheidung richtet sich nicht gegen diese Menschen oder ihre Arbeit.

Ich habe selbst entschieden, diesen Weg zu gehen.

Ebenso wenig möchte ich für alle Zeiten ausschließen, irgendwann wieder ein Plugin auf WordPress.org zu veröffentlichen. Doch bis auf Weiteres überwiegen für mich die Gründe, meine Projekte anders bereitzustellen.

Ich entwickle weiterhin gern für WordPress. Ich möchte nützliche Werkzeuge bauen, sie gut dokumentieren und langfristig pflegen können. Dafür brauche ich einen Rahmen, der auch für mich als Menschen funktioniert.

Im Moment finde ich diesen Rahmen auf GitHub.

Ein persönlicher Meinungsbeitrag von David Decker. Er beschreibt meine eigenen Erfahrungen, Wahrnehmungen und Entscheidungen.

Beitrag auf der Website lesen

Plugin oder Code-Snippet: Was passt besser?

Wed, 28 Oct 2026 20:16:29 GMT

Ein Code-Snippet ist nicht automatisch schlanker, sicherer oder besser als ein Plugin. Beide haben ihren Platz. Entscheidend ist, was der Code tut, wie er geladen wird und wer ihn langfristig pflegt.

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.

Dieser Meinungsbeitrag basiert auf meinem englischen GitHub-Wiki-Text von 2025. Für die Website habe ich Sprache und Aufbau überarbeitet und eine deutsche Fassung ergänzt. Die Abwägung beschreibt meine Erfahrungen, keinen umfassenden Test heutiger Snippet-Manager. Möglichkeiten und Schutzfunktionen hängen vom konkreten Werkzeug und seiner Version ab.

Mein Originalbeitrag im GitHub-Wiki (2025, Englisch)

Beitrag auf der Website lesen

Wenn das Mutter-Plugin fehlt: Funktionen pausieren, weiterarbeiten können

Tue, 27 Oct 2026 11:58:37 GMT

Ein Add-on braucht häufig ein anderes Plugin oder ein bestimmtes Theme. Ich möchte, dass eine fehlende Voraussetzung die Einrichtung oder Wartung nicht unnötig blockiert: klare Hinweise, erhaltene Einstellungen und ein sinnvoller Ruhezustand statt einer Sackgasse.

Was mit „Mutter-Plugin“ gemeint ist

Ein Add-on ergänzt ein vorhandenes Werkzeug. Bricks QuickNav braucht für seine Navigation beispielsweise einen unterstützten Bricks-Builder; Genesis Widgetized Footer benötigt ein aktives Genesis-Theme für seine Footer-Funktionen. GP Project Export Name arbeitet mit GlotPress.

Fehlt diese Grundlage oder ist sie vorübergehend inaktiv, können bestimmte Funktionen nicht sinnvoll laufen. Das ist etwas anderes als ein Fehler beim Speichern oder ein Anlass, dich zwangsweise auf eine andere Admin-Seite umzuleiten.

Installieren können, abhängige Funktionen pausieren

Meine Leitlinie ist: Ein solches Add-on soll sich bei erfüllten technischen Mindestanforderungen grundsätzlich installieren und aktivieren lassen, auch wenn seine fachliche Grundlage noch nicht bereitsteht. Die davon abhängigen Funktionen pausieren. Ein verständlicher Hinweis erklärt, was fehlt.

Vorhandene Einstellungen sollen dabei erhalten bleiben. Wo es sinnvoll umgesetzt ist, bleibt auch die Einstellungsseite erreichbar, sodass du die Situation nachlesen oder die Einrichtung vorbereiten kannst. Es müssen also nicht alle Einstellungen gesperrt sein – entscheidend ist, dass nicht ausführbare Funktionen ruhig bleiben.

Die geprüften Beispiele unten zeigen dieses Verhalten bereits. Es ist keine Aussage, dass jedes ältere Plugin oder jede einzelne Funktion schon denselben Stand hat; die Anleitung der jeweiligen Version beschreibt den konkreten Umfang.

Bei der Einrichtung zählt nicht die Reihenfolge

Vielleicht installierst du zuerst mein Add-on und erst zehn Minuten später das benötigte Hauptplugin. Vielleicht bereitest du eine Website vor, bevor das passende Theme aktiviert wird. Das Add-on soll dir erklären, was noch fehlt, statt aus dieser Reihenfolge ein Hindernis zu machen.

Sobald die unterstützte Voraussetzung wieder erkannt wird, können die zugehörigen Funktionen wieder zur Verfügung stehen. Ein Hinweis auf eine fehlende Grundlage ersetzt dabei nicht die eigentliche Einrichtung des Hauptplugins oder Themes.

Wenn Support oder Fehlersuche eine Pause erfordern

Bei einer Supportanfrage empfiehlt ein Hersteller manchmal, sein Plugin kurzzeitig zu deaktivieren. Auch bei der Fehlersuche kann das sinnvoll sein. Mein Add-on soll diese Arbeit nicht durch eine eigene Aktivierungssperre, eine erzwungene Weiterleitung oder den Verlust seiner Einstellungen erschweren.

Die abhängigen Funktionen stehen währenddessen nicht zur Verfügung. Nach der erneuten Aktivierung prüfst du, ob die Hinweise verschwunden sind und die benötigten Funktionen wieder arbeiten. Ein Themewechsel oder die Pause des Hauptplugins kann weiterhin dessen eigene Auswirkungen auf die Website haben – der Ruhezustand des Add-ons hebt sie nicht auf.

Drei vorhandene Beispiele

Die Beispiele beziehen sich auf die hier dokumentierten veröffentlichten Versionen. Entscheidend ist jeweils, welche Funktion ihre Voraussetzung vermisst – nicht bloß, ob das Add-on als aktiv angezeigt wird.

bricks-quicknav · v2.0.2: Ohne aktiven unterstützten Builder bleiben die Einstellungen erreichbar; die Toolbar-Navigation wartet auf ihre Voraussetzung. Ein Hinweis erklärt den Zustand.
genesis-widgetized-footer · v2.0.2: Ohne aktives Genesis pausieren die Footer-Funktionen. Der Hinweis auf der Einstellungsseite erklärt, dass gespeicherte Widgets und Einstellungen erhalten bleiben.
gp-project-export-name · v2.0.0: Ohne einsatzbereites GlotPress pausieren die Exportfunktionen. Einstellungen und Kurzanleitung bleiben erreichbar; zusätzlich ist eine andere Permalink-Struktur als „Einfach“ erforderlich.

Technische Mindestanforderungen gelten weiterhin

Eine fehlende fachliche Grundlage ist nicht dasselbe wie eine zu alte WordPress- oder PHP-Version. Die Mindestanforderungen des Plugins gelten weiterhin. Ebenso bleiben Berechtigungen und ausdrücklich dokumentierte Besonderheiten maßgeblich.

Ich möchte diesen ruhigen Umgang mit Voraussetzungen bei weiteren Updates dort ergänzen oder verbessern, wo er sinnvoll ist. Es geht nicht darum, jede Abhängigkeit zu ignorieren, sondern ihren Zustand verständlich zu behandeln und den weiteren Weg offenzuhalten.

Passende FAQ-Antwort

Beitrag auf der Website lesen

Gut eingebaut: Wie meine Plugins mit WordPress zusammenarbeiten

Tue, 27 Oct 2026 11:58:37 GMT

Ein gutes Plugin muss nicht für jede Aufgabe eine neue Oberfläche erfinden. Viele meiner aktuellen Plugins nutzen bereits die Werkzeuge, die WordPress mitbringt – dort, wo sie im Alltag wirklich helfen.

WordPress als Zuhause, nicht nur als Unterbau

Ich möchte, dass sich meine Plugins in WordPress einfügen. Dazu gehören verständliche Einstellungen, passende Berechtigungen und nachvollziehbare Hinweise. Die Befehlspalette und der Website-Zustand sind zwei gute Beispiele: Sie bieten bereits vertraute Orte für schnelle Zugriffe und technische Informationen.

Dabei ist weniger oft mehr. Ein zusätzlicher Eintrag soll eine häufige Aufgabe erleichtern oder eine konkrete Frage beantworten. Eine zweite, konkurrierende Befehlspalette oder ein Diagnosebereich voller belangloser Werte wäre kein Gewinn.

Website-Zustand: Informationen von Prüfungen unterscheiden

Unter Werkzeuge → Website-Zustand findest du neben den Statusprüfungen den Bereich Bericht. Viele meiner Plugins ergänzen dort kompakte Informationen, etwa zum Komponentenstand, zur erkannten Umgebung oder zu wirksamen Einstellungen. Das kann bei einer Supportfrage helfen, ohne dass du erst mehrere Einstellungsseiten durchsuchen musst.

Ein solcher Informationsbereich ist kein eigener Zustandstest und keine Sicherheitsbewertung. Brand Admin Schemes zeigt beispielsweise Informationen zu Schema-Auswahl, Palettenquelle und Umgebung, ohne dafür zusätzliche Tests oder externe Abfragen auszuführen. Site Essentials beschreibt unter anderem den Wartungsstatus und wirksame beziehungsweise derzeit nicht anwendbare Regeln.

Manche Plugins haben zusätzlich echte, auf ihre Aufgabe zugeschnittene Prüfungen. TabulaMea prüft beispielsweise Aspekte seiner Speicherstruktur, Tabellen und geplanten Aufgaben. Die Bedeutung eines Ergebnisses richtet sich nach dem jeweiligen Plugin; eine reine Diagnoseangabe soll nicht unnötig als Warnung erscheinen.

Befehlspalette: kurze Wege zu sinnvollen Aufgaben

Wo WordPress seine native Befehlspalette bereitstellt, können passende Plugin-Befehle häufige Aufgaben schneller erreichbar machen. Welche Befehle du siehst, hängt von WordPress-Version, geöffneter Ansicht, deinen Berechtigungen und dem Zustand des Plugins ab.

Advanced Scripts QuickNav bietet beispielsweise Zugriffe auf die Script-Verwaltung, neue Scripts, die Suche und persönliche Favoriten. Site Essentials ergänzt vier Navigationsbefehle für Einstellungen, Berichte, Website-Prüfungen und Wartung. Türchenzeit stellt einen gezielten Einstieg zum Anlegen eines neuen Türchens bereit.

Diese Befehle ersetzen weder Berechtigungsprüfungen noch die normalen Plugin-Menüs. Ist die native Palette in einer Ansicht nicht verfügbar, bleiben die regulären Zugänge der passende Weg. Ein Menüpunkt, den WordPress selbst auffindbar macht, ist außerdem nicht automatisch ein zusätzlich vom Plugin registrierter Befehl.

Konkrete Beispiele zum Nachlesen

Die folgenden Beispiele beziehen sich auf die hier dokumentierten veröffentlichten Versionen. Nicht jedes Plugin bringt beide Integrationen mit; Umfang und Voraussetzungen stehen in seiner eigenen Anleitung.

brand-admin-schemes · v1.1.1: Kompakter Informationsbereich im Website-Zustand, ohne zusätzliche Status-Tests.
advanced-scripts-quicknav · v1.3.2: Diagnoseinformationen und native Befehle für die Arbeit mit Advanced Scripts.
site-essentials · v1.1.1: Konfigurationsinformationen zu Wartung und wirksamen Regeln sowie gezielte Navigationsbefehle für Einstellungen, Berichte, Dashboard und aktive Avatar-Funktionen.
tabulamea · v0.9.1: Statistikbezogene Zustandsprüfungen, Diagnoseinformationen und berechtigte Schnellzugriffe.
tuerchenzeit · v1.0.1: Diagnoseinformationen und ein nativer Befehl für ein neues Türchen.

Hilfreich für den Support – bewusst weitergeben

Wenn du eine Frage meldest, können Plugin-Version, erkannte Voraussetzungen und ein passender Diagnoseauszug die Einordnung erleichtern. Lies den Auszug vor dem Weitergeben und teile nur die Angaben, die für deine konkrete Frage benötigt werden.

Der Website-Zustand ist dabei zunächst eine lokale Ansicht im WordPress-Admin. Eine dort sichtbare Information ist nicht gleichbedeutend mit einem automatischen Versand an mich. Ob ein Plugin für andere Aufgaben externe Verbindungen verwendet, beschreibt seine eigene Dokumentation.

Schritt für Schritt – mit einem Grund dafür

Plugins, die noch keine passende Integration haben, sollen sie im Laufe künftiger Updates erhalten, wenn sich daraus ein sinnvoller Nutzen ableiten lässt. Das ist eine Entwicklungsleitlinie, kein Versprechen für eine bestimmte Version oder dafür, jedes Plugin mit denselben Einträgen auszustatten.

Mein Maßstab bleibt die konkrete Aufgabe: Welche Information hilft bei einer Rückfrage? Welcher Befehl spart im Alltag wirklich einen Umweg? Was diese Fragen nicht sinnvoll beantwortet, muss die beiden WordPress-Werkzeuge auch nicht füllen.

Passende FAQ-Antwort

Beitrag auf der Website lesen