In einigen meiner Hobbyprojekte nutze ich weiterhin klassische WordPress-Themes und klassische Widgets. Diese Projekte sind sehr alt und über viele Jahre gewachsen. Allerdings möchte ich jetzt nicht zu viel Arbeit hineinstecken, um sie auf ein Block-Theme umzuziehen. Was ich allerdings bei diesen Projekten nach wie vor benötige, ist eine schlanke Lösung, die mir hilft, die Ausgabe der Widgets zu steuern. Idealerweise mit der WordPress-Funktionalität Conditional Tags.
Genau dafür gab es lange Zeit das Plugin Widget Logic. Bereits 2014 habe ich beschrieben, wie sich damit die Widget-Ausgabe mithilfe von Conditional Tags steuern lässt. Unter jedem Widget erschien ein zusätzliches WordPress-Feld, in das du Conditional-Tags eintragen konntest. Einfach, flexibel und für viele Jahre vollkommen ausreichend. Das Problem ist nur: Widget Logic ist imho keine vernünftige Lösung mehr.
Einfache Bedingung als KO-Kriterium
Natürlich gibt es andere Plugins, mit denen du WordPress-Widgets ein- und ausblenden kannst. Einige davon sind allerdings deutlich umfangreicher, als ich es für meine kleinen Projekte benötige. Andere bieten zwar eine übersichtliche Auswahl mit Checkboxen, unterstützen aber nicht die Bedingungen, die ich tatsächlich brauche. Ein gutes Beispiel ist:
is_home() AND is_paged()Damit lässt sich ein Widget ausschließlich auf der Beitragsübersicht ab Seite zwei anzeigen. is_home() prüft, ob die Blogübersicht aufgerufen wurde. is_paged() erkennt, ob sich der Besucher auf Seite zwei oder einer späteren Archivseite befindet.
Die Unterscheidung zwischen is_home(), is_front_page() und den paginierten Folgeseiten habe ich bereits in einem älteren Artikel über die gezielte Ansprache der WordPress-Startseite ausführlicher erklärt. Auch Verknüpfungen wie diese sind für mich wichtig:
is_paged() OR is_archive()is_home() OR is_archive()is_single() OR is_page()
Wenn ein Plugin solche Bedingungen nicht oder nur über mehrere umständliche Einstellungsseiten abbilden kann, ist das für meinen Einsatzzweck ein KO-Kriterium. Ich möchte die WordPress-Conditional-Tags direkt verwenden und nicht erst eine mittellange Klick- und Fummelstrecke absolvieren.
Warum Widget Logic für mich ausgeschieden ist
Widget Logic war nicht nur flexibel. Das Plugin erlaubte auch die Ausführung von PHP-Ausdrücken über eval(). Genau diese Freiheit ist gleichzeitig das Problem.
WPScan führt für Widget Logic mehrere bekannte Sicherheitslücken auf, darunter eine Remote-Code-Execution-Lücke in Versionen vor 6.0.6. Das Plugin wird dort außerdem als geschlossen geführt.
Das bedeutet nicht automatisch, dass jede frühere Installation unsicher oder bereits kompromittiert war. Für mich stellt sich allerdings eine andere Frage: Warum sollte ich in einem kleinen Hobbyprojekt weiterhin eine Lösung einsetzen, die beliebigen PHP-Code auswerten kann, wenn ich eigentlich nur eine Handvoll Conditional-Tags benötige?
Daher habe ich mich entschieden, einen schlankeren Nachfolger für meinen eigenen Bedarf entwickeln zu lassen.
Was Widget Conditional Tags kann
Das Ergebnis heißt wenig überraschend Widget Conditional Tags. Das Plugin ergänzt jedes klassische WordPress-Widget um ein Feld für die Anzeige-Bedingung. Dort kannst du die unterstützten Conditional Tags positiv oder negativ eintragen und miteinander verknüpfen.
Unterstützt werden:
ANDoder&&ORoder||- Negationen mit
! - Klammern zur Gruppierung
- die übliche Reihenfolge
NOTvorANDvorOR
Ein leeres Feld bedeutet, dass das Widget überall angezeigt wird. Fehlerhafte Bedingungen werden bereits beim Speichern erkannt und mit einem verständlichen Hinweis zurückgewiesen.
Das Plugin unterstützt unter anderem is_home, is_front_page, is_archive, is_single, is_page, is_singular, is_paged, is_search, is_404 und is_user_logged_in.
Parameter wie is_page( 42 ) oder is_category( 'wordpress' ) sind bewusst noch nicht vorgesehen. Das schränkt die Möglichkeiten ein, hält den Parser aber klein und übersichtlich.
Unterschied zu Widget Logic
Der wichtigste Unterschied zu Widget Logic befindet sich im Code. Widget Conditional Tags übergibt die eingegebene Bedingung nicht an eval(). Ein kleiner Parser zerlegt den Ausdruck und prüft jeden Conditional-Tag gegen eine festgelegte Whitelist. Nur freigegebene und tatsächlich vorhandene Funktionen werden aufgerufen.
Auch beim Umgang mit Fehlern folgt das Plugin einem vorsichtigen Prinzip. Kann eine gespeicherte Bedingung nicht mehr ausgewertet werden, wird das Widget ausgeblendet. Es wird also nicht nach dem Motto »Wird schon passen« vorsichtshalber angezeigt.
Das ist keine Garantie, dass ein Plugin niemals eine Sicherheitslücke enthalten kann. So etwas zu behaupten wäre unseriös. Die gefährliche Klasse der eval()-Probleme wird durch diesen Aufbau allerdings gar nicht erst benötigt.
Wichtig: Das Plugin steuert lediglich die Sichtbarkeit eines Widgets. Es ist kein Zugriffsschutz. Vertrauliche Informationen sollten niemals allein dadurch abgesichert werden, dass ein Widget auf bestimmten Seiten nicht ausgegeben wird.
Entwickelt mit ChatGPT, Claude, Gemini und Grok
Der Entstehungsprozess war für mich spannend. Ich habe die Anforderungen vorgegeben: schlank, sicher aufgebaut, an den WordPress-Best-Practices orientiert und auf klassische Widgets konzentriert.
Anschließend habe ich ChatGPT, Claude, Gemini und Grok Entwürfe, Kritikpunkte und Verbesserungsvorschläge gegenseitig prüfen lassen. Die Modelle haben nicht direkt miteinander kommuniziert. Ich habe die jeweiligen Vorschläge und Einwände von einem Modell zum nächsten weitergereicht und die KI-Modelle begründen lassen, warum sie taten, was sie taten.
Das fertige Ergebnis habe ich anschließend noch einmal von ChatGPT, Gemini, Claude, Grok und DeepSeek prüfen lassen.
Schon bei früheren Versuchen mit ChatGPT und WordPress-Code war meine Erfahrung: Der ausgegebene Code kann eine gute Grundlage sein, sollte aber getestet und mit anderen Quellen abgeglichen werden.
Mehrere KI-Modelle machen einen Quellcode nicht automatisch fehlerfrei. Sie setzen aber teilweise unterschiedliche Schwerpunkte und entdecken dadurch Dinge, die ein anderes Modell übersehen hat. Das war bei diesem kleinen Projekt durchaus hilfreich.
Für klassische Themes und klassische Widgets
Widget Conditional Tags ist nicht als universelle Sichtbarkeitssteuerung für sämtliche WordPress-Blöcke und Page-Builder gedacht.
Das Plugin arbeitet mit der klassischen Widget-Oberfläche. Bei aktuellen WordPress-Installationen kannst du diese beispielsweise mit dem Plugin Classic Widgets aktivieren. Der Block-Widget-Editor wird nicht unterstützt. Das Plugin weist im Backend darauf hin, falls die klassische Oberfläche fehlt.
Die aktuelle Version 1.2.0 setzt WordPress 6.5 und PHP 7.4 oder neuer voraus. Der komplette Plugin-Code befindet sich bewusst in einer einzigen PHP-Datei. Für ein kleines Werkzeug dieser Art reicht das vollkommen aus.
Das Plugin steht unter der Lizenz GPL-2.0-or-later. Den Quellcode, die Dokumentation und die Installationsanleitung findest du auf GitHub: Widget Conditional Tags.
Ein kleines Plugin für ein konkretes Problem
Widget Conditional Tags ist schlank und es löst ein vergleichsweise kleines und individuelles Problem: die Sichtbarkeit klassischer WordPress-Widgets mithilfe bekannter Conditional Tags zu steuern.
Für moderne Block-Themes und umfangreiche Projekte gibt es andere Lösungen. Wer jedoch noch klassische Themes nutzt, direkte Bedingungen wie is_home() AND is_paged() benötigt und auf beliebig ausgeführten PHP-Code verzichten möchte, findet hier möglicherweise genau das passende kleine Werkzeug.
Ich habe das Plugin in erster Linie für meine eigenen Hobbyprojekte erstellt. Da aber vermutlich noch andere WordPress-Nutzer vor einem ähnlichen Problem stehen, liegt es öffentlich auf GitHub.
Wie schaut es bei euch aus? Nutzt ihr noch klassische Widgets und womit steuert ihr deren Sichtbarkeit?
