New Review: Tokens are not being translated in email

General Reviews
1

When a review is approved, the confirmation email from hive press is not replacing the tokens and including them in the email.

The email for Review Approved, the customer gets this email:

Your listing Business Name just received a new review:

New feedback (%listing_url%)

%review%

Steps to reproduce

User submits Review and Review is approved.

Actual result

User receives email including the tokens and the user cannot see/access the review.

Expected result

The tokens should be swapped out for the actual content.

Extra details

Also I would like to hyper link these but I am not allowed to make the link: %listing_url% or because then browsers gets error trying to literally go to: http://%listing_url%

2

Hi,

Thank you for the details.

Could you please clarify if you’ve customized this email template in WP > HivePress > Emails? The default template for the Review Approved email works correctly. We tested it on our end and received an email with all the details.

If you’re trying to customize the email, please note that tokens like %review% are object types and require you to specify which data from the object you want to use. For objects, you need to add the desired field using dot notation [the available fields of objects can be found in the code of an extension]. For example, if you want to display the review text, use the %review.text% token. If you let us know what specific information you’d like to show in the email, we’d be happy to provide the appropriate tokens for you.

I realize that it can sometimes be a little confusing, and we’ll work on improving the UI with prompts.

3

Hi HivePress team,

Thanks for the quick reply!

Yes — we customized the “Review Approved” email in WP → HivePress → Emails. The default works on your side; on ours the customized version was using tokens like %listing_url% and %review% (object roots), which I now understand is incorrect.

To get this right, can you please confirm the exact token paths for the fields we want to display?

What we want in the vendor notification (Review Approved):

  1. Listing title (as a link to the listing)

    • I believe this should be:
      Listing: <a href="%listing.url%">%listing.title%</a>
      Please confirm %listing.url% and %listing.title%.

  2. Reviewer display name

    • Proposed: %review.user.display_name%
      Please confirm the correct path for the reviewer’s name.

  3. Rating (stars/number)

    • Proposed: %review.rating% (or whatever field you use for rating).
      What’s the correct token for the numeric rating?

  4. Review text/body

    • From your note: %review.text%
      Please confirm this is the right field to show what the user typed.

  5. Our custom Review ID to help our support team track references

    • We registered a field on the Review model and store it in comment-meta. Can you confirm that the following is the correct approach so %review.review_id% becomes available in templates?
// Register Review field so %review.review_id% resolves
add_filter( 'hivepress/v1/models/review', function( $model ){
    $model['fields']['review_id'] = [
        'type'      => 'text',   // per your guidance
        '_external' => true,     // expose to tokens/templates
    ];
    return $model;
}, 100 );

// Store value in comment meta where HP reads model fields for reviews
add_action( 'hivepress/v1/models/review/create', function ( $comment_id, $review ) {
    if ( ! get_comment_meta( $comment_id, 'hp_review_id', true ) ) {
        $code = strtoupper( wp_generate_password( 4, false, false ) ); // e.g., WTQZ
        update_comment_meta( $comment_id, 'hp_review_id', $code );
    }
}, 10, 2 );

  • We assume the meta key must be hp_review_id so that %review.review_id% is populated. Is that correct?

  • We also understand custom fields won’t appear in the token picker UI, but should still render if the field exists.

Proposed final template (please sanity-check tokens):

Subject: New review for you on %listing.title% ★

Your listing <a href="%listing.url%">%listing.title%</a> just received a new review.

<strong>Reviewer:</strong> %review.user.display_name%  
<strong>Rating:</strong> %review.rating% / 5  
<strong>Review ID:</strong> %review.review_id%

<blockquote>%review.text%</blockquote>

View or reply to this review: <a href="%listing.url%">%listing.url%</a>

Extra dev note: we built a small internal debugger to confirm what tokens are in the bag per event. For this event, we see %listing.title% resolving, but wanted to verify the exact token names for reviewer name, rating, and review text, and that our custom %review.review_id% approach is correct.

If any of the above token paths differ in your implementation, could you share the canonical list for the Review Approved email? That would help us (and happy to post a summary back to the community).

Thank you so much!
William

5

Hi,

Thanks for the details,

  1. Please use the %review_url% token for this purpose as it’s basically the listing URL, with the anchor part that scrolls the page to the Reviews section.
  2. Please try the %review.author__display_name% token.
  3. Yes, this one %review.rating% should work.
  4. Yes.
  5. Yes, if you added a new model field via the hook they you can access it via %review.field_name_here%. In this case, %review.review_id% should work.

Please note that the Review Approved email is sent to the review author, not to the listing vendor. If you want to notify vendors that their listing got a new review, you can use the Review Added email instead.

Sorry for the confusion – we plan to improve the back-end UI to show a full list of tokens for object-based ones (that require field names via the dot). We plan to do this by creating a sample model object and listing its fields via the $model->_get_fields() method.

Hope this helps

6

Hi HivePress team,

Thanks for the guidance, quick update with what we tested and what worked:

What worked (confirmed)

  • Links & fields: %review_url%, %listing.title%, %listing.url%, %review.text%, %review.rating%, and %review.author__display_name% all render correctly.

  • Who gets which email: We’re using Review Approved for the reviewer and Review Added for the vendor (as you noted).

What didn’t work on our install

  • %review.review_id% (custom field) was consistently stripped to blank even after registering a review_id field on the Review model with type => 'text', _external => true, and (for safety) an explicit meta mapping (source => 'meta', meta_key => 'hp_review_id') and a fallback get callback.

  • A flat token we inject at send time, %review_id%, renders perfectly in both events.

Our working solution (usable for others)

  1. We store an alphanumeric code in comment-meta (hp_review_id) on create/update.

  2. We inject a flat token %review_id% into the Review Added and Review Approved token bags.

  3. We added a tiny shim that rewrites %review.review_id% → %review_id% just before HP renders the email, so editors can use either form.

  4. As a last safety net, we added a small wp_mail replacer that, if any %review_id% pattern survives, parses the final %review_url% anchor (#review-123/#comment-123), fetches the code from meta, and swaps it in.

If helpful, we can post a cleaned gist, but the core idea is: use %review_id% in templates and optionally map %review.review_id% to it pre-render for backward compatibility.

Questions (to help us and the docs)

  1. Should %review.review_id% resolve for custom fields today?
    Our assumption (per your note) is “yes,” if the field is registered as text and _external—but on our site it still resolves empty/strips. Is there a known limitation in the email renderer for Review custom fields, or a minimum HivePress version where this is guaranteed?

  2. Preferred way to expose review meta
    Is the source => 'meta', meta_key => 'hp_review_id' mapping officially supported for Review fields in emails, or should we rely solely on a get callback for now?

Small UX/doc suggestions

  • In Emails → Edit, a short hint like “Object tokens require dot notation (e.g., %review.text%, %listing.title%). Bare object roots (e.g., %review%) won’t render.”

  • A built-in “Token Inspector” that shows the token bag for each event (even just top-level keys) would save a lot of guesswork. Your idea to surface $model->_get_fields() sounds perfect.

  • Document %review_url% prominently (super useful).

Thanks again for the help—and for a great plugin. Happy to share our final snippet for the community if you think it’d be useful.

Best,
William

1 Like
8

Thanks for sharing!

  1. Yes, custom fields should be detected if registered for the model, you can find the implementation here hivepress/includes/helpers.php at master ¡ hivepress/hivepress ¡ GitHub An array of fields is fetched from the model using _get_fields(), so if the field is registered via the model hook, it should be there. If the token is replaced (even with an empty value) this means that the field is registered, but maybe the value is not available yet?
  2. These seem like WP-level parameters, there are no such parameters for the HivePress model fields. The _external parameter should be enough – it registers the field as a meta field.

Thanks for the feedback – we plan to improve the UI for the email customization, for example by listing all the available model fields for non-plain tokens.

Hope this helps