Wordpress z Git

Zadaję to pytanie, ponieważ szukałem w Internecie, ale nie mogę znaleźć właściwego rozwiązania. Właściwie chcę rozwiązania, w którym wielu programistów może pracować nad jednym projektem WordPress bez tworzenia bałaganu, ale jak wiemy, w WordPressie wszystko jest utrzymywane w bazie danych, tak jak która wtyczka jest aktywna, a która nie.

Jeśli programiści instalują wtyczki w swoim lokalnym projekcie, niż w jaki sposób komunikują się ze sobą, że każdy powinien zainstalować tę konkretną wtyczkę lub wtyczki itp., A niektóre nieporozumienia mogą uszkodzić witrynę innych, jeśli każdy programista pchnie / pociągnie kod.

Czy powinniśmy również udostępnić bazę danych, aby udostępnić ustawienia wtyczek / motywów, aby nie było żadnych konfliktów lub małych konfliktów między programistami.

Dzięki

Git dla wtyczek :

• Użyj Composer do wtyczek, które są już spakowane na packagist lub wpackagist . Dodaj je do composer.json.
• Użyj aktywacji wtyczek TGM dla innych wtyczek.

Następnie użyj Git do zarządzania composer.jsoni zmian we wtyczce TGM.

Najtrudniejsza jest synchronizacja bazy danych :

Zdecydowanie powinniśmy udostępnić bazę danych. Ponowna konfiguracja ustawień / opcji wtyczki nie jest dobrym pomysłem.

Istnieje wiele wtyczek , zarówno darmowych, jak i premium, które mogą pomóc.

Jeśli chcesz spróbować czegoś ręcznie, dołącz wp-cli z odpowiedzią @Wyck.

Mój zespół napotkał podobny problem. Używamy git do wersji własnego kodu niestandardowego, takiego jak wtyczki i motyw, który piszemy. Używamy Composera do zarządzania zależnościami, takimi jak wtyczki, których nie napisaliśmy. Sprawdzamy pliki composer.json i composer.lock w git, aby wszyscy byli zsynchronizowani. Od każdego dewelopera oczekuje się ciągnięcia gałęzi git master i composer updateczęstego korzystania z kojców, aby wszyscy byli na bieżąco.

W bazie danych programiści dbają głównie o konfigurację i często używamy WP-CLI, aby zachować synchronizację konfiguracji. Na przykład mamy skrypt powłoki, który uruchamia polecenie WP-CLI w celu włączenia lub wyłączenia wtyczek dla poszczególnych hostów; niektóre wtyczki są używane tylko na naszym serwerze oceny zawartości, na przykład, więc skrypt można uruchomić na dowolnym hoście i włączyć tylko odpowiedni zestaw na tym hoście. Niektóre konfiguracje, które są zbyt czasochłonne dla skryptu, są po prostu dokumentowane i w razie potrzeby powielane ręcznie.

Mamy również skrypt perla, który całkowicie sklonuje bazę danych z naszego serwera oceny zawartości na host QA lub dev. Deweloperzy mogą używać tego okresowo, jeśli chcą całej bieżącej zawartości, choć zwykle jest to mniej ważne niż posiadanie kodu i konfiguracji. Skrypt wykonuje następujące zadania:

• Zrzut mySQL bazy danych serwera pomostowego zawartości, zmień nazwy tabel, załaduj do bazy danych serwera docelowego
• użyj wp-cli, aby zmienić odniesienia do serwera pomostowego w bazie danych, aby odwoływał się do serwera docelowego
• zsynchronizuj katalog uploads na serwerze docelowym z uploadem serwera pomostowego zawartości

Istnieje kilka obiecujących rozwiązań umożliwiających szybką wersjonowanie bazy danych. VersionPress i Mergebot to dwa, o których wiem i mogą istnieć inne.

Napisałem więcej szczegółów technicznych na temat tego, jak skonfigurowaliśmy WordPress do pracy z git i Composer na moim blogu. Konieczne było uruchomienie z rdzeniem WordPress we własnym katalogu, aby dokonać czystego oddzielenia kodu, który chcemy zachować w git i rdzeniu WordPress. Sam WordPress traktujemy jako zależność i zarządzamy nim za pomocą Composer.

Najlepszym rozwiązaniem, jakie widziałem, jest użycie Bedrock ( https://roots.io/bedrock/ ).

Inne odpowiedzi na to pytanie (Kompozytor i coś do zarządzania wtyczkami) to dobre odpowiedzi; ale Bedrock zapewnia usystematyzowany, obsługiwany, udokumentowany i ciągle doskonalony sposób na zrobienie tego, który jest lepszy niż rozwijanie własnego.

Pamiętaj też, że możesz mieć więcej niż jedno repozytorium git - jedno dla twojego motywu, jedno dla każdej niestandardowej wtyczki, którą opracowujesz, a następnie jedno „główne” dla samej instalacji Bedrock / Wordpress.

Jeśli absolutnie konieczne jest, aby mieć zainstalowane wszystkie te same wtyczki działające na motywie lub wtyczkę niestandardową, wówczas udostępniłbym również bazę danych.

Używamy git i kompozytora, aby aktualizować różne środowiska programistyczne. Wystarczy pobrać najnowsze zmiany i ponownie uruchomić kompozytora i gotowe.

W tym celu przede wszystkim musimy zrozumieć strukturę katalogów WordPress. Struktura katalogów WordPress nie jest zbyt przyjazna dla użytkownika git. Proponuję więc, abyś używał tego z raczej gitprzyjazną zmodyfikowaną architekturą. Nie, nie trzeba panikować. Nie musisz tego tworzyć. Istnieje wiele tego rodzaju szablonów lub uporządkowanych systemów WordPress. Wybierz jeden z nich i zacznij kodować.

Teraz przejdź do momentu pisania dobrze zorganizowanego kodu lub kodu możliwego do utrzymania. W rzeczywistości umieszczamy nasz kod na wp-content\themes\your-themelub wp-content\themes\your-theme. Tak więc w większości gitprzyjaznych szablonów WordPress wp-contentczęść jest oddzielona. I głównie przyciągają repozytorium WordPress composer. Dzięki temu cały projekt jest znacznie czystszy.

Synchronizacja wtyczek to kolejna ważna część. Byłoby lepiej, gdybyś zainstalował wtyczkę composer. To sprawia, że ​​kod projektu jest o wiele czystszy. Tutaj znajdziesz przegląd instalacji wtyczek WordPress composer.

Teraz przejdź do najważniejszej części, jak zsynchronizować bazę danych. Myślę, że łatwiej to zrobić na dwa sposoby -

• Wszyscy programiści powinni korzystać z jednej zdalnej bazy danych. I często twórz kopię zapasową.
• Zautomatyzuj funkcję importu eksportu WordPress. Wydaje się to skomplikowane, ale nie jest. Po prostu zrób Google, mam nadzieję, że możesz to zrobić.

Mam nadzieję, że ci pomoże.