Using $GLOBALS may be acceptable in legacy systems like WordPress plugins where it ensures compatibility, 2. It can be used temporarily during bootstrapping before dependency injection is available, 3. It is suitable for read-only debugging tools in development environments. Despite these cases, risks like unintended mutations and testing difficulties remain, so best practices include using unique prefixes, avoiding mutable state, limiting scope, and encapsulating access—use $GLOBALS only when necessary and with caution.

Using $GLOBALS in PHP is often seen as a red flag — and for good reason. It exposes all variables in the global scope, making code harder to test, debug, and maintain. But while indiscriminate use of $GLOBALS should be avoided, there are a few narrow, legitimate scenarios where it can be useful — if handled carefully.

Let’s look at when, and why, you might actually consider using $GLOBALS — and how to do so without shooting yourself in the foot.

When You’re Working with Legacy Code or Plugins

One of the most common reasons you’ll encounter $GLOBALS is when maintaining or extending older PHP applications — especially in ecosystems like WordPress.

In WordPress, for example, plugin developers sometimes rely on $GLOBALS to:

• Store plugin configuration or state
• Share data between hooks and functions that don’t easily pass parameters
• Access global variables defined by the core or other plugins

Example:

function my_plugin_init() {
    $GLOBALS['my_plugin_config'] = [
        'api_key' => 'abc123',
        'debug'   => true
    ];
}

While not ideal, this pattern is widespread. If you're integrating with such a system, using $GLOBALS may be the least disruptive way to ensure compatibility.

Best practice: Wrap access in helper functions to encapsulate the global dependency:

function get_my_plugin_config() {
    return $GLOBALS['my_plugin_config'] ?? null;
}

This minimizes direct exposure and makes future refactoring easier.

Bootstrapping or Early-Stage Application Setup

In some frameworks or custom bootstrapping routines, $GLOBALS might be used temporarily to store environment settings or configuration before dependency injection is available.

For instance, during the very early phases of request handling — before autoloading or service containers are ready — you might need to pass data between procedural setup functions.

Example:

// bootstrap.php
$GLOBALS['app_env'] = getenv('APP_ENV') ?: 'production';

// later, in a config loader
$env = $GLOBALS['app_env'];

This is acceptable only if:

• The use is limited to the bootstrap phase
• No business logic depends on it
• Values are quickly transferred into proper services or configuration objects

Once the application structure is initialized, avoid referencing $GLOBALS elsewhere.

Debugging or Instrumentation Tools

Sometimes, diagnostic tools or debugging libraries use $GLOBALS to capture the state of the global scope for analysis.

For example, a debugging toolbar might snapshot $GLOBALS to show what variables are defined at a given point in the request lifecycle.

// In a debug tool
$global_snapshot = array_keys($GLOBALS);
error_log("Global variables present: " . implode(', ', $global_snapshot));

This kind of introspection is read-only and non-invasive — it doesn’t alter behavior, just observes it.

Key point: This is acceptable when:

• You’re not modifying globals
• The code is isolated to development or testing environments
• It’s part of a transparent diagnostic process

Never use this pattern in production logic or for application control flow.

Why These Cases Are Still Risky

Even in these scenarios, $GLOBALS introduces risks:

• Unintended mutations: Any part of the code can change a global variable
• Naming collisions: $GLOBALS['config'] could be overwritten by another script
• Testing complexity: Unit tests can’t easily isolate state

So even if you have a valid use case, apply safeguards:

• Use unique, prefixed keys (e.g., myapp_config instead of config)
• Avoid storing mutable state
• Document why $GLOBALS is necessary
• Limit scope and lifetime of global data

Bottom line: $GLOBALS isn’t inherently evil, but it’s like handling explosives — possible in controlled conditions, but dangerous if misused. Stick to the rare cases where alternatives aren’t feasible, and always minimize exposure.

Basically, if you can avoid it, do. But if you must use it, at least use it wisely.

The above is the detailed content of Navigating the Minefield: Legitimate (and Rare) Use Cases for $GLOBALS. For more information, please follow other related articles on the PHP Chinese website!