Skip to content
Gaurav TiwariDocs

wp-config Constants

Updated October 18, 2026

Core Support encrypts every password, token and API key you save on its screens. Encrypted or not, those values still sit in the database, so they travel with every backup, staging copy and migration export.

The credentials can move into wp-config.php instead: mailboxes, attachment storage, the mail API key, team alerts and every Chat setting. A value defined there always wins, shows read-only on its screen and is never saved to the database. This page lists the 6 constants Core Support reads, with the exact shape each one expects.

How the Constants Behave

  • They win. A constant overrides the same setting saved on the screen.
  • They lock the screen. The matching field or card shows read-only.
  • A broken entry is skipped. An invalid mailbox is ignored and named in a red notice on Core Support → Connections. An invalid alert value is ignored and the saved value keeps working. A broken storage setup sends new files to the database.
  • Multisite needs blog IDs for some of them. Each section says which. The others apply to every site in the network.

Define them above the /* That's all, stop editing! */ line, like any other constant.

CORE_SUPPORT_MAILBOXES

Receiving mailboxes. The outer key is always the blog ID, so use 1 on a single site. A mailbox here wins over a mailbox with the same key on the Connections screen.

define('CORE_SUPPORT_MAILBOXES', [
    1 => [
        'support' => [
            'address'       => 'support@example.com',
            'reply_address' => 'support@example.com',
            'secret'        => '<random, 32 to 256 characters>',
            'token'         => '<random, 32 to 256 characters>',
            'max_bytes'     => 10 * 1024 * 1024,
            'reply_routing' => 'plus',
            'imap'          => [
                'host'             => 'imap.example.com',
                'port'             => 993,
                'encryption'       => 'ssl',
                'username'         => 'support@example.com',
                'password'         => '<app password>',
                'folder'           => 'INBOX',
                'processed_folder' => '',
                'interval'         => 120,
            ],
        ],
    ],
]);
  • Mailbox key (support above): lowercase letters, digits and hyphens, starting with a letter, up to 40 characters.
  • address: required. The support address customers write to.
  • reply_address: optional, defaults to address. Replies go to its plus address. It can’t contain +, and the part before @ must be 37 characters or fewer.
  • secret: required, 32 to 256 characters. Signs Cloudflare relay requests.
  • token: optional, 32 to 256 characters. Turns on automation tools such as FlowMattic and Zapier.
  • max_bytes: optional, default 2 MiB, from 1 MiB to 25 MiB. Core Support caps it at 10 MiB while files are stored in the database.
  • reply_routing: plus (the default) or headers.
  • imap: optional. Leave it out to turn polling off.

The imap array:

  • host: the IMAP server name.
  • port: defaults to 993 for ssl and 143 otherwise.
  • encryption: ssl or starttls. none is accepted only for localhost or 127.0.0.1.
  • username and password: required. Use an app password where the provider offers one.
  • folder: default INBOX.
  • processed_folder: optional. Imported mail moves here.
  • interval: seconds between checks, 60 to 3600, default 120.

Generate secrets and tokens with wp eval 'echo bin2hex(random_bytes(32));' or a password manager. How Email Reaches Core Support explains which route each setting turns on.

CORE_SUPPORT_STORAGE

Where email originals and attachments are stored. It takes one configuration for every site, or a map of blog IDs to configurations like CORE_SUPPORT_MAILBOXES.

// Cloudflare R2
define('CORE_SUPPORT_STORAGE', [
    'driver'     => 'r2',
    'endpoint'   => 'https://<account-id>.r2.cloudflarestorage.com',
    'bucket'     => 'support-files',
    'access_key' => '<access key ID>',
    'secret_key' => '<secret access key>',
]);
  • driver: database (the default), local, s3, r2 or bunny.
  • endpoint: s3 and r2. Must be an https:// URL.
  • region: s3 defaults to us-east-1 and r2 to auto. For bunny, leave it empty for Falkenstein or use uk, ny, la, sg, se, br, jh or syd.
  • bucket: s3 and r2.
  • zone: bunny. The storage zone name.
  • access_key: s3, r2 and bunny. For Bunny, the storage zone password.
  • secret_key: s3 and r2.
  • path_style: s3 and r2, default true. Set false for virtual-hosted buckets.
  • prefix: optional folder inside the bucket. Default core-support. Files go under site-<blog-id>/ inside it.
  • encrypt: default true. Set false to store bucket and Bunny files under their real names. Local files are always encrypted.

['driver' => 'local'] stores private, encrypted files in wp-content/uploads/core-support-private.

A broken configuration doesn’t stop mail. With a missing key, an unknown driver or an endpoint that isn’t https://, Core Support stores new files in the database instead. The Attachment storage health check then fails with the reason, such as Attachment storage is missing "bucket" in CORE_SUPPORT_STORAGE. Check Diagnostics after every change to this constant.

Once files have gone to an external destination, keep that destination in the constant. Existing files depend on it, and the storage migrate command only moves database originals. Store Attachments in the Database, Private Files, R2, S3 or Bunny has the full provider setup.

CORE_SUPPORT_MAIL_API_KEY

The API key for the provider chosen under Settings → Notifications → Mail delivery: Emailit, Resend, Brevo or SendGrid. It’s a plain string and replaces Mail provider API key.

define('CORE_SUPPORT_MAIL_API_KEY', '<provider API key>');

The constant holds one key. If you switch providers, change the constant too. The Mail delivery health check reports “key from wp-config.php” when this constant is in use.

CORE_SUPPORT_ALERTS

Team alert settings. Use one array for the site, or a map of blog IDs to arrays on multisite.

define('CORE_SUPPORT_ALERTS', [
    'telegram_token' => '<bot token>',
    'telegram_chat'  => '-1001234567890',
    'telegram_topic' => '15',
    'discord_webhook' => 'https://discord.com/api/webhooks/...',
    'slack_enabled'  => false,
]);

The keys are the alert setting names:

  • General: alert_new_ticket, alert_customer_reply, alert_preview
  • Switches: telegram_enabled, pushover_enabled, discord_enabled, slack_enabled, webhook_enabled
  • Telegram: telegram_token, telegram_chat, telegram_topic
  • Pushover: pushover_user, pushover_token
  • Discord and Slack: discord_webhook, slack_webhook
  • Webhook: webhook_url, webhook_secret

Values can be strings, integers or booleans. A channel added through the core_support_alert_channels filter reads its own <key>_... settings from here too.

CORE_SUPPORT_CHAT

Any Chat setting, API keys included. It’s one array for the site, keyed by Chat setting name. Keys Chat doesn’t know are ignored.

define('CORE_SUPPORT_CHAT', [
    'openai_api_key'     => '<OpenAI key>',
    'voyage_api_key'     => '<Voyage key>',
    'daily_token_budget' => 500000,
    'retention_days'     => 90,
]);

The keys you’ll most likely want here:

  • API keys: openai_api_key, anthropic_api_key, xai_api_key, deepseek_api_key, voyage_api_key
  • Models: llm_provider, chat_model, embedding_provider, embedding_model
  • Limits: message_max_chars (default 2000), max_turns (30), daily_token_budget (500000), max_response_tokens (1200)
  • Privacy: retention_days (180), moderation_enabled (true)
  • On or off: chat_enabled (false), handoff_enabled (true)

The core_support_chat_default_settings filter lists every key with its default. Values from the constant are used as written, so match the type of the default. Set Up Chat: Provider, Models and Placement explains what each setting does.

CORE_SUPPORT_TRUSTED_PROXIES

Reverse proxies whose forwarding headers Chat trusts when it reads a visitor’s address for rate limits. Use a comma-separated string or an array of addresses and CIDR ranges.

define('CORE_SUPPORT_TRUSTED_PROXIES', '192.0.2.10, 198.51.100.0/24');

Chat also trusts Cloudflare’s published edge ranges by default. Return false from the core_support_chat_trust_cloudflare filter to trust only your own list. Leave the constant out when the site isn’t behind a proxy.

WordPress Constants That Matter

  • AUTH_KEY and AUTH_SALT: Core Support derives its encryption keys from these. If they change, saved credentials and stored originals can no longer be opened. Data, Privacy and Uninstall lists everything tied to them.
  • SCRIPT_DEBUG: when true, Core Support serves its unminified stylesheets and scripts.

I’d keep mailbox, storage and API credentials in wp-config.php on any site that has staging copies or shared backups. The screens stay useful for everything else.

Share

Was this helpful?

Still stuck? Open a support ticket