Ein bisschen Klarheit.
Dann geht’s weiter.

Der einmalige manuelle Wechsel betrifft insbesondere frühere WordPress.org-Ausgaben von Genesis Widgetized Footer, Genesis Widgetized Not Found & 404, Builder Shortcode Extras, Builder Template Categories und Multisite Toolbar Additions. Auch die früheren GitHub-Ausgaben meiner anderen Plugins hatten noch keinen eigenen eingebetteten Updater. Wer damals keine externe Update-Lösung nutzte, muss deshalb ebenfalls einmal manuell aktualisieren.

In den erneuerten 2026er Versionen wurde auf Rückwärtskompatibilität geachtet, etwa bei bestehenden Genesis-Widget-IDs und Shortcodes. Das Ziel ist, vorhandene Inhalte und Einbindungen weiterzuverwenden. Beachte dennoch die Hinweise des jeweiligen Plugins und prüfe deine konkrete Website nach dem Wechsel. Wichtig: deaktivieren, nicht löschen.

1. Erstelle eine aktuelle Sicherung deiner Website. Prüfe die WordPress-, PHP- und gegebenenfalls Theme- oder Plugin-Anforderungen auf der Produktseite.
2. Deaktiviere das bestehende Plugin unter Plugins → Installierte Plugins. Klicke nicht auf Löschen.
3. Lade das aktuelle installierbare ZIP des betreffenden Plugins von seiner Produktseite herunter. Öffne Plugins → Plugin hinzufügen → Plugin hochladen und wähle diese ZIP-Datei.
4. Wenn WordPress meldet, dass das Plugin bereits installiert ist, bestätige „Installierte Version durch hochgeladene Version ersetzen“ beziehungsweise die sinngleiche Schaltfläche.
5. Aktiviere das Plugin wieder und prüfe Einstellungen, Inhalte und die verwendeten Funktionen, etwa Widgets oder Shortcodes. Falls kein Ersetzen angeboten wird: nicht vorschnell löschen oder eine zweite Variante parallel aktivieren, sondern zunächst die Zuordnung des ZIP-Pakets prüfen.

• Genesis Widgetized Footer →
• Genesis Widgetized Not Found & 404 →
• Builder Shortcode Extras →
• Builder Template Categories →
• Multisite Toolbar Additions →

Nutze den Download auf der jeweiligen Produktseite. Er ist für das installierbare Plugin-Paket vorgesehen. Auf GitHub können zusätzlich automatisch erzeugte Quellcode-Archive stehen; diese sind nicht immer dasselbe wie das fertige Plugin-Paket.

• Plugin auswählen →

Meine früheren GitHub-Ausgaben hatten keinen eigenen eingebetteten Updater. Damals habe ich häufig Git Updater empfohlen und selbst genutzt. Der heutige deckerweb Updater kam erst mit den erneuerten Ausgaben hinzu.

Die aktuellen GitHub-Ausgaben binden in der Regel den deckerweb Updater ein. Er bringt neue GitHub-Releases in den WordPress-Updateablauf. Ob und wie er bei einem Plugin enthalten ist, steht in dessen Dokumentation.

Eine sehr alte Installation kann zunächst ein manuelles Update benötigen. Ein funktionierender Updater bedeutet außerdem nicht, dass WordPress Updates ohne deine gewählte Einstellung automatisch installiert.

• Mehr zum Updater →
• Updater-Dokumentation →

Lies den aktuellen Changelog und die Mindestanforderungen. Sichere die Website und teste größere Änderungen möglichst zuerst in einer Testumgebung. Prüfe danach die Funktionen, die du tatsächlich nutzt.

Ein Update ersetzt Dateien. Eine Deinstallation kann je nach Plugin zusätzlich Daten entfernen. Deshalb sind „deaktivieren“, „ersetzen“ und „löschen“ unterschiedliche Schritte.

Der deckerweb Updater verbindet neue GitHub-Releases eines installierten Plugins mit dem normalen WordPress-Updateablauf. Die deckerweb Library ist der gemeinsame Katalog, in dem du weitere Plugins entdecken, gezielt installieren und bei passenden Katalogeinträgen auch Updates ausführen kannst.

Beide Komponenten sind in passende Plugins eingebettet. Für ihre normale Nutzung installierst du kein zusätzliches Updater- oder Library-Plugin.

• Zum Updater →
• Zur Library →

Für aktuelle deckerweb-Plugins mit eingebettetem Updater ist Git Updater als zusätzlicher Updateweg nicht nötig. Früher habe ich Git Updater häufig empfohlen und selbst verwendet. Andere Plugins oder Themes können ihn weiterhin benötigen – deshalb nicht pauschal entfernen.

Updater und Library erkennen aktive Git-Updater- beziehungsweise ältere GitHub-Updater-Installationen lokal und können einen gemeinsamen ausblendbaren Hinweis anzeigen. Niemand wird automatisch deaktiviert. Library 1.1.0 enthält außerdem konkrete Anpassungen an Git-Updater-Nonce-Prüfungen und die Übergabe der Pluginidentität. Das ist keine Garantie für jede Kombination von Versionen und Erweiterungen.

Wenn eine Installation oder ein Update fehlschlägt, deaktiviere Git Updater vorübergehend und versuche es erneut. Aktiviere ihn danach wieder, wenn andere Erweiterungen darauf angewiesen sind. Dauerhaft abschalten erst, wenn für alle betroffenen Plugins und Themes ein zuverlässiger anderer Updateweg vorhanden ist.

• Zusammenspiel im Detail →
• Library-Fragen & Antworten →

Öffne Plugins → Plugin hinzufügen → deckerweb. Das WordPress.org-Verzeichnis bleibt die Standardansicht. Mehrere Plugins mit eingebetteter Library teilen sich einen Katalog und seine Einstellungen.

Unter Einstellungen → deckerweb Library kannst du den Katalog ausblenden; bei Multisite liegen die gemeinsamen Einstellungen in der Netzwerkverwaltung. Das Ausblenden deaktiviert nicht automatisch bestehende Updatewege. Den optionalen Online-Katalogabruf schaltest du getrennt aus.

• Zur Library-FAQ →

Für öffentliche deckerweb-Releases brauchst du weder ein GitHub-Konto noch einen persönlichen Token. Der Updater fragt GitHub nach Releases ab; Paketdownloads laden Dateien von GitHub und seiner Download-Infrastruktur. Dabei werden übliche Verbindungsdaten wie die anfragende IP-Adresse verarbeitet.

Die Library kann ihren mitgelieferten Katalog lokal anzeigen. Online-Katalogabruf ist standardmäßig aus und muss bewusst eingeschaltet werden. Die Library sendet keine Website-URL, Nutzer-ID oder Plugin-Inventarliste und fügt keine Telemetrie hinzu. Private Repositories benötigen eine gesonderte, installationsgebundene Einrichtung.

• Updater: Daten & Verbindungen →
• Library: Daten & Verbindungen →

Bei passenden installierten Katalogeinträgen kann die Library ein geprüftes Update direkt in der Karte anbieten, auch wenn die alte Version noch keinen eigenen Updater enthält. Entscheidend sind eine eindeutige Zuordnung und ein freigegebenes kompatibles Paket.

Wenn kein passendes Angebot erscheint oder du unabhängig vom Katalog wechseln möchtest, nutze den manuellen ZIP-Weg oben. Weder der Katalog noch ein Update installiert notwendige Drittanbieter-Abhängigkeiten ungefragt.

• Zum manuellen Updateweg →
• Aktionen im Katalog →

Nein. Manche Werkzeuge sind allgemein nutzbar, andere sind gezielt für Genesis, Bricks oder ein anderes System entwickelt. Die jeweilige Produktseite und Dokumentation nennen Voraussetzungen und Grenzen.

Installiere ein Plugin passend zu deiner Aufgabe und Umgebung – nicht allein deshalb, weil es im Katalog steht.

Das hängt vom jeweiligen Plugin ab. Lies die Hinweise zu Multisite, Netzwerkaktivierung und Einstellungen in dessen Dokumentation. Website-Einstellungen und netzwerkweite Update- oder Library-Funktionen können unterschiedlich behandelt werden.

Nein, wenn die Snippet-Ausgabe als Alternative zum Plugin angeboten wird. Wähle dann eine Variante. Kleine ergänzende Code-Rezepte sind etwas anderes: Sie können ein aktives Plugin voraussetzen.

Beachte Ausführungskontext und Anleitung. Snippet-Ausgaben können einen anderen Funktionsumfang haben und müssen gegebenenfalls manuell aktualisiert werden.

• Zu Snippets und Werkzeugen →

Eine pauschale Zusage wäre nicht ehrlich. Entscheidend sind das konkrete Plugin, seine aktivierten Funktionen und deine Website. Lies die Angaben zu Datenverarbeitung und externen Verbindungen in der jeweiligen Dokumentation.

Beispielsweise benötigen GitHub-Updateprüfungen eine Verbindung zu GitHub. Bei anderen Funktionen können bewusst aktivierte Kataloge oder externe Medien eine Rolle spielen. Open Source ersetzt nicht die Prüfung der eigenen Konfiguration.

Viele meiner aktuellen Plugins ergänzen bereits die WordPress-eigenen Werkzeuge. Der Website-Zustand kann kompakte Diagnoseinformationen enthalten; ausgewählte Plugins bieten zusätzlich gezielte Befehle in der nativen Befehlspalette. Nicht jedes Plugin unterstützt beides oder denselben Umfang.

Ein Diagnosebericht ist nicht automatisch ein zusätzlicher Zustandstest. Befehle hängen unter anderem von der WordPress-Version, der geöffneten Ansicht und deinen Berechtigungen ab. Die regulären Plugin-Menüs bleiben der vertraute Zugang.

Mein Maßstab ist der Nutzen im Alltag: hilfreiche Informationen und kurze Wege statt möglichst vieler Einträge. Bei weiteren Updates sollen passende Integrationen dort hinzukommen, wo es einen sinnvollen Bedarf gibt. Der Beitrag zeigt bereits vorhandene Beispiele und erklärt die Unterschiede.

• Gut eingebaut: die WordPress-Integrationen →

Meine Leitlinie ist, dass ein Add-on bei erfüllten technischen Mindestanforderungen grundsätzlich installierbar und aktivierbar bleibt. Die abhängigen Funktionen sollen in einen ruhigen Zustand gehen; ein eindeutiger Hinweis erklärt, was fehlt. Vorhandene Einstellungen sollen erhalten und, wo sinnvoll umgesetzt, im Admin weiter erreichbar bleiben.

Das hilft bei der Einrichtung und bei Wartungs- oder Supportarbeiten: Du musst nicht zwingend zuerst das Hauptplugin installieren, und eine vorübergehende Deaktivierung soll keine erzwungene Weiterleitung oder den Verlust der Add-on-Einstellungen auslösen. Bricks QuickNav, Genesis Widgetized Footer und GP Project Export Name zeigen bereits konkrete Umsetzungen.

Nicht jedes ältere Plugin hat schon denselben Stand. WordPress-/PHP-Mindestversionen und die Hinweise der jeweiligen Plugin-Dokumentation gelten weiterhin. Der Beitrag erklärt das Prinzip und die Grenzen anhand der vorhandenen Beispiele.

• Wenn Voraussetzungen fehlen: das Prinzip und Beispiele →

Beginne auf der Produktseite: Dort findest du Dokumentation, den Changelog und die passenden Hilfewege. Die allgemeinen Fragen hier ersetzen keine pluginbezogene Anleitung.

• Zum Plugin-Katalog →
• Zur Dokumentation →

Nenne Plugin-Version, WordPress- und PHP-Version sowie relevante Themes oder Erweiterungen. Beschreibe das erwartete Verhalten, das tatsächliche Ergebnis und möglichst kurze Schritte zum Nachstellen.

Ein bereinigter Screenshot oder eine passende Fehlermeldung hilft. Veröffentliche keine Zugangsdaten, privaten Kundendaten oder vollständigen unbereinigten Protokolle. Bei vermuteten Sicherheitslücken nutze einen privaten Meldeweg.

Veröffentliche Details zu einer noch nicht behobenen möglichen Sicherheitslücke nicht in einem öffentlichen Issue. Nutze die Sicherheitsrichtlinie im jeweiligen Repository beziehungsweise den dort genannten privaten Kontaktweg.

Meine Plugins sind persönliche Projekte neben meiner übrigen Arbeit und meinem Privatleben. Ich kann deshalb keine feste Antwort- oder Behebungsfrist zusagen. Konkrete Vereinbarungen über individuelle Leistungen wären davon getrennt zu betrachten.

Ja. Besonders hilfreich ist eine konkrete Aufgabe aus deinem Alltag: Was möchtest du erreichen, und wo fehlt dir etwas? Nutze den auf der Produktseite verlinkten Austauschweg.

Ein Vorschlag ist keine Zusage für eine Umsetzung. Auch nachvollziehbare Fehlerberichte, Übersetzungen oder gezielte Code-Beiträge können helfen. Größere Änderungen am besten vorher abstimmen.

Ich entwickle Werkzeuge für konkrete Aufgaben, die mir bei der täglichen Arbeit mit WordPress begegnen. Sie sollen Umwege verkürzen, wiederkehrende Handgriffe erleichtern und verständlich bleiben.

Nicht jede gute Idee braucht ein großes Plugin. Mir ist wichtiger, dass ein Werkzeug seine Aufgabe gut löst, als dass es möglichst viele Funktionen versammelt.

• Mehr über mich →

Die Entwicklung von Toolbar Extras war zu komplex geworden. Rückblickend musste ich mir eingestehen, dass ich mich verrannt hatte: Die ursprüngliche Konzeption war nicht klar genug, und der Umfang war von Anfang an nicht deutlich genug abgegrenzt. Ich wollte zu viel auf einmal und konnte es schließlich nicht mehr so umsetzen, wie ich es mir vorgenommen hatte.

Hinzu kamen andere Prioritäten in meinem Privatleben, die eine weitere Entwicklungsarbeit nicht mehr möglich machten. Deshalb habe ich Toolbar Extras eingestellt.

Diese Erfahrung prägt meine heutigen Plugins: kleinere, klarer abgegrenzte Aufgaben und ein Umfang, den ich bewusst steuern kann. Die QuickNav-Serie führt die Grundidee der kurzen Wege mit eigenständigen Werkzeugen weiter – sie ist kein vollständiger Ersatz für jede frühere Funktion.

• Toolbar Extras & QuickNav →

Ein Plugin kann seine Aufgabe erfüllt haben, technisch überholt sein oder seine Funktion inzwischen direkt im ursprünglichen Werkzeug finden. Auch verfügbare Zeit und andere Prioritäten spielen eine Rolle.

Ich möchte lieber wenige wichtige Projekte sinnvoll pflegen, als für jedes frühere Plugin dauerhafte Weiterentwicklung zu versprechen. In der Historie bleiben frühere Projekte sichtbar.

• Zur Plugin-Historie →

Die Produktseiten verlinken auf die jeweiligen GitHub-Repositories. Dort findest du den Quellcode und die Lizenzangaben für das konkrete Projekt. Hinweise zu mitgelieferten Bibliotheken und anderen Bestandteilen können zusätzlich eigene Lizenzdateien nennen.