Phần lớn dự án phát triển plugin WordPress đều đi theo một quỹ đạo giống nhau. Ai đó cần một biểu mẫu đặt lịch, một trình nhập dữ liệu hay thêm một trường ở trang thanh toán, lập trình viên viết ra, nó chạy được, rồi mọi người chuyển sang việc khác. Hai năm sau, website mắc kẹt ở một phiên bản WordPress cũ vì không ai dám chắc plugin đó sống sót qua một lần cập nhật, còn người viết nó thì đã nghỉ.

Nguyên nhân hiếm khi là lõi thay đổi quá nhanh. WordPress rất thận trọng khi phá vỡ tương thích, và nhiều plugin viết tốt từ năm năm trước vẫn chạy nguyên vẹn trên WordPress 7.1. Plugin hỏng vì những quyết định đưa ra trong tuần đầu tiên: đặt chức năng vào theme, sửa thẳng tệp lõi thay vì móc hook, cất dữ liệu vào cấu trúc nào gần tay nhất, và không ai thử với bản phát hành ứng viên.

Điều gì giúp một plugin WordPress tùy chỉnh trụ được qua các bản cập nhật lõi? Bốn thứ. Mã nằm trong plugin chứ không nằm trong theme. Nó mở rộng WordPress qua action và filter thay vì sửa tệp lõi. Mỗi mẩu dữ liệu được cất vào cấu trúc hợp với hình dạng của nó. Và trước mỗi bản phát hành, có người đã thử plugin với bản phát hành ứng viên.

Vì sao phát triển plugin WordPress thuộc về plugin chứ không phải theme

Chỗ trú mặc định của mã tùy chỉnh là tệp functions.php của theme, vì nó sẵn có ở đó và sẵn chạy. Nó cũng là tệp biến mất trong lần thiết kế lại kế tiếp.

Theme là phần trình bày. Đổi theme thì mọi việc theme cũ đang làm đều dừng. Kiểu bài viết tùy chỉnh không còn được đăng ký, nội dung nằm lại trong cơ sở dữ liệu mà không có màn hình quản trị lẫn đường dẫn tĩnh. Shortcode hiện ra giữa trang dưới dạng văn bản thô. Đoạn mã phân tích, phần đánh dấu schema và cuộc gọi đêm sang CRM cùng biến mất, và không có lỗi nào được báo.

Quy tắc đủ đơn giản để ghi vào bản yêu cầu. Bất cứ thứ gì vẫn phải đúng sau khi thiết kế lại đều thuộc về plugin: kiểu bài viết và taxonomy tùy chỉnh, mọi tích hợp với bên ngoài, shortcode và block, quy tắc nghiệp vụ, tác vụ định kỳ, và mọi thứ ghi vào cơ sở dữ liệu. Theme giữ lại mẫu giao diện, kiểu dáng và các phần mẫu.

Hóa đơn đến muộn. Đến lần thiết kế lại sau, bạn hoặc trả tiền lần nữa để dựng lại thứ đã có, hoặc bê nguyên tệp functions.php cũ sang. Với một website tích tụ nhiều năm đoạn mã vụn, đó là vài nghìn bảng công việc lẽ ra tránh được, và là lý do báo giá thiết kế lại quay về gấp đôi mức khách hàng dự tính. Theme con thì vẫn là theme.

Mô hình mở rộng và quy tắc duy nhất thực sự quan trọng

WordPress được dựng để thay đổi từ bên ngoài. Cơ chế đó là hook, và tài liệu về hook mô tả chúng là những điểm định sẵn nơi một đoạn mã có thể tương tác hoặc sửa đổi đoạn mã khác. Action kích hoạt tại một thời điểm xác định và cho bạn làm một việc: gửi thông báo sau khi bài đăng lên, hoặc đăng ký một kiểu bài viết. Filter đưa cho bạn một giá trị, chờ bạn đổi nó hoặc để nguyên, rồi chờ bạn trả lại.

Quy tắc rút ra là tuyệt đối. Nếu bạn đang sửa một tệp bên trong wp-admin, wp-includes hay thư mục của plugin khác thì bạn đã thua. Những sửa đổi đó bị xóa ở bản cập nhật kế tiếp, không cảnh báo, không lỗi, và thường không ai phát hiện cho tới khi khách hàng báo có thứ ngừng chạy. Hãy hỏi thẳng lập trình viên điều này trước khi thuê.

Khi hook bạn cần không tồn tại, hãy bọc lấy hành vi thay vì thay thế nó, lùi lên một hook rộng hơn, fork plugin bên thứ ba dưới quyền quản lý phiên bản và ghi lại phần khác biệt, hoặc đề nghị dự án gốc bổ sung hook, vốn là cách phần lớn hook hiện có ra đời.

Đặt tên, tiền tố và một không gian tên rất chật

PHP trong WordPress chạy trong một không gian tên toàn cục duy nhất, dùng chung với lõi, theme đang bật và mọi plugin đang bật khác. Hai plugin cùng khai báo hàm get_settings() không nhường nhau lịch sự: cái thứ hai gây lỗi nghiêm trọng và website trắng xóa.

Tiền tố dài hơn bạn tưởng

Trang thực hành tốt nhất cho plugin trong sổ tay yêu cầu một tiền tố riêng cho mọi thứ truy cập được ở phạm vi toàn cục, tối thiểu bốn ký tự và tốt nhất là năm, tránh các từ tiếng Anh thông dụng và không bao giờ dùng wp_, _ hay chính chữ WordPress. Với hàng chục nghìn plugin đang lưu hành, ba chữ cái đầu tên khách hàng chỉ là tung đồng xu.

Không gian tên và tự động nạp

Cách làm hiện đại giải quyết một nửa vấn đề. Khai báo một không gian tên PHP, mỗi tệp một lớp, và để trình tự động nạp PSR-4 tìm chúng, nhờ vậy không còn câu lệnh require viết tay và không còn cơ hội trùng tên lớp với plugin khác. Nó cũng giúp mã dễ kiểm thử, vì lớp nhận phụ thuộc qua hàm khởi tạo có thể tạo ra mà không cần nạp WordPress.

Tự động nạp không xử lý được việc hai plugin đóng gói hai phiên bản khác nhau của cùng một thư viện. Bên nạp trước thắng. Với mọi thứ đem phân phối, hãy gắn tiền tố cho không gian tên của thư viện bên thứ ba ngay lúc dựng gói.

Những chuỗi mà không gian tên không cứu được

Không gian tên chỉ phủ các ký hiệu PHP. Phần lớn thứ một plugin đăng ký không phải ký hiệu PHP mà là chuỗi nằm trong một sổ đăng ký dùng chung, và chúng vẫn cần quy ước tiền tố kiểu cũ: tên hook, khóa option và transient, khóa post meta, tên kiểu bài viết và taxonomy, thẻ shortcode, tên sự kiện cron, không gian tên REST và tên bảng riêng. Chúng sống trong một không gian phẳng, nơi bản đăng ký sau cùng thắng hoặc hai plugin lặng lẽ dùng chung trạng thái.

Có hai giới hạn nên biết trước khi đặt tên. Khóa kiểu bài viết không được quá 20 ký tự và khóa taxonomy không quá 32, cả hai đều chỉ gồm chữ thường, số, gạch ngang và gạch dưới. Một tiền tố năm ký tự chỉ chừa 15 ký tự cho tên kiểu bài viết, chật hơn nhiều so với cảm giác ban đầu.

Chọn nơi dữ liệu sẽ nằm

Đây là quyết định để lại cái đuôi dài nhất. Chọn sai thì plugin vẫn chạy tốt lúc ra mắt, chậm dần từng tháng khi dữ liệu lớn lên, và đến lúc có người nhận ra thì cách sửa là di trú dữ liệu chứ không còn là chỉnh mã.

Option và transient

Option dành cho thiết lập ở cấp toàn website: vài khóa, giá trị nhỏ, được đọc ở hầu hết yêu cầu. Cái bẫy là tự động nạp, vì mọi option được đánh dấu tự động nạp đều bị lấy ra ở từng yêu cầu một, kể cả các lệnh gọi admin-ajax và REST, bất kể có ai dùng đến hay không.

WordPress 6.6 đã đổi cơ chế này, như bài viết của Make WordPress Core về việc tắt tự động nạp cho option lớn trình bày. Giá trị lưu lại giờ là on, off hoặc auto, và option lớn hơn 150.000 byte mặc định không được tự động nạp, với ngưỡng chỉnh được qua filter wp_max_autoloaded_option_size. Hãy xem đó là trần chứ không phải đích. Transient là option có hạn dùng, và là chỗ đúng cho mọi thứ lấy về từ bên ngoài.

Post meta không phải kho khóa giá trị

Post meta dành cho thuộc tính của một bài viết: phụ đề, giá, mã nhà cung cấp. Nó không phải kho khóa giá trị đa dụng, và lý do nằm ngay trong định nghĩa bảng. Bảng wp_postmeta có bốn cột và ba khóa. Chỉ post_id và 191 ký tự đầu của meta_key được đánh chỉ mục. Cột meta_value là kiểu longtext và không có chỉ mục nào.

Vì vậy truy vấn lọc theo giá trị meta không thể dùng chỉ mục. Mỗi mệnh đề trong một meta query thêm một phép nối, và trên website có 50.000 bài viết, mỗi bài mang 20 dòng meta, bảng đó chứa một triệu dòng. Ba mệnh đề nghĩa là ba phép nối trên một triệu dòng ở mỗi lượt tải trang. Đây là một trong những lý do phổ biến nhất khiến website nhanh ở năm đầu trở nên không dùng nổi ở năm thứ ba, và nó xuất hiện liên tục trong công việc tối ưu WooCommerce.

Kiểu bài viết và taxonomy tùy chỉnh

Kiểu bài viết tùy chỉnh là lựa chọn đúng khi thứ đó là nội dung. Nó cần màn hình danh sách riêng, đường dẫn tĩnh, bản sửa đổi và quy trình biên tập, và hợp lý khi tồn tại như một trang ai đó có thể ghé thăm. Taxonomy tùy chỉnh là lựa chọn đúng khi bạn cần một bộ từ vựng chung để nhóm những thứ đó lại và bộ từ vựng ấy xứng đáng có trang lưu trữ riêng.

Cả hai mang theo bộ máy miễn phí: màn hình quản trị, phân quyền, tìm kiếm, trình soạn thảo block và REST API. Hãy đặt show_in_rest thành true, nếu không trình soạn thảo block sẽ không xử lý kiểu đó, và đăng ký cả hai trên hook init, không bao giờ sớm hơn.

Khi nào bạn thực sự cần bảng riêng

Bảng riêng là lựa chọn đúng khi dữ liệu không phải nội dung: các bản ghi chỉ ghi thêm với khối lượng lớn như nhật ký sự kiện, hàng đợi nhập liệu, lịch sử giá hay vết kiểm toán, hoặc bất cứ thứ gì bạn sẽ lọc và sắp xếp theo một trường không thuộc bảng bài viết. Vượt vài trăm nghìn dòng và được truy vấn theo trường của chính nó, một bảng có chỉ mục đúng vượt post meta vài bậc độ lớn và giữ hiệu năng dự đoán được khi lớn lên.

Cái giá là bạn tự lo mọi thứ: tạo bảng và di trú có đánh phiên bản, dọn dẹp trong uninstall.php, màn hình quản trị riêng, điểm cuối REST và bộ nhớ đệm. Vì vậy câu trả lời trung thực cho phần lớn plugin vẫn là kiểu bài viết tùy chỉnh.

Bảo mật là bốn thói quen, và ba trong số đó bị bỏ qua

Sổ tay bảo mật WordPress nêu nguyên tắc rất thẳng: đừng tin dữ liệu người dùng nhập, đừng tin API bên thứ ba, và đừng tin cả dữ liệu đã nằm sẵn trong cơ sở dữ liệu của bạn. Bốn thói quen gánh gần như toàn bộ rủi ro, và trong những plugin chúng tôi rà soát, chúng bị bỏ qua theo một thứ tự khá cố định. Kiểm tra quyền trước, nonce thứ hai, escape đầu ra thứ ba. Câu lệnh chuẩn bị đứng cuối, vì thiếu nó thì bị bắt ngay khi review.

Kiểm tra quyền

Mọi hàm xử lý có thay đổi thứ gì đó đều phải hỏi người dùng này có được phép hay không, nghĩa là gọi current_user_can() với quyền cụ thể, và kiểm tra bên trong hàm xử lý chứ không chỉ quanh nút bấm gọi nó.

is_admin() không phải phép kiểm tra quyền. Nó cho biết yêu cầu đang ở phía nào của website, và trả về true với bất kỳ subscriber đã đăng nhập nào gọi một điểm cuối admin-ajax. Một action admin_post_ hay wp_ajax_ không kiểm tra quyền thì mọi người dùng đã đăng ký đều chạm tới được, mà với một cửa hàng thì đó là mọi khách từng đặt hàng. Danh sách kiểm tra tăng cường bảo mật WordPress của chúng tôi bàn về các kiểm soát ở cấp website quanh chuyện này.

Nonce

Nonce bảo vệ một biểu mẫu hay một đường dẫn khỏi yêu cầu mà người dùng không chủ ý gửi. Dùng wp_nonce_field() trong biểu mẫu và check_admin_referer() trong hàm xử lý, hoặc check_ajax_referer() cho AJAX. Bất chấp cái tên, chúng không dùng một lần: chúng là các chuỗi băm có hiệu lực trong một khoảng, mặc định một ngày, theo cơ chế hai nhịp khiến tuổi thọ thực nằm giữa 12 và 24 giờ.

Tài liệu về nonce nói rõ không bao giờ được dựa vào chúng để xác thực, phân quyền hay kiểm soát truy cập. Nonce xác lập rằng yêu cầu đến từ biểu mẫu của bạn. Nó không nói gì về việc người đó có được phép làm việc đó hay không.

Làm sạch lúc vào, escape lúc ra

Hãy kiểm định ở nơi có thể, vì kiểm định là cụ thể: một mã bưu chính hoặc khớp mẫu hoặc không. Ở nơi không thể, hãy làm sạch bằng sanitize_text_field(), sanitize_email(), sanitize_key(), absint() hoặc wp_kses_post() tùy theo trường.

Rồi escape ngay tại điểm xuất ra, mọi lần, bằng esc_html(), esc_attr(), esc_url() hoặc wp_kses_post(). Tài liệu về escape yêu cầu làm việc này càng muộn càng tốt, để người review thấy escape và đầu ra trên cùng một dòng.

Escape bị bỏ qua nhiều hơn bất cứ thứ gì khác, vì bỏ qua nó thì chẳng có gì trông sai cả. Trang vẫn hiển thị hoàn hảo cho tới khi ai đó nhét một thẻ script vào một trường.

Câu lệnh chuẩn bị

Mọi truy vấn bạn tự viết đều đi qua $wpdb->prepare(), hàm nhận %d cho số nguyên, %f cho số thực, %s cho chuỗi và %i cho định danh như tên bảng và tên cột. Chỗ giữ chỗ không được đặt trong dấu nháy, dấu phần trăm theo nghĩa đen phải viết hai lần, và ký tự đại diện của LIKE được truyền trong đối số thay thế chứ không gõ thẳng vào truy vấn. Nối một biến vào SQL không phải khác biệt phong cách, nó chính là lỗ hổng.

REST API và trình soạn thảo block

Một plugin viết trong năm nay nên phơi dữ liệu qua REST API và phơi thiết lập qua trình soạn thảo, chứ không phải qua một trang tùy chọn tự dựng.

Route được đăng ký bằng register_rest_route() trên hook rest_api_init. Từ WordPress 5.5, đối số permission_callback là bắt buộc, và bỏ sót nó sẽ kích hoạt một cảnh báo _doing_it_wrong() nêu đích danh route. Một điểm cuối thực sự công khai dùng __return_true, và đó chính là ý đồ thiết kế: mở công khai một route trở thành một dòng mã cố ý thay vì một chỗ quên. Tài liệu về điểm cuối tùy chỉnh cũng nói về lược đồ đối số, nơi đặt các callback làm sạch và kiểm định để dữ liệu xấu không bao giờ tới được hàm xử lý.

Thiết lập được đăng ký bằng register_setting() với show_in_rest đặt thành true. Việc đó đưa chúng lên điểm cuối settings của lõi, nên trình soạn thảo block hay một script bên ngoài có thể đọc và ghi qua một giao diện đã lo sẵn xác thực, phân quyền và kiểm định. Nó xóa bỏ một trang tùy chọn, nonce của trang đó, hàm xử lý biểu mẫu và những lỗi sống trong đó.

Block được đăng ký từ tệp block.json, cách chuẩn được khuyến nghị từ WordPress 5.8. Tài liệu về siêu dữ liệu block nêu lợi ích: tài nguyên khai báo ở đó chỉ nạp trên những trang có block xuất hiện, thay vì nạp toàn website chỉ vì plugin đang bật.

Kỷ luật hiệu năng bên trong plugin

Bốn thứ chiếm phần lớn độ chậm do plugin gây ra mà chúng tôi gặp khi rà soát, và cả bốn đều rẻ khi tránh, đắt khi vá về sau. Thứ nhất là option tự động nạp, vì chúng tính phí ở mọi yêu cầu, mãi mãi.

Thứ hai là các yêu cầu ra ngoài không lưu đệm trong lúc tải trang. Một lệnh wp_remote_get() tới API của nhà cung cấp mà không lưu đệm nghĩa là mọi khách đều phải chờ nhà cung cấp đó. Họ chậm thì website bạn chậm, họ sập thì website bạn treo tới khi hết thời gian chờ. Hãy lưu đệm phản hồi vào một transient, đặt thời gian chờ tường minh, và quyết định trước trang hiển thị gì khi lệnh gọi thất bại.

Thứ ba là truy vấn nằm trong vòng lặp. Gọi get_post_meta() cho từng dòng trong 200 dòng là 200 lượt đi về, trừ khi bộ đệm meta đã được nạp sẵn, và WP_Query nạp giúp bạn nếu bạn để yên cho nó. Cách sửa thường là thôi tắt một thứ gì đó, điều đúng với phần lớn phát hiện trong một đợt rà soát Core Web Vitals.

Thứ tư là việc được làm bên trong yêu cầu trang của một người dùng. WP-Cron không phải cron hệ thống: nó được kích hoạt khi tải trang, nên tác vụ định kỳ chạy bên trong yêu cầu của khách, và trên website vắng thì việc lẽ ra chạy lúc hai giờ không chạy tới khi có người ghé lúc năm giờ. Hãy định nghĩa DISABLE_WP_CRON, chạy wp-cron.php từ một bộ lập lịch hệ thống thật, và giữ tác vụ ngắn gọn, chạy lại nhiều lần vẫn cho kết quả như nhau.

Sống sót qua cập nhật lõi, phần không ai lập ngân sách

Lõi hiếm khi xóa hẳn thứ gì. Hàm bị đánh dấu lỗi thời, vẫn chạy và phát ra một thông báo, đó là lý do chạy môi trường thử nghiệm với WP_DEBUG bật là hệ thống cảnh báo sớm rẻ nhất có thể có. Một thông báo lỗi thời là lời mời có ghi ngày, mời bạn sửa khi việc đó còn rẻ.

Quy trình ngăn được bất ngờ tốn khoảng một giờ mỗi quý. Theo dõi blog phát triển lõi để biết khi nào có bản beta rồi bản phát hành ứng viên. Đọc Field Guide, công bố trong giai đoạn phát hành ứng viên, liệt kê các tính năng hướng lập trình viên và những thay đổi phá vỡ tương thích của bản đó. Rồi đặt bản phát hành ứng viên lên một bản sao thử nghiệm và chạy một kịch bản kiểm tra nhanh đã viết sẵn cho các chức năng thật của plugin.

Phiên bản được hỗ trợ quan trọng ngang với mã. WordPress yêu cầu PHP 7.4 làm mức sàn tuyệt đối và khuyến nghị 8.3 trở lên, cùng với MariaDB 10.11 hoặc MySQL 8.0. Hãy khai báo trung thực Requires PHP và Requires at least trong phần đầu plugin, rồi kiểm thử trên phiên bản thấp nhất bạn đã khai, chứ không phải trên phiên bản chạy trên máy của lập trình viên.

Hãy đánh phiên bản plugin của bạn theo ngữ nghĩa và làm đúng như vậy. Bản vá sửa một thứ, bản phụ thêm hành vi mà không phá gì, bản chính có thể phá nhưng phải nói rõ đã phá gì. Khách hàng bật cập nhật tự động dựa vào chính lời hứa đó.

Phân phối, giấy phép và cách bản cập nhật đến được website

WordPress phát hành theo GPL phiên bản 2 trở lên, và trang giấy phép của wordpress.org nêu quan điểm của dự án rằng plugin và theme là tác phẩm phái sinh nên thừa hưởng giấy phép, đồng thời thừa nhận có vùng xám pháp lý về việc thế nào là phái sinh.

Bạn luôn nhận được mã nguồn, và bạn có thể thuê bất kỳ ai khác sửa nó. Điều GPL không làm là buộc bạn công bố nó, nên một plugin làm riêng cho một doanh nghiệp có thể giữ kín. Nó cũng không ngăn lập trình viên bán chính công việc đó cho người khác. Nếu tính độc quyền quan trọng, đó là điều khoản hợp đồng chứ không phải điều khoản giấy phép.

Nếu plugin lên thư mục công khai, nó phải thỏa mãn bộ quy định của thư mục plugin, gồm 18 điều. Điều đầu tiên đòi giấy phép tương thích GPL cho mọi thứ trong gói, kể cả hình ảnh. Các điều khác loại bỏ phần mềm dùng thử, tức là khóa chức năng sau một khoản thanh toán hay bản nâng cấp, cấm mã bị làm rối, cấm theo dõi người dùng khi chưa có đồng thuận, và cấm thêm liên kết hay dòng ghi công vào website công khai khi chưa được phép.

Nếu nó ở lại dạng riêng tư, cập nhật thành việc của bạn. Hãy đặt header Update URI, thứ sinh ra để ngăn một plugin riêng bị ghi đè bởi một plugin trùng tên trên thư mục, rồi phục vụ bản cập nhật từ điểm cuối của chính bạn. Để việc này đến cuối là cách khách hàng kết thúc bằng việc cập nhật qua FTP.

Một plugin WordPress tùy chỉnh có giá bao nhiêu

Các khoảng giá dưới đây là giá của agency Anh tính bằng GBP, cho công việc giao theo chuẩn mô tả ở đây: có kiểm thử, có tài liệu và có người chịu trách nhiệm sau khi ra mắt. Một lập trình viên đủ năng lực về WordPress và PHP tính khoảng £400 đến £600 mỗi ngày, nên đây là phát biểu về phạm vi chứ không phải về đơn giá.

Một plugin tiện ích nhỏ rơi vào £1.500 đến £3.000. Một việc, vài hook, có lẽ một công tắc thiết lập: xử lý chuyển hướng, thêm một trường vào đơn hàng, xuất dữ liệu hằng đêm sang nhà cung cấp.

Một tích hợp cỡ trung rơi vào £3.000 đến £15.000. Một API bên thứ ba có xác thực, thử lại và xử lý lỗi, một kiểu bài viết tùy chỉnh, các màn hình quản trị và xử lý nền. Đây là cỡ được đặt hàng nhiều nhất và cũng bị ước lượng thiếu nhiều nhất, vì phần tích hợp mất một tuần còn phần xử lý thất bại mất hai tuần.

Một plugin sản phẩm thực thụ rơi vào £20.000 đến £75.000 và cao hơn. Nó có bảng riêng, giao diện trong trình soạn thảo block, hạ tầng cấp phép và cập nhật, hỗ trợ multisite, và gánh nặng hỗ trợ từ ngày phát hành.

Trả ở mức thấp không tự động là sai. Nó sai khi mức giá đó đến từ một phạm vi lặng lẽ loại bỏ những hạng mục bàn giao dưới đây. Hướng dẫn của chúng tôi về đơn giá lập trình viên WordPress và những gì cần hỏi bàn cách đọc một báo giá, còn trang phát triển WordPress trình bày cách chúng tôi xác định phạm vi công việc này.

Những gì phải có trong hạng mục bàn giao

Hãy yêu cầu tất cả những điều này bằng văn bản trước khi bắt đầu, vì mọi thứ đều rẻ khi đưa vào và đắt khi thêm sau. Mã nguồn, trong một kho bạn sở hữu, còn nguyên lịch sử, chứ không phải một tệp nén gửi qua email vào ngày cuối. Kiểm thử đơn vị cho các quy tắc nghiệp vụ và kiểm thử tích hợp cho mọi thứ ghi vào cơ sở dữ liệu hoặc gọi dịch vụ bên ngoài, đó là thứ khiến hai năm sau một người chưa từng tham gia vẫn sửa được an toàn.

Một tệp readme nói plugin làm gì, móc vào đâu, lưu gì và lưu ở đâu, gọi những dịch vụ bên ngoài nào và chuyện gì xảy ra khi từng dịch vụ đó hỏng. Hai trang là đủ, và sự vắng mặt của nó là lý do plugin bị thay thế thay vì được bảo trì. Một tệp uninstall.php xóa option, bảng, sự kiện cron và meta. Và một thỏa thuận hỗ trợ có người phụ trách, bao gồm kiểm thử với từng bản phát hành lõi và sửa những gì đợt kiểm thử đó tìm ra.

Bắt tay vào làm

Mecanik xây dựng plugin ở cả ba cỡ trên, và cũng tiếp nhận plugin do người khác viết, thường là dạng hợp tác hữu ích hơn. Trang lập trình viên WordPress và phát triển phần mềm của chúng tôi giải thích cách chúng tôi xác định phạm vi và bàn giao. Nếu bạn đang có một plugin không ai muốn đụng vào, một đợt rà soát theo các thực hành ở trên mất khoảng một ngày và cho bạn biết nó sửa được hay nên thay.

Câu hỏi thường gặp

Chức năng tùy chỉnh nên đặt trong plugin hay trong theme? Trong plugin, trừ khi nó thuần túy là phần trình bày. Theme bị thay ở lần thiết kế lại kế tiếp và mọi việc nó đang làm đều dừng: kiểu bài viết tùy chỉnh mất màn hình quản trị, shortcode hiện ra dưới dạng văn bản thô, và các tích hợp lặng lẽ ngừng chạy. Bất cứ thứ gì vẫn phải đúng sau khi thiết kế lại đều thuộc về plugin.

Một plugin WordPress tùy chỉnh ở Anh có giá bao nhiêu? Một plugin tiện ích nhỏ thường tốn £1.500 đến £3.000, một tích hợp cỡ trung với API bên thứ ba và màn hình quản trị tốn £3.000 đến £15.000, còn một plugin sản phẩm thực thụ có bảng riêng và hạ tầng cập nhật tốn £20.000 đến £75.000 hoặc hơn. Lập trình viên đủ năng lực cho công việc này tính khoảng £400 đến £600 mỗi ngày.

Có khi nào chấp nhận được việc sửa lõi WordPress hay tệp của plugin khác không? Không. Những sửa đổi đó bị xóa ở bản cập nhật kế tiếp, không báo lỗi và thường không ai phát hiện cho tới khi có thứ ngừng chạy. Hãy dùng action và filter. Nếu hook bạn cần không tồn tại, hãy bọc lấy hành vi, fork plugin dưới quyền quản lý phiên bản, hoặc đề nghị dự án gốc bổ sung hook.

Tôi có sở hữu plugin mà tôi trả tiền thuê người xây dựng không? Bạn sở hữu bản của mình và những gì hợp đồng ghi. GPL cho bạn mã nguồn, quyền sửa đổi và quyền thuê bất kỳ ai khác bảo trì, và không buộc bạn công bố, nên một plugin làm riêng cho một doanh nghiệp có thể giữ kín. Nó không ngăn lập trình viên bán lại chính công việc đó, nên hãy đưa tính độc quyền vào hợp đồng nếu điều đó quan trọng.

Làm sao để plugin không hỏng khi WordPress cập nhật? Hãy thử nó với mọi bản phát hành ứng viên trên một bản sao thử nghiệm trước khi phiên bản đó ra mắt, chạy môi trường thử nghiệm với WP_DEBUG bật để các thông báo lỗi thời lộ ra sớm, và khai báo phiên bản PHP cùng WordPress mà plugin hỗ trợ trong phần đầu tệp. WordPress yêu cầu PHP 7.4 làm mức sàn và khuyến nghị 8.3 trở lên.