support: use cases

Nothing leaves the site without an explicit user action (wordpress.org guideline 7). The package has no tracking, no phoning home, no remote assets, no update checks and no automatic sends. The only outgoing data is the one email a logged-in administrator sends by pressing Send. The site report is added only when they tick Include site report, and Preview what will be sent shows the exact text. Secrets are never collected and a redaction pass runs over everything. Copy-paste text for your readme.txt: docs/PRIVACY.md↗ (opens in a new tab).

One canonical screen; plugins can only add shortcuts to it, never move it.

Site owners override with the constant MMWP_SUPPORT_MENU or the filter mmwp_support_menu (the filter wins). A plugin adds a shortcut under its own menu with 'menu' => [ 'parent' => 'my-plugin-settings', 'title' => 'Support' ]; it links to the canonical screen with that plugin preselected. Every registered plugin also gets a "Support" action link on the Plugins screen (mmwp_support_action_link turns it off). Support::MENU_PARENT (mmwp-support) is the top-level menu slug, so Mammoth WP plugins can add pages under it. In multisite the screen is per site, plus a network admin screen when a registered plugin is network-activated.

wp mmwp support plugins and the report show the resolved location and where it came from.

Branding (name, menu and page titles, icon, local logo, subject prefix, reference prefix, "Powered by", vendor names) resolves from defaults (Mammoth WP when a Mammoth WP plugin is registered, neutral otherwise), then a plugin's 'branding' array (honoured only when every registered plugin has the same vendor), then the site owner's MMWP_SUPPORT_WHITELABEL constant (true = fully neutral, or an array of overrides), then the mmwp_support_branding filter. Agency guide: docs/WHITELABEL.md↗ (opens in a new tab).

add_filter( 'mmwp_support_report_sections', function ( array $sections ): array {
    $sections[] = new My_Plugin_Report_Section(); // implements \MammothWP\Support\Report\Section_Interface
    return $sections;
} );

Section_Interface has key(), label() and collect() (scalars, lists or one level of associative arrays). Contract: no secrets (no keys, tokens, passwords, customer data). A redaction pass over the whole report removes absolute paths (ABSPATH), emails, IP addresses, URL credentials, key=value pairs with secret-looking keys, JWTs and long tokens, but do not rely on it.

Every bundled copy registers its version and path in a shared registry. On plugins_loaded (priority -50) exactly one copy boots: the highest version. It prepends a class loader for MammothWP\Support\ pointing at its own src/, so its classes are the ones used. Only Support (a thin shim) and the functions in bootstrap.php come from whichever copy loaded first, so they stay tiny and backwards compatible forever. register_plugin() may be called before boot (queued, replayed) or after (applied at once). The menu appears only if at least one plugin is registered.

Bundling

wp-kit has no election across plugins: whichever copy loads first wins. Prefix bundled libraries (for example with Strauss↗ (opens in a new tab)) so your copies cannot collide with another plugin's. This package guards against it (it checks the loaded wp-kit version) but cannot fix it.

TransportInterface with one implementation, MailTransport (wp_mail()); swap through mmwp_support_transport. There is no API transport. Any future one needs the same explicit user consent.

develop is the working branch. main is release-only.