Phương pháp tích hợp dữ liệu Plugin với chủ đề

Tôi muốn có một số ý kiến ​​liên quan đến các thực tiễn tốt nhất để phát triển các plugin WordPress cung cấp tích hợp chủ đề.

Để có ý nghĩa khi tôi đặt câu hỏi này, hãy để tôi bắt đầu với một ví dụ giả thuyết về một kịch bản mà tôi tò mò. Hãy tưởng tượng rằng tôi tạo một plugin có tên "Discography". Discography đăng ký ba loại bài đăng tùy chỉnh: "Ban nhạc", "Album" và "Bài hát". Plugin cũng cung cấp các hộp meta cung cấp chi tiết cho từng loại bài đăng, cũng như các nguyên tắc phân loại tùy chỉnh để sắp xếp từng loại bài đăng. Các loại bài đăng này được gắn với nhau bằng plugin Bài viết 2 . Trong quản trị viên, người dùng có thể thêm các băng tần mới, có thể được liên kết với các album, lần lượt được liên kết với các bản nhạc, tất cả sẽ có nhiều dữ liệu khác được thêm vào chúng thông qua các hộp meta và phân loại.

Bây giờ, tôi không muốn plugin này chỉ cần thiết lập một quản trị viên để người dùng nhập thông tin này; Tôi muốn nó cung cấp một số màn hình mặc định cho dữ liệu. Một người dùng / nhà phát triển nâng cao hơn sẽ ổn khi chỉ có quản trị viên này. Nó sẽ đủ dễ dàng để cô ấy lấy dữ liệu đó và sử dụng trong chủ đề; tuy nhiên, nếu không có một số lượt xem mặc định, plugin này sẽ vô dụng đối với hầu hết người dùng. Trong ví dụ này, bạn có thể hiển thị bất cứ thứ gì như (dấu ngoặc đơn hiển thị các cách thông tin có thể được hiển thị theo thứ tự phân cấp mẫu):

• Các băng tần (đơn tiền tố-band.php, single.php, index.php, shortcode)
• Album (tiền tố đơn-album.php, single.php, index.php, shortcode)
• Các bản nhạc (đơn tiền tố-track.php, single.php, index.php, shortcode)
• Danh sách băng tần (template-band-list.php, page-band-list.php, page- {id} .php, page.php, index.php, shortcode)
• Danh sách album (template-album-list.php, page-album-list.php, page- {id} .php, page.php, index.php, shortcode)
• Dòng thời gian của album (template-album-timeline.php, page-album-timeline.php, page- {id} .php, page.php, index.php, shortcode)

Điều quan trọng là có một số bản trình bày mặc định cho các loại bài đăng này vì các tệp mẫu mặc định sẽ không hiển thị tất cả thông tin cần thiết cho từng loại bài đăng. Chẳng hạn, chủ đề Twenty Eleven, theo mặc định, sẽ chỉ hiển thị tên, danh mục, mô tả và ngày đăng cho một album. Không hữu ích cho một album. Tôi muốn cung cấp một mẫu bài đăng duy nhất trong ban nhạc, ngày phát hành, nhãn đĩa, phiên bản album, bản nhạc, v.v. Là một nhà phát triển plugin tôi sẽ cảm thấy rằng điều đó rất quan trọng để cung cấp. Tôi biết mẫu sẽ không phù hợp với mọi chủ đề, nhưng cần có một số mặc định có thể được tích hợp thêm với chủ đề của người dùng.

Một lần nữa, tôi tò mò về cách tốt nhất để xử lý tình huống này là gì? Tôi nghĩ rằng bạn có thể làm bất kỳ điều sau đây.

Mã ngắn

Shortcodes có thể được sử dụng như một cách rất linh hoạt và thân thiện với người dùng để cho phép những người không phải nhà phát triển thêm một ban nhạc, album, bản nhạc, danh sách ban nhạc, v.v. ở bất cứ đâu trong trang web. Nó sẽ hữu ích cho việc làm nổi bật các băng tần trên các trang cụ thể hoặc tạo các trang riêng biệt cho từng băng tần (không hiệu quả lắm, nhưng một số người dùng tiếp cận mọi thứ theo cách này). Shortcode sẽ tạo HTML, được gắn với tệp CSS được cung cấp sẽ cung cấp chế độ xem mặc định đẹp cho dữ liệu mong muốn. Mọi thứ sẽ được chứa trong các tập tin plugin và không cần phải làm gì với chủ đề.

Tệp mẫu

Các plugin cũng có thể xuất xưởng với các tệp mẫu. Các tệp mẫu có thể được đánh dấu và tạo kiểu cho chế độ xem mặc định đẹp. Bạn có thể cung cấp hướng dẫn cho người dùng của mình để di chuyển các tệp vào thư mục chủ đề để chủ đề sẽ tìm thấy các mẫu phù hợp khi các loại bài đăng được xem. Bạn thậm chí có thể cung cấp một giao diện để cho phép người dùng di chuyển các tệp chỉ bằng một cú nhấp chuột (lưu ý: Tôi sẽ không tạo các tệp trong thư mục chủ đề của người dùng khi kích hoạt vì thêm tệp vào chủ đề của họ mà không khởi tạo nó là xấu) .

Bạn cũng có thể sử dụng các bộ lọc để sử dụng các tệp này mà không cần di chuyển chúng ra khỏi thư mục plugin, giữ mọi thứ độc lập. Tôi đã thấy các bộ lọc "template_include" và "{$ type} _template" được sử dụng cho mục đích này. Trên thực tế, bạn có thể sử dụng các mẫu từ thư mục chủ đề và nếu chúng không có mặt, bạn có thể quay lại các bộ lọc này để cung cấp chế độ xem mặc định.

Câu hỏi

Tôi muốn biết những gì người khác nghĩ là cách thực hành tốt nhất cho những tình huống này, nếu các ý tưởng được trình bày có vấn đề theo bất kỳ cách nào và bất kỳ giải pháp thay thế nào mà tôi không bao gồm.

Cảm ơn bạn!

Tôi không thể trả lời từng Q mà bạn đã hỏi, vì đọc Q đã mất đủ thời gian cho đến nay;), nhưng tôi cố gắng cung cấp cho bạn một số hiểu biết về trải nghiệm cá nhân của tôi với việc phát triển các plugin nguồn mở miễn phí.

1. Không bao giờ làm quá nhiều. Các tính năng là cái chết của mọi plugin. Xây dựng phiên bản cơ bản trước và kiểm tra phản ứng của người dùng của bạn. Nếu plugin của bạn nhận được nhiều sự chú ý, bạn có thể tích hợp các tính năng chủ yếu được yêu cầu.

2. Tránh làm đầy mọi trường hợp sử dụng. Bạn cần duy trì plugin của bạn. WP cung cấp một phiên bản mới mỗi ba tháng. Và đôi khi thật khó để theo dõi với tất cả các plugin của bạn. Để làm ví dụ: Phiên bản mới của API Cài đặt hiện đang được thảo luận trên Trac. Khi điều này kết thúc, có khả năng rất nhiều nhà phát triển plugin hoặc chủ đề cần thay đổi một phần lớn mã và một số người - như tôi - thậm chí đã viết một lớp trừu tượng bên trên API. Vì vậy, bạn cần quay lại, viết lại lớp cơ sở / trừu tượng của bạn và sau đó làm lại mọi thứ gọi là các phần của nó. Tôi hứa rằng đây là rất nhiều công việc. Và thậm chí nhiều hơn nếu nó ràng buộc chặt chẽ với mã của bạn. Khi bạn bắt đầu điền vào nhiều trường hợp sử dụng, thì bạn cũng có rất nhiều tiến hóa mã lõi WP mà bạn cần theo dõi, cũng như bạn có rất nhiều công việc để giữ cho mã của bạn được cập nhật.

3. Không bao giờ thử gói nhiều ví dụ mã (hoặc mẫu) vào plugin hoặc chủ đề của bạn. Nếu bạn muốn nhắm mục tiêu các nhà phát triển và người dùng cuối: Sử dụng blog của bạn để làm tài liệu. Các nhà phát triển ghét những thứ như vậy và người dùng cuối không bao giờ hài lòng (xem: điền vào mọi trường hợp sử dụng).

4. Chia mã của bạn một cách khôn ngoan thành các tệp duy nhất. Quy tắc của ngón tay cái: Một tập tin cho một phần. Ví dụ: Styles.php, scripts.php, taxonomies.php, cpts.php, v.v ... Tải mọi thứ từ lớp "mẹ" (nhà máy) và giữ cho công cụ của bạn "có thể cắm được". Nếu bạn cần viết lại công cụ, bạn sẽ tìm thấy nó dễ dàng. Nếu các nhà phát triển đang tìm kiếm một cái gì đó: họ sẽ tìm thấy nó dễ dàng. Rất nhiều tập tin được đặt tên tốt, không gây hại cho bạn.

5. Nếu bạn có một danh sách các kiểu cơ bản (các lớp), hãy để nó cho người dùng . Cơ hội đơn giản là quá cao, rằng các phong cách từ chủ đề hoặc các plugin khác sẽ chặn các định nghĩa của bạn (cho dù bạn có ném bao nhiêu thông số cụ thể). Chỉ cần cố gắng giải thích nó ở đâu đó với càng ít văn bản càng tốt.

6. Yêu plugin của bạn. Nhưng hãy đi nếu bạn chán. :)

Bây giờ - nói ngắn gọn - một cái gì đó về ý tưởng plugin của bạn một cách chi tiết:

A. Tệp mẫu là xấu. Như tôi đã nói: Tài liệu trên blog của bạn, cung cấp ví dụ đánh dấu và phong cách ở đó. Blog của bạn sẽ thu được lợi nhuận (và bạn cũng vậy nếu bạn có quảng cáo).

B. Mã ngắn là kool. Chúng không gây hại cho ai nếu plugin không còn (trong hầu hết các trường hợp) và sau đó có thể được mở rộng / phát triển thành các nút TinyMCE (mà mọi người yêu thích).

C. Hãy làm rõ rằng plugin của bạn cần một plugin khác. Đặt câu hỏi này và thêm ghi chú vào admin_notices (thông qua register_activation_hook) nếu plugin khác không thoát (liên kết nó trong trường hợp này) hoặc không được kích hoạt (bạn có thể thực hiện điều này cho người dùng khi kích hoạt). Cũng lưu ý rằng plugin này đến từ một nguồn đáng tin cậy và sẽ được duy trì trong những năm tiếp theo.

Lưu ý: Không có gì tôi viết là bất cứ điều gì nhiều hơn ý kiến ​​cá nhân của tôi, điều này phản ánh kinh nghiệm của tôi.

Về mặt nào đó, bạn phải cân bằng giữa việc tạo một plugin hoặc một chủ đề, nếu kịch bản của bạn đòi hỏi nhiều tùy chỉnh / tính năng, thường thì tốt hơn là tạo một chủ đề thay thế. Bằng cách đó, người dùng có thể tùy chỉnh về mặt giao diện luôn dễ dàng hơn sau đó giúp người dùng tùy chỉnh chức năng (bằng cách gây nhiễu mã ngắn ở mọi nơi), bạn có quyền kiểm soát tính năng lớn hơn, nó hoạt động với các plugin khác, v.v.

Một plugin cố gắng tích hợp mạnh mẽ với tất cả các chủ đề đa dạng trên thị trường chắc chắn sẽ gây ra nhiều rắc rối và thực sự rất nhiều công việc cho bạn.

Ví dụ, thay vì tạo một plugin rất tích hợp dựa trên quản lý âm nhạc và đĩa hát, thay vào đó tạo một chủ đề cho mục đích đó, điều này đang trở nên phổ biến hơn cho các thị trường thích hợp đòi hỏi công việc tùy chỉnh. Một ví dụ trong thế giới thực sẽ là một chủ đề dựa trên bất động sản, không có cách nào tôi sử dụng plugin cho việc này vì nó có một bộ tính năng sâu sắc như vậy, thay vào đó nó được tạo ra từ một chủ đề, vì các chủ đề có thể tận dụng Dù sao thì tất cả các tính năng của plugin.

Cũng có khả năng từ góc độ tiếp thị, một chủ đề thích hợp sẽ làm tốt hơn một plugin khi cân bằng các tính năng front-end.

Trang ảo

Một kỹ thuật thứ ba tôi thấy là chỉ định một trang đặc biệt làm trình giữ chỗ cho plugin của bạn và sử dụng bộ lọc 'the_content' để xuất bất cứ thứ gì bạn cần để xuất.

Theo cách này, bạn có thể tạo các mẫu kết hợp với cấu trúc chủ đề, vì bạn không phải xử lý các tiêu đề, thanh bên, chân trang và div trình bao bọc.

Một ví dụ tuyệt vời về điều này có thể được tìm thấy trong plugin bbPress:

http://bbpress.trac.wordpress.org/browser/branches/plugin/bbp-includes/bbp-core-compabilities.php?rev=3434#L931