PHP Dotenv вызывает запуск конфигурации WordPress дважды

У меня есть относительно сложный проект laravel, в котором у меня есть установка WordPress для блога на стороне, которая устанавливается вместе с композитором.

В моем wp-config.php Я использую включение в файл в моем каталоге конфигурации под названием application.php (для организационных целей). У меня есть разные случаи define('XXX', 'config stuff'); и аналогичные в файле. Когда ‘configонастройка’ жестко запрограммирована, сайт работает отлично, но недавно я пытаюсь использовать dotenv, установленный композитором, чтобы получить значения из моего .env с помощью getenv ()

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

Когда я var_dump мой getenv('example_env_constant') это дает мне правильные значения абсолютно нормально. Поэтому я занялся их настройкой по всему файлу application.php.

Но теперь, когда я загружаю сайт, я получаю большое количество

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

Один на каждого define('XXX', value);

А также

Cannot modify header information

На тестировании я обнаружил, что мой wp-config.php файл запускается один раз. Но как-то мой application.php запускается дважды. Первый прогон от моего включенного звонка в wp-config.php так, как это должно быть. 2-ой запуск, который вызывает ошибки, происходит в течение wp-settings.php по линии 326

do_action( 'plugins_loaded' );

Я понятия не имею, как это происходит.

Если я удалю код Dotenv из application.php и вместо этого положить его прямо в мой wp-config.php поведение точно такое же, с wp-config.php работает один раз и application.php работает дважды.

Теперь, если я удалю application.php и положить весь мой код в wp-config.php как конфиг wp традиционно делается. Затем я снова получаю ту же самую проблему, и она ссылается на удаленный файл … это, конечно, указывает на проблему с кешем в данный момент, хотя я не думаю, что кеш является причиной первоначальной проблемы. Запуск очистки кеша с помощью wp cli не работает, так как на самом деле удается получить те же ошибки из application.php при промывке Не берите в голову, что кэширование вообще отключено в любом случае. Это не проблема кеша браузера, так как новый экземпляр инкогнито хрома и жесткое обновление не имеют значения.

Это долгое чтение, так что сожалею об этом, надеюсь, я был достаточно ясен. Я совершенно сбит с толку относительно того, как это происходит, и любая помощь или советы по устранению неполадок это было бы здорово. Может быть, я упустил что-то очень очевидное, так как кажется, что использование dotenv для моей конфигурации wp полностью разрушает все, что я никогда раньше не видел. Худшее приходит к худшему, я вернусь к жесткому кодированию файла wp-config.

Обновить:

Я ошибся при удалении файла application.php, не останавливая связанные ошибки. Это останавливает требуемые ошибки, но вместо этого я получаю другие. Если я просто удаляю содержимое application.php, то у меня нет разницы.

Что-то в основном не так, если у кого-то просто есть какой-либо совет по устранению неполадок, это будет высоко оценено

файлы:

  • общественности / помощь-совет /WP-config.php

  • конфиг /application.php

  • Установка WordPress является публичной / help-advice / wp

  • wp-файлы, созданные не композитором, находятся в общедоступной / help-advice / app или
    общественности / помощь-совет

Вставленный код, если вы не можете использовать pastebin:

Это 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');

Это приложение.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/');

1

Решение

Я понятия не имею, почему он запускается дважды или запускается do_action (‘plugins_loaded’); на 2-м пробеге.

Поскольку это довольно уникальная сборка / ситуация, и я не ожидаю, что это будет легко исправить, или когда это понадобится более чем двум людям. Поэтому вместо того, чтобы продолжать рвать на себе волосы, я добавил проверку к каждому определению в моем application.php, чтобы увидеть, существует ли оно уже, и если да, не переопределять. пример: if (!defined('WP_DEBUG')) {define('WP_DEBUG', true);}

Я также получал ошибки из файла advanced-cache.php, отсутствующие в результате добавления dotenv в application.php, не знаю почему, тем более что я никогда не устанавливал и не имел ничего общего с advanced-cache. Так что я просто отключил это define('WP_CACHE', false);

0

Другие решения

Других решений пока нет …

По вопросам рекламы [email protected]