Veröffentlichungen

ReportedIP Hive 2.1.57: Eine Schutz-Seite, eine Werkzeug-Seite

15. September 2026 · Patrick Schlesinger

ReportedIP Hive 2.1.57 ersetzt die Seiten Einstellungen und Firewall durch eine einzige Schutz-Seite mit vierzehn Karten und legt alles, was keine Einstellung ist, auf eine Werkzeug-Seite. Das Dashboard nennt jetzt den nächsten Schritt, statt ihn suchen zu lassen.

Das Update kommt über den WordPress-Adminbereich, alternativ liegt die ZIP-Datei im Release v2.1.57 auf GitHub. Die vollständige Funktionsliste steht in der Dokumentation zum Hive-Plugin.

Eine Schutz-Seite statt Einstellungen und Firewall

Hive ist auf 169 gespeicherte Einstellungen gewachsen, verteilt auf zwei Seiten und ein Dutzend Registerkarten. Wer die passende suchte, musste wissen, unter welchem Reiter sie abgelegt war. Jeder Bereich des Einstellungsregisters ist jetzt eine aufklappbare Karte auf einer Seite, jede mit einem Kurzstatus, und ein Suchfeld öffnet die passende Karte und markiert die gefundene Beschriftung.

Die Seite hat zwei Tiefen. Einfach zeigt die sechzehn Einstellungen, die eine Website im Alltag wirklich anfasst, höchstens sechs pro Bereich. Experte zeigt jedes Feld und ist ein Schalter im Seitenkopf, der pro Person gespeichert wird: Ein Administrator kann in der kurzen Ansicht arbeiten, während ein anderer Schwellenwerte bearbeitet.

• Jede Karte speichert über denselben Dienst, den MainWP, die Cloud-Flotte und der Einstellungsimport ohnehin schon benutzt haben. Prüfung, Tarifgrenzen und Fehlermeldungen sind damit auf jedem Weg identisch.
• Ein abgelehnter Wert wird an der Karte gemeldet, die ihn erzeugt hat, nicht als seitenweiter Hinweis.
• Ein gesperrtes Feld wird vom Speichern seiner Karte nie zurückgesetzt: Deaktivierte Eingaben sind nicht Teil des Formulars, und das Speichern verwirft versteckte und gesperrte Schlüssel, statt leere Standardwerte darüberzuschreiben.
• Felder, deren Tarifgrenze vom Wert abhängt, etwa die Registrierungslisten und die Paranoia-Stufe der Firewall, bleiben mit sichtbarer Tarifmarkierung bearbeitbar, und das Register weist einen Wert ab, der die Grenze überschreitet.

Alte Adressen mit page=reportedip-hive-settings und page=reportedip-hive-firewall leiten auf die passende Karte oder den passenden Werkzeug-Tab weiter. Lesezeichen, MainWP-Links und Links aus Bereitschaftshinweisen funktionieren also weiter.

Eine Werkzeug-Seite für alles, was keine Einstellung ist

Serverarbeit, Wartung und Diagnose haben eine eigene Seite mit vier Tabs bekommen: das Drop-in des erweiterten Schutzes samt Webserver-Snippets, Regel-Sync und WAF-Ausnahmen, den Hardening-Status mit seinen Handschaltern, Import, Export und Zurücksetzen sowie die Test-Mail. Im Menü steht sie im Expertenmodus, per URL ist sie jederzeit erreichbar.

Das Dashboard beantwortet „fertig, und jetzt?“

Ein Statusbanner oben auf dem Dashboard nennt den Tarif, für den die Empfehlung angewendet wurde, das Datum der Einrichtung und die Zahl der Einstellungen, die von dieser Empfehlung abweichen. Darunter stehen Karten für den nächsten Schritt, gespeist aus sechs neuen Hinweis-Detektoren im Bereitschaftsregister: Die Login-Adresse ist noch öffentlich, die Storefront-2FA ist im Tarif enthalten, aber aus, das Footer-Badge ist aus, der erweiterte Schutz wäre möglich, läuft aber nicht, die Website fährt Local Shield statt Community-Netzwerk, oder der Administrator, der gerade liest, hat selbst keinen zweiten Faktor.

Diese Karten tragen die Aktion, nicht bloß einen Link darauf. Badge und Storefront-2FA schalten sich mit einem Klick ein, Hide Login nimmt einen Slug entgegen und aktiviert sich damit, und „Nicht jetzt“ blendet eine Karte für sieben Tage aus. Das Bereitschaftsregister zählt jetzt achtzehn Detektoren: zwölf melden einen Fehler, sechs schlagen eine Verbesserung vor.

Die Aktivitätsseite öffnet auf dem Protokoll, gefilterte Ansichten sind Lesezeichen

Der Menüpunkt Sicherheit heißt jetzt Aktivität und führt direkt ins Ereignisprotokoll. Die Filter sind aus der Tabellenleiste in eine eigene, beschriftete Filterleiste gewandert: Suche, Ereignistyp, Schweregrad, Zeitraum und der Hardening-Schalter, dazu eine Schaltfläche zum Anwenden und ein Reset-Link, der nennt, wie viele Filter aktiv sind. Die Leiste ist ein GET-Formular, eine gefilterte Ansicht übersteht damit Blättern, Sortieren und Massenaktionen, und ein Support-Ticket kann die exakte URL dessen mitschicken, was der Administrator gesehen hat. Die alten Links tab=logs, tab=blocked und tab=api_queue funktionieren weiter.

Die Community-Seite teilt sich in Einstellungen, Community und Badges

Die Community-Seite öffnet auf Einstellungen: Betriebsmodus, Community Access Key, Client-IP-Header, Flottenverwaltung und Verbindungstest. Community behält Beitrag, Tageskontingent, lizenzierte Domains und die Tarifübersicht. Badges löst die früheren Backlink-Werkzeuge ab, mit dem Ein-Klick-Footer-Badge samt Live-Vorschau und einem Banner-Generator, dessen Vorlagen Variante, Kennzahl und Wortlaut in einem Klick setzen. Die separate Shortcode-Galerie ist verschwunden, ihre Beispiele sind Vorlagen im Generator.

Korrekturen, die im echten Betrieb zählen

• Ein Community Access Key, den der Dienst mit HTTP 401 oder 403 ablehnt, zählt nicht mehr als Fehlversuch im laufenden API-Gesundheitsfenster. Zweimal ein falscher Schlüssel bei der Einrichtung reichte bisher, um für drei Stunden „Community-Prüfungen schlagen fehl“ zu melden, obwohl mit dem Netz alles in Ordnung war.
• Die Bereitschaftsprüfungen für einen Berichtsrückstand und für fehlgeschlagene Berichte schweigen in Local Shield und ohne Schlüssel. Übrig gebliebene Zeilen aus einer früheren Community-Phase erzeugten dort ein kritisches Problem, dessen Lösungen es in diesem Zustand gar nicht gibt.
• Das Dashboard-Banner nannte als Einrichtungsdatum den 1. Januar 1970: Der Zeitpunkt liegt als UTC-Datum vor und wurde als Ganzzahl gelesen.
• Sieben Score-Links öffneten seit der Bereichsaufteilung in 2.1.56 die falsche Karte. REST-Zugriff, XML-RPC, Feeds, wp-admin für Besucher, Uploads und Software-Fingerabdrücke zeigten auf Sicherheits-Header statt auf Zugriffsbeschränkung.
• Der Hinweis zum stehenden Cron nennt jetzt die übliche Ursache zuerst: eine Website, die ihre eigene wp-cron.php per Loopback nicht erreicht.
• Rund 1.300 Zeilen Stylesheet-Regeln für die stillgelegten Seiten, der entfernte SMS-Provider-Abschnitt und zwei tote Firewall-Handler sind mit verschwunden.

Was sich für eine verwaltete Flotte ändert

Am Remote-Protokoll ändert sich nichts, und genau das ist der Punkt. Weil die Schutz-Seite über denselben Dienst speichert wie Cloud Fleet Management und die MainWP-Brücke, wird ein Wert, den das Backend ablehnt, auch über die Leitung abgelehnt, und ein Wert, den der Tarif nicht abdeckt, kommt als skipped_tier zurück statt als stiller Schreibvorgang. Schema und Drift-Hash reisen weiter in den Headern X-Rip-Settings-Schema und X-Rip-Settings-Hash, ein Dashboard sieht also weiterhin auf einen Blick, welche Website von der Richtlinie abweicht.

2.1.57 folgt auf 2.1.54, das den Einrichtungsassistenten durch einen einseitigen Schnellstart ersetzt hat, und auf 2.1.52 und 2.1.53, die Kommentare und Formulare zu einer eigenen Abwehrebene gemacht haben. Die Plugin-Dokumentation führt die aktuelle Funktionsliste je Tarif, die neunzehn Sensoren und ihre Standardwerte.