Documentation

Every dashboard page carries a support button in the floating cluster at the top-right — third in the row, after the dark-mode toggle and the exit-to-website link. Clicking it opens a modal where the user picks what kind of request this is (report a bug, suggest a feature, ask for help), types a subject and the details, and sends. The message is emailed straight to the WebProCMS support desk with the site's install details attached, and a reply goes back to the person who sent it.

The problem

When something looks wrong on a site, the person who notices it is standing in the dashboard — not in their email client. Asking them to switch context, remember the support address, describe which site they're on, and dig up their CMS version means most small reports never get sent at all. The ones that do arrive usually open with a round-trip: which install is this? what version are you on?

The fix

A support form where the problem is, pre-loaded with the answers to the triage questions. The user types two fields; the install supplies the rest.

The three request types

The type is a required choice, rendered as three cards. It sets the subject-line prefix so requests sort themselves in the support inbox.

The full subject is [<type>] <install host>: <subject>, so the inbox shows which site each request came from without opening it.

What gets sent

Alongside the typed subject and details, the email carries a short diagnostics table so support doesn't have to ask:

• Site name and install URL
• The dashboard page the request was sent from
• CMS version, PHP version, Laravel version
• Update engine (package or git)
• The last four characters of the license key — enough to match the install to its Member record. The key itself is never sent.
• The sender's role, and the send time in the site's timezone

The modal states plainly what is attached ("Your name, email, site address, and CMS version are included so we can help faster") — nothing is collected silently.

Attaching recent server errors

Bug reports and help requests offer an Attach recent server errors checkbox, checked by default. It sends the five most recent entries from this install's own error log (within the last 7 days) — each with level, exception class, message, file:line, the page URL and method, and the occurrence count — plus the full stack trace of the newest one.

It never sends visitor data. The ip, user_agent, user_id, and request context columns are all omitted: they describe who was browsing, not what broke. The email says so where the errors are listed.

Two deliberate constraints:

• Admin-only. The checkbox is gated to Admin and above, matching the role:admin route on the Error Log page. A Manager cannot read these entries in the dashboard, so they cannot mail them out either — and unchecking is not required, a Manager's report simply carries no errors even if the property is set.
• Hidden for feature suggestions. An idea for a new capability has no error to explain, so the checkbox only appears for bug and help requests. (The type picker is wire:model.live so it appears and disappears as the type changes.)

The gate deliberately does not check whether any errors exist. This modal renders on every dashboard page and error_logs.last_seen_at carries no index, so a per-page-view existence check would buy a slightly more precise checkbox with a table scan. Attaching when nothing recent has errored simply attaches nothing, and the email omits the section.

Why this is not redundant with error telemetry

Installs already stream a scrubbed error digest to the mothership on the 6-hourly license check-in (see Error Telemetry). That feed answers "is the fleet erroring?" — up to 20 deduplicated signatures, with no stack traces, no URLs, and no request context, arriving up to six hours late, and switched off entirely by any install that opts out of telemetry.share_errors.

A bug report needs the opposite shape: full detail about a handful of errors, right now, tied to a human explaining what they were doing. The attach option is the consent gate for that richer local data, and it works even on an install that has telemetry turned off.

Reply-To is the person who sent it. The email leaves with the site's own From address but a Reply-To of the requesting user, so hitting reply in the support inbox answers them directly rather than the site's generic mailbox.

Delivery

Mail is sent through the install's own mailer, synchronously — production installs run the database queue driver with no worker, so a queued support request would sit forever undelivered.

If that send fails (an install with unconfigured or broken mail settings), nothing throws and no error page appears. The modal reports the failure inline and names the support address so the user can email it directly from their own client. The failure is logged as a warning.

Each user may send five requests per fifteen minutes. A sixth is turned away with a message asking them to wait — enough headroom for a real burst of bug reports, not enough to hand someone an accidental mail relay.

Reaching it on mobile

The floating cluster is desktop-only, so on smaller screens the same modal opens from Get Support near the bottom of the sidebar, beside Language Settings and View Website. Both triggers open one modal instance, mounted outside the (hidden-below-lg) cluster so the dialog can open at any screen size.

White-label installs

CMS_SUPPORT_EMAIL repoints the widget at a reseller's own support desk, so an agency's client sends requests to the agency rather than to WebProCMS. Setting it empty removes the widget entirely — both the floating button and the sidebar item disappear, and the modal is never rendered.