Get Pro 0

Multisite

Network admin configuration, per-site inheritance and overrides, and locking fields network-wide.

Articles

WordPress Multisite Overview

Network-activate NimblyMail once and every sub-site inherits the network defaults you configure, with optional per-field overrides.

WordPress Multisite

NimblyMail has first-class support for WordPress Multisite. Network-activate the plugin once and every sub-site inherits the network defaults you configure, with the option for site admins to override individual fields. How Inheritance Works Every setting resolves through a fixed precedence order. The first layer that defines a value wins: PHP constant in wp-config.php (e.g., NIMBLY_MAIL_SMTP_HOST) […]

Network Admin Interface

Navigation: Network Admin > NimblyMail Once the plugin is network activated, super admins get a dedicated NimblyMail menu in the Network Admin with three pages: Dashboard, Sites, and Settings. Network Dashboard Navigation: Network Admin > NimblyMail > Dashboard The dashboard aggregates delivery metrics across every sub-site on the network: Sent (24h) / Failed (24h) — […]

Inheritance & Per-Site Overrides

NimblyMail stores settings sparsely on multisite: each sub-site’s option row only contains the fields it has explicitly overridden. Everything else resolves through the inheritance chain. Precedence The first layer that defines a value wins: PHP constant in wp-config.php — read-only everywhere on the network. Network lock — super admin has pinned the field. See Locking […]

Locking Fields Network-Wide

Sometimes super admins need a setting to be mandatory across the whole network — for example, every sub-site must use the same transactional SMTP account, or the failure-alert recipient must always be the platform operator. NimblyMail exposes two mechanisms for this: PHP constants (strongest, read-only everywhere) and network locks (configured in the admin UI). PHP […]