get_template_part vs hook hành động trong các chủ đề


15

Dường như với tôi cả hai điều này đều có cơ hội cho người dùng cuối sửa đổi một chủ đề mà không thực sự chỉnh sửa các tệp chủ đề (thông qua các chủ đề con).

Câu hỏi của tôi là, một phương pháp được ưa thích hơn phương pháp khác.

Ví dụ, lấy một chủ đề tôi đang làm việc bây giờ. Tôi đang cố gắng quyết định có nên đi với các phần của mẫu móc không.

<?php get_template_part('before_sitecontainer' ); ?>
<div id="sitecontainer" class="sitecontainer" <?php //closed in footer ?>>

<?php get_template_part( 'before_topcontainer' ); ?>
<div id="topcontainer ">

    <?php get_template_part( 'before_topedge_navigation' ); ?>
    <?php get_template_part( 'topedge_navigation' ); ?>

    <?php get_template_part( 'before_site_header' ); ?>
    <?php get_template_part( 'site_header' ); ?>

    <?php get_template_part( 'before_second_navigation' ); ?>
    <?php get_template_part( 'second_navigation' ); ?>

    <?php get_template_part( 'after_second_navigation' ); ?>

</div><!-- end topcontainer div -->
<?php get_template_part( 'after_topcontainer' ); ?>

Ở trên cho phép người dùng chủ đề thay thế bất kỳ phần nào của mã hiện tại bằng cách chỉ cần tạo một tệp có tên thích hợp trong thư mục chủ đề con của họ cũng như thêm mã mới trước / sau mỗi phần trước đó bằng cùng một phương thức - mẫu trước / sau một phần tệp không tồn tại trong chủ đề gốc và chỉ đơn giản là cho phép chúng chèn mã - và phương pháp này không yêu cầu họ hiểu móc / bộ lọc để thực hiện việc này.

Tất nhiên tôi có thể đạt được điều tương tự bằng cách sử dụng móc và bộ lọc.

Có một lợi thế để sử dụng hook / bộ lọc thay thế? Ghi nhớ đối tượng mục tiêu sẽ sử dụng điều này chắc chắn là không hiểu biết về mã. Tôi có thể cung cấp cho họ các hướng dẫn tương đối cơ bản mà họ có thể làm theo để sử dụng phương thức mẫu nhưng gần như chắc chắn sẽ khiến ma quỷ nhầm lẫn với chúng bằng móc.

Hoặc có những tình huống mà một người sẽ tốt hơn so với người khác trong cùng một chủ đề?

Câu trả lời:


8

Tôi thích hook hơn, vì chúng linh hoạt hơn: bạn có thể móc vào chúng từ functions.phptệp của chủ đề , nhưng cũng từ plugin. Tôi cố gắng đưa càng nhiều logic vào các plugin, để các chủ đề chứa chủ yếu là bố cục.

Nếu bạn sử dụng một hook hành động, vẫn có thể sử dụng get_template_part() trong trình xử lý hook đó . Điều này cung cấp cho bạn tốt nhất của cả hai thế giới. Bạn thậm chí có thể tạo một hook mặc định gọi get_template_part(), để những người không có nhiều kinh nghiệm về mã hóa có thể thêm các tệp bổ sung và những người khác có thể xóa hook này nếu họ không muốn.

Về hiệu suất: get_template_part()sử dụng ( tronglocate_template() ) file_exists()một, hai hoặc bốn lần (tùy thuộc vào cách bạn gọi nó). Nó xuất hiện file_exists()rất nhanhsử dụng bộ nhớ đệm trong PHP và thậm chí có thể trong HĐH. Vì vậy, đó có lẽ không phải là một vấn đề.


Điều đó có ý nghĩa. Một phần của lực đẩy thiết kế của tôi là để loại bỏ sự cần thiết của các plugin trong hầu hết các tình huống sử dụng phổ biến trong khi vẫn duy trì khả năng sử dụng chúng cho những ai muốn. Khách hàng mục tiêu của tôi biết rất ít về WordPress hoặc plugin, không đủ điều kiện để nói các plugin tốt từ xấu (điểm yếu lớn của plugin IMO) và không muốn phải đối phó với việc cập nhật và quản lý nhiều phần mềm. Vì vậy, tôi phải xây dựng rất nhiều chức năng ngay trong các chủ đề để cung cấp những gì họ muốn: đơn giản để sử dụng, đơn giản để duy trì, giải pháp một cửa.
Ashley G

4

Tôi muốn nói rằng sự khác biệt chính là khả năng đọc. Nếu bạn thấy một số phần, được đặt tên tốt, các phần mẫu, bạn có thể nắm bắt những gì đang xảy ra một cách dễ dàng. Nếu bạn chỉ nhìn thấy một cái móc, bạn sẽ cần tìm kiếm trong phần còn lại của chủ đề để thiết lập những gì được gắn vào móc.


1
Vâng, điều đó có ý nghĩa và là một phần của những gì tôi đã cố gắng đạt được với mã ví dụ.
Ashley G

4

Thật dễ dàng để loại bỏ chức năng khỏi hook trong chủ đề con, nhưng khó hơn nhiều để làm cho nó bỏ qua mẫu cha không mong muốn.

Về cơ bản, làm việc với các hook gần với phía PHP hơn và làm việc với các mẫu gần với phía HTML hơn. Tôi sử dụng chủ đề Hybrid, rất có định hướng hook. Đó là một quyền lợi cho đến khi bạn cần thoát khỏi một số mẫu của cha mẹ.

Đối với người dùng không am hiểu về công nghệ cũng không phải là lựa chọn tốt. Tại sao họ cần phải lộn xộn với nội bộ chủ đề như vậy?

PS cũng lưu ý các vấn đề hiệu suất. Thứ có móc xảy ra trong bộ nhớ, thứ có mẫu cần nhiều tra cứu đĩa. Đặc biệt là nếu bạn đang viết một cái gì đó như trong ví dụ của bạn.

PPS không phải sở thích của mọi người ... nhưng thay vì viết chủ đề gốc từ đầu, tại sao không lấy chủ đề gốc hiện có và cung cấp chủ đề con đơn giản cho người dùng?


Bỏ qua một mẫu cha mẹ sẽ dễ như tạo một tệp mẫu trống để thay thế nó tôi nghĩ. Dễ dàng hơn nhiều so với việc làm rối với các hook (và do đó là PHP) cho người dùng không am hiểu về công nghệ. Mặc dù đối với một người có kinh nghiệm móc sẽ dễ dàng hơn nhiều. Về lý do, luôn có những người muốn tùy chỉnh, thậm chí bạn thừa nhận bạn làm. Về lý do tại sao tôi tạo chủ đề, đó là hướng tôi muốn đưa doanh nghiệp của mình vào. Xây dựng xung quanh doanh nghiệp của người khác dường như không phải là bằng chứng tương lai với tôi, bởi vì hầu hết các chủ đề hiện tại của IMO đều không được mong muốn. Tôi nghĩ rằng tôi có thể làm tốt hơn.
Ashley G

Điểm tốt về các vấn đề hiệu suất mặc dù. Mặc dù, vì wordpress được thiết kế để hoạt động với get_template_part, tôi đã nghĩ rằng nó sẽ không phải là một hit hiệu suất. Bất cứ ai có bất kỳ điểm chuẩn về điều này?
Ashley G

Tôi hiểu ý của bạn về việc bỏ qua một phần mẫu. Không dễ như tôi nghĩ
Ashley G

Trên thực tế, nó dễ dàng như việc đặt một tệp mẫu trống vào thư mục con, với điều kiện là nó nằm trong thư mục gốc của thư mục. Điều khó khăn là khi các tệp mẫu nằm trong các thư mục con của thư mục chủ đề cha / con
Ashley G

Trên thực tế, ngay cả các thư mục con cũng không có vấn đề gì. Tôi vừa có thư mục có tên sai (một dấu hiệu chắc chắn tôi đang làm việc quá muộn LOL). Để ghi đè một phần mẫu, nó chỉ yêu cầu một tệp có cùng tên trong cùng một đường dẫn ở trẻ như trong cha mẹ
Ashley G
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.