Write once, notify every user who needs to see it
Set up a notifications generator WordPress admins can compose from directly: pick a type, choose all users, a role, or one person, and send — delivery batches automatically and every notification stays logged with real read/pending status per recipient.
- Send to all users, a role, or a single searched-up user.
- Batches delivery 100 recipients at a time — no timeouts.
- Per-recipient read, pending and deleted status, on demand.
- Requires Notifications Off-Canvas — the two work as a pair.
Notifications generator WordPress: what does the module actually send?
This is what a notifications generator WordPress sites get with TheOneWP: an admin screen where TOWP_Notifications_Generator composes a typed message (success, info, warning or error), targets all users, a role, or a single user, and delivers it by writing into each recipient's towp_noc_state user meta — the same meta the Notifications Off-Canvas module displays from. Every send is logged in a dedicated towp_ng_sent table, delivery batches at 100 recipients per request, and a stats view shows exactly who has read, has pending, or has deleted each notification.
WordPress has no built-in way to message users in-app
Telling every user, or just the editors, or one specific person, that something changed usually means an email blast, a pinned post, or a message typed into Slack that only reaches whoever happens to be online.
Email gets lost in an already-full inbox
An in-app announcement about a maintenance window or a policy change competes with everything else in someone's inbox, if it gets read there at all.
Nobody can tell who actually saw the message
Without per-recipient tracking, an administrator has no way to know whether an important notice reached the people who needed it.
Compose once, track every recipient
The module writes each message directly into the exact user meta the in-app notification system already reads, then gives the sender a real record of who saw it.
One composer, three targets
All users, a specific role, or one person found by search — the same message form handles every case.
Batched delivery, not one giant write
Recipients get written in groups of 100, so sending to a large user base never risks a timed-out request.
Real per-recipient status
A stats view built on a fresh, uncached database read shows exactly who has read, still has pending, or has deleted each notification.
The complete notifications generator WordPress feature set
Every capability below is present in the class, its AJAX handlers, or the admin composer view.
Four message types, live preview
Success, info, warning and error, each with its own visual style, plus a live preview of exactly what the recipient will see.
All users, a role, or a specific person
Role targeting also reaches users with that role as an extra role through Multi Role Assignment, not only their primary role.
Batched sending at 100 per request
The first 100 recipients get the notification synchronously; the rest deliver through repeated background AJAX calls until every recipient is done.
Dedicated sent-notifications table
Every send is recorded in towp_ng_sent with its type, message, sender, target and full recipient list — capped at the 100 most recent entries.
Per-recipient delivery stats
Expand any sent notification to see each recipient's display name, avatar and current status — read, pending, deleted or unknown.
Two-scope delete
Remove a notification from the admin log only, or wipe it from every recipient's own notification state at once.
Send a notifications generator WordPress message in four steps
Enable the dependency first — nothing else in this module works without it.
Enable Notifications Off-Canvas first
Notifications Generator stays disabled and shows a dependency notice until Off-Canvas is turned on in the UX tab.
Compose the message
Pick a type, write the message, and check the live preview before choosing who receives it.
Choose the target
All users, a specific role, or search for one person by name or email.
Send and check delivery stats
Watch the batches complete, then open the sent-log entry any time to see who has actually read it.
Where an in-app message beats an email
The module fits announcements that need to reach people inside WordPress itself, not their inbox.
Maintenance and downtime notices
Tell every logged-in user about a scheduled maintenance window without relying on them checking email first.
Role-specific policy updates
Notify only Editors about a new content workflow, or only Shop Managers about an order-processing change.
Agencies messaging a single client contact
Search up one specific person and send a direct, trackable message without touching every other account on the site.
Messaging with a real delivery record
Every design choice in the verified code favors accountability over a fire-and-forget broadcast.
Built to survive a very large recipient list
The verified implementation is explicitly designed around avoiding one oversized request.
100 recipients per batch
Both the first synchronous batch and every follow-up call are capped at 100 recipients, keeping each write predictable.
Assets load on this screen only
The composer's CSS and JavaScript enqueue only when the current admin page matches the Notifications Generator screen.
Self-capping log table
The sent-log table trims itself back to 100 rows after every insert, so it never grows into a maintenance problem of its own.
Every send goes through the same checks
Composing, sending, viewing stats and deleting a log entry all share the same access and sanitization rules.
Capability and nonce on every AJAX action
Send, batch delivery, stats, delete and user search all call check_ajax_referer( 'towp_ng', 'nonce' ) and require manage_options.
Message content sanitized with wp_kses_post()
The composed message passes through wp_kses_post() before storage and before delivery, and an empty message after tag-stripping is rejected outright.
Message type validated against a whitelist
Only error, warning, success or info are accepted; anything else falls back to info automatically.
Prepared queries for every lookup
Reading a notification's recipients, HTML or stats by notif_id always goes through $wpdb->prepare().
Built as the companion to Notifications Off-Canvas
The supplied code has one explicit, enforced dependency and one cross-module integration. No compatibility claim beyond the verified implementation is assumed.
Notifications Off-Canvas
Gated in both bootstrap.php and the settings UI — the module cannot be enabled, and does nothing, without Off-Canvas active.
Multi Role Assignment
Role-targeted sends also query users holding that role as an extra role, via the same towp_extra_roles user meta other modules read.
Custom table via dbDelta()
The towp_ng_sent table is created on activation using WordPress's own dbDelta() upgrade routine, so future schema changes stay upgrade-safe.
TheOneWP versus common alternatives
Compare a real notifications generator WordPress implementation with typical email-based announcements or a dedicated messaging plugin.
| Capability | TheOneWP Notifications Generator | Other common solutions |
|---|---|---|
| Delivery channel | In-app, via the same meta the Off-Canvas panel reads | Usually email, competing with an already full inbox |
| Targeting | All users, any role (including extra roles), or one person | Often limited to a mailing list or every subscriber |
| Large sends | Batched at 100 recipients per request | Depends entirely on the sending service's own limits |
| Read tracking | Per-recipient status, read from an uncached query | Email open tracking is unreliable and often blocked |
| Cleanup | Delete from the log, or from every recipient's own state | An email already sent cannot be recalled |
| Administration | One TheOneWP composer, submenu or standalone | May require a separate email platform and its own login |
Send messages people actually act on
A few habits keep in-app notifications useful instead of becoming noise.
Match the type to the message
Reserve "error" and "warning" for things that genuinely need attention, so they still stand out when they matter.
Target as narrowly as the message allows
A role-specific or single-user notice is easier to act on than a broadcast to everyone.
Check the stats before assuming it landed
Open the sent-log entry to confirm recipients are moving from pending to read, especially for anything time-sensitive.
Delete "for all users" when a message no longer applies
An outdated maintenance notice left in everyone's notifications just adds clutter — clear it properly instead of leaving it in the log only.
Avoid assumptions the code does not support
The module has a defined, verified scope — a few assumptions outside it cause confusion.
Enabling it without Notifications Off-Canvas
The toggle stays inactive and a dependency notice shows until Off-Canvas is turned on — this module has no independent delivery path.
Expecting it to send an email too
Delivery is entirely in-app, through user meta. Nothing in the verified code sends an email alongside the notification.
Assuming "delete" always reaches every recipient
Choosing "only for me" removes the log entry but leaves the notification in every recipient's own notifications — use "for all users" to actually retract it.
Notifications Generator FAQ
These answers come directly from the verified class, its AJAX handlers and the admin composer view.
Does Notifications Generator work on its own?
No. It requires the Notifications Off-Canvas module to be enabled first — bootstrap.php only instantiates TOWP_Notifications_Generator when both options are on, and the settings panel shows a dependency notice and disables the toggle until Off-Canvas is active.
Where do sent notifications actually get stored?
Two places. A dedicated database table, towp_ng_sent, logs every send with its type, message, sender, target and recipient list. Each recipient also gets the notification written into their own towp_noc_state user meta — the same meta key the Off-Canvas module reads to display it.
How does sending to thousands of users avoid timing out?
Delivery is batched at 100 recipients per request. The first 100 are written synchronously when you click send; the JavaScript then calls a second AJAX action repeatedly, 100 recipients at a time, until every recipient has the notification in their meta.
Can I target more than "all users"?
Yes. A notification can go to every user, to everyone with a specific role, or to one specific user found through a live search. Role targeting also reaches users who hold that role as an extra role through Multi Role Assignment, not only their primary role.
What happens when I delete a sent notification?
"Only for me" removes it from the admin log alone. "For all users" also strips it out of every recipient's own user meta — from their notices, read and deleted arrays — so it disappears from their notifications entirely, not just from the log.
Can the message include formatting, or just plain text?
It can include safe HTML. The message passes through wp_kses_post() before it is stored or delivered, so basic formatting survives while disallowed tags and attributes get stripped.
How many notifications does the log keep?
The 100 most recent. append_log() checks the row count after every send and deletes the oldest rows once the table holds more than 100, so the log never grows without bound.
Why does the read/deleted stats check bypass the object cache?
A direct database query reads each recipient's current state on every stats request, deliberately skipping the cache layer, so an administrator checking who has read a notification always sees the latest state rather than a stale cached one.
Stop hoping your announcement gets read.Send it, and see who actually did.
Use a notifications generator WordPress admins can trust: batched delivery, a real sent log, and per-recipient read status on every message.