Làm cách nào để tạo API cho plugin của tôi?

Tôi đã phát triển các plugin cho WordPress, hầu hết các plugin tôi đã phát triển đều sử dụng hai hoặc ba lớp, do đó không lớn như Buddypress hay WooC Commerce.

Tôi đang lên kế hoạch phát triển hai plugin nguồn mở để cung cấp một số loại hệ thống phức tạp (không thể chia sẻ chi tiết vào lúc này nhưng sau này trong quá trình phát triển), nơi các nhà phát triển khác có thể tùy chỉnh các chức năng và hệ thống cho chúng cần giống như Buddypress và WooC Commerce .

Khi tôi kiểm tra các tệp bổ trợ đó và nhận ra rằng họ đã đăng ký các hành động và bộ lọc của riêng mình mà nhà phát triển có thể sửa đổi theo nhu cầu. Tuy nhiên, vấn đề của tôi là không thể hiểu hoàn toàn, làm thế nào tôi nên viết một plugin nơi người khác có thể linh hoạt ghi đè các chức năng cũng như thêm chức năng của họ.

Tôi biết rằng thật khó để đưa ra một câu trả lời chắc chắn, nhưng tôi cần một số hướng dẫn khởi nghiệp để tôi có thể đi đúng hướng. Tôi có cần phải đăng ký hành động và bộ lọc của riêng mình không? Nếu có thì thế nào? Nếu không thì lựa chọn của tôi là gì?

Lời khuyên của bạn sẽ giúp tôi rất nhiều ... Cảm ơn

API bạn cung cấp trong một plugin hoặc một chủ đề phụ thuộc vào logic của mã cụ thể đó. Có lẽ không có hướng dẫn áp dụng cho tất cả các tình huống.

Tôi là người đóng góp cho nhiều plugin với API và những gì tôi đã học được cho đến nay là:

1. Không cung cấp API cho đến khi bạn thực sự biết cách mọi người sử dụng mã của mình.

   Phát hành hai hoặc ba phiên bản đầu tiên mà không có bất kỳ API nào. Không có hành động hoặc bộ lọc tùy chỉnh, không có phương thức hoặc hàm công khai (và không bao giờ có bất kỳ biến toàn cục nào) nếu có thể. Đợi các yêu cầu từ người dùng của bạn, nhưng đừng thêm mã cho đến khi bạn biết cấu trúc mã bên trong của bạn sẽ hoạt động lâu dài.

   Duy trì khả năng tương thích ngược của API là khó . Nó có thể ngăn chặn những cải tiến cần thiết ở những nơi khác. Hãy suy nghĩ về tất cả các biến toàn cầu mà WordPress không thể loại bỏ ngày nay. Đó là một API tồi và chúng tôi đã bị mắc kẹt trong nhiều năm, bởi vì mọi người đã sử dụng nó .

2. Xem xét tách API của bạn khỏi phần còn lại của mã (xem liên kết trước để biết ý tưởng).
   API của bạn sẽ hữu ích không chỉ cho các nhà phát triển bên thứ ba mà còn cho cả bạn. Đừng thêm hạn chế cho chính mình nếu bạn không phải làm vậy.

3. Ăn thức ăn cho chó của riêng bạn.
   Nếu bạn cung cấp các móc tùy chỉnh, sử dụng chúng trong mã của bạn. Điều này sẽ cung cấp cho các nhà phát triển khác các ví dụ hữu ích và bạn có thể thấy các lỗ hổng có thể sớm.
   Nếu lõi WordPress sẽ sử dụng cái gọi là API Cài đặt bên trong, thì hôm nay chúng ta sẽ không gặp rắc rối này. Có lẽ.

4. Dẫn bằng ví dụ.
   Sử dụng các phần hay của API lõi WordPress trong plugin của bạn. Tránh các đối tượng ẩn danh , hằng số, biến toàn cục và bất kỳ loại mã không thể đoán trước .

5. Hãy chắc chắn rằng bạn đang sử dụng một sơ đồ đặt tên nhất quán (không phải là một mớ hỗn độn ) và đặt mọi thứ trong không gian tên của riêng bạn.

6. Viết tài liệu trước. Phát hành API mới (một phần của) sau.
   Tạo các ví dụ hữu ích cho mọi thứ. Bạn sẽ ngạc nhiên khi thấy bạn sẽ tìm thấy bao nhiêu lỗ hổng và dư thừa.

7. Tránh gọi lại địa ngục.
   Cung cấp các công cụ cụ thể để gỡ lỗi API của bạn khi mọi thứ không hoạt động như bình thường (bao gồm cả các tập lệnh và biểu định kiểu không được rút gọn). Tôi đã viết một ví dụ về cách gỡ lỗi AJAX , chỉ để minh họa cách bạn có thể sáng tạo ở đây. Một lần nữa, những công cụ này nên được giải thích trong tài liệu của bạn trước khi bạn phát hành chúng.

8. Một thay thế cho nghịch lý gọi lại của WordPress có thể là mẫu Observer . Điều này sẽ tăng rào cản cho các nhà phát triển bên thứ ba, nhưng nó có thể dẫn đến mã tốt hơn ở cả hai bên.