How to Check Whether a PHP Constant Is Defined (Without Breaking Production)

By Greg Nowak. Last updated 2026-10-18.

A WordPress editor disappears in production but works on staging. Or an agency team cannot install an update that worked in its test environment. Before changing permissions or blaming a plugin, check whether a PHP constant is controlling the behaviour. The check takes minutes; deciding whether the setting should change requires knowing who owns the deployment.

Short answer: how to check if a PHP constant is defined

// Global constant
if (defined('MY_FLAG')) { /* exists; the value may still be false */ }

// Define only if missing (avoids "Constant MY_FLAG already defined")
if (!defined('MY_FLAG')) {
    define('MY_FLAG', true);
}

// Class constant
if (defined('App\Config::TIMEOUT')) {
    $timeout = constant('App\Config::TIMEOUT');
}
// or: (new ReflectionClass(App\Config::class))->hasConstant('TIMEOUT')

// A variable, not a constant
if (isset($var)) { /* set and not null */ }

defined() takes the name as a string and works for global and class constants, including a namespaced name written out in full. In PHP 8 a redefinition raises a warning and define() returns false, and a constant cannot be undefined, so guard the definition instead. Built-in names such as INF, PHP_EOL or E_ALL are always defined, which is why define('INF', ...) always warns. To see what your own code has defined in the current process, read get_defined_constants(true)['user']. The rest of this page is about doing this on a live WordPress site without exposing anything.

Check the constant before reading its value

PHP’s defined() answers one question: does a constant with this name exist in the current runtime? It does not tell you its value. If the name is stored in a variable, use constant() only after defined() succeeds. Since PHP 8.0, asking constant() for an undefined name throws an Error.

This example checks two named WordPress settings. Run it in a controlled maintenance context that has loaded the same WordPress configuration as the affected request. It prints only those two values:

<?php

$names = ['DISALLOW_FILE_EDIT', 'DISALLOW_FILE_MODS'];

foreach ($names as $name) {
    if (!defined($name)) {
        echo $name . ': undefined' . PHP_EOL;
        continue;
    }

    echo $name . ': ' . var_export(constant($name), true) . PHP_EOL;
}

var_export() makes true, false, strings and numbers distinguishable. A plain echo can make false look like an empty value. Keep the list limited to settings relevant to the symptom; do not turn a targeted check into a public configuration dump.

Defined does not mean enabled

For a Boolean flag, undefined, false and true are different findings. defined('DISALLOW_FILE_EDIT') returns true even when that constant’s value is false. When the name is fixed and you only need to test whether the flag is active, use defined('DISALLOW_FILE_EDIT') && DISALLOW_FILE_EDIT. The second condition runs only if the first succeeds.

If a flag has a string or numeric value, record the actual value and check how the application interprets it. A truthiness test alone may conceal a configuration mistake. For constants declared in a PHP namespace, pass the fully qualified name to defined() or constant(); those functions treat the name as a string rather than resolving it from your current namespace.

What the two WordPress settings change

DISALLOW_FILE_EDIT disables WordPress’s built-in plugin and theme file editors. WordPress presents this as one security measure, while noting that it does not prevent malicious files from being uploaded by other means. DISALLOW_FILE_MODS goes further: it blocks plugin and theme installation and update functions in the administration area and also disables those file editors.

That distinction matters during a handover. A team may intentionally block dashboard code editing while retaining a managed update process. Another may route all code changes through deployment and therefore block dashboard updates too. If an action is unavailable, check both constants, the affected user’s role and the site’s update process before proposing a change. An absent constant also does not prove that the action should be available; permissions and other controls may still apply.

Compare staging and production without exposing configuration

Run the same narrow check in each environment and record the environment, runtime and result. A command-line PHP process and a web request can load different bootstrap files, so compare equivalent contexts where possible. If the values differ, locate the definition in wp-config.php, environment bootstrap code or host-managed configuration. The runtime result tells you what is set, not which file or person set it.

PHP’s get_defined_constants(true) can help when you do not yet know the name: it groups currently defined constants, including a user category. Treat that output as a private investigative tool. It can include unrelated values, and it reflects only the process in which it ran. Review a relevant subset in a protected maintenance environment; avoid publishing the full array on a web page or attaching it to an unrestricted ticket.

Turn the finding into a useful decision

1. Describe the symptom. Note the exact screen or action, user role and environment. “Plugin updates are unavailable to administrators in production” is more useful than “WordPress is broken.”
2. Record the state. Capture whether each relevant constant is undefined, false or true, without copying unrelated configuration values.
3. Find the owner. Ask whether the setting is an approved security policy, a deployment safeguard or leftover configuration. Check the deployment instructions before editing a live file.
4. Make one controlled change if needed. Update the source of configuration, test the expected administration action and document the decision for the next person maintaining the site.
5. Remove diagnostics. Delete temporary scripts or output after recording the conclusion.

The PHP check is straightforward. The harder work is making sure production behaviour matches an agreed operating model. If your team keeps rediscovering these differences during releases or handovers, Greg can help document the decisions and coordinate a clearer delivery process.

Related on GrN.dk

• WordPress 7.0 Upgrade Planning: What Old Meta Boxes Still Mean
• WordPress Supports Old PHP; Your Production Server Shouldn’t
• Before You Buy a GPU: Test Your Team’s Local AI Workload

Need help with this kind of work?

Talk to Greg about your delivery setup Get in touch with Greg.

Sources

• PHP Manual: defined()
• PHP Manual: constant()
• PHP Manual: get_defined_constants()
• WordPress Developer Handbook: Editing wp-config.php
• WordPress Developer Handbook: Hardening WordPress