Site Settings

Site Settings is the central admin UI for platform-wide and tenant-wide configuration. Almost every customisable behaviour — security policies, email senders, payment processors, branding, integrations — has a control in Site Settings.

Top-Level Sections

• General: Site title, timezone, languages, locale defaults.
• Security: Password policy, 2FA, banning, encryption.
• Users: Registration, sessions, password resets, custom fields.
• Communication: Email, SMS, chat, push notifications.
• eCommerce: Carts, payments, discounts, subscriptions.
• Files: Upload rules, storage, conversion, indexing.
• Integrations: Stripe, SendGrid, Twilio, Slack, Azure, Google.
• Logs: Retention, error logging, audit trail.
• Branding: Logo, colours, fonts, headers, footers.
• Advanced: Cache, queues, feature flags, debugging.

Settings Scope

• Platform-wide: Hard-coded defaults shipped with the platform.
• Tenant-wide: Per-tenant overrides — different brand colours, different Stripe accounts.
• Group-wide: Per-security-group overrides — different password policy for admins.
• User-wide: Per-user preferences.

Audit and Change Tracking

Every setting change is logged in the activity log with the before/after value and the user who changed it. Useful when “who turned off 2FA?” comes up months later.

Worked Examples

• New tenant onboarding: Use Site Settings to set up the tenant's Stripe keys, branding logo, password policy.
• Compliance rollout: Site Settings used to enforce stricter password rules, mandatory 2FA and longer log retention.
• Branding refresh: Update logo and colour palette in Site Settings; cascades to every page.
• Feature flag toggle: Advanced section to enable a beta feature on the staging tenant only.

Configuration values come from two places: appconfig.php (a file on disk) and the database (rows in .config). Knowing which source wins for which kind of setting prevents surprises.

appconfig.php

• A PHP file deployed alongside the application.
• Edited by developers; changes go through git.
• Best for: database credentials, encryption keys, environment-specific URLs, anything that's a deployment concern.
• Restart not always required, but cache may need clearing.

Database (.config table)

• Rows in the .config datastore.
• Edited by administrators in the Site Settings UI.
• Best for: business-tweakable values — email templates, branding, password policy thresholds.
• Changes take effect immediately (or on next cache invalidation).

Resolution Order

1. Database value (if present for the current scope: user → group → tenant → global).
2. appconfig.php value.
3. Code-level default.

Best Practices

• Keep secrets out of the database. appconfig.php is the right place.
• Keep environment-specific values out of the database. appconfig.php per environment.
• Keep all business-tweakable values in the database so non-developers can change them.
• Document each setting's preferred source.

Worked Examples

• Stripe secret key: appconfig.php — sensitive, environment-specific.
• Maximum login attempts: Database — admins tune this without redeploying.
• Brand colour: Database — designer changes via the UI.
• Database connection string: appconfig.php — environment-specific.
• Welcome email template: Database — marketing edits the wording.

When the platform behaves unexpectedly, configuration inconsistency is a common cause — appconfig.php disagrees with the database, a tenant override is hiding a global change, a cached value is stale. This article walks through systematic diagnosis.

Diagnostic Tools

• Effective-value lookup: Type any setting key, see which scope's value won and why.
• Source breakdown: For each level (global, tenant, group, user) see the configured value and the source (appconfig.php, database).
• Cache flush: Force the configuration cache to reload from source.
• Audit log: See who changed what and when.

Common Inconsistency Patterns

• Stale cache: DB value updated but cache hasn't refreshed. Click flush cache.
• Tenant override hiding global change: You updated the global value but a tenant has an override that wins. Decide whether to clear the override.
• appconfig.php conflict: appconfig.php has a value that's also set in the DB. The DB wins. Decide which source should be authoritative.
• Wrong scope: You set the value at the wrong scope (e.g. user-level when you meant tenant-level). Move it to the right scope.

Systematic Diagnostic Procedure

1. Reproduce the unexpected behaviour with a test user.
2. Open the effective-value lookup and find the relevant setting.
3. Compare the effective value to what you expected.
4. Use the source breakdown to identify which scope's value won.
5. Decide whether the value is wrong, the scope is wrong, or the cache is stale.
6. Apply the fix at the appropriate scope.
7. Flush cache.
8. Re-test.

Worked Examples

• Password policy not enforcing: Global is 12 chars but the tenant override is 8. Either remove the override or raise the override.
• Stripe key mismatch: appconfig.php has the live key but the DB has a test key. DB wins; switch the DB value to live.
• Stale logo: New logo uploaded but old still appears. Flush cache.
• One user sees an old language: User-level preference was set in the past. Clear that user's preference to inherit current default.

Tip: Run a quarterly “configuration audit” — review which tenants have overrides, whether they're still warranted, and clean up stale ones. Less drift means easier diagnosis later.