How enquiries work

This page follows one enquiry from the button to your inbox, and documents how the dialog behaves.

The shopper’s experience

1. On a single product page the shopper sees the Ask a question button directly under add to cart (it is hooked to woocommerce_after_add_to_cart_form).
2. Clicking it opens a native <dialog> via showModal(). Focus moves to the first field, the rest of the page is inert, Escape closes the dialog, and a click on the backdrop outside the panel closes it too. On close, focus returns to the button that opened it.
3. The shopper fills in the fields you marked required and submits. Required fields are checked first by the browser’s own reportValidity() before anything is sent.
4. The submit button sets aria-busy and disables while the request is in flight. On success an inline message appears in an aria-live="polite" status region, the form resets, and a small “sent” seal is revealed inside the panel, no page reload.

The dialog’s open animation is skipped under prefers-reduced-motion. If a browser does not support <dialog>, the form still posts.

What happens on submit

The form posts to admin-ajax.php with a fetch request (no jQuery). On the server, in order:

1. Honeypot. A hidden field named enquire_hp is checked. If a bot filled it, Enquire returns success without sending anything, the bot gets no signal that it was caught.
2. Nonce. A failed or stale nonce returns an error (HTTP 400) asking the shopper to reload.
3. Rate limit. One submission per visitor per 30 seconds, keyed by user ID for logged-in shoppers or a hashed IP for guests, stored as a transient. A second submit inside the window returns HTTP 429.
4. Product + validation. The product is resolved from its ID; the configured required-field rules run; an entered email must be a valid format even if email is optional. Validation failures return HTTP 422 with the combined messages.
5. Send. Enquire builds the email and calls wp_mail(). If the mailer returns false, the shopper sees your error message (HTTP 500) and the hook does not fire.

After a successful send the rate limit is recorded and enquire/enquiry_sent fires. See the developer hook.

What the email contains

A plain-text email to your recipient (or the admin email if none is set):

• Subject, your Email subject with {product} replaced by the product name, e.g. Product enquiry: Blue Mug.
• Body, a line naming the product, its permalink, then the submitted Name, Email and Message.
• Reply-To, the shopper’s address, with their name when given (Name <email>), so a reply goes straight back to them.

If a field was left blank and not required, the body shows (not provided) for name or email and (no message) for the message, so the email is always readable.

Where it loads

The front-end CSS and the single defer JavaScript file load only on single product pages (is_product()), and only while Enable enquiries is on. Every other page is untouched. The plugin declares WooCommerce HPOS and Cart & Checkout Blocks compatibility.

Replying

Open the email and hit reply. Because the shopper’s address is the Reply-To, your answer goes to them from your normal inbox, there is no dashboard or separate tool, and nothing to mark as resolved.

Accessibility notes

The dialog is a real <dialog> labelled by its title via aria-labelledby. Every field has a real <label>; required fields are marked with both the required attribute and a visual asterisk. The status region is role="status" with aria-live="polite", so results are announced. The honeypot input is inert and aria-hidden, kept out of the tab order and away from screen readers. Built with WCAG 2.2 AA in mind.

No shortcode

There is no shortcode and no template override path in the free edition, the button is placed automatically by the WooCommerce hook above. Developers who need to react to enquiries use the enquire/enquiry_sent action.