Cách đưa plugin lên WordPress.org

[wp102]

Lưu ý: plugin được chấp thuận ở ORG sẽ đồng nghĩa cũng lên được MarketPlace của WordPress COM nhé!

Tại sao nên đưa plugin lên Directory?​

• Dễ cho khách hàng tiện cập nhật khi có các phiên bản mới. Đỡ phải tạo hệ thống cập nhật trung gian.
• Có thể nhận được các feedback lỗi và góp ý để hoàn thiện tính năng. Đỡ phân tích nhu cầu người dùng.
• Có thể thống kê dữ liệu để tham khảo ban đầu cho nhu cầu sử dụng các tính năng plugin được tích hợp. Đỡ phải rơi vào trường hợp nghĩ cái gì cũng code cái đấy rồi chỉ mình dùng.
• Có thể gián tiếp bán các phiên bản premium cho plugin với chi phí 0đ.
• Tối ưu SEO cho WordPress Plugin của bạn trên 1 nền tảng lớn, uy tín và chính thống của WordPress là ORG và COM.

Quá trình cơ bản các bước submit plugin​

Dĩ nhiên đầu tiên là code cái gì, giải quyết việc gì,... thì bạn tự nghiên cứu nhé!

Tips: đơn giản nhất là:

• Xác định tính năng
• Tìm kiếm các plugin đang có.
• Xem dung lượng active.
• Phân tích phản hồi của các khách hàng gặp vấn đề.
• Xác định mình có thể giải quyết và làm tốt hơn không?
• Lặp lại các bước trên để tìm các tính năng liên quan.
• Tổng kết lại => viết thành plugin mới của bạn.

Đừng code xịn quá ngay từ đầu vì lượng code và tính năng rất nhiều sẽ gây khó khăn cho kiểm duyệt viên. Code vừa đủ các tính năng cơ bản trước nhé, lên được thì commit đơn giản hơn nhiều.

- Sau khi lên một vài plugin mình thấy gần như không có quy chuẩn khắt khe nhất định nào để quy định plugin được lên WordPress. Nhưng khi code nên làm tới đâu xem qua tài liệu yêu cầu của họ tới đó nhé! Có gì thì có thể thảo luận, đặt câu hỏi trên group để anh em hỗ trợ.

- Nên code theo cấu trúc Namespace, Class để hạn chế xung đột với plugin khác. Quan điểm của mình cái này là bắt buộc để site cài đặt plugin ổn định và không phát sinh lỗi xung đột.

- Dùng Class và Namespace sẽ giảm thiểu việc tìm kiểm prefix phù hợp cho các hàm bên trong. Tuy nhiên, một số kiểm duyệt viên sẽ đề xuất prefix trong chỉ dẫn. Tốt nhất nên theo chỉ dẫn để họ dễ kiểm duyệt vì “đó là phong cách code của họ”. Cấu trúc prefix nên lấy theo tên plugin, ví dụ "White Label Builder" thì có thể dùng WHLABU_, WHILABBUI_ hạn chế lấy 1 ký tự WLB_ có thể chấp nhận được tuy nhiên khả năng xung đột rất cao.

Tips: sau khi được duyệt bạn có thể điều chỉnh lại sau. Tuy nhiên, nếu bạn không dùng namespace bạn nên giữ nguyên prefix function.
Namespace nên đặt theo cấu trúc yourBrand/PluginName. Tổ hợp này hiện tại khó bị xung đột. Cẩn thận hơn có thể thêm cả prefix của brand.

- Nên comment nếu có logic các thành phần nào đó gây khó hiểu. Ví dụ các tình huống gây dương tính giả khi kiểm tra Wordpress nonce qua class trung gian dùng chung.
Tips: Luôn luôn và tốt nhất nên comment code cho logic phức tạp. Nó dễ cho kiểm duyệt viên hỗ trợ bạn. Nếu xác định dương tính giả nên chủ động hỗ trợ đặt comment ignore lên code đó, chỉ cần ghi chú cho kiểm duyệt viên là được.

- Nếu dùng webpack đóng gói nên đặt webpack config và package json theo plugin. Kèm mô tả thông tin cho kiểm duyệt viên khi gửi.
Đầu file webpack nên comment mô tả hướng dẫn cho người dùng để họ có thể build lại nếu muốn. Thường cũng không ai build lại đâu, ngay cả mình đang dùng plugin free của dev khác mình cũng ít khi build lại. Mục đích của WordPress là để đảm bảo code plugin minh bạch, có thể đọc và an toàn cho người dùng.

Plugin cũng cần đính kèm các tập tin assets và mã có thể đọc. Việc mã hoá hoặc Minify các file này sẽ bị từ chối.

Các tập tin build sẽ được chấp thuận Minify khi có mô tả bên trên và tập tin gốc đi theo.

Tips: tốt nhất không mã hoá vì không cần thiết để tránh bị từ chối. Quan điểm của mình Minify là đủ. Hầu hết các package js như jquery, sortablejs,… gần như chỉ Minify. Hãy nhớ code của chúng ta không có gì là tinh túy đâu )))))

- Kiểm tra và xử lý thật kỹ mọi chỉ dẫn qua Plugin Check trước khi submit. Plugin này hỗ trợ lập trình viên đảm bảo các phương thức tích hợp, cấu trúc tập tin hay nội đi kèm plugin đáp ứng tiêu chuẩn cơ bản của Wordpress core mới nhất. Nó cũng hỗ trợ loại bỏ các rủi ro tiềm ẩn về bảo mật và hiệu suất khi phát triển plugin.

- Nếu không có gì xảy ra plugin sẽ được chấp nhận. Ngược lại, hãy thực hiện điều chỉnh theo chỉ dẫn của kiểm duyệt viên. Nếu có vấn đề không rõ và cần xử lý, hãy điều chỉnh và chủ động phản hồi email nhanh nhất có thể. Điều này sẽ hỗ trợ plugin được chấp thuận nhanh hơn nếu nó không còn vấn đề.

Vì kiểm duyệt viên cũng là anh em lập trình chúng ta thôi, ở lần kiểm tra trước vẫn nhớ phần nào code của bạn. Và họ cũng thấy sự nghiêm túc, mong muốn của bạn về việc đưa plugin lên WordPress.

Nhìn chung mình chưa có plugin nào được chấp thuận ở lần đầu kiểm duyệt. Tuy nhiên, từ lần 2 thì đều được chấp thuận. Góc nhìn cá nhân mình thì đây có lẽ là quy trình tiêu chuẩn của WordPress rồi!?

Thời gian trung bình của mỗi plugin trải qua là:

• Lần 1: sau 3-7 ngày sẽ có chỉ dẫn của kiểm duyệt viên.
• Lần 2: sau khi điều chỉnh theo chỉ dẫn thì cũng 3-7 ngày plugin được chấp nhận nếu đạt yêu cầu.
• Lần 3: mình chưa gặp nên chưa rõ!

Vậy trung bình từ khi submit đến khi lên Wordpress là 3-14 ngày nhé! Điều kiện là plugin trong hàng chờ tầm 300-400 plugin. Mình đoán sẽ lâu hơn nếu danh sách này lớn.

P/s: anh em nào có kinh nghiệm gì chia sẻ bổ sung nhé! Trường hợp gặp vấn đề cứ đặt câu hỏi mình biết gì thì chia sẻ đó!

Theo Cù Kim Ngọc​

 

Hướng dẫn cấu hình WP Rocket Nginx trên FastPanel