Messaging dynamic tags

Messaging adds paths to groups you already use, so a button that starts a conversation is built the same way as anything else in the picker.

Everything here works in Elementor, Bricks, the block editor's bindings, and anywhere VX expressions run.

Starting a conversation

These are added to @post, @author, and @user. Which one you reach for decides what the conversation is about.

Tag	What it gives you
@post(message_url)	A link to the post's author, with the post as the subject
@author(message_url)	A link to the post's author, with no subject
@user(message_url)	A link to whoever the template is about

On a listing template, @post(message_url) is almost always the one you want: the conversation arrives carrying the listing, so the owner can see what it is about.

Hiding the button when it would not work

message_url returns nothing when the viewer cannot message that person — signed out, blocked, or looking at their own listing. A link with an empty URL still looks like a button, so pair it with a visibility rule:

Tag	Use
@post(can_message)	1 or 0 — show the button only when it leads somewhere
@post(is_messageable)	The same thing under a second name

A worked example on a listing template:

1. Add a Button.
2. Set its link to @post(message_url).
3. Add a visibility rule: Expression @post(can_message) is 1.

That is the whole integration. No widget to place, no shortcode.

Response figures

How quickly and how often somebody answers, for a listing page. They need Messaging → In the conversation → Response figures on.

Tag	What it gives you
@author(response_time)	A phrase: within minutes, within an hour, within a few hours, within a day, within a few days
@author(response_rate)	A whole number — the percentage of conversations they have answered
@author(answers)	1 when there are figures worth showing, 0 when there are not

A phrase rather than a figure on purpose. "Usually replies in 47 minutes" invites an argument the site owner cannot win; "within an hour" does not.

All three are empty until there are at least three conversations to judge, so a new vendor shows nothing rather than something unflattering worked out from two samples. Wrap the whole block in a rule on @author(answers) so the row disappears rather than rendering half-filled.

Usually replies within an hour · answers 89% of messages

They work on @post and @user as well, always about the person.

The viewer's own inbox

The @inbox group is about whoever is looking at the page.

Tag	What it gives you
@inbox(url)	The Messages page
@inbox(compose_url)	A bare composer, for a "New message" link. Empty when the member directory is closed
@inbox(unread_threads)	Conversations with something unread in them
@inbox(unread_messages)	Unread messages across all of them
@inbox(unread_mentions)	Unread messages that named this person
@inbox(has_unread)	1 or 0
@inbox(thread_count)	How many conversations they have
@inbox(can_start_new)	1 when this member may start a conversation from the directory

The unread badge on a cached page

Read this before putting a count in your header

The counts above resolve on the server. On a page rendered per visitor that is right. On a page held by a full-page cache it is not: the first member to load it bakes their number into the cache, and everybody after them is shown it — stale for them, and a small piece of somebody else's business.

Use the shortcode instead. It renders identically for every visitor and fills in afterwards, per viewer, from a request the cache does not touch.

[vxm_unread]

Attribute	What it does
zero	What to show at nought. Leave it out and the badge is simply absent until there is something to say
class	Added to the badge, so your own CSS can take it over

[vxm_unread zero="0" class="header-pip"]

Two custom properties carry the colors if you would rather not write a rule:

.vxm-unread { --vxm-unread-bg: #111; --vxm-unread-ink: #fff; }

The url and compose_url tags are safe on a cached page either way — they are the same for everybody.