Bagaimana saya harus menyusun proyek situs web WP menggunakan git dan memperbarui dari dashboard WP?

13

Selama berbulan-bulan saya telah mencoba merencanakan struktur proyek yang baik untuk menggunakan kontrol versi git untuk pengembangan situs WordPress yang tidak mengorbankan kemampuan untuk memperbarui inti dan plugin melalui dashboard WP, tidak memerlukan struktur direktori yang tidak konvensional (wp -content di luar folder induk WP) dan itu mudah untuk mengelola dan menggunakan seluruh situs web. Saya sudah membaca tentang submodula, subtree, repositori bersarang, dll, dan saya masih mengalami kesulitan untuk menyatukan semuanya dan memilih strategi yang tepat.

Inilah yang saya pikirkan saat ini, dengan pemikiran saya tentang bagaimana saya akan menangani repositori git dalam tanda kurung.

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

Ini membuat saya memiliki beberapa masalah / pertanyaan;

Pembaruan otomatis; Saya suka fitur pembaruan otomatis yang baru, ini berpotensi menghemat banyak waktu dan upaya untuk menjaga situs saya tetap diperbarui dan aman, tetapi tampaknya ia sangat sulit melacak perubahan kode dengan git. Apakah ada cara untuk melacak perubahan kode saya sementara masih memungkinkan inti WordPress untuk memperbarui otomatis?
Apakah memiliki subtree di bawah repo inti WordPress mencegah saya menggunakan git untuk menggabungkan pembaruan inti baru atau mendorong perubahan saya kembali ke repo inti WordPress (jika saya pernah memutuskan saya ingin menjadi kontributor inti)?
Untuk plugin yang tidak memiliki repo git publik, mengabaikannya sama sekali akan menimbulkan masalah karena tidak dapat dengan cepat mengkloning seluruh situs pada server baru tanpa menyalin file secara manual ke server. Ini juga menyebabkan masalah jika saya ingin membuat perubahan pada kode plugin yang tidak dilacak dan bisa dengan mudah hilang dalam peningkatan plugin.

Jadi, untuk meringkas, apa itu git + WordPress setup yang baik yang menghindari masalah ini? Saya akan menghargai tanggapan Anda tentang struktur proyek yang saya usulkan. Cara apa pun yang Anda dapat membantu saya meningkatkan ini, akan sangat dihargai!

PS, jika ada forum yang lebih baik untuk diskusi ini, tunjukkan saya di sana.

updates automatic-updates git

— Josiah Sprague
sumber

6

Dari sudut pandang saya ada dua masalah dengan rencana Anda - Git dan struktur "konvensional". Jadi pada dasarnya semuanya. :)

Git (dan kontrol versi secara umum) adalah alat yang buruk untuk seluruh tumpukan situs. Pernah ke sana, melakukan itu, sangat menyakitkan.
Apa yang Anda sebut struktur "tidak konvensional" dengan konten yang dipisahkan dari inti telah menjadi pilihan yang sangat konvensional dan kuat untuk situs serius mana pun untuk sementara waktu.
Hampir tidak ada cara turn-key untuk menggabungkan seluruh tumpukan situs dengan pembaruan asli. Itu tidak berjalan dengan baik karena mencoba untuk mencapai tujuan yang berbeda dalam proyek-proyek tingkat yang berbeda (pengembang dalam kontrol vs pengguna akhir dalam kontrol).

Jika Anda bertanya kepada saya, taruhan terbaik untuk seluruh situs WordPress adalah Composer , namun pendapat mungkin waspada. :)

Tentang masalah spesifik Anda:

Seperti di atas - pembaruan asli (lebih otomatis) tidak berfungsi dengan baik dengan tumpukan yang dikontrol dengan ketat.
Inti WordPress tidak dikembangkan di Git dan tidak menerima permintaan tarik, semua kontribusi (sejauh ini) melalui berkas tambalan ke Subversion.
Anda mungkin harus memasukkan plugin tersebut ke dalam repo Anda. Atau pergi dengan pendekatan lain seperti Komposer.

— Jarang
sumber

WordPress tidak menggunakan Git untuk pengembangan, tetapi ada cermin di github.com/WordPress/WordPress (disinkronkan dari SVN setiap 15 menit). Itu tidak dimaksudkan untuk mendorong tambalan dll - untuk itu Anda pasti perlu menggunakan SVN & Trac. Saya tidak tahu apakah ini akan sesuai untuk tujuan OP atau tidak, tetapi demi kelengkapan, itu ada.

— Pat J

@PatJ poin bagus, saya agak menganggap Q berarti memanfaatkan yang itu, tapi mungkin tidak

— Rarst

Poin yang sangat bagus. Saya punya satu set seluruh situs yang diatur menggunakan git dengan submodules dan itu sangat menyebalkan. Saya kira saya bertanya-tanya apakah ada cara yang kurang terkontrol untuk tetap memanfaatkan Git, tetapi juga memanfaatkan pembaruan asli untuk menghemat kerja keras. Saya tim satu orang saat ini, jadi saya pada dasarnya hanya mencoba untuk mengatur situs seefisien mungkin.

— Josiah Sprague

@JosiahSprague jika titik nyeri utama Anda adalah pengaturan awal (daripada pemeliharaan tumpukan jangka panjang) mungkin masuk akal untuk fokus pada hal itu dengan install.phprutinitas khusus atau sesuatu dan menggunakan mekanisme pembaruan normal dari sana. Tumpukan komposer dapat menangani pembaruan dengan sangat baik dalam abstrak, tetapi itu bergantung pada kualitas paket yang Anda gunakan dan hal-hal seperti proxy repositori WP resmi untuk itu belum cukup matang.

— Rarst

3

Anda mungkin kita lihat ini masalah dan ini masalah.

Lihat juga file README di setiap repo juga:

Berdasarkan repo di atas, sebagai contoh lain dari pengaturan Git / WP, saya membuat ini . Saya memilih untuk menggunakan symlinks untuk tema (saya coba menutupi itu di README saya ).

Saya agak di kapal yang sama dengan pembaruan otomatis ... Rencana saya adalah untuk secara manual memperbarui submodule WP ketika pembaruan terjadi. Saya pikir alternatifnya adalah, dalam teori (saya belum menguji diri sendiri), untuk membiarkan pembaruan submodule itu sendiri untuk pembaruan kecil (ada pengaturan WP untuk ini) dan kemudian melakukan gitkekuatan / reset submodule ketika pembaruan besar keluar ( mungkin salah satu jawaban di sini bisa membantu ... tentu saja, saya pikir, seseorang ingin menargetkan tag WP tertentu ketika memperbarui ke rilis besar berikutnya).

Satu hal yang perlu diperhatikan adalah bahwa jika WP melihat .gitdi jalur, ia akan secara otomatis mematikan pembaruan otomatis. Untuk info lebih lanjut, lihat:

Pembaruan Inti Otomatis, pembaruan

Agar Pembaruan Otomatis diaktifkan, ada beberapa persyaratan sederhana:

Jika instalasi menggunakan FTP untuk pembaruan (dan meminta kredensial), pembaruan otomatis dinonaktifkan

Jika pemasangan berjalan sebagai checkout SVN atau GIT, pembaruan otomatis dinonaktifkan

Jika konstanta DISALLOW_FILE_MODSatauAUTOMATIC_UPDATER_DISABLED ditentukan, pembaruan otomatis dinonaktifkan

Jika konstan WP_AUTO_UPDATE_CORE didefinisikan sebagai false, pembaruan otomatis dinonaktifkan

Instalasi WordPress Anda juga harus dapat menghubungi WordPress.org melalui koneksi HTTPS, sehingga instalasi PHP Anda juga perlu OpenSSL diinstal dan berfungsi

Wp-Cron perlu operasional, jika karena alasan tertentu cron gagal berfungsi untuk instalasi Anda, Pembaruan Otomatis juga tidak akan tersedia

Tautan terkait lainnya:

Mei, 2015 pembaruan

Saya membuat repo ini yang merupakan cara cepat bagi saya untuk memulai proyek WordPress. Pendekatan terbaru saya adalah hanya mengontrol versi tema. Dengan kata lain, saya menginstal WP secara lokal (menggunakan setup di repo yang disebutkan sebelumnya) dan pada produksi, kemudian saya memodifikasi file konfigurasi pada setiap sistem dan gitmenarik tema saya untuk mendapatkan situs fungsional.

— mhulse
sumber

2

Jenis pengembangan ini termasuk dalam "tidak begitu mudah dan membutuhkan alur kerja kustom yang mungkin membutuhkan waktu lama untuk puas".

Saya menemukan Subtrees, submodules atau repo bersarang, rasa sakit yang hebat di pantat.

Beberapa pemikiran (melacak semuanya).

Aktifkan pembaruan otomatis dengan git / svn menggunakan:
add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Metode aman melalui komit manual + email:

Anda dapat menggunakan server pementasan dan notifikasi pembaruan email untuk diri sendiri, melakukan pembaruan dan mendorong ke server langsung yang dimatikan pembaruan otomatisnya.

Ini juga memungkinkan Anda untuk menyalin / menempelkan folder untuk repo Anda sendiri sesuka hati, yang sering kali saya lakukan. Ini juga membuatnya mudah untuk mengkloning / menghancurkan beberapa server staging, git benar-benar mulai berlaku dengan metode ini sejak didistribusikan.

The downside: salin / tempelkan folder, manajemen.

Metode otomatis

Siapkan skrip build (Phing, Ant, Bash, Capistrano, dll) dan beberapa kode kustom yang akan melakukan git add + commit ketika pembaruan diterapkan dan mengirimkannya ke server langsung. Anda juga dapat memisahkan plugin / tema repos dan kemudian membuat kompilasi skrip / memindahkan / apa pun itu, dan / atau menggunakan Komposer dalam campuran.

Mengotomatiskan alur kerja seperti ini juga cenderung tidak fleksibel dan hanya layak jika Anda melihat kebutuhan nyata untuk waktu yang diinvestasikan.

The downside: tidak fleksibel, butuh waktu untuk membuat.

Git tidak boleh digunakan untuk cadangan, dan secara umum tidak perlu bagi Anda untuk mengkloning sejarah komit WP.

— Wyck
sumber

0

Setelah beberapa pemikiran, karena saya pasti ingin mengambil keuntungan dari pembaruan WP asli untuk menghemat kerja keras saya, tidak masuk akal untuk melacak apa pun yang WP akan perbarui menggunakan git. Ini ide yang direvisi.

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

Tentu saja, maka saya kehilangan kemampuan untuk melacak plugin dan tema mana yang merupakan bagian dari proyek dari dalam VCS, tetapi saya benar-benar hanya membutuhkan itu untuk keperluan pencadangan, dan saya akan tetap menggunakan semacam sistem cadangan biasa.

Jadi, satu-satunya kekurangan yang saya inginkan adalah kemampuan untuk dengan mudah menyebarkan seluruh tumpukan ke server yang berbeda tanpa menggunakan FTP untuk menyalin semuanya secara manual. Adakah yang punya pemikiran tentang itu?

— Josiah Sprague
sumber

0

Oke, menonton pembicaraan Mark Jaquith di sini , mungkin saya berada di jalur yang salah. Inilah tikaman lain yang melacak segalanya.

   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

Saya kira kelemahan utama dengan ini adalah memiliki direktori konten khusus, yang telah menyebabkan masalah bagi saya di masa lalu dengan plugin dan tema yang ditulis dengan buruk tidak dapat menemukan direktori konten.

— Josiah Sprague
sumber