Есть ли лучшая практика для включения вашего wp-config.php
файла в ваш репозиторий контроля версий?
Я подумываю о создании нового сайта с такой конфигурацией (по аналогии с Алексом Кингом и Марком Джакитом ):
/index.php
/local-config.php
/wp-config.php
/wp/ (core)
/wp-content/ (plugins, themes, etc.)
Как я могу сделать это, не выставляя свои пароли на git, если этот репозиторий когда-нибудь станет публичным?
Особенно в посте Марка, похоже, что local-config.php может хранить детали и пароли локальной базы данных, но рабочие остаются в wp-config.php. Это слишком много проблем, и я должен просто оставить wp-config.php без версии?
wp-config
version-control
jjeaton
источник
источник
Ответы:
Вот как я это делаю, и я не встречал ничего лучше этого. Я держу другую версию файла wp-config.php под контролем версий, а затем держу файл на один каталог выше, который содержит все учетные данные базы данных и соли / ключи. Кроме того, таким образом, я могу различать тип установки, которую я использую, и по-другому это делать.
Вот то, что
wp-config.php
я держу подgit
( https://gist.github.com/1923821 ):А вот локальный файл конфигурации, который я храню на один каталог выше корневого каталога WordPress, и это также делает его вне каталога, доступного через Интернет, поэтому в случае, если apache прекратит парсинг PHP-файлов и начнет их выбрасывать, наши учетные данные базы данных по-прежнему будут в безопасности ( https: / /gist.github.com/1923848 ):
Таким образом, если указанный выше файл назван
local-config.php
, моя система ведет себя как локальная установка. Если его имяstaging-config.php
, оно ведет себя как инсталляционная установка и если его имяproduction-config.php
. Это помогает мне иметь разные значения определенных констант, например, отладка имеет разные значения в разных средах и все еще в SCM (git). Возможности бесконечны, и нет необходимости в хакерстве для различных сред.Это гарантирует, что вы никогда не будете раскрывать какую-либо конфиденциальную информацию публично, и я использую это просто для запуска любого проекта, над которым я работаю, по умолчанию у меня есть более надежные ключи, и как только я добавляю их во второй файл конфигурации на одну папку выше, те используются вместо определенных здесь. Блаженство!
источник
../
(то есть../filename
) где-то? - Я не нашел ничего../
в основномwp-config.php
файле.DB_CREDENTIALS_PATH
делает это.Если ваш
wp-config.php
файл находится в режиме управления версиями, то все содержащиеся в нем пароли также будут находиться в режиме управления версиями. Единственный способ избежать этого - не помещать файл в систему контроля версий.Моим внутренним чувством было бы
wp-config.php
полное сохранение неосторожности. Но есть несколько способов обойти это.Извлеките часть
wp-config.php
, содержащую ваши пароли и хэши, в отдельный файл иinclude()
в обычныйwp-config.php
файл. Затем поместитеwp-config.php
под контроль версий, но держите вашinclude()
файл отдельно.wp-config.php
:Теперь вы можете видеть, что пароли и хэши вообще не включены
wp-config.php
.conf.php
:Но, честно говоря, на данный момент вы просто добавляете избыточный уровень абстракции здесь. Во
wp-config.php
-первых, вся причина в том, что она зависит от окружающей среды. Вы вообще не должны копировать его с локального сервера в рабочий ... поэтому он вообще не должен находиться под контролем версий.источник
wp-config.php
имеет дополнительное преимущество: вы можете включитьconf.php
в сценарий не WP без загрузки всего WordPress.Пример Марка предполагает, что вы работаете с частным репо:
Вместо определения учетных данных вы также можете легко создать файл production-config.php и включить его в условную проверку:
Затем в вашем неверсионном файле production-config.php:
источник
Вы можете зафиксировать
wp-config.php
файл в хранилище без ваших секретных строк, а затем запустить:Это скажет git предположить, что файл, в общем-то, не изменился.
источник
assume-unchanged
переключателе, но вот два моих замечания: (1) Если вы добавите файл напрямую, он будет добавлен в индекс. Таким образом, существует риск, что вы можете случайно добавить его в какой-то момент. (2) Слияние коммита с этим флажком приведет к изящному сбою слияния, так что вы можете обработать его вручную, что делает его не элегантным решением. Он может использоваться только для временного игнорирования изменений во время чего-то вроде сеанса разработки. Здесь читайте больше - gitready.com/intermediate/2009/02/18/…