Skip to content
This is documentation for version 1.X.X, which may no longer be maintained. Go to the latest version (2.2).

Mail templates and account changes

1.1.2 fixed four things members and operators actually ran into: mails that could not be edited and arrived in the wrong language, account details changed with nobody told, reputation that could not be given at all, and an error log filled with traffic that was never an error.

Mails are editable and arrive in the member's language

AACP → System → Mail templates. Every mail the site sends to a member is editable, with one card per active language; turn on a third language in AACP → Locales and a third card appears. Nine mails are covered: e-mail verification, welcome, waiting-for-approval, account approved, the three account-change notices, and the envelopes around single notifications and the notification digest.

Each member receives them in the language they picked at registration. That choice was recorded but never read back: the language came from whatever request triggered the mail, so an administrator approving an account mailed the member in the administrator's language, and anything sent from a queue worker or cron used the kernel default. The registration form now lists the languages that are actually active, and the profile page has a "language for mail" field.

Fallback order: your wording for that language, then your wording for the site's default language, then the wording that shipped with the release. Clearing a field, or saving text identical to the shipped default, deletes your copy, so an untouched installation keeps receiving improvements to the shipped text. Your text is never run through the translation formatter, so a stray { cannot turn registration mail into an exception.

E-mail and username changes need an administrator

The profile form used to write both straight to the account, a quiet account-takeover primitive. Now the request is held: AACP → Users → Change requests lists it, nothing on the account changes until it is approved, the member keeps signing in with the old details and can withdraw the request. The member is mailed on receipt and on approval or decline; the approval notice goes to the new address. Approval re-validates at the moment you click. Operators can turn this off under Settings → Account → registration; it is on by default.

Reputation no longer needs a topic

The mandatory topic picker only listed topics the recipient had posted in, so it was usually empty. It is replaced by an optional link field. A link to a thread on this forum is recognised and stays connected to the real topic, even if it is renamed or moved.

Quieter, more honest logs

  • 404 and 405 now log at notice level, so scanner traffic (/wp-login.php, /.env) stops filling the error log.
  • A blog category in another language is not a 404: a Turkish slug on the English site redirects to the translated category when there is one, and otherwise shows the archive with a 404 status.

Upgrade notes

Nothing beyond applying the patch. It needs a table (cp_mail_templates) and a column (forum_user_reputations.topic_url), and a patch cannot run migrations, so the code creates both once, the first time they are needed. If the database user cannot run DDL, mails fall back to the shipped wording and AACP → Updates → Apply creates both properly.

Limits

  • The per-event body templates a module ships are still Twig files; only the envelope around them is editable.
Last updated: 16.10.2026