# support: use cases

## Privacy statement

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](docs/PRIVACY.md).

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md

## Where the screen lives

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

| Location | Meaning |
|---|---|
| `toplevel` | Own top-level menu (position filterable). Default **when a registered plugin has vendor "Mammoth WP"**, titled "Mammoth WP" with the submenu "Support". |
| `tools` | Tools → Support. Default otherwise (neutral title "Support", no new top-level menu). |
| `settings` | Settings → Support. |
| `parent:<menu-slug>` | Submenu of any existing menu. |
| `hidden` | Registered page without a menu item (shortcuts and links only). |

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.

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md

## White-label

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](docs/WHITELABEL.md).

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md

## Site-owner overrides

| Setting | Constant | Filter | Order |
|---|---|---|---|
| Recipient | `MMWP_SUPPORT_EMAIL_<SLUG_UPPER_UNDERSCORED>` | `mmwp_support_email` | filter > constant > array > JSON |
| Menu location | `MMWP_SUPPORT_MENU` | `mmwp_support_menu` | filter > constant > default |
| White-label | `MMWP_SUPPORT_WHITELABEL` | `mmwp_support_branding` | filter > constant > vendor > defaults |

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md

## Adding a report section

```php
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.

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md

## Single instance across many plugins

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](https://github.com/BrianHenryIE/strauss)) 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.

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md

## Transport

`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.

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md

## Branches

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

Source: https://github.com/mammothwp/support/blob/v1.1.1/README.md