Czy istnieje najlepsza praktyka dołączania wp-config.php
pliku do repozytorium kontroli wersji?
Zastanawiam się nad utworzeniem nowej witryny z tego rodzaju konfiguracją (podobną do Alexa Kinga i Marka Jaquitha ):
/index.php
/local-config.php
/wp-config.php
/wp/ (core)
/wp-content/ (plugins, themes, etc.)
Jak mogę to zrobić bez narażania mojego hasła na git, na wypadek gdyby to repozytorium kiedykolwiek stało się publiczne?
Zwłaszcza w poście Marka wygląda na to, że local-config.php może przechowywać szczegóły lokalnej bazy danych i hasła, ale produkcyjne pozostają w wp-config.php. Czy to zbyt duży problem i czy powinienem pozostawić wp-config.php niewersjonowane?
wp-config
version-control
Jjeaton
źródło
źródło
Odpowiedzi:
Oto jak to robię i nie spotkałem nic lepszego niż to. Trzymam inną wersję pliku wp-config.php pod kontrolą wersji, a następnie trzymam plik o jednym katalogu powyżej, który przechowuje wszystkie poświadczenia bazy danych i sole / klucze. Również w ten sposób mogę rozróżnić rodzaj konfiguracji, którą prowadzę i na tej podstawie robię różne rzeczy.
Oto
wp-config.php
trzymam podgit
( https://gist.github.com/1923821 ):A oto lokalny plik konfiguracyjny, który trzymam jeden katalog powyżej katalogu głównego WordPress, a to czyni go również poza katalogiem dostępnym w Internecie, więc w przypadku, gdy apache przestanie analizować pliki PHP i zacznie je wyrzucać, nasze poświadczenia bazy danych są nadal bezpieczne ( https: / /gist.github.com/1923848 ):
W ten sposób, jeśli powyższy plik ma nazwę
local-config.php
, mój system zachowuje się jak instalacja lokalna. Jeśli jest nazwanystaging-config.php
, zachowuje się jak instalacja przejściowa i jeśli jest nazwanyproduction-config.php
. Pomaga mi to mieć różne wartości niektórych stałych, takich jak debugowanie, mieć różne wartości w różnych środowiskach i nadal mieć wszystko pod SCM (git). Możliwości są nieskończone i nie ma potrzeby hakowania dla różnych środowisk.To gwarantuje, że nigdy nie ujawnisz żadnych poufnych informacji i używam ich tylko po to, aby rozpocząć każdy projekt, nad którym pracuję, domyślnie mam mocniejsze klucze i jak tylko dodam je do drugiego pliku konfiguracyjnego jeden katalog powyżej, są one używane zamiast tu zdefiniowanych. Błogość!
źródło
../
(tj.../filename
)? - Nie znalazłem nic../
w głównymwp-config.php
pliku.DB_CREDENTIALS_PATH
robi.Jeśli
wp-config.php
plik jest pod kontrolą wersji, wszelkie zawarte w nim hasła będą również pod kontrolą wersji. Jedynym sposobem, aby tego uniknąć, jest nie umieszczanie pliku w kontroli wersji.Moim przeczuciem byłoby
wp-config.php
całkowicie nie wywracać uwagi. Ale jest na to kilka sposobów.Wyodrębnij część,
wp-config.php
która zawiera hasła i skróty do osobnego pliku iinclude()
znajduje się w zwykłymwp-config.php
pliku. Następniewp-config.php
przejdź pod kontrolę wersji, ale zachowajinclude()
osobny plik.wp-config.php
:Teraz widać, że hasła i skróty nie są w ogóle uwzględnione
wp-config.php
.conf.php
:Ale szczerze mówiąc, w tym momencie dodajesz tutaj zbędny poziom abstrakcji. Cały powód
wp-config.php
jest oddzielny przede wszystkim dlatego, że jest specyficzny dla środowiska. Nie powinieneś w ogóle kopiować go z lokalnego serwera do wersji produkcyjnej ... więc nie powinien on być w ogóle pod kontrolą wersji.źródło
wp-config.php
ma dodatkową zaletę: możesz dołączyćconf.php
do skryptu innego niż WP bez ładowania całego WordPressa.Przykład Marka zakłada, że pracujesz z prywatnym repozytorium:
Zamiast definiować poświadczenia, równie łatwo można utworzyć plik production-config.php i włączyć go do kontroli warunkowej:
Następnie w niewersjonowanym pliku config-config.php:
źródło
Możesz zatwierdzić
wp-config.php
plik do repozytorium bez swoich tajnych ciągów, a następnie uruchomić:To powie gitowi założenie, że plik jest, cóż, niezmieniony.
źródło
assume-unchanged
zmianie, ale oto moje dwa punkty: (1) Jeśli dodasz plik bezpośrednio, zostanie on dodany do indeksu. Istnieje ryzyko, że w pewnym momencie możesz go przypadkowo dodać. (2) Scalenie zatwierdzenia z tą flagą spowoduje, że scalenie zakończy się niepowodzeniem z wdziękiem, dzięki czemu będziesz mógł obsługiwać go ręcznie, co czyni to nie eleganckim rozwiązaniem. Można go użyć tylko do tymczasowego zignorowania zmian podczas sesji programistycznej. Tutaj czytaj więcej - gitready.com/intermediate/2009/02/18/…