Global variables and configuration

The Gestor is procedural and shares state through four global arrays. Inside a function, declare global $_GESTOR; (and $_CONFIG, $_BANCO) before using them.

There is also $_CRON (set by cron.php before config.php, with the scheduled domain's SERVER_NAME and ROOT_PATH) and $_ENV itself, with the raw .env keys.

How the .env is found

1. ROOT_PATH is the Gestor folder: $_INDEX['sistemas-dir'] on the web, the config.php folder on the CLI and $_CRON['ROOT_PATH'] on cron.

2. The .env looked up is autenticacoes/<SERVER_NAME>/.env, loaded by Dotenv. On the CLI, with no SERVER_NAME set, it uses localhost.

3. If it does not exist, config.php tries each folder in autenticacoes/ in alphabetical order and loads the first one that has a .env.

4. None found: 503 with JSON Configuration file (.env) not found. Without Composer installed (no Dotenv): 500.

Cookie names get a per-domain suffix (_ + the first 8 characters, uppercase, of the MD5 of the domain folder name), for example _C2FCID_05B11065. That way, two projects on the same parent domain do not swap cookies. A CLI script that creates a cookie for a site must run with that site's SERVER_NAME.

$_BANCO

The connection itself ($_BANCO['conexao']) is opened on demand by banco.php.

$_CONFIG: map of the .env

Read $_CONFIG for system settings. For keys that code outside the web bootstrap may also read, the core modules use the order $_CONFIG → $_ENV → getenv(): a key read from a single place goes silently inert, with no error, wherever that place is not filled.

$_GESTOR: installation state (from config.php)

A project can add or override keys in config-project.php (at the Gestor root), included at the end of config.php. That is where, for example, these live:

• project-css and project-javascript, with the *-layouts-include and *-layouts-remove variants;

• project-page-tailwind-bundles;

• project-version.

$_GESTOR: request state

Controlled Access: gestor_get(), gestor_set(), gestor_has() and gestor_contexto()

Starting from req-229 (BATCH-238), as an architectural foundation for the Line 3.1 OOP refactoring, new developments should prioritize controlled access functions via GestorState instead of direct global mutations:

• gestor_get(string $chave, mixed $padrao = null): mixed: Read with fallback and dot notation support (e.g. gestor_get('banco.conexao.host', 'localhost')).

• gestor_set(string $chave, mixed $valor): bool: Safe write with validation. Protects critical core keys from accidental mutation.

• gestor_has(string $chave): bool: Deterministic existence check (supports dot notation).

• gestor_contexto(string $escopo): array: Delimited context slices (modulo, usuario, sistema, etc.).

Protected Core Keys (Read-only after boot)

The following keys cannot be accidentally overwritten via gestor_set():

• raiz-absoluta

• url-raiz

• linguagem-codigo

• versao-num

Overwrite attempts trigger a system log alert and return false.

100% Backwards Compatibility

The $_GESTOR superglobal array continues to exist as the underlying state storage. Existing legacy code that reads or writes directly to $_GESTOR['key'] remains fully functional.

See also

• Request lifecycle: when each key is filled.

• Installation: how the .env is born.

• Skills c2f-global-variables and c2f-environment-configuration.