Tại sao chúng ta không hack lõi?

Tôi không thể tin rằng câu hỏi này chưa được trả lời trên trang này, nhưng tôi đã không tìm thấy nó khi tôi tìm kiếm, vì vậy ...

Tại sao nó là một ý tưởng tồi tệ chống lại tự nhiên để hack cốt lõi?

• Có thực sự tuyệt vời khi có thể nâng cấp phiên bản cốt lõi của bạn? Hầu hết các trang web của tôi cuối cùng đã hết hạn sử dụng, vì vậy tại sao phải bận tâm?
• Ngay cả khi nó là xấu cho chủ sở hữu trang web, tại sao cộng đồng quan tâm rất nhiều? Tại sao nó được gọi là "giết mèo con"? Đó không phải là hyperbolic?
• Việc hack lõi rất dễ dàng, chúng ta có muốn đi theo con đường dễ dàng hơn đến giải pháp cho vấn đề không?
• Không có vấn đề chỉ có thể được giải quyết bằng cách hack cốt lõi? Sau đó thì sao?

Nói chung, có ba lý do để không thay đổi mã lõi Drupal:

• Thay đổi của bạn sẽ bị mất mỗi khi bạn cập nhật Drupal, nếu bạn không thực hiện bất kỳ bước cần thiết nào. Ngay cả trong trường hợp bạn tạo một bản vá cho phiên bản Drupal hiện tại bạn đang sử dụng, bản vá không thể áp dụng cho phiên bản mới hơn và bạn cũng cần tạo một bản vá cho phiên bản mới.

• Các bản sửa lỗi bảo mật áp dụng cho lõi Drupal như được duy trì trên Drupal.org, nhưng không thể áp dụng cho phiên bản bị hack của bạn. Điều đó có nghĩa là bạn nên kiểm tra phiên bản của mình không bị ảnh hưởng bởi vấn đề bảo mật được nêu ra đối với lõi Drupal.
  Trong trường hợp phiên bản bị hack của bạn giới thiệu một vấn đề bảo mật khác, bạn là người duy nhất bạn có thể tìm thấy nó, vì bạn không có sự hỗ trợ của nhóm bảo mật điều tra về các lỗi bảo mật có trong mã lõi Drupal và bên thứ ba các mô-đun được lưu trữ trên Drupal.org.

• Những thay đổi bạn giới thiệu có thể không tương thích với chính Drupal, nhưng cũng với các mô-đun của bên thứ ba, được yêu cầu để hoạt động với lõi Drupal, không phải với bất kỳ phiên bản hack nào có thể tạo.
  Mỗi khi Drupal giới thiệu một tính năng mới (vẫn xảy ra trong Drupal 7 và trong Drupal 6, mặc dù với tần suất ít hơn) hoặc thay đổi API mới, có khả năng phiên bản bị hack không tương thích với các thay đổi gần đây.

Điều đó nói rằng, có thể tạo ra một phiên bản bị hack, nhưng đó không phải là nhiệm vụ mà một nhà phát triển duy nhất có thể thực hiện, theo cách tương tự Drupal không được duy trì bởi một người. Trên thực tế, Pressflow là phiên bản hack của Drupal đã được tạo ra với hiệu suất trong tâm trí và để giải quyết một số vấn đề về hiệu suất mà một trang web Drupal có thể có.

Không có vấn đề chỉ có thể được giải quyết bằng cách hack cốt lõi? Sau đó thì sao?

Hầu hết thời gian, có thể thay đổi các tính năng / hành vi mà không cần chỉnh sửa mã lõi Drupal. Luôn có một cái móc cho phép thay đổi các tính năng / hành vi mà Drupal có, và đó là phương pháp ưa thích.

Tôi có thể viết một câu trả lời lớn ở đây, nhưng tôi sẽ đăng liên kết này: Không bao giờ hack cốt lõi !

Lý do chính tôi đoán là nếu bạn hack core để làm thứ gì đó bạn cần, và sau đó cập nhật nó ... BANG! Những thay đổi của bạn đã biến mất. Mất đi. Sau đó, bạn có thể thử và khôi phục mã từ VCS của mình, nhưng thấy rằng bạn không thể khôi phục nâng cấp cơ sở dữ liệu từ lõi Drupal - bạn đang xem xét khôi phục tất cả mã từ VCS, sau đó khôi phục cơ sở dữ liệu từ bản sao lưu của bạn. Trong suốt thời gian bạn cố gắng khôi phục mã của mình, có lẽ bạn sẽ nhận thấy rằng bản sao lưu cơ sở dữ liệu cập nhật trước của bạn không thành công và bạn sẽ thề nhiều hơn những gì bạn từng tuyên thệ trước đây.

Ngoài ra - quan trọng nhất - nếu bạn hack core, thì Dries và Webchick đều giết một con mèo con: -o

"Những gì không thể hack cốt lõi làm cho tôi, nhà phát triển?"

• Trang web của bạn có thể được nâng cấp để phát hành bảo mật
• Trang web của bạn có thể được nâng cấp để sửa lỗi khó chịu trong lõi
• Trang web của bạn có thể được nâng cấp để hỗ trợ các mô-đun mới
• Báo cáo lỗi và yêu cầu hỗ trợ của bạn về cốt lõi và đóng góp sẽ có thể được phản hồi
• Bạn muốn sử dụng một CMS được hỗ trợ, đó là lý do tại sao bạn chọn Drupal. Khi bạn hack core, theo lời của webchick , "Nếu bạn hack core, xin chúc mừng! Bạn đã tạo ra một ngã ba Drupal của riêng bạn, và bây giờ bạn và bạn một mình chịu trách nhiệm duy trì nó!"

"Những gì không thể hack cốt lõi làm cho khách hàng của tôi?"

• Trang web của bạn có thể được duy trì bởi người khác sau khi bạn bắn khách hàng của mình / trúng xổ số / bị xe buýt đâm

"Những gì không thể hack cốt lõi làm cho cộng đồng của tôi?"

• Báo cáo lỗi của bạn sẽ thực sự cung cấp thông tin hữu ích cho người duy trì các mô-đun lõi hoặc đóng góp.
• Nếu bạn tìm thấy một lỗi hợp pháp trong lõi phải được vá, thì ranh giới giữa 'hack lõi' và 'trở thành người đóng góp cốt lõi' cũng tốt như chỉ đơn giản là thay đổi các thay đổi của bạn và tải chúng lên như một bản vá vào một vấn đề có liên quan. Bạo chúa! Core tốt hơn cho những nỗ lực của bạn và tên của bạn được liên kết với việc trả lại mã cho cộng đồng.

Mọi người đều là người chiến thắng khi bạn không hack cốt lõi!

Tôi hiện đang làm việc trên một trang web cốt lõi bị hack. Tôi gặp khó khăn khi tìm cách làm một cái gì đó đơn giản như phông chữ đang được thiết lập. Tôi cũng dành vài ngày để sửa một lỗi được giới thiệu bởi hack lõi. Tôi tìm thấy nó bằng cách tìm kiếm một chuỗi trong toàn bộ mã drupal.

Nếu bạn không tuân theo cấu trúc tiêu chuẩn của lập trình trong drupal thì làm sao người khác có thể tìm và chỉnh sửa các thay đổi bạn giới thiệu? Điều này đặc biệt khó khăn vì trong drupal, mỗi tệp php có thể thực hiện một hook. Hãy thử tìm xem cái nào gây ra vấn đề.

"Không có vấn đề nào chỉ có thể được giải quyết bằng cách hack cốt lõi sao? Vậy thì sao?"

Để trả lời câu hỏi này, vâng, đôi khi có những vấn đề bạn phải khắc phục điều đó có nghĩa là bạn phải hack core (hoặc một mô-đun đóng góp).

Trong trường hợp này tôi tin rằng việc hack là được, miễn là bạn đặt nhiều bình luận vào mã bị hack và ghi lại mọi thứ bạn thay đổi.

Ví dụ, đối với bất kỳ thay đổi cốt lõi hoặc đóng góp nào, tôi sẽ tạo một bản vá. Nếu nó là chung chung và hữu ích cho những người khác, tôi gửi nó cho drupal.org trong một vấn đề, nếu không thì đó là để sử dụng cho riêng tôi.

Sau đó tôi cam kết tệp vá để kiểm soát phiên bản của mình cùng với thay đổi mã.

Điều này có nghĩa là tôi có thể nhìn thấy bằng cách tìm kiếm các tệp vá nếu có thứ gì đó đã bị hack.

Ngoài ra, tôi cũng thêm một danh sách các bản hack vào tài liệu dành cho nhà phát triển cho trang web (bạn thực sự nên có tài liệu dành cho nhà phát triển vì lợi ích của những người khác có thể làm việc trên trang web và cho chính bạn khi bạn chắc chắn quên mọi thứ).

Trong tài liệu hack này, tôi liệt kê từng hack với những gì hack thực hiện và tại sao, các mô-đun / tệp bị ảnh hưởng, tên của tệp vá có chứa mã hack và liên kết đến một vấn đề drupal.org liên quan nếu có (hầu như luôn luôn trong trường hợp của tôi là có).

Sau đó, bạn và bất kỳ ai khác làm việc trên trang web trong tương lai đều có một danh sách đầy đủ các bản hack và không phải lo lắng về việc vô tình phá vỡ thứ gì đó bằng một bản cập nhật.

Sau đó, để biết quá trình cập nhật, tôi kiểm tra danh sách các bản hack và xem nhanh các tệp vá trong tất cả các mô-đun tôi đang cập nhật. Nếu có một bản hack và nó có vấn đề về drupal.org, tôi sẽ kiểm tra vấn đề để xem phiên bản mới nhất có bản vá đi kèm hay không, trong trường hợp đó tôi sẽ xóa bản hack bằng bản cập nhật và xóa nó khỏi danh sách hack của mình (thực hiện chắc chắn bằng cách xem các thông báo cam kết của drupal.org rằng những gì đã cam kết giống với phiên bản của bản vá bạn đang sử dụng hoặc ít nhất là về mặt chức năng giống nhau).

Nếu bản vá không được cam kết, tất cả những gì tôi phải làm là cập nhật các mô-đun và áp dụng lại các bản vá. Trong nhiều trường hợp, các bản vá vẫn sẽ được áp dụng sạch sẽ và quá trình này rất dễ dàng, nhưng đôi khi bạn phải lục lại các bản vá cho phiên bản mới và sau đó cam kết phiên bản mới của bản vá vào kho lưu trữ cục bộ của bạn (cùng với việc đăng nó lên bản có liên quan vấn đề drupal.org khi áp dụng).

Một điều nữa tôi muốn làm nếu tôi có các bản vá hoặc bản vá quan trọng hơn tương tác với tính năng cốt lõi của một mô-đun (hoặc chỉ các mô-đun tùy chỉnh mở rộng trên đầu mô-đun drupal.org), là kiểm tra ghi chú phát hành của mô-đun được cập nhật ( điều đó có nghĩa là tất cả các phiên bản ở giữa phiên bản hiện tại của bạn và phiên bản bạn đang cập nhật) và đảm bảo không có gì có khả năng phá vỡ mã của bạn. Lưu ý: Rất nhiều người bảo trì mô-đun tốt trong những ngày này với việc đưa ra các ghi chú phát hành hoàn chỉnh nhưng vẫn còn rất nhiều ghi chú phát hành rác. Trong trường hợp này, trong một số trường hợp, tôi xem qua tất cả các thông báo cam kết kể từ phiên bản hiện tại của tôi (điều này thường chỉ trong trường hợp tôi có mã phức tạp tương tác sâu với mô-đun khác). Ghi chú:

Sau đó, sau khi cập nhật (trên bản sao phát triển của trang web), hãy kiểm tra kỹ lưỡng. Cuối cùng bạn sẽ tìm hiểu ý nghĩa kỹ lưỡng sau khi một vài lỗi xảy ra.

Sau đó, khi nó đã được kiểm tra đầy đủ, hãy nâng cấp trang web trực tiếp hoặc đẩy các bản cập nhật cục bộ của bạn lên hoặc bất kỳ quy trình triển khai nào của bạn có thể.

Lý do tại sao mọi người nói không làm điều đó, ngay cả khi nó dễ dàng hơn: Bởi vì hầu hết mọi người không có hệ thống như tôi đã phác thảo, vì vậy khi đến lúc phải cập nhật hoặc trang web được giao cho người khác làm việc trên đó, nó trở thành một cơn ác mộng và rất nhiều thời gian (đôi khi là một lượng thời gian khổng lồ) phải được dành để giải quyết các lỗi và theo dõi các vụ hack và tìm ra lý do tại sao chúng ở đó, v.v.

Nếu bạn từng kế thừa một trang web như thế bạn sẽ hoàn toàn hiểu :)

Nếu bạn kiếm sống từ việc cài đặt và tạo các trang web Drupal, thì cần phải cập nhật chúng. Nếu hầu hết các trang web của bạn cuối cùng bị lỗi thời, thì bạn không chuyên nghiệp.