Restore WordPress post review notifications

Check status before looking for email

A contributor finishes a post and chooses “Submit for Review.” The reviewer expects an email, but nothing arrives. Start by opening Posts in administration on the same site and displaying posts pending review. Find the title and, if two items share the name, compare their IDs. In the editor, status also appears in post settings. If the text remained a draft, the first task is to understand why submission was not saved. Email cannot serve as evidence of that step.

Record the time, content type, status before and after submission, and account performing the action. For a network site, specify the subsite. In a custom workflow, the screen may display a stage called “Legal approval” or “To review” whose name differs from native status. Ask the workflow maintainer which status or event actually triggers the alert. If the team calls a simple draft save “review,” agree on an action both accounts can reproduce.

Post state, the alert rule, and mailbox receipt are three separate observations. Pending Review status organizes work in WordPress. To obtain a team alert, check which mechanism is configured on your site to associate that status with recipients. A site may use a manually checked queue, a plugin-provided rule, or a team-specific mechanism. If nobody knows the expected rule, start by restoring queue access.

Approach 1. Give the reviewer access to the native queue

With their usual account, the reviewer opens Posts, then the Pending Review filter. They open the post and confirm access to actions expected in the workflow, such as editing content, requesting corrections through the working channel, or handing it to the person authorized to publish. An account that can read the list does not necessarily have the same actions on another author's posts. Standard roles provide a comparison point, but an installation may have adjusted roles. Check expected capabilities with the person responsible.

If the post appears only for an administrator, compare author, subsite, content type, and reviewer account. Try another dummy post submitted by the same contributor to determine whether the difficulty concerns one item or all items from that author. If the workflow uses pages or a custom type, ask the maintainer which list corresponds to that content and whether the role has access. An email containing the edit link does not fix denied access. Test opening from the recipient account.

When the queue suits the workload, agree on someone to check it and a checking time. On a copy, submit a synthetic draft and have the reviewer find it without an automatic message. This provides a usable route if an alert is delayed. You can keep an internal link to the filtered list in the team's working material after checking that it opens the correct site and view. On a small site, this arrangement may suffice without a new plugin.

Approach 2. Correct the existing alert rule

If an alert previously existed, open its managing tool and find the rule intended for submission. Record its state, status transition, post type, and any category or author filters. Then record whom it targets. Depending on the tool, the target may be an explicit account, role, group, post author, or people already subscribed to that content. Check the actual recipient list on the copy with reference accounts. A rule notifying the post author does not meet a review team's need.

Compare a submission that produced a notification with one that did not, if records are available. A missing category, different previous status, or excluded content type may explain the difference. A new save while a post is already pending is not a new Draft to Pending transition. If the workflow should also flag resubmission after requested corrections, first decide which action marks that new transition and configure a rule matching the decision. Avoid using every save as a general reminder.

Check the recipient account and configured address with necessary permissions and without copying the mailbox into a public document. When the reviewer belongs to several teams, confirm inclusion on the correct site and in the correct group. If another rule covers the same submission, record which should be retained. Two similar emails make it harder to establish which rule actually worked. Copy the configuration or record parameters before changing recipient or trigger.

Approach 3. Create a targeted alert in PublishPress Planner

If the team wants an automatic alert and no installed tool supplies the rule, PublishPress Planner offers status-change notifications in its free edition. Check the plugin listing's prerequisites against the copy's WordPress and PHP versions. With an authorized account, open Plugins > Add New Plugin, search for PublishPress Planner, then install and activate it on the test copy. If an editorial tool already manages the same transition, use its rule through the previous approach to avoid duplicate emails.

Under Planner > Notifications, click Add New and give the rule a name describing its scope, such as “Team post review.” In the panel defining when to notify, select a transition to a new status. Choose Draft as the previous status and Pending Review as the new one. In the content filter, limit the rule to the Post type. Add a category only if it belongs to the workflow. In recipients, choose a staging account or a role whose members all have staging destinations. Labels may vary by language and version. Save the rule, check that it is active, and reread its summary before the first test.

Planner's default rules cover publishing and editorial comments, among other things. Check your new rule on a submission because these other events occur at different times. In the message, provide an understandable subject and a link to the post in the appropriate context. Keep the text short. A title and expected action generally suffice for the recipient. Avoid transmitting confidential excerpts if an administration link serves the same purpose. After an initial positive test, have the message checked with the account that will actually review.

Follow the alert to the recipient

After submitting the reference draft, record its ID and time. If your tool has a log, find the entry corresponding to this event. For Planner, documentation locates the log under Planner > Notifications through the notification logs button. Read the line corresponding to the content and check the trigger, recipient, and reported status. If the rule produced no entry and your version logs this event, return to the status change and filters. Also check that the log belongs to the same site and its displayed period includes the test.

If an entry exists for an unexpected account, return to the rule's target and compare groups. If the entry identifies the correct account and reports sending, continue in the test mailbox and, if necessary, the authorized sending method's logs. A positive WordPress email-function result indicates that the request was processed by the called mechanism. It does not guarantee delivery to the inbox. Check the Spam folder, mailbox filters, or available delivery events within the reviewer's or email manager's access limits.

An installation may also intercept or redirect messages on the copy. Check its test destination before considering absence from the real mailbox a failure. If another email type also fails in the same context, record that observation and examine general sending separately. Changing the status rule will not repair an outage affecting all messages. Conversely, another email's success does not prove the review rule selected the right person.

Prepare a test matrix on an authorized copy

On your authorized copy, configure an email catcher or staging addresses controlled by the team. Check routing with a dummy message to that destination. If the copy inherits production rules, disable editorial outgoing messages unrelated to the test or redirect them to the catcher. Create reference contributor and reviewer accounts with the same capabilities as usual roles. Prepare an included post, an out-of-category post if the rule filters by category, and excluded-type content able to move to pending. Give contents distinct titles and record submission times. This distinguishes their log entries and received messages.

For the positive case, open the post with the contributor account, submit it, then reload the list with the reviewer account. Status must match the intended transition. Next check receipt in the test mailbox and open the link using the reviewer account. Record whether the mailbox contains only one message for this rule and whether the link opens the correct post. For the out-of-scope control, perform the same transition and confirm no message from the rule under study. If several rules remain active on the copy, identify every notification through its subject and log.

1. Submit the included post from Draft to Pending. Exactly one message from the tested rule should reach the staging reviewer.
2. Save a change to that post without leaving Pending. The Draft to Pending rule must not produce another message.
3. Submit the out-of-category post if the rule uses this filter. The post may move to pending. No message from the tested rule should arrive.
4. Move the excluded-type content to the same destination status using an account permitted to do so. Check that the rule restricted to the Post type sends nothing.

Interpret variants without replaying real submissions

To test a new submission, return the dummy post to draft using an authorized account. If another rule monitors that return, isolate it or identify its messages separately. Submit again as the contributor, record the time, and check that a new message corresponds to the Draft to Pending transition. Saving without a status change, checked in the second case, should produce a different result. In a PHP-maintained mechanism, the maintainer must compare old and new status to recognize an actual transition.

If the rule works with an ordinary post but fails with a custom status, ask the maintainer to check both states actually saved by the tool. The displayed label may have been renamed. If the test works only when an administrator performs the transition, repeat using the contributor role. Good evidence associates status, rule, and recipient with the same event. If you find only a publication notification, check that none of the actions published the control when you intended to submit it.

If the message reaches the mailbox but its link leads to production instead of the copy, record the domain and destination used in the template. Correct the link according to the tool's options, then repeat with a new dummy submission. For a team reviewing several sites, add an understandable identifying cue in the message. The reviewer should know which site and post are involved before opening the link.

Validate receipt and plan rollback

Consider the flow restored when the reference account finds the pending post, receives the intended alert, opens the correct post, and can perform expected review actions. Also check a post that must remain excluded, then a save without transition. Record dates, reference content, expected recipients, and the setting that resolved the problem. If validation is limited to an environment where emails are captured locally, record that scope before going live.

To roll back, disable the newly created rule or restore previous parameters of the changed rule. Check that no other editorial rule was accidentally stopped and the native queue remains accessible. If the plugin was installed only for this test, first check that no other process on the copy came to rely on it before removing it. A message already delivered remains in the recipient's mailbox. If the installation queues notifications, ask the person responsible how to handle those still pending before changing the workflow again.

Finish by removing reference content and accounts according to your copy's rules. Keep only the record useful to the team, with the active rule, scope, workflow owner, and verification method. If a notification is reported missing in the future, this record indicates where to check status, triggering, and destination first.

PHP alternative for a precise editorial transition

For a workflow limited to Draft → Pending posts, a maintainer can use the native hook. Place this fragment in a copy-specific plugin or PHP snippet manager without running it alongside the corresponding Planner rule. Replace 123 with the ID of the staging reviewer whose emails are captured.

The recipient must have permission to edit this post. The message avoids sending draft content. This free alternative provides no log, retry queue, or category rules: Planner is more suitable if the team needs to manage these without editing code. It does not cover a custom status or a direct transition from another state to Pending.

Check one submission, one save without status change, and a new submission after returning to draft. Only the two transitions should produce a message. A positive wp_mail() return does not prove receipt: check the catcher or intended mailbox. To roll back, disable only this fragment and confirm that the native queue remains accessible.

add_action('transition_post_status', function ($nouveau, $ancien, $article) {
    if ('post' !== $article->post_type || 'draft' !== $ancien || 'pending' !== $nouveau) {
        return;
    }
    $relecteur = get_user_by('id', 123);
    if (!$relecteur || !user_can($relecteur, 'edit_post', $article->ID)) {
        return;
    }
    $lien = admin_url('post.php?post=' . absint($article->ID) . '&action=edit');
    wp_mail($relecteur->user_email, 'Un article attend votre relecture', $lien);
}, 10, 3);