Git kullanarak ve WP kontrol panelinden güncelleme yaparak bir WP web sitesi projesini nasıl yapılandırmalıyım?

Aylardır WordPress web sitesi geliştirme için WP panosu üzerinden çekirdek ve eklentileri güncelleme yeteneğinden ödün vermeyen, alışılmadık bir dizin yapısı (wp) gerektirmeyen iyi bir proje yapısı planlamaya çalışıyorum. - içerik WP üst klasörü dışında) ve tüm web sitelerini yönetmek ve dağıtmak kolaydır. Alt modülleri, alt ağaçları, iç içe geçmiş depoları, vb.

İşte şu anda düşündüğüm şey, git depolarını parantez içinde nasıl ele alacağımla ilgili düşüncelerimle.

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

Bu bana birkaç sorun / soru bırakıyor;

• Otomatik güncellemeler; Yeni otomatik güncellemeler özelliğini seviyorum, potansiyel olarak sitelerimi güncel ve güvenli tutmak için çok fazla zaman ve çaba tasarrufu sağlayabilir, ancak git ile kod değişikliklerini izlemek için bir anahtar atar gibi görünüyor. WordPress çekirdeğinin otomatik olarak güncellenmesine izin verirken kod değişikliklerimi izlemenin bir yolu var mı?

• WordPress çekirdek repo altında alt ağaçlara sahip olmak, yeni çekirdek güncellemelerde birleştirmek veya değişiklikleri WordPress çekirdek deposuna geri itmek için git kullanmamı engelliyor mu (eğer bir çekirdek katılımcı olmaya karar verirsem)?

• Ortak bir git repo'su olmayan eklentiler için, bunları tamamen yok saymak, dosyaları sunucuya manuel olarak kopyalamadan tüm siteyi yeni bir sunucuda hızlı bir şekilde klonlayamama sorununu yaratır. Bu eklentinin kodunda değişiklik yapmak istiyorsam bu değişiklikler izlenmez ve bir eklenti yükseltmesinde kolayca kaybolabilir.

Özetlemek gerekirse, bu problemlerden kaçınan iyi bir git + WordPress kurulumu nedir? Önerilen proje yapımla ilgili görüşlerinizi takdir ediyorum. Bunu geliştirmeme yardımcı olabilecek herhangi bir yol çok takdir edilecektir!

PS, bu tartışma için daha iyi bir forum varsa, lütfen beni orada işaret et.

Benim bakış açımdan planınızla ilgili iki sorun var: Git ve "geleneksel" yapı. Yani temelde her şey. :)

1. Git (ve genel olarak sürüm kontrolü) tüm site yığınları için zayıf bir araçtır. Orada, bunu yaptım, çok acıttı.

2. Çekirdekten ayrılmış içeriğe sahip "alışılmadık" bir yapı olarak adlandırdığınız şey, bir süredir ciddi bir yer için çok geleneksel ve sağlam bir seçim olmuştur.

3. Tüm site yığınını yerel güncellemelerle birleştirmenin hemen hemen hiçbir anahtar yolu yoktur. Farklı düzeylerdeki projelerde farklı hedeflere ulaşmaya çalıştığı için birlikte iyi gitmiyor (kontroldeki geliştirici ile kontrol altındaki son kullanıcı).

Bana tüm site için en iyi bahsi sorarsanız WordPress yığını şu anda Besteci'dir , ancak görüşler dikkatli olabilir. :)

Özel endişeleriniz hakkında:

1. Yukarıdaki gibi - yerel güncellemeler (daha çok otomatik) sıkı kontrol edilen yığınlarla iyi oynamıyor.

2. WordPress çekirdeği Git'te geliştirilmemiştir ve çekme isteklerini kabul etmemektedir, tüm katkılar (şimdiye kadar) Subversion'a yama dosyaları aracılığıyla yapılmıştır.

3. Muhtemelen bu eklentileri deponuza eklemeniz gerekecektir. Veya Composer gibi başka bir yaklaşımla devam edin.

Bu soruna ve bu soruna bir göz atabilirsiniz .

Ayrıca her repodaki README dosyalarına da göz atın:

• markjaquith / WordPress-İskelet
• davidwinter / wordpress-with-git ile

Yukarıdaki repo dayanarak, bir Git / WP kurulum Başka bir örnek olarak, benim yarattığım bu . (Ben denemek temalar için sembolik kullanmayı tercih benim README o kapağa ).

Yine de otomatik güncellemelerle aynı bottayım ... Planım güncellemeler olduğunda WP alt modülünü manuel olarak güncellemekti. Alternatif olarak, teoride (henüz kendimi test etmedim), alt modülün küçük güncellemeler için kendisini güncellemesine izin vermek (bunun için bir WP ayarı var) ve daha sonra gitbüyük güncellemeler çıktığında alt modülün bir güç / sıfırlaması yapmak ( belki buradaki cevaplardan biri biraz yardımcı olabilir ... tabii ki, bir sonraki büyük sürüme güncelleme yaparken belirli bir WP etiketini hedeflemek isterim).

Dikkat edilmesi gereken bir nokta, WP .gityollarda görürse otomatik güncellemeleri otomatik olarak kapatacağıdır. Daha fazla bilgi için, bkz.

• Otomatik Çekirdek Güncellemeleri, bir güncelleme

Otomatik Güncelleştirmeler'in etkinleştirilebilmesi için birkaç basit gereksinim vardır:

• Yükleme, güncellemeler için FTP kullanıyorsa (ve kimlik bilgileri isteniyorsa), otomatik güncellemeler devre dışı bırakılır
• Kurulum SVN veya GIT kasası olarak çalışıyorsa, otomatik güncellemeler devre dışı bırakılır
• Sabitler DISALLOW_FILE_MODSveya AUTOMATIC_UPDATER_DISABLEDtanımlanmışsa, otomatik güncellemeler devre dışı bırakılır
• Sabit WP_AUTO_UPDATE_COREyanlış olarak tanımlanırsa, otomatik güncellemeler devre dışı bırakılır
• WordPress kurulumunuzun ayrıca HTTPS bağlantıları üzerinden WordPress.org ile iletişim kurabilmesi gerekir, bu nedenle PHP kurulumunuzun da OpenSSLkurulu ve çalışıyor olması gerekir
• Wp-Cron herhangi bir nedenle cron kurulumunuz için çalışmazsa, Otomatik Güncelleştirmeler de kullanılamaz

İlgili diğer bağlantılar:

• WP 3.7 otomatik güncelleme
• GitHub alt modül tema geliştirme?
• Git ile WordPress'i yükleyin ve yönetin

Mayıs 2015 güncellemesi

WordPress projelerine başlamamın hızlı bir yolu olan bu repoyu yarattım . En son yaklaşımım temaları yalnızca sürümle kontrol etmektir. Başka bir deyişle, WP'yi yerel olarak (yukarıda belirtilen repoda kurulumu kullanarak) ve üretime yüklüyorum, sonra her sistemdeki yapılandırma dosyasını değiştiriyorum ve gitişlevsel bir site elde etmek için temalarımı çekiyorum.

Bu tür bir geliştirme, "o kadar kolay değil ve mutlu olmak için uzun zaman alabilecek özel bir iş akışı gerektiriyor".

Subtrees, submodules veya nested repos, kıçta büyük bir acı buluyorum.

Bazı düşünceler (her şeyi takip edin).

1. Git / svn ile otomatik güncellemeleri aşağıdakileri kullanarak etkinleştirin:
   add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Manuel taahhütler + e-posta yoluyla güvenli yöntem:

Bir hazırlama sunucusu ve e-posta güncelleme bildirimlerini kendiniz kullanabilir, güncellemeleri gerçekleştirebilir ve otomatik güncellemeleri kapalı olan canlı sunucuya iletebilirsiniz.

Bu, kendi depolarınız için klasörleri kopyala / yapıştırmanıza da izin verir, bu da genellikle bunu yaparım. Ayrıca, birden çok hazırlama sunucusunu klonlamayı / yok etmeyi kolaylaştırır, git dağıtıldığından bu yöntemle gerçekten yürürlüğe girer.

Dezavantajı: klasörleri kopyalama / yapıştırma, yönetim.

Otomatik yöntem

Bir güncelleme betiği (Phing, Ant, Bash, Capistrano, vb.) Ve bir güncelleme uygulandığında git add + commit yapacak ve canlı sunucuya gönderecek bazı özel kodlar ayarlayın. Ayrıca eklentileri / tema depolarını ayırabilir ve daha sonra komut dosyasının bunları derlemesini / taşımasını / ne olursa olsun birleştirmesini ve / veya karışımda Composer'ı kullanmasını sağlayabilirsiniz.

Bunun gibi bir iş akışını otomatikleştirmek de esnek değildir ve yalnızca yatırılan zaman için gerçek bir ihtiyaç görürseniz buna değerdir.

Dezavantajı: esnek olmayan, oluşturulması zaman alır.

Git yedeklemeler için kullanılmamalıdır ve genel olarak WP'nin taahhüt geçmişini klonlamanıza gerek yoktur.

Biraz daha düşündükten sonra, kendimi ayak işini kurtarmak için yerel WP güncellemelerinden kesinlikle yararlanmak istediğimden, WP'nin git kullanarak güncelleyeceği hiçbir şeyi izlemek mantıklı değil. İşte gözden geçirilmiş bir fikir.

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

Tabii ki, o zaman hangi eklentilerin ve temaların VCS içinden projenin bir parçası olduğunu izleme yeteneğini kaybediyorum, ama gerçekten sadece yedekleme amacıyla buna ihtiyacım var ve yine de bir çeşit düzenli yedekleme sistemi kullanacağım.

Yani, bunun gerçekten istediğim tek şey, her şeyi elle kopyalamak için FTP kullanmadan tüm yığını kolayca farklı sunuculara dağıtma yeteneğidir. Bununla ilgili herhangi bir fikri olan var mı?

Tamam, Mark Jaquith'in burada konuşmasını izlerken , belki de yanlış yoldayım. İşte her şeyi izleyen başka bir bıçak.

   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

Bu ana dezavantajı geçmişte benim için kötü yazılmış eklentileri ve temaları içerik dizini bulmak mümkün olmayan sorunları neden olan bir özel içerik dizini sahip sanırım.