Skip to main content

1.30.0 - Make the WordPress system emails look like they came from your site

· 5 min read
Konstantin Brazhnik
Senior Full Stack Engineer @ Yoko Co

WordPress sends its password resets and account notices as plain text that could have come from any site on the internet. 1.30.0 adds the option to send them as HTML carrying the site's own logo, colour and fonts, with a new Appearance > Email Branding screen to switch it on and rewrite what the four most visible ones say. It ships off — updating changes nothing an account holder receives until a site opts in. The Login Screen customiser moves to Appearance beside it, and both now inherit the block theme's main colour when no colour is set.

  • [NEW FEATURE] The WordPress system emails can now be sent as branded HTML: the site's logo across the top, its brand colour on the bar, the button and the links, and its theme fonts throughout. Off until switched on under Appearance > Email Branding. Covers the password reset, the new user welcome, the password-changed and email-changed notices, the two administrator notifications, and the comment notification and moderation emails. Every one is sent as multipart/alternative, so a plain-text reader still gets exactly the copy WordPress wrote. See Email Branding.
  • [NEW FEATURE] Adds Appearance > Email Branding, with the master switch at the top of it, and where the logo, the brand colour and the footer are set, and the subject and body of the four user-facing emails can be rewritten. The preview works while branding is off, so a site can be set up and looked at before anything reaches a recipient. Leave a field empty and WordPress's own wording is used — including after a WordPress update changes it, which is the reason to leave it empty unless there is a reason not to.
  • [NEW FEATURE] Every placeholder an email understands is a button under its fields: clicking one inserts it at the cursor, and hovering says what it resolves to. A line containing nothing but a link becomes the email's button, which is how the stock reset email produces one.
  • [NEW FEATURE] Send a test email delivers the email being previewed, with the settings currently on screen — saved or not — to any address.
  • [IMPROVEMENT] The Login Screen customiser moves from Settings to Appearance, beside Email Branding. It is theme work, not a setting.
  • [IMPROVEMENT] Both screens inherit the block theme's main colour when no colour is set — its button background, then its link colour, then a palette entry named primary, brand or accent — and each panel says which of the sources is in use, so an empty field does not read as a broken one. The emails take the theme's fonts the same way.
  • [IMPROVEMENT] Adds the yoko_email_branding_enabled, yoko_email_branding_color, yoko_email_branding_logo_url and yoko_email_branding_html filters, plus yoko_branding_primary_color, yoko_branding_body_font and yoko_branding_heading_font — the last three shared by the login screen and the emails, and the hook a classic theme uses to name a brand colour its stylesheet never described.
What changes for recipients after updating

Nothing, until someone switches branding on. It ships off, so every system email keeps going out exactly as it does today. Opting in is one toggle at the top of Appearance > Email Branding, and switching it back off restores plain text on the next email — nothing is stored in a branded form.

The login screen is the one thing that does change on update: a site that never chose an accent colour will pick up its theme's main colour. The old #2271b1 default emitted no styling at all, so that value is migrated to empty once; a site that deliberately chose WordPress blue should set it again.

Where the branding comes from​

Beyond the switch, nothing has to be configured for a site to look like itself. The logo falls back to the Site Icon, the colour to the block theme's, and the fonts to the theme's typography — so on a site with a Site Icon and a block theme, opting in is the only step, and the settings screen is for overriding those rather than supplying them.

Only the WordPress system emails are touched. A Gravity Forms notification, a WooCommerce receipt or any other plugin's mail goes out exactly as that plugin built it.

For the team​

Nothing below reaches a client site — none of it is in the release zip:

  • The dev/ Docker environment now runs Mailpit beside WordPress, and every wp_mail() the site sends lands in it instead of failing silently against a sendmail the container never had. ./dev.sh mail prints the inbox, ./dev.sh mail clear empties it, and WP-CLI-sent mail goes there too.
  • The PHPUnit suite can be run in a cloud session after all, against that stack's MySQL. The dev-site skill has the four setup steps, and names which failures belong to that environment rather than to the change under test.
  • A feature is now expected to end at the origin: pushed, with a pull request opened unasked, its screenshots in the PR body, and the Playground demo link in the reply. AGENTS.md has the rule and the deployment skill has the sequence.