SupportRequestTemplate

Corex\Guides\Support\SupportRequestTemplate · class · Add-ons layer

The Guides support message, wearing the CoreX admin’s face (spec 093). This class extends a Corex Mail base class, so it must never be autoloaded on an install where addons/corex-email is absent — referencing it would fatal on the missing parent. {@see \Corex\Guides\GuidesServiceProvider} guards its only construction with class_exists(), and {@see SupportMailer} keeps a plain-text wp_mail() path for exactly that install (Principle IX: no optional add-on is a hard dependency). Values arrive as {{ support.* }} placeholders and are merged and escaped by {@see \Corex\Email\Template\TemplateRenderer}, so nothing a reader types can become live markup. That is also why the message body is wrapped in a container with white-space: pre-wrap rather than converted to <br>: the newlines somebody typed survive without this template ever concatenating their text into HTML. Styling is inline and table-based because that is what mail clients support — no stylesheet, no custom properties, no flexbox. The colours come from {@see EmailPalette}, the one place every CoreX email takes them from, which explains why they are literals at all. Layout still wraps the result: the 600px shell, the direction, and the site logo are its job. This is the card inside it.

Public API

name(): string

subject(MailContext $context): string

Built from placeholders, not taken from the MailRequest. TemplateRenderer composes the subject from this method whenever a template is named — the request’s own subject is ignored on that path. Returning a literal here would therefore have thrown away the site name and the category, which are the two things that make one of these triageable in a shared inbox, and the loss would have been invisible: the email still arrives. The renderer merges subject placeholders unescaped (a subject is not markup), which is correct and is why nothing here needs esc_*.

body(MailContext $context): string