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:

1. PHP constant in wp-config.php — read-only everywhere on the network.
2. Network lock — super admin has pinned the field. See Locking Fields.
3. Site override — this sub-site has explicitly stored a value.
4. Network default — value saved under Network Admin > NimblyMail > Settings.
5. Plugin default — built-in fallback.

On a Fresh Sub-Site

Immediately after a new sub-site is created, its NimblyMail option row is empty. Every field resolves to the network default (or the plugin default for fields that aren’t configured at the network level).

On the sub-site’s settings page, every field displays an Inherited from network pill next to its label, and the input shows the inherited value pre-filled but unsaved. The pill is a visual marker only — it means "this value comes from somewhere up the chain, not from this site."

Creating an Override

Type a different value, toggle a switch, or pick a different option on any field and press Save Changes. Only the changed fields are written to the sub-site’s option row. Everything else continues to inherit.

After saving, the overridden field shows an Overridden on this site pill and the section grows a Reset to network defaults button.

In the example above, only From Name has been overridden on this sub-site — every other field continues to inherit the network defaults. The Force From Email toggle shown is also inherited (it’s on because the network default has it on).

Resetting an Override

The Reset to network defaults button appears per section (Sender Identity, Logging Settings, etc.) whenever that section contains at least one overridden field. Clicking it:

1. Removes every override stored for fields in that section from this sub-site.
2. Re-fetches the current inherited values so the form repopulates from the network layer.
3. Does not touch overrides in other sections.

Use this to roll a sub-site back to the network defaults for a given area without hand-removing each field.

What Gets Sparse-Stored

All field groups support sparse per-site overrides:

• mail — sender identity (From Email / From Name, Return Path).
• smtp / gmail / ses / resend / sendlayer — provider-specific credentials and options.
• logs — logging toggles, retention, display preferences.
• controls — individual WordPress notification toggles.
• alerts — failure alert recipients, CC, BCC.
• general — miscellaneous (debug, do-not-send, uninstall).

Sensitive fields (passwords, API keys) are still encrypted at rest per the regular credential encryption scheme. Overrides inherit the same protection.

What If I Delete a Sub-Site?

When a sub-site is removed, its nimbly_mail_options row and its wp_<blog_id>_nimbly_mail_logs table are dropped along with the rest of the site’s data. Other sub-sites and the network defaults are untouched.