Global Settings

Website Title and Author Email are two of the simplest global settings — but they ripple out across countless pages, emails, sitemaps and external integrations. Getting them right early saves cleanup later.

Where the Title Appears

• HTML <title> tags on every page (suffixed after page-specific titles).
• RSS / Atom feed titles.
• OpenGraph metadata (when not overridden per page).
• Sitemap.xml top-level entry.
• Email template footer signatures (where defaults apply).
• Default placeholder in printable documents.
• The system's audit log entries identifying which platform performed the action.

Where the Author Email Appears

• RSS / Atom feed managingEditor field.
• Default From header on system-generated emails (unless a more specific sender is configured).
• OpenGraph article:author tag.
• Sitemap submission emails to search engines.
• Default contact in error reports sent to external aggregators.

Best Practices

• Keep the title short (under 60 characters) so it doesn't get truncated in search results.
• Make it clearly identifiable — no cute codenames unless the codename is also the brand.
• Use a monitored email for Author Email — not noreply@, since RSS readers and external aggregators may send legitimate replies.
• If you white-label per tenant, override these at tenant level rather than only setting the global.

Worked Examples

• SaaS platform: Title “Acme Workspace”, author hello@acme.io.
• Internal tool: Title “Operations Hub”, author operations@yourcompany.com.
• Multi-tenant white-label: Global title “Generic Platform”, but Tenant A overrides to “Tenant A Portal” and provides their own contact.
• Public marketplace: Title “Marketplace by Brand”, author support@brand.com.

The copyright line appears in the footer of every page and many emails. It's a small detail that signals professionalism, legitimacy and brand consistency.

What to Set

• Copyright text: The notice itself, e.g. “© 2026 Acme Ltd. All rights reserved.”.
• Copyright link: Optional URL the notice links to — usually your terms or about page.
• Year auto-update: Use the {{year}} token so the year refreshes each January without manual edits.

Where It Appears

• Footer of every public page.
• Footer of admin pages (smaller, less prominent).
• Footer of HTML emails (where the template inherits from the global setting).
• Printable PDFs generated from document templates (where the template uses the token).

Legal Considerations

• The “©” symbol isn't strictly required by law in most jurisdictions, but it's conventional.
• The year should be the year of first publication or the most recent edit — typically the latter for ongoing services.
• “All rights reserved” is largely traditional; copyright protection exists regardless of the phrasing.
• For multi-tenant deployments, each tenant should set their own legal entity name.

Worked Examples

• UK SaaS: “© {{year}} Acme Software Ltd. All rights reserved.” linking to /legal/terms.
• US SaaS: “© {{year}} Acme Inc. All rights reserved.”.
• Creative Commons offer: “© {{year}} Acme — content licensed under CC-BY-SA.”
• Multi-tenant override: Global default; each tenant supplies their own “© {{year}} TenantName Ltd.”.

The database character set determines which characters can be stored in your tables and how they're encoded. Get it wrong and you'll see “?” marks where emojis should be, or mangled accented characters. Get it right and everything just works.

Recommended: utf8mb4

utf8mb4 is the modern correct choice — it supports the full unicode range including emojis (😀, 🎉), uncommon CJK characters, mathematical symbols and ancient scripts. New installations default to utf8mb4 throughout.

Why Not Just utf8

MySQL's utf8 historically supported only 3-byte unicode characters (Basic Multilingual Plane). Emojis live in the supplementary planes and require 4 bytes. Storing an emoji in a utf8 column either truncates the data or throws an error.

Where the Character Set Matters

• Table definitions (per-table DEFAULT CHARSET).
• Column definitions (per-column override).
• Connection charset (set on each new connection).
• Database default (used when CREATE TABLE doesn't specify).
• HTML page meta tag (<meta charset="UTF-8">).
• HTTP response Content-Type charset.

Migrating from utf8 to utf8mb4

1. Backup the database. This is reversible but important to insure against errors.
2. Set the global default to utf8mb4.
3. Convert each table: ALTER TABLE x CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci.
4. Restart the application so new connections use utf8mb4.
5. Test with an emoji-containing record.

Worked Examples

• Consumer-facing app: utf8mb4 throughout — users use emojis everywhere.
• B2B legacy system: utf8 sufficed for years; migrating now because a customer's company name includes a special character utf8 can't store.
• International SaaS: utf8mb4 essential to support all locales.
• Highly-restricted legacy: latin1 — only viable if all input is guaranteed to be Western European; emoji submission throws an error.