You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Constant XXX already defined notice output twice #4944
Occasionally I find a constant becomes defined twice in wp-config.php - due to a plugin adding something that already exists.
In that case the already defined error is thrown twice, and one of them is in stdout making it hard to ignore/ditch.
E.g. if DISALLOW_FILE_EDIT is defined twice:
$ wp option get siteurl
=> `PHP Notice: Constant DISALLOW_FILE_EDIT already defined in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1150) : eval()'d code on line 81
Notice: Constant DISALLOW_FILE_EDIT already defined in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1150) : eval()'d code on line 81 http://test.com`
$ wp option get siteurl --quiet
=> (as above)
$ wp option get siteurl --quiet 2>/dev/null
=> Notice: Constant DISALLOW_FILE_EDIT already defined in phar:///usr/local/bin/wp/vendor/wp-cli/wp-cli/php/WP_CLI/Runner.php(1150) : eval()'d code on line 81 http://test.com
To guarantee only the desired output is returned we are currently grepp'ing out blank lines and lines starting 'Notice' (suits our current use, but not at all robust). Especially as we are relying on json output.
This "feels" like a bug in WP CLI - I wonder if one error comes from PHP itself and one from WP CLI? Is perhaps stderr from PHP being redirected to WP CLI's stdout? I feel out of my depth to dig into the cause, and tight on time to flounder around, but would be more than happy to provide any more (guided) help and testing.
no, this happens by design because PHP does what it is told: when you use ini_set('display_errors', 1); and then throw an Error or Exception (whether otr not you intend for this to happen, it will) PHP ALWAYS reports it to ERROR_LOG immediately so if you use error_reporting(E_ALL); it reports it to STDOUT, if you then try/catch and write error_log($e->getMessage(),0); or echo $e->getMessage() depending on your ini_set('display_errors', 1); / error_reporting(E_ALL); settings you will potentially see it twice
I am struggling to understand why this was cclosed as completed. This is a real issue and a problem, and ConanMan's comment does not accurately explain why this happens.
Activity
danielbachhuber commentedon Oct 1, 2018
I've seen this before too but never thought to track it down.
At the very least, it would be useful to know why two notices are reported instead of the expected one.
@wp-cli/committers Any ideas as to what might be the cause?
OpenTranslationBible commentedon Jan 21, 2019
it is
if you throw an error it reports it to stdout
schlessera commentedon Jan 25, 2019
My guess would be that the notice is produced twice because:
We might want to silence notices while WP-CLI evaluates the config, to avoid double notices like this.
OpenTranslationBible commentedon Jan 25, 2019
no, this happens by design because PHP does what it is told: when you use
ini_set('display_errors', 1);and then throw anErrororException(whether otr not you intend for this to happen, it will) PHP ALWAYS reports it to ERROR_LOG immediately so if you useerror_reporting(E_ALL);it reports it to STDOUT, if you then try/catch and writeerror_log($e->getMessage(),0);or echo$e->getMessage()depending on yourini_set('display_errors', 1); / error_reporting(E_ALL);settings you will potentially see it twicerobrecord commentedon Apr 30, 2025
I am struggling to understand why this was cclosed as completed. This is a real issue and a problem, and ConanMan's comment does not accurately explain why this happens.
swissspidy commentedon Apr 30, 2025
@robrecord because the issue was fixed. Try
wp cli update --nightly.robrecord commentedon Apr 30, 2025
Apologies, I missed the pull request and I must be running an older version.
Many thanks @swissspidy, @pwtyler and @schlessera