Jak utworzyć strukturę projektu strony WP za pomocą git i aktualizacji z pulpitu WP?

Od miesięcy staram się zaplanować dobrą strukturę projektu do używania kontroli wersji git do tworzenia stron internetowych WordPress, która nie poświęca możliwości aktualizacji rdzenia i wtyczek poprzez pulpit nawigacyjny WP, nie wymaga niekonwencjonalnej struktury katalogów (wp -zawartość poza folderem nadrzędnym WP) i który jest łatwy do zarządzania i wdrażania całych stron internetowych. Czytałem o podmodułach, poddrzewach, zagnieżdżonych repozytoriach itp. I nadal mam trudności z dopasowaniem ich do siebie i wybraniem odpowiedniej strategii.

Oto, co myślę teraz, z moimi myślami, jak poradzę sobie z repozytoriami git w nawiasach.

root (main project repo)
|-- wordpress (public git repo added as subtree)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo added as subtree)
|    |    |    |-- other-plugin-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-plugin-without-git-repo (ignored/untracked)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo added as subtree)
|    |    |    |-- other-theme-with-git-repo  (git repo added as subtree)
|    |    |    +-- other-theme-without-git-repo (ignored/untracked)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

To pozostawia mi kilka problemów / pytań;

• Automatyczne aktualizacje; Uwielbiam nową funkcję automatycznych aktualizacji, może potencjalnie zaoszczędzić dużo czasu i wysiłku, aby moje witryny były aktualizowane i bezpieczne, ale wydaje się, że rzuca klucz do śledzenia zmian kodu za pomocą git. Czy jest jakiś sposób na śledzenie zmian w kodzie przy jednoczesnym umożliwieniu automatycznej aktualizacji rdzenia WordPress?

• Czy posiadanie poddrzewa pod repozytorium rdzenia WordPress uniemożliwia mi używanie git do scalania nowych aktualizacji rdzenia lub wypychanie moich zmian z powrotem do repozytorium rdzenia WordPress (jeśli kiedykolwiek zdecyduję, że chcę być głównym współautorem)?

• W przypadku wtyczek, które nie mają publicznego repozytorium git, ich całkowite zignorowanie powoduje problem polegający na niemożności szybkiego sklonowania całej witryny na nowym serwerze bez ręcznego kopiowania plików na serwer. Powoduje to również problem, jeśli chcę wprowadzić zmiany w kodzie tej wtyczki, zmiany te nie są śledzone i mogą zostać łatwo utracone podczas aktualizacji wtyczki.

Podsumowując, jaka jest dobra konfiguracja git + WordPress, która pozwala uniknąć tych problemów? Byłbym wdzięczny za opinie na temat mojej proponowanej struktury projektu. Byłbym bardzo wdzięczny za każdy sposób, w jaki możesz pomóc mi to poprawić!

PS, jeśli istnieje lepsze forum dla tej dyskusji, proszę mnie tam wskazać.

Z mojego punktu widzenia są dwa problemy z twoim planem - Git i „konwencjonalna” struktura. Więc w zasadzie wszystko. :)

1. Git (i kontrola wersji w ogólności) to słabe narzędzie do stosów całej witryny. Byłem tam, zrobiłem to, bardzo bolało.

2. To, co nazywacie „niekonwencjonalną” strukturą z zawartością oddzieloną od rdzenia, jest przez pewien czas bardzo konwencjonalnym i solidnym wyborem dla każdej poważnej witryny.

3. Nie ma praktycznie żadnych gotowych sposobów na połączenie całego stosu witryn z aktualizacjami natywnymi. Po prostu nie idzie dobrze razem, ponieważ próbuje osiągnąć różne cele w projektach na różnych poziomach (programista w kontroli vs użytkownik końcowy w kontroli).

Jeśli zapytasz mnie o najlepszy zakład dla całej witryny, stos WordPress jest obecnie Kompozytorem , jednak opinie mogą być ostrożne. :)

W sprawie twoich konkretnych obaw:

1. Jak wyżej - aktualizacje natywne (bardziej automatyczne) nie działają dobrze przy ściśle kontrolowanych stosach.

2. Rdzeń WordPress nie jest rozwijany w Git i nie przyjmuje żądań ściągania, wszystkie wkłady są (jak dotąd) za pośrednictwem plików łatek do Subversion.

3. Prawdopodobnie będziesz musiał zatwierdzić takie wtyczki w swoim repozytorium. Lub zastosuj inne podejście, takie jak Kompozytor.

Możesz spojrzeć na ten problem i ten problem.

Zobacz także pliki README w każdym repozytorium:

• markjaquith / WordPress-Skeleton
• davidwinter / wordpress-with-git

Na podstawie powyższych repozytoriów, jako kolejny przykład konfiguracji Git / WP, stworzyłem to . Zdecydowałem się używać dowiązań symbolicznych do motywów (staram się opisywać to w README ).

Jestem trochę w tej samej łodzi z automatycznymi aktualizacjami ... Mój plan polegał na ręcznej aktualizacji podmodułu WP, gdy pojawią się aktualizacje. Myślę, że alternatywą jest teoretycznie (muszę się jeszcze przetestować), aby sam moduł podrzędny aktualizował się w przypadku drobnych aktualizacji (jest do tego ustawienie WP), a następnie gitwymusić / zresetować podmoduł, gdy pojawią się główne aktualizacje ( może jedna z odpowiedzi tutaj może być pomocna ... oczywiście, myślę, że przy aktualizacji do następnej głównej wersji chciałoby się kierować na konkretny tag WP).

Należy zauważyć, że jeśli WP zobaczy .gitścieżkę (ścieżki), automatycznie wyłączy automatyczne aktualizacje. Aby uzyskać więcej informacji, zobacz:

• Automatyczne aktualizacje rdzenia, aktualizacja

Aby włączyć automatyczne aktualizacje, istnieje kilka prostych wymagań:

• Jeśli instalacja używa FTP do aktualizacji (i monituje o poświadczenia), automatyczne aktualizacje są wyłączone
• Jeśli instalacja działa jako kasa SVN lub GIT, automatyczne aktualizacje są wyłączone
• Jeśli stałe DISALLOW_FILE_MODSlub AUTOMATIC_UPDATER_DISABLEDsą zdefiniowane, automatyczne aktualizacje są wyłączone
• Jeśli stała WP_AUTO_UPDATE_COREjest zdefiniowana jako fałsz, automatyczne aktualizacje są wyłączone
• Twoja instalacja WordPress musi także móc kontaktować się z WordPress.org przez połączenia HTTPS, więc Twoja instalacja PHP również musi być OpenSSLzainstalowana i działać
• Wp-Cron musi działać, jeśli z jakiegoś powodu cron nie będzie działał podczas instalacji, Aktualizacje automatyczne również będą niedostępne

Inne powiązane linki:

• Automatyczna aktualizacja WP 3.7
• Opracowywanie motywów submodułowych GitHub?
• Zainstaluj i zarządzaj WordPress za pomocą Git

Aktualizacja z maja 2015 r

Stworzyłem to repozytorium, które jest dla mnie szybkim sposobem na rozpoczęcie projektów WordPress. Moim najnowszym podejściem jest kontrola wersji tylko tematów. Innymi słowy, instaluję WP lokalnie (używając instalacji we wspomnianym repozytorium) i na produkcji, następnie modyfikuję plik konfiguracyjny w każdym systemie i gitpobieram moje motywy, aby uzyskać funkcjonalną witrynę.

Ten rodzaj rozwoju zalicza się do „nie tak łatwego i wymaga niestandardowego przepływu pracy, z którego zadowolenie może zająć dużo czasu”.

Uważam, że poddrzewa, submoduły lub zagnieżdżone repozytoria to ogromny ból w dupie.

Kilka myśli (śledź wszystko).

1. Włącz automatyczne aktualizacje za pomocą git / svn, używając:
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Bezpieczna metoda dzięki ręcznym zatwierdzeniom + e-mail:

Możesz użyć serwera pomostowego i powiadomień e-mail o aktualizacjach, zatwierdzić aktualizacje i przekazać serwer na żywo, na którym wyłączono automatyczne aktualizacje.

Pozwala to również na kopiowanie / wklejanie folderów do własnych repozytoriów do woli, co często robię. Ułatwia także klonowanie / niszczenie wielu serwerów pomostowych, git naprawdę wchodzi w życie dzięki tej metodzie, ponieważ jest rozproszona.

Minusem: kopiowanie / wklejanie folderów, zarządzanie.

Metoda automatyczna

Skonfiguruj skrypt kompilacji (Phing, Ant, Bash, Capistrano itp.) I jakiś niestandardowy kod, który wykona polecenie git add + commit po zastosowaniu aktualizacji i wyśle ​​ją na serwer na żywo. Możesz także oddzielić wtyczki / repozytorium tematów, a następnie skryptu skompilować / przenieść / cokolwiek i / lub użyć Composer w miksie.

Automatyzacja takiego przepływu pracy również jest nieelastyczna i jest tego warta tylko wtedy, gdy widzisz prawdziwą potrzebę zainwestowanego czasu.

Wada: nieelastyczny, tworzenie zajmuje dużo czasu.

Git nie powinien być używany do tworzenia kopii zapasowych i ogólnie rzecz biorąc, nie ma potrzeby klonowania historii zatwierdzeń WP.

Po kilku przemyśleniach, ponieważ zdecydowanie chcę skorzystać z natywnych aktualizacji WP, aby zaoszczędzić sobie pracy, nie ma sensu śledzić niczego, co WP zaktualizuje przy użyciu git. Oto zmieniony pomysł.

root (main project repo)
|-- wordpress (ignored/untracked)
|    |-- wp-content 
|    |    |-- plugins
|    |    |    |-- my-custom-plugin (git repo not connected to parent)
|    |    |    |-- other-plugin (ignored/untracked)
|    |    |    +-- modified-plugin (unignored, added to main project repo)
|    |    |-- themes
|    |    |    |-- my-custom-theme (git repo not connected to parent)
|    |    |    |-- other-theme (ignored/untracked)
|    |    |    +-- modified-theme (unignored, added to main project repo)
|    |    +-- uploads (ignored/untracked)
|    |-- wp-admin
|    +-- wp-includes
|-- wp-config.php (ignored/untracked)
+-- other-files.txt

Oczywiście wtedy tracę możliwość śledzenia, które wtyczki i motywy są częścią projektu z poziomu VCS, ale tak naprawdę potrzebuję tego tylko do tworzenia kopii zapasowych, a mimo to będę używać jakiegoś regularnego systemu tworzenia kopii zapasowych.

Tak więc jedyną rzeczą, której tak naprawdę mi brakuje, jest możliwość łatwego wdrożenia całego stosu na różnych serwerach bez użycia FTP do ręcznego skopiowania całej rzeczy. Czy ktoś ma jakieś przemyślenia na ten temat?

Ok, oglądając rozmowę Mark Jaquith jest tutaj , może jestem na niewłaściwym torze. Oto kolejny dźgnięcie, które śledzi wszystko.

   root (main project repo)
    |-- wordpress (repo as subtree)
    |-- wp-config.php (ignored/untracked)
    |-- wp-content 
    |    |-- plugins
    |    |    |-- my-custom-plugin (repo as subtree)
    |    |    |-- other-plugin-with-git-repo (repo as subtree)
    |    |    +-- plugin-without-git-repo
    |    |-- themes
    |    |    |-- my-custom-theme (repo as subtree)
    |    |    |-- other-theme-with-git-repo (repo as subtree)
    |    |    +-- theme-without-git-repo
    |    +-- uploads (ignored/untracked)
    +-- other-files.txt

Wydaje mi się, że głównym minusem tego jest posiadanie niestandardowego katalogu treści, co w przeszłości powodowało problemy ze źle napisanymi wtyczkami i motywami, które nie mogły znaleźć katalogu treści.