Admin Notifications and Announcements

Benecaster displays admin notices in two places: a notification bell (🔔) in the Benecaster top bar and a persistent notice bar above all Benecaster screens. Both surfaces draw from the same benecaster_notices table. What appears where depends on each notice’s display_mode.

Where Notices Appear

Notification bell — the 🔔 icon in the Benecaster top bar shows a badge with the count of unread notices at or above your minimum severity preference. Clicking opens a slide-in panel listing each notice with its tier badge, title, message, timestamp, and dismiss button. A “✓ All” button dismisses all currently visible notices at once.

Persistent notice bar — a full-width colored stripe above all Benecaster admin screens, below the WordPress admin toolbar. Used for high-priority notices that need to stay visible until acknowledged or resolved. When multiple bar-eligible notices exist, only the highest-tier one is shown. A close [✕] button dismisses a dismissible bar notice; non-dismissible bar notices remain until the underlying condition clears.

display_mode controls which surface a notice uses:

Critical notices default to both. All others default to bell.

Notice Tiers

Notification Severity Preference

Settings → Notifications lets you set the minimum notice tier you want to see. The dropdown has four options:

Default is “Show all notices.” Critical notices are always shown regardless of this setting. The preference is stored as benecaster_min_notice_tier in wp_options and is site-wide — it applies to all admin users.

Built-in Health Checks

Benecaster runs seven health check classes and generates local notices automatically. Most checks run once per admin session (transient-gated so they do not fire on every page load). The feed health check and license server check also run on the daily license validation cron, so they surface even on days when no admin visits the site.

---

PHP Version

---

WordPress Version

---

Feed Health

Runs on the daily cron in addition to admin page loads, so feed errors surface promptly without requiring a site visit.

---

License Server

Runs on the daily cron alongside the license validation request. The two dismissible notices re-surface every 7 days as long as the underlying condition is still true — dismissing them is a “remind me later,” not a permanent suppression.

---

Setup Completion

---

Milestones

---

Listener Support Setup

---

Feed Request Log

Appears when the nightly cron pass detects the raw feed request log (benecaster_feed_request_log) has grown past the hard row cap. Benecaster automatically trims the oldest rows to 80% of cap when this happens, but the notice re-surfaces every 7 days as long as the log remains near the limit — a prompt to raise the cap or shorten the retention window at Settings → Tools → Feed request log. See Feed Request Log Retention →.

---

License Server Notices

The license server pushes notices as part of the daily POST /validate response. These cover security alerts, version announcements, deprecation warnings, feature announcements, and promotional messages. Benecaster stores them in the benecaster_notices table with source = 'remote' and processes them alongside local health notices in the bell panel and notice bar.

Remote notices respect your severity preference setting — a marketing promotion from the server is hidden if you have set your minimum to “Warnings and above.”

All dismissals are site-wide. Dismissed License Server notices do not automatically return after a period of time — once dismissed, a notice with the same ID stays gone. The server can re-surface a notice by issuing a new notice ID (for example, appending -reminder to a security alert slug), which is treated as a distinct notice by Benecaster.

Dismissal

Once any admin on the site dismisses a notice, it is gone for the entire installation — with three exceptions. The following notices re-surface every 7 days as long as the underlying condition persists:

• License expires within 30 days
• License server unreachable for more than 7 days
• Feed request log hit the emergency row cap

Dismissing any of these is a “remind me later,” not a permanent suppression. You cannot configure the 7-day cadence — it is set per-notice in code and is not exposed in Settings.

Critical notices are non-dismissible — they remain visible until the underlying condition resolves. When a critical condition clears (for example, you update PHP past the minimum version), the notice is removed on the next health check run.

For Developers

The notification system is extensible via two filter hooks documented in the Filter Hooks Reference:

• benecaster_before_notice_display — modify or suppress a notice per display context (bell or bar) just before it is included in the REST response
• display_mode_in

The re-surfacing behavior is controlled by a re_dismiss_after field on NoticeManager::publish() data arrays. Pass a positive integer (days) to opt a notice into the 7-day re-dismissal cycle; omit the field or pass 0 to preserve the default “dismiss = suppress forever” behavior for that notice. This field is code-side only — it is not configurable per-user or per-installation.