Notifications
Notifications
Shared across every PremiumPress product. 5 classes in inc/Notifications.
AccountMail AccountMail.php
Account emails in the owner's own words: "Welcome", "New member registered" and "Password changed". All three were in Settings ▸ Email ▸ Manage emails, but nothing sent them. WordPress sent its own versions instead, so an owner who reworded them saw no effect (Email screen audit, 2026-10-02). This sends the catalog emails at the same moments and stops WordPress's copies, so each moment gets exactly ONE email: - New member, to the admin: WordPress's "New User Registration" is replaced through wp_send_new_user_notification_to_admin. That covers every path that calls wp_new_user_notification() — the core register form, the theme's sign-in page, the sign-up wizard, the app API. Social sign-up never called it, so it calls newMember() itself. - Welcome, to the member: WordPress's "Login Details" (the set-a-password link) is replaced through wp_send_new_user_notification_to_user. The link travels in the welcome as {password_link}. Two cases keep WordPress's email, because without it the member has no way to set a password: the owner switched the welcome off, or reworded it without {password_link}. A member who chose a password already gets no WordPress email at all, so the callers that create one (sign-up wizard, social sign-up, app API) call welcome() themselves. - Password changed, to the member: the hub's Change password (Account\AccountEdit, which uses wp_set_password and so never mailed anyone) calls passwordChanged(). A forgotten-password reset arrives through after_password_reset. An admin, the wp-admin profile screen or the API changing it goes through wp_update_user(), whose own "Password Changed" email is replaced through send_password_change_email. WordPress's ADMIN copy of a reset ("Password Changed for user") is left alone: it is a different email to a different person. Switching one of these off in Manage emails stops it for real: WordPress's version is not sent in its place (except the welcome's password link, above).
Center Center.php
On-site notification centre — a shared, theme-wide notification store with a floating bell + dropdown panel for logged-in members. Any part of the theme pushes an event with Center::push($userId, …); the member sees an unread count on the bell and the list in the panel, each item linking to the relevant page. Self-contained and header-agnostic: like the popup Messenger, it renders on wp_footer rather than needing a theme header hook, so it works across every design. Storage is a custom table (wp_ppt_notifications); delivery is a small poll + fetch, mirroring the Messenger's live-badge approach. This is the ON-SITE channel; it sits alongside (not instead of) the email templates — callers typically send both (e.g. a new proposal emails the client AND pushes here).
ListingLiveMail ListingLiveMail.php
"Your listing is now live" — the member's email when the site admin approves a listing they submitted, however the admin approves it. The listing editors' own save handler (each fork's ListingEditor::save(), admin mode) already sends listing_approved when the admin approves from the theme's editor. Every OTHER way a pending listing goes live — the Listings screen's row menu ("Set Published", Admin\Listings::ajaxAction), its bulk action, WordPress's own edit screen / Quick Edit, a plugin — changed the status and told the member nothing, although they had been promised "we'll let you know once it's live" by the listing_received email. Found in the BO12TEST run-through, 2026-09-29. So this listens to the status change itself (pending → publish) and sends the same catalog email as a safety net, with three guards: - deferred to shutdown and skipped when a call site already sent listing_approved for this listing in the same request (EmailTemplates::send fires ppt_email_sent), so the editor path never mails twice; - only for a member's listing: never for one written by an admin (nobody to tell), never for seeded demo content (Support\Demo), never when the author approves their own listing; - once per approval: a post-meta stamp suppresses a repeat inside a short window (a double-clicked row action, a bulk action re-run).
ListingReviewMail ListingReviewMail.php
"Listing awaiting review" — tells the site admin a member's listing is waiting for approval (admin_new_listing in Manage emails). The template was offered in Manage emails but nothing sent it (Email screen audit, 2026-10-02), so a listing could sit in the queue until the admin happened to look. This listens to the status change itself (anything → pending) rather than to one submit form, because a listing reaches review several ways: every fork's ListingEditor::save(), the app API (Api\App\Submit), and the payment callback that moves a paid submission out of draft. WordPress has no email of its own for this, so nothing needs replacing. Same guards as ListingLiveMail: - deferred to shutdown, so a save that sets pending and then publishes in the same request (auto-approve) sends nothing; - only a member's listing: never one written by an admin, never seeded demo content, never when an admin is the one moving it back to pending; - once per submission: a post-meta stamp suppresses a repeat inside a short window.
Sms Sms.php
PPT — SMS gateway. Sends text messages through the provider configured in Settings → SMS (Twilio / Vonage / MessageBird / Plivo). Other code triggers a message with either: do_action('ppt_send_sms', $to, $message); $result = \Ppt\Notifications\Sms::send($to, $message); // true | WP_Error A "Send test SMS" button on the SMS settings tab proves the credentials work (admin-only AJAX). When SMS is disabled/unconfigured, send() returns a WP_Error and nothing is dispatched.