INI Control Files — Cheat Sheet

Every setting you can tune on your own sites lives in a plain text INI file you create and edit — no ticket, no root. This page is the quick primer: the two files you'll ever touch, which one wins when they disagree, how to apply a change and confirm it landed, and the one big trap (the PHP version isn't an INI setting). Everything here links to the full story.

The pieces in 30 seconds

The site file — boa_site_control.ini, in one site's own modules folder; it changes just that site. It doesn't exist until you create it. → The two INI files
The platform file — boa_platform_control.ini, in sites/all/modules/; the shared default for every site on the platform, using the same setting names. → same page
The site file wins — when both set the same key, the site value overrides the platform default. Platform = the shared baseline, site = the per-site exception. → Which file do I edit?
The PHP version is a different family — it is not an INI setting; it lives in small files under ~/static/control/. This is the #1 "which file" mix-up. → Choosing a PHP version

Edit one site

Create sites/<your-domain>/modules/boa_site_control.ini and add one name = VALUE line per setting:

INI

; sites/example.com/modules/boa_site_control.ini
session_cookie_ttl = 172800

Save it — there's nothing to run, no ticket, no root. Values are plain: UPPERCASE keywords (TRUE / FALSE / YES / NO), one setting per line, no quotes needed around a plain word or number.

→ The two INI files, in full

Edit every site on a platform

Same setting names, one file up: sites/all/modules/boa_platform_control.ini. Every site on that platform inherits it, unless a site file overrides the same key.

→ Platform vs site settings

When both set the same key, the site file wins

The platform file is the shared default; the site file is the override. That's the whole precedence story a hosted site needs — set a baseline once for the platform, then make exceptions per site. (There are two more layers below these, but they're host-only files you can't reach — see the full precedence chain (for operators).)

Start from the self-documenting template

You don't have to remember setting names. BOA keeps a template copy right next to where your file goes — copy it and uncomment the lines you want:

BASH

cp sites/example.com/modules/default.boa_site_control.ini sites/example.com/modules/boa_site_control.ini

Every option is listed commented-out with its system default next to it — delete the leading ; from the lines you want to change.

→ Using the template

Apply it, then check it landed

A saved change goes live in about 60 seconds on a normal site — that's PHP holding the compiled INI in cache, not a broken file. To skip the wait and confirm the value in one move, make (or use) a hostname with .dev. in it: .dev. names bypass that cache and print verify headers.

BASH

curl -sI https://www.dev.example.com/ | grep -i x-ini
# X-Ini-Loc-Src: sites/example.com/modules/boa_site_control.ini
# X-Ini-Session-Cookie-Ttl: 172800

X-Ini-Loc-Src is your site file, X-Ini-Plr-Src the platform file, and X-Ini-Src: BOA-Default means neither is set — so the headers also tell you which layer supplied a value. They appear only on .dev. names, never on your live URLs.

→ The .dev. preview URL · verify headers in full

The PHP version is a separate file, not INI

A version like 8.3 never goes in an INI file. It lives in its own small control files under ~/static/control/:

BASH

echo 8.3 > ~/static/control/fpm.info      # the version your site is served with
echo 8.3 > ~/static/control/cli.info      # drush / composer on the shell
touch ~/static/control/php83.info          # switch the shell version now

BOA can run 12 versions, 5.6 through 8.5. → Choosing a PHP version

The settings and files most people touch

Setting	What it does	Default
`session_cookie_ttl`	How long a login stays alive, in seconds	`86400`
`speed_booster_anon_cache_ttl`	Seconds anonymous visitors see a cached page	`10`
`redis_debug_header`	Turn on the neutral `X-Cache-*` verify headers	`FALSE`

They go in either the site or the platform file above. The platform template offers 34 settings and the site template 33 — every one listed, commented, with its default, in the two INI files. (A few are site-only, like the solr_* family, and a few are platform-only — the template marks each one.)

If something's weird

A change "didn't show up" → it's almost always the ~60-second cache, not a broken file. Wait a minute, or edit on a .dev. name for instant apply — don't reflexively run Verify Site. Why the wait.
Trying to set the PHP version in the INI file → wrong family; the version lives in ~/static/control/. The PHP-version files.
The setting only exists in a .cnf file → those are server-wide host files you can't reach; that change is a support request, not a file you edit. Which file do I edit?.

Going deeper

The full task guide: Which file do I edit? and the two INI files — every tenant-editable setting, the edit routine, and the verify headers.
Module opt-outs that live in the platform file: Module settings.
The whole control-file model, all four layers and the host-only .cnf files (for operators): Control files & INI precedence · overview.
The complete cross-audience catalogue (most of it host-only, not tenant settings): the variables reference and control-files reference.