Làm thế nào để ghi đè chức năng cắm trong chủ đề?

Tất cả các tài liệu tôi đã gặp thảo luận về chức năng ghi đè thông qua plugin của bạn.

Nếu bạn đang phát triển chủ đề thì sao?

Hàm của tôi.php yêu cầu một tệp khác ghi đè get_user_by()hàm, được xác định trong pluggable.php.

Nếu tôi bỏ qua if( function_exists() )cuộc gọi, tôi sẽ gặp lỗi "Không thể xác định lại ...".

Nếu tôi bao gồm if( function exists() )cuộc gọi, thì tôi không gặp lỗi, nhưng tất nhiên chức năng của tôi sẽ bị bỏ qua, vì phiên bản có thể cắm được tồn tại.

Dựa trên bài đăng tuyệt vời của Dominic về thứ tự khởi động WordPress , rõ ràng nó pluggable.phpđược tải trước chủ đề của bạn functions.phpvà vv, để giải thích lỗi.

Vì vậy, câu hỏi là - làm thế nào bạn có thể tận dụng kiến ​​trúc có thể cắm tốt đẹp đó từ bên trong một chủ đề, mà không cần dùng đến các plugin mà sau đó phải được gói hoặc cài đặt với chủ đề?

Ghi chú thêm : Vì vậy, có vẻ như đối số là các chủ đề không nên cố gắng làm những gì plugin làm. Nhưng lập luận đó đã hơn bốn năm tuổi (theo số trac gồm 4 chữ số). Tôi rất muốn nghe từ một số người tuyệt vời cho dù triết lý này vẫn được áp dụng, với cấu trúc liên kết phức tạp của bối cảnh phát triển chủ đề ngày nay. Tôi muốn tin rằng chúng tôi đã phát triển kể từ đó.

Bối cảnh : Tôi đang phát triển giải pháp CMS một lần cho khách hàng, với rất nhiều siêu dữ liệu tùy chỉnh, tùy chỉnh back-end của Quản trị viên, quy trình đăng nhập / xác thực, các công việc. Và tất nhiên, có thành phần thiết kế - đó là nơi phần chủ đề xuất hiện. Thực tế, đây đơn giản là những thành phần không thể tái sử dụng - chúng sẽ không bao giờ áp dụng cho khách hàng khác, chúng sẽ không bao giờ được đặt dưới GPL và mở nguồn, và chúng hầu hết chắc chắn không được phân phối / cài đặt trên các triển khai WordPress khác. Tốt nhất là có một số thực tiễn tốt nhất tôi sẽ tận dụng cho các dự án trong tương lai, nhưng đó sẽ hoàn toàn là một công việc tham khảo / sao chép-dán.

Điều này không giống như trường hợp sử dụng cho các plugin đối với tôi. Chủ đề đã được cài đặt, có thể là chủ đề con của Twenty Eleven, có thể là độc lập, các hàm của nó gọi trong một khối thuyền bao gồm, mỗi xử lý một khía cạnh khác nhau của CMS. Sau đó, các tệp mẫu chủ đề sử dụng 'thẻ mẫu' tùy chỉnh được xác định trong bao gồm. Tôi không muốn có các tệp chủ đề với các phụ thuộc vào một số plugin hoặc khác được kích hoạt, v.v. Điều đó không có nghĩa gì để xây dựng sự phức tạp vào hệ thống. Chắc chắn, tôi có thể đặt nó trong thư mục plugin phải sử dụng, nhưng vẫn cảm thấy như một bản hack - ngay bây giờ, mọi thứ phải làm với các tùy chỉnh được thực hiện cho dự án này đều được chứa trong đó wp-content/themes/my-theme/. Tôi cũng không muốn phải xem xét tìm kiếm nội dung trong một số thư mục bổ trợ.

Đừng hiểu lầm tôi. Tôi yêu các plugin và tôi sử dụng chúng và viết chúng. Và tôi sử dụng các plugin kết hợp với loại phát triển chủ đề tùy biến cao này khi plugin là bên thứ ba và thể hiện các thực tiễn tốt nhất vượt xa những gì tôi có thể đưa ra trong một khung thời gian hợp lý. Nhưng khi tôi cần sửa đổi chức năng cốt lõi cho kịch bản một lần, tôi chuyển sang móc hành động, móc lọc và tôi muốn có thể dựa vào các chức năng có thể cắm cho người dùng và cả mặt xác thực của mọi thứ.

Nếu bạn đang xây dựng điều này cho một khách hàng, bạn hoàn toàn nên tận dụng mu-plugins.

Có rất nhiều thứ trong WordPress mà bạn không thể làm được functions.php. Các chức năng có thể cắm là một trong số đó, nhưng rõ ràng hơn, một số móc (cả hành động và bộ lọc) kích hoạt trước đó functions.php. Trong một số trường hợp, các hook này thậm chí kích hoạt trước các plugin thông thường, sau đó yêu cầu bạn sử dụng mu-pluginshoặc plugin kích hoạt mạng. Trong các trường hợp khác, ngay cả một plugin mu cũng là quá muộn. Có lẽ bạn cần một cái gì đó trong sunrise.php. Hoặc thậm chí một cái gì đó (một hằng số hoặc cách khác) trong wp-config.php.

Tôi thà thêm một số hook vào các hàm có thể cắm, hơn là để dễ ghi đè chúng hơn. Chúng ta sẽ không bao giờ có thêm một chức năng có thể cắm được nữa - chúng có sẵn các móc nối trước và tôi gần như chưa bao giờ thấy tình huống nào có lợi thế cho chúng so với một cái móc kiểu cũ (kiểu mới?).

Tôi vẫn đồng ý, sáu năm sau, với Andy Skelton - "Có nhiều sự khác biệt giữa tệp chức năng của một chủ đề và một plugin. Hãy giữ nguyên như vậy."

Bỏ qua một bên, một sự thay đổi như thế này không bao giờ có thể xảy ra. Nó sẽ phá vỡ rất nhiều thứ. Vô số chủ đề gọi các hàm trong phần thân functions.phpsẽ dẫn đến lỗi nghiêm trọng nếu pluggable.phpchưa được tải - như current_user_can(), hoặc wp_create_nonce(). Tất cả đều thất bại. Và nó cũng sẽ phá vỡ các plugin, thông thường có thể bắt đầu gọi các chức năng này plugins_loaded. (Chỉ cần di chuyển pluggable.phpxuống thấp hơn wp-settings.phpvà tôi đặt cược một nửa lõi sẽ bị hỏng - hoặc ít nhất, tùy biến sẽ.)

Cuối cùng, có một ý tưởng không thể tránh khỏi là một chủ đề có thể bao gồm một tệp riêng như pluggable.phpchúng ta có thể tải ngay khi chúng ta tải plugin và do đó có thể ghi đè các chức năng có thể cắm. Bên cạnh đó là một ý tưởng tồi (xem bốn đoạn đầu của nhận xét này), nó vẫn sẽ không tương thích, bởi vì cho đến khi setup_themehook, người ta có thể ghi đè lên chủ đề nào sẽ được tải bằng cách lọc giá trị của biểu định kiểu và mẫu.

Thật không may, điều này không thể thực hiện được khi WordPress được kiến ​​trúc. Điều tốt là, có vô số cách (tốt hơn) để làm điều đó.

(Ban đầu được đăng tại đây: http://core.trac.wordpress.org/ticket/2479#comment giáp )

Trong bối cảnh của một dự án một lần, việc bỏ mã phải sử dụng vào là hoàn toàn phù hợp mu-plugins. Nếu "có tất cả trong một nơi" là một mối quan tâm, chỉ cần tạo một liên kết tượng trưng trong thư mục chủ đề đến trình đơn mu-pluginsthả xuống, vì vậy nó sẽ hiển thị khi tìm kiếm thư mục chủ đề.

Tôi không thể nghĩ ra một cách để thực hiện điều này, quá sớm trong trình tự tải.

Giải pháp gần gũi nhất sẽ là thêm tùy chỉnh bao gồm wp-config.php(theo mã hoặc yêu cầu người dùng), nhưng so sánh với plugin đi kèm đó có lẽ sẽ có ý nghĩa hơn.