Skip to main contentSkip to footer
Releases

ReportedIP Hive 2.1.57: One Protection Page, One Tools Page

Patrick Schlesinger
Release card for ReportedIP Hive 2.1.57 showing two settings screens becoming one page, fourteen protection cards with one search box and eighteen readiness detectors of which six are new

ReportedIP Hive 2.1.57 replaces the Settings and Firewall screens with a single Protection page of fourteen cards, and moves everything that is not a setting onto a Tools page. The dashboard now names the next step instead of leaving an admin to find it.

Update from the WordPress admin or download the ZIP from the v2.1.57 release on GitHub. The full feature list is documented on the Hive plugin documentation page.

One Protection page replaces the Settings and Firewall screens

Hive grew to 169 stored settings across two screens and a dozen tabs. Finding the one that mattered meant knowing which tab it had been filed under. Every area of the settings registry is now a collapsible card on one page, each with a one-line status, and a search box opens the matching card and marks the label it found.

The page has two depths. Simple shows the sixteen settings that a site actually touches in daily operation, at most six per area. Expert shows every field and is a per-person switch in the page header, so one administrator can work in the short view while another edits thresholds.

  • Every card saves through the same apply service that MainWP, the cloud fleet and the settings import already used, so validation, plan limits and error messages are identical on every path.
  • A rejected value is reported at the card that produced it, not as a page-wide notice.
  • A locked field is never reset by saving its card: disabled inputs are not part of the submission, and the save drops hidden and locked keys instead of writing empty defaults over them.
  • Fields whose plan gate depends on the value, such as the registration lists and firewall paranoia level, stay editable with the plan marker visible, and the registry refuses a value that crosses the line.

Old page=reportedip-hive-settings and page=reportedip-hive-firewall addresses redirect to the matching card or Tools tab, so bookmarks, MainWP links and links inside readiness issues keep working.

A Tools page for everything that is not a setting

Server work, maintenance and diagnosis moved onto their own page with four tabs: the Extended Protection drop-in and the web-server snippets, rule sync and WAF exceptions, the hardening status and its manual switches, import, export and reset, and the test mail. It is listed in the menu in expert mode and reachable by URL at any time.

The dashboard answers “done, and now?”

A status banner at the top of the dashboard names the plan the recommendation was applied for, the date protection was switched on and how many settings deviate from that recommendation. Below it, next-step cards come from six new advisory detectors in the readiness register: the login address is still public, storefront 2FA is included in the plan but off, the footer badge is off, Extended Protection is supported but not running, the site runs Local Shield instead of the community network, or the administrator reading the page has no second factor of their own.

Those cards carry the action rather than a link to it. The badge and storefront 2FA switch on with one click, Hide Login takes a slug and enables itself, and “Not now” hides a card for seven days. The readiness register is now eighteen detectors: twelve report a fault, six suggest an improvement.

Activity opens on the event log, and a filtered view can be bookmarked

The menu entry called Security is now Activity and links straight to the event log. Its filters left the table toolbar for a labelled filter bar of their own: search, event type, severity, date range and the hardening toggle, with an Apply button and a reset link that names how many filters are active. The bar is a GET form, so a filtered view survives paging, sorting and bulk actions, and a support ticket can carry the exact URL of what an admin was looking at. The old tab=logs, tab=blocked and tab=api_queue links keep working.

Community splits into Settings, Community and Badges

The Community page now opens on Settings, which holds the operation mode, the Community Access Key, the client-IP header, fleet management and the connection test. Community keeps contribution, daily quota, licensed domains and the plan overview. Badges replaces the former backlink tools with a one-click footer badge and its live preview, plus a banner builder whose templates set variant, number and wording in one click. The separate shortcode gallery is gone; its examples are templates inside the builder.

Fixes that matter on a real install

  • A Community Access Key the service rejects with HTTP 401 or 403 no longer counts as a failed sample in the rolling API health window. Pasting a wrong key twice during setup used to raise “Community threat checks are failing” for the next three hours on a perfectly healthy network.
  • The readiness checks for a pending report backlog and for failed reports stay silent in Local Shield and without a key. Leftover rows from an earlier Community period raised a critical issue whose remedies did not exist in that state.
  • The dashboard banner reported the setup date as 1 January 1970: the completion time is stored as a UTC datetime and was cast to an integer.
  • Seven score links opened the wrong card after the 2.1.56 section split. REST access, XML-RPC, feeds, wp-admin for visitors, uploads and software fingerprints pointed at Security Headers instead of Access Lockdown.
  • The stalled-cron issue now names the usual cause first: a site that cannot call its own wp-cron.php over a loopback request.
  • About 1,300 lines of stylesheet rules for the retired screens, the removed SMS provider section and two dead firewall handlers left the codebase with them.

What it changes for a managed fleet

Nothing about the remote protocol changed, and that is the point. Because the Protection page saves through the same service as Cloud Fleet Management and the MainWP bridge, a value refused in wp-admin is refused over the wire too, and a value a plan does not cover comes back as skipped_tier rather than a silent write. The settings schema and drift hash keep travelling in the X-Rip-Settings-Schema and X-Rip-Settings-Hash headers, so a dashboard still sees at a glance which site has drifted from policy.

2.1.57 follows 2.1.54, which replaced the setup wizard with a one-page quickstart, and the 2.1.52 and 2.1.53 releases that turned comments and forms into a defence layer of their own. The plugin documentation carries the current feature list per plan, the nineteen sensors and their defaults.

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.
You need to agree with the terms to proceed