Tôi nên cấu trúc dự án trang web WP bằng git và cập nhật từ bảng điều khiển WP như thế nào?


13

Trong nhiều tháng, tôi đã cố gắng lên kế hoạch cho một cấu trúc dự án tốt để sử dụng kiểm soát phiên bản git để phát triển trang web WordPress mà không hy sinh khả năng cập nhật lõi và plugin thông qua bảng điều khiển WP, không yêu cầu cấu trúc thư mục độc đáo (wp -content bên ngoài thư mục mẹ WP) và dễ dàng quản lý và triển khai toàn bộ trang web. Tôi đã đọc về các mô hình con, cây con, repos lồng nhau, v.v. và tôi vẫn đang gặp khó khăn trong việc kết hợp tất cả lại với nhau và chọn chiến lược phù hợp.

Đây là những gì tôi đang nghĩ ngay bây giờ, với suy nghĩ của tôi về cách tôi sẽ xử lý repos git trong ngoặc đơn.

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

Điều này để lại cho tôi một số vấn đề / câu hỏi;

  • Cập nhật tự động; Tôi yêu tính năng cập nhật tự động mới, nó có khả năng tiết kiệm rất nhiều thời gian và công sức trong việc giữ cho các trang web của tôi được cập nhật và bảo mật, nhưng có vẻ như nó ném cờ lê trong việc theo dõi thay đổi mã bằng git. Có cách nào để theo dõi các thay đổi mã của tôi trong khi vẫn cho phép lõi WordPress tự động cập nhật không?

  • Việc có các cây con dưới repo lõi WordPress có ngăn tôi sử dụng git để hợp nhất trong các bản cập nhật lõi mới hoặc đẩy các thay đổi của tôi trở lại repo lõi WordPress (nếu tôi quyết định muốn trở thành người đóng góp cốt lõi)?

  • Đối với các plugin không có repo git công khai, việc bỏ qua chúng hoàn toàn sẽ tạo ra vấn đề không thể sao chép nhanh chóng toàn bộ trang web trên máy chủ mới mà không sao chép thủ công các tệp vào máy chủ. Nó cũng gây ra sự cố nếu tôi muốn thay đổi mã của plugin đó, những thay đổi đó không được theo dõi và có thể dễ dàng bị mất trong quá trình nâng cấp plugin.

Vì vậy, để tóm tắt, một thiết lập git + WordPress tốt để tránh những vấn đề này là gì? Tôi sẽ đánh giá cao phản hồi của bạn về cấu trúc dự án đề xuất của tôi. Bất cứ cách nào bạn có thể giúp tôi cải thiện điều này, sẽ được đánh giá cao!

PS, nếu có một diễn đàn tốt hơn cho cuộc thảo luận này, xin vui lòng chỉ cho tôi ở đó.

Câu trả lời:


6

Từ quan điểm của tôi, có hai vấn đề với kế hoạch của bạn - cấu trúc Git và "thông thường". Về cơ bản mọi thứ. :)

  1. Git (và kiểm soát phiên bản nói chung) là một công cụ kém cho toàn bộ ngăn xếp trang web. Ở đó, làm điều đó, nó đau rất nhiều.

  2. Những gì bạn gọi là một cấu trúc "độc đáo" với nội dung được tách ra khỏi cốt lõi đã là một lựa chọn rất thông thường và mạnh mẽ cho bất kỳ trang web nghiêm túc nào trong một thời gian.

  3. Có khá nhiều cách không có chìa khóa trao tay để kết hợp toàn bộ ngăn xếp trang web với các bản cập nhật gốc. Nó chỉ không kết hợp tốt với nhau vì nó cố gắng đạt được các mục tiêu khác nhau trong các dự án ở các cấp độ khác nhau (nhà phát triển trong kiểm soát so với người dùng cuối trong kiểm soát).

Nếu bạn hỏi tôi đặt cược tốt nhất cho toàn bộ trang web WordPress stack hiện là Trình soạn thảo , tuy nhiên ý kiến ​​có thể cảnh giác. :)

Về mối quan tâm cụ thể của bạn:

  1. Như trên - các bản cập nhật gốc (tự động hơn) không chơi tốt với các ngăn xếp được kiểm soát chặt chẽ.

  2. Lõi WordPress không được phát triển trong Git và không chấp nhận các yêu cầu kéo, tất cả các đóng góp (cho đến nay) thông qua các tệp vá cho Subversion.

  3. Bạn có thể sẽ phải cam kết các plugin như vậy vào repo của bạn. Hoặc đi với một cách tiếp cận khác như Nhà soạn nhạc.


WordPress không sử dụng Git để phát triển, nhưng có một tấm gương tại github.com/WordPress/WordPress (được đồng bộ hóa từ SVN cứ sau 15 phút). Nó không có nghĩa là để đẩy các bản vá, v.v. - vì bạn chắc chắn cần phải sử dụng SVN & Trac. Tôi không biết điều này có phù hợp với mục đích của OP hay không, nhưng vì mục đích hoàn chỉnh, nó tồn tại.
Pat J

@PatJ điểm tốt, tôi nghĩ rằng Q có nghĩa là sử dụng cái đó, nhưng có lẽ không
Rarst 31/12/13

Điểm rất tốt. Tôi đã có một ngăn xếp toàn bộ trang web được thiết lập bằng git với các mô đun con và đó là một nỗi đau lớn ở mông. Tôi đoán tôi đang tự hỏi liệu có cách nào ít kiểm soát chặt chẽ hơn để vẫn tận dụng lợi thế của Git hay không, nhưng cũng tận dụng các cập nhật riêng để tiết kiệm cho mình một số công việc. Hiện tại tôi là một nhóm một người, vì vậy về cơ bản tôi chỉ đang cố gắng thiết lập các trang web hiệu quả nhất có thể.
Josiah Sprague

@JosiahSprague nếu điểm đau chính của bạn là thiết lập ban đầu (thay vì bảo trì ngăn xếp dài hạn) có thể có ý nghĩa tập trung vào đó với install.phpthói quen tùy chỉnh hoặc một cái gì đó và sử dụng cơ chế cập nhật bình thường từ đó. Trình soạn thảo có thể xử lý các bản cập nhật rất tốt trong trừu tượng, nhưng nó phụ thuộc vào chất lượng của các gói bạn sử dụng và những thứ như kho lưu trữ WP chính thức cho nó chưa hoàn thiện.
Hiếm

3

Bạn có thể có một cái nhìn tại này vấn đề và này vấn đề.

Đồng thời hãy xem các tệp README trong mỗi repo:

Dựa trên các repos ở trên, như một ví dụ khác về thiết lập Git / WP, tôi đã tạo ra cái này . Tôi đã chọn sử dụng symlink cho các chủ đề (Tôi cố gắng bao quát điều đó trong README của mình ).

Mặc dù vậy, tôi cũng đồng hành với các bản cập nhật tự động ... Kế hoạch của tôi là cập nhật thủ công WP khi cập nhật xảy ra. Tôi nghĩ rằng giải pháp thay thế là, về mặt lý thuyết (tôi vẫn chưa tự kiểm tra), để cho mô hình con tự cập nhật cho các cập nhật nhỏ (có cài đặt WP cho việc này) và sau đó thực hiện gitbắt buộc / thiết lập lại mô hình con khi các cập nhật chính xuất hiện ( có lẽ một trong những câu trả lời ở đây có thể là một số trợ giúp ... tất nhiên, tôi nghĩ, người ta sẽ muốn nhắm mục tiêu một thẻ WP cụ thể khi cập nhật lên bản phát hành chính tiếp theo).

Một điều cần lưu ý là nếu WP nhìn thấy .gittrong (các) đường dẫn, nó sẽ tự động tắt cập nhật tự động. Để biết thêm thông tin, xem:

Để Tự động cập nhật được bật, có một vài yêu cầu đơn giản:

  • Nếu cài đặt sử dụng FTP để cập nhật (và lời nhắc cho thông tin đăng nhập), cập nhật tự động sẽ bị tắt
  • Nếu cài đặt đang chạy dưới dạng thanh toán SVN hoặc GIT, cập nhật tự động sẽ bị tắt
  • Nếu các hằng số DISALLOW_FILE_MODShoặc AUTOMATIC_UPDATER_DISABLEDđược xác định, cập nhật tự động bị tắt
  • Nếu hằng số WP_AUTO_UPDATE_COREđược định nghĩa là sai, cập nhật tự động bị tắt
  • Cài đặt WordPress của bạn cũng cần có khả năng liên hệ với WordPress.org qua các kết nối HTTPS, vì vậy cài đặt PHP của bạn cũng cần OpenSSLđược cài đặt và hoạt động
  • Wp-Cron cần phải hoạt động, nếu vì lý do nào đó, cron không hoạt động cho cài đặt của bạn, Cập nhật tự động cũng sẽ không khả dụng

Các liên kết khác có liên quan:

Cập nhật tháng 5 năm 2015

Tôi đã tạo repo này , đây là cách nhanh chóng để tôi bắt đầu các dự án WordPress. Cách tiếp cận mới nhất của tôi là chỉ phiên bản kiểm soát (các) chủ đề. Nói cách khác, tôi cài đặt WP cục bộ (sử dụng thiết lập trong repo đã nói ở trên) và khi sản xuất, sau đó tôi sửa đổi tệp cấu hình trên mỗi hệ thống và gitkéo (các) chủ đề của tôi để có được một trang web chức năng.


2

Kiểu phát triển này rơi vào "không dễ dàng và đòi hỏi một quy trình công việc tùy chỉnh có thể mất nhiều thời gian để hài lòng".

Tôi tìm thấy Subtrees, subodules hoặc repos lồng nhau, một nỗi đau rất lớn ở mông.

Một số suy nghĩ (theo dõi mọi thứ).

  1. Cho phép cập nhật tự động với git / svn bằng cách sử dụng:
    add_filter( 'auto_upgrade_ignore_checkout_status', '__return_true' );

Phương pháp an toàn thông qua cam kết thủ công + email:

Bạn có thể sử dụng máy chủ dàn và thông báo cập nhật email cho chính mình, cam kết các bản cập nhật và đẩy đến máy chủ trực tiếp có tự động cập nhật.

Điều này cũng cho phép bạn sao chép / dán các thư mục cho các repos của riêng bạn theo ý muốn, thường là cách tôi làm. Nó cũng giúp dễ dàng sao chép / phá hủy nhiều máy chủ dàn, git thực sự có hiệu lực với phương thức này vì nó được phân phối.

Nhược điểm: sao chép / dán thư mục, quản lý.

Phương pháp tự động

Thiết lập tập lệnh xây dựng (Phing, Ant, Bash, Capistrano, v.v.) và một số mã tùy chỉnh sẽ thực hiện git add + commit khi cập nhật được áp dụng và gửi nó đến máy chủ trực tiếp. Bạn cũng có thể tách riêng các plugin / repos chủ đề và sau đó biên dịch tập lệnh / di chuyển / bất cứ thứ gì chúng và / hoặc sử dụng Trình soạn thảo trong hỗn hợp.

Tự động hóa một quy trình làm việc như thế này cũng có xu hướng không linh hoạt và chỉ có giá trị nếu bạn thấy một nhu cầu thực sự cho thời gian đầu tư.

Nhược điểm: không linh hoạt, mất thời gian để tạo.

Git không nên được sử dụng để sao lưu và nói chung, bạn không cần phải sao chép lịch sử cam kết của WP.


0

Sau khi suy nghĩ thêm, vì tôi chắc chắn muốn tận dụng các bản cập nhật WP gốc để tự cứu mình, nên việc theo dõi bất cứ thứ gì mà WP sẽ cập nhật bằng git là điều vô nghĩa. Đây là một ý tưởng sửa đổi.

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

Tất nhiên, sau đó tôi mất khả năng theo dõi các plugin và chủ đề nào là một phần của dự án từ bên trong VCS, nhưng tôi thực sự chỉ cần điều đó cho mục đích sao lưu và dù sao tôi cũng sẽ sử dụng một loại hệ thống sao lưu thông thường.

Vì vậy, điều duy nhất thực sự thiếu mà tôi muốn là khả năng dễ dàng triển khai toàn bộ ngăn xếp đến các máy chủ khác nhau mà không cần sử dụng FTP để sao chép toàn bộ nội dung. Bất cứ ai có bất kỳ suy nghĩ về điều đó?


0

Ok, xem cuộc nói chuyện của Mark Jaquith ở đây , có lẽ tôi đang đi sai đường. Đây là một cú đâm khác vào đó để theo dõi mọi thứ.

   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

Tôi đoán nhược điểm chính của việc này là có một thư mục nội dung tùy chỉnh, điều này đã gây ra vấn đề cho tôi trong quá khứ với các plugin và chủ đề được viết kém không thể tìm thấy thư mục nội dung.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.