# Plugin compatibility

The short answer: plugins work. Sirius Press changes how people sign in, not
how WordPress works. Roles, capabilities, nonces, the options API, the REST
API, the hook system and `wp_mail()` are all untouched, so a plugin that does
not ask "what is this user's email address?" cannot tell the difference.

The rest of this page is the long answer, for the plugins that do ask.

---

## The mechanism

Every account has a `user_email`. It is a placeholder under a domain ending in
`.invalid` — a top-level domain [RFC 2606](https://www.rfc-editor.org/rfc/rfc2606)
reserves precisely so that it can never resolve anywhere, ever.

This matters more than it sounds. `$user->user_email` is read in thousands of
places across the ecosystem, usually without a null check. Leaving it empty
would produce warnings, blank "From" headers and outright fatals in other
people's code. Filling it with something permanently undeliverable means every
one of those reads returns a string and behaves normally.

Mail addressed to one of those placeholders never reaches a mail transport. It
is caught by `pre_wp_mail` and delivered to the **Sirius Press inbox**, where
the recipient reads it while signed in. That is where password-reset mails,
comment-moderation notices, update nags and "your plugin needs attention"
messages end up.

Mail addressed to a real domain is passed straight through. If you configured
SMTP, it sends. If you did not, it fails exactly as stock WordPress fails.

`is_email()` is left completely alone, and it is worth saying why, because
the obvious guess is wrong. WordPress validates an address's *syntax*, not
whether its domain could ever exist — so `.invalid` addresses already pass
`is_email()` unchanged. No shim is needed to make the placeholders acceptable
to plugins that validate, and none is shipped. (Verified against WordPress
7.1.1; an earlier draft of this fork carried a filter based on the wrong
assumption, and it never fired.)

The flip side is that `is_email()` will also accept `someone@example.invalid`
typed into a contact form by a visitor. That is stock WordPress behaviour, not
something this fork introduced, and it is the contact form's business to care
about.

---

## The top ten

Three of these were installed and activated on a Sirius Press 0.1.0 instance
running WordPress 7.1.1, with all four fork plugins active, and the whole
wallet sign-in suite re-run with them loaded. Those rows say **tested**. The
rest are reasoned from each plugin's setup and activation path and say
**expected** — treat them as claims awaiting a test, and report anything that
behaves differently.

| Plugin | Status | Notes |
|---|---|---|
| **Yoast SEO** 28.6 | tested — activates cleanly | No errors on any admin screen with it loaded. Reads `admin_email` for schema output and gets the placeholder. Its XML sitemaps export to your name along with everything else. |
| **Contact Form 7** 6.1.7 | tested — activates cleanly | Forms build and save. The default recipient is the placeholder, so submissions land in the inbox — fine for a small site, not what you want for a real contact form. Set a real address and configure SMTP. |
| **WooCommerce** 11.1.1 | tested — activates cleanly | Store and admin work. Order emails to customers use the address the customer typed, so they send once SMTP is configured. One behaviour worth knowing: WooCommerce redirects subscriber-role accounts away from wp-admin, so a newly registered reader lands on the shop rather than their profile. That is WooCommerce's own setting, not this fork's. |
| **Elementor** | expected to work | No email dependency. Pages built with it export normally. |
| **Wordfence** | expected to work | Alert emails go to the inbox unless you set a real address. Its login-security features overlap with wallet auth; two-factor on top of a signature is redundant, and its "email me a code" option cannot work. |
| **WP Super Cache / W3 Total Cache** | expected to work | Compatible, but consider whether you need them: the static export already serves cached HTML from the name, which is the harder-working cache. |
| **Akismet** | expected to work | Needs an API key, obtained on akismet.com with a real address of yours. Nothing to do with site accounts. |
| **Jetpack** | expected to work partly | Connection requires a WordPress.com account. The modules built around subscriber email lists cannot do anything useful here. Not recommended. |
| **UpdraftPlus** | expected to work | Backups work. Report emails go to the inbox. Back up `wp-config.php` too, or you lose `SIRIUS_PRESS_KEY` and with it the stored publishing phrase. |
| **Advanced Custom Fields** | expected to work | No email dependency at all. |

"Activates cleanly" means the plugin activated without a fatal or a WP_Error,
and every Sirius Press admin screen plus Users, Profile and Plugins rendered
with no PHP diagnostic while it was loaded.

---

## What genuinely cannot work

Not because of a shim we did not write, but because the feature is the mailbox:

- **Email-based two-factor.** There is no mailbox to send a code to.
- **Newsletter plugins managing your site's own accounts.** A newsletter to a
  list of real addresses people typed into a form works fine. A newsletter to
  "all subscribers" does not, because subscribers have wallets, not mailboxes.
- **"Email me when someone comments" for account holders.** Goes to the inbox
  instead, which the person sees next time they sign in.
- **Password reset by email.** Deliberately removed. See
  [accounts.md](accounts.md).

---

## Making a plugin behave

If a plugin refuses to finish its setup because of a missing address, the usual
fix is one filter:

```php
add_filter( 'pre_option_their_email_setting', function ( $value ) {
	return $value ?: 'admin@' . SP_Settings::stub_email_domain();
} );
```

`sirius-press-compat` is a short file of exactly these. If you write one for a
plugin not listed here, it is worth sending — the whole file is under a hundred
lines of real code and it grows one plugin at a time.

If a plugin sends mail to a real address and it does not arrive, that is an
SMTP problem rather than a Sirius Press one: see [smtp.md](smtp.md).