PHP Dotenv causing wordpress configuration to run twice

Question

I have a relatively complex laravel project, within it I have a wordpress installation for a blog on the side which is installed with composer.

In my wp-config.php I use an include to a file in my config directory called application.php (for organisation purposes). I have various cases of define('XXX', 'config stuff'); and similar in the file. When 'config stuff' is hard coded the site works perfectly, but recently I'm trying to use dotenv installed by composer to pull in values from my .env with getenv()

require_once(LARAVEL_PATH . '/vendor/autoload.php');
$dotenv = new Dotenv\Dotenv(APP_ROOT_DIR);
$dotenv->load();

When I var_dump my getenv('example_env_constant') it gives me the correct values absolutely fine. So I went about setting these throughout my application.php file.

But now when I load up the site I get a large number of

Notice: Constant XXX_XXXX_XXX already defined in /path/to/application.php on line X

One for every single define('XXX', value);

And also a

Cannot modify header information

On testing I've found that my wp-config.php file is being run once. But somehow my application.php is being run twice. The 1st run is from my include call in wp-config.php as it should be. The 2nd run which is triggering the errors is happening within wp-settings.php on line 326

do_action( 'plugins_loaded' );

I have no idea how this is happening.

If I remove the dotenv code from application.php and instead put it directly into my wp-config.php the behaviour is exactly the same, with wp-config.php running once and application.php running twice.

Now if I remove application.php and put all of my code into wp-config.php as wp config is traditionally done. Then I get the exact same issue again and it references the deleted file... this of course indicates a cache issue at this point although I don't think cache is the cause of the original issue. Running a cache flush using the wp cli doesn't work as it actually manages to hit the same errors from application.php when flushing. Never mind that caching is disabled in the first place anyway. This isn't a browser cache issue here either as a new incognito chrome instance and hard refreshing makes no difference.

This is a long read so sorry about that, I hope I was clear enough. I'm quite confused as to how this is happening and any help or tips for debugging this would be great. Maybe I've missed something very obvious as it appears that using dotenv for my wp config thoroughly breaks everything in ways that I've never seen before. Worst comes to worst I'll go back to hardcoding the wp-config file

Update:

I was mistake about deleting the application.php file not stopping the related bugs. It stops the require bugs but I get others instead. If I just delete the contents of application.php then I have no difference.

Something is majorly wrong, if anyone simply has any debugging advice it would be highly appreciated

Files:

• public/help-advice/ wp-config.php

• config/ application.php

• wordpress installation is in public/help-advice/wp

• non composer generated wp files are in public/help-advice/app or public/help-advice

Pasted code if you can't use pastebin:

This is the config.php

<?php
/**
 * The base configuration for WordPress
 *
 * The wp-config.php creation script uses this file during the
 * installation. You don't have to use the web site, you can
 * copy this file to "wp-config.php" and fill in the values.
 *
 * This file contains the following configurations:
 *
 * * MySQL settings
 * * Secret keys
 * * Database table prefix
 * * ABSPATH
 *
 * @link https://codex.wordpress.org/Editing_wp-config.php
 *
 * @package WordPress
 */

 /*
  * Caching
  */
define('WP_CACHE', true);
define('LARAVEL_PATH', dirname(__FILE__) . '/../..'); // Make sure this is pointed to same server

require_once(LARAVEL_PATH . '/vendor/autoload.php');
require_once(LARAVEL_PATH . '/config/application.php');
require_once(ABSPATH . 'wp-settings.php');

This is the application.php

<?php

//This file pulls in data for WP and is included in the wp-config.php file within help-advice

/*
 * Base paths
 */
define('APP_ROOT_DIR', dirname(__DIR__));

// $dotenv = new Dotenv\Dotenv(APP_ROOT_DIR);
// $dotenv->load();
// this one above works but causes this file to run twice causing errors, the one below errors
// if (file_exists(APP_ROOT_DIR . '/.env')) {
//     Dotenv\Dotenv::load(APP_ROOT_DIR);
// }

define('APP_PUBLIC_DIR', APP_ROOT_DIR . '/public/help-advice');
define('APP_STORAGE_DIR', APP_ROOT_DIR . '/storage');
define('APP_LOG_DIR', APP_STORAGE_DIR . '/logs');


// ** MySQL settings - You can get this info from your web host ** //
/** The name of the database for WordPress */
define('DB_NAME', 'redacted');

/** MySQL database username */
define('DB_USER', 'redacted');

/** MySQL database password */
define('DB_PASSWORD', 'redacted');

/** MySQL hostname */
define('DB_HOST', '127.0.0.1');

/** Database Charset to use in creating database tables. */
define('DB_CHARSET', 'utf8mb4');

/** The Database Collate type. Don't change this if in doubt. */
define('DB_COLLATE', '');

/**#@+
 * Authentication Unique Keys and Salts.
 *
 * Change these to different unique phrases!
 * You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/salt/ WordPress.org secret-key service}
 * You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.
 *
 * @since 2.6.0
 */
define('AUTH_KEY',         'redacted');
define('SECURE_AUTH_KEY',  'redacted');
define('LOGGED_IN_KEY',    'redacted');
define('NONCE_KEY',        'redacted');
define('AUTH_SALT',        'redacted');
define('SECURE_AUTH_SALT', 'redacted');
define('LOGGED_IN_SALT',   'redacted');
define('NONCE_SALT',       'redacted');


/*
 * Debugging/errors
 */
define('APP_DEBUG', (boolean) getenv('APP_DEBUG'));
// Always log errors
ini_set('log_errors', 1);
ini_set('error_log', APP_LOG_DIR . '/wp_debug.log');
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', APP_DEBUG);
define('SCRIPT_DEBUG', APP_DEBUG);
/*
 * URLs
 */
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'].'/help-advice/wp');
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'].'/help-advice');
/*
 * Custom Content Directory (/public/help-advice/app)
 */
define('CONTENT_DIR', '/app');
define('WP_CONTENT_DIR', APP_PUBLIC_DIR . CONTENT_DIR);
define('WP_CONTENT_URL', WP_HOME . CONTENT_DIR);


//google analytics
define('GA_PROPERTY_ID',getenv('GA_PROPERTY_ID'));
/**#@-*/

/**
 * WordPress Database Table prefix.
 *
 * You can have multiple installations in one database if you give each
 * a unique prefix. Only numbers, letters, and underscores please!
 */
$table_prefix  = 'wp_';

/* That's all, stop editing! Happy blogging. */

/** Absolute path to the WordPress directory. */
if ( !defined('ABSPATH') )
    define('ABSPATH', dirname(__FILE__) . '/../public/help-advice/wp/');

Answer 1

I have no idea why it runs twice or is triggered by the do_action( 'plugins_loaded' ); on the 2nd run.

Since this is a fairly unique build/situation and I don't expect this to be easily fixed or for more than a couple of people to ever need this. So instead of continuing to tear my hair out I added a check to every definition in my application.php to see if it already existed, if so don't re-define. example: if (!defined('WP_DEBUG')) {define('WP_DEBUG', true);}

I was also getting errors from advanced-cache.php missing as a result of the dotenv being added to application.php, no idea why, especially since I never installed or had anything to do with advanced-cache. So I simply disabled this define('WP_CACHE', false);